Remote consultation doctor resource dynamic scheduling method and system for medical association two-way referral

Abstract

The application discloses a remote consultation doctor resource dynamic scheduling method and system for medical association two-way referral, relates to the technical field of medical resource scheduling, and discloses the remote consultation doctor resource dynamic scheduling method and system for medical association two-way referral. The disclosed remote consultation doctor resource dynamic scheduling method and system for medical association two-way referral determine a consultation period by acquiring current state data and historical behavior data of registered doctors in the medical association, analyze referral intention information in a consultation request, determine main and alternative doctors in combination with scheduling adaptation, and realize seamless switching in an abnormal state, effectively solve the problems of doctor state misjudgment, fragmented referral process and consultation interruption, and can improve the resource coordination efficiency of the medical association and the patient referral experience.

Description

Technical Field

[0001] This application relates to the field of medical resource allocation technology, and in particular to a method and system for dynamic allocation of remote consultation physician resources for two-way referral within medical consortia. Background Technology

[0002] Within the medical consortium framework, the remote consultation platform serves as a core hub connecting primary healthcare institutions with experts at higher-level hospitals, undertaking the crucial function of optimizing medical resource allocation. Current mainstream scheduling mechanisms employ a linear processing flow, instantly matching and assigning patients based on departmental needs in the consultation request and the status tagged in the doctor's information system. This model has significant technical flaws: First, doctor status identification relies solely on static system-level identifiers, such as equating terminal login status with actual work readiness, failing to capture the cognitive transition process after completing preceding tasks. In clinical practice, after completing high-intensity work such as surgery or ward rounds, doctors typically need to undergo cognitive adjustment phases such as mental processing and medical record archiving. Although the system displays "idle" during this phase, doctors cannot immediately begin consultation preparation, leading to unexpectedly prolonged patient waiting times. Second, consultation scheduling and two-way referral processes are clearly disconnected; the scheduling process does not consider patients' potential upward referral needs. When a referral decision is made during a consultation, it often faces practical constraints such as bed shortages in the receiving department and overloaded attending physicians. This forces the repeated transmission of patient information and the re-coordination of resources, resulting in interruptions in the referral path and gaps in medical information. Furthermore, existing platforms lack proactive mechanisms to handle anomalies during the consultation process. When the attending physician's terminal encounters network fluctuations or equipment failures, the system can only passively trigger a rescheduling process. Issues such as audio and video interruptions and loss of diagnostic context during this process not only affect the continuity of the consultation but may also delay the treatment of critically ill patients. These technical bottlenecks collectively lead to low efficiency in resource collaboration within medical alliances and a compromised patient referral experience. There is an urgent need to establish a dynamic scheduling framework that integrates physician real-time readiness perception, pre-analysis of referral intentions, and pre-configuration capabilities for abnormal continuation.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method and system for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia, aiming to improve the efficiency of resource collaboration within medical consortia.

[0005] To achieve the above objectives, this application proposes a method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia. The method includes: Obtain the current status data and historical behavior data of registered doctors within the medical consortium, and determine the consultation time periods for each doctor within the future time window based on the current status data and historical behavior data; Receive a remote consultation request, obtain the patient's diagnosis and treatment data contained in the consultation request, extract the request features from the consultation request, parse the information attached to the consultation request, and obtain referral intention information reflecting the patient's needs for subsequent diagnosis and treatment pathways; Candidate doctors are selected based on the request features. The scheduling suitability of each candidate doctor is calculated by combining the available consultation time slots and the referral intention information of each candidate doctor. Based on the scheduling suitability, the primary doctor and at least one alternative doctor are determined. The patient's medical data is sent to the primary physician to prepare for the consultation, and preset data generated based on the patient's medical data is sent to the alternative physicians to put them into a pre-preparation state. During the consultation, the consultation status of the primary physician is continuously monitored. When it is detected that the consultation status of the primary physician does not meet the preset conditions, the current consultation is switched to the alternative physician who is in the pre-preparation state. The actual execution data after the consultation is completed is obtained, and the actual execution data is used to make feedback adjustments to the process of determining the consultation time period, the process of parsing the referral intention information, and the process of calculating the scheduling adaptability.

[0006] In one embodiment, the current status data includes information on the tasks currently being performed by the doctor, terminal network quality parameters, and terminal device status parameters; the historical behavior data includes records of doctor task switching time, consultation response delay, historical network quality records of the doctor's terminal, and historical device operating status records. Determine the available consultation periods for each doctor within the future time window, including: Based on the currently executing task information and the preset historical average processing time for each task type, the estimated completion time of the current task is calculated. Based on the task switching time record, the time from when the doctor completes the current task to when the cognitive state is switched is determined, which is taken as the cognitive transition time. The sum of the expected completion time and the cognitive transition duration is taken as the doctor's initial available time; Starting from the initial available time, exclude the unavailable task time slots already scheduled in the doctor's subsequent schedule to obtain the initial available consultation time slots; Using the terminal network quality parameters and terminal device status parameters, the availability of the initial consultation period is verified. Sub-periods that do not meet the minimum consultation requirements due to network or device conditions are removed from the initial consultation period, resulting in the consultation period after filtering by network and device conditions.

[0007] In one embodiment, the availability of the initial consultation period is verified using the terminal network quality parameters and terminal device status parameters, including: Obtain the network quality change trend curve of the doctor's terminal within a historical time period and the device operation status change trend curve within the historical time period; Based on the network quality change trend curve, the predicted network quality values ​​at each time point within the initial consultation period are obtained. Based on the trend curve of the equipment's operating status change, the predicted values ​​of the equipment status at each time point within the initial consultation period are obtained. The sub-periods in which the predicted network quality value does not meet the minimum network requirements for remote consultation, and the sub-periods in which the predicted device status value does not meet the minimum device requirements for remote consultation, are removed from the initial consultation-available period to obtain the consultation-available period.

[0008] In one embodiment, the request features include the required specialty, estimated consultation duration, and a description of the patient's condition; parsing the information attached to the consultation request to obtain referral intention information reflecting the patient's subsequent treatment pathway needs includes: Extract key treatment description fields from the referral application form and medical record text attached to the consultation request; Semantic analysis was performed on the key diagnosis and treatment description fields to identify the referral tendency expressions contained therein; The referral tendency expression is vectorized to obtain the semantic vector corresponding to the referral tendency expression of the current request; Based on the aforementioned referral propensity expression, an initial probability propensity value is generated indicating whether the patient needs to be referred to a higher-level hospital; Obtain the actual referral execution records of cases in the medical consortium whose semantic vectors corresponding to the referral tendency expression of historical cases are less than a preset distance threshold from the semantic vectors corresponding to the referral tendency expression of the current request. The initial probability propensity value is corrected using the actual referral execution records to obtain the corrected probability propensity value; And based on the receiving department requirements and monitoring conditions contained in the key diagnosis and treatment description fields, generate a predicted set of receiving departments and the required supporting conditions; The corrected probability tendency value, the predicted set of receiving departments, and the required supporting conditions are used as the referral intention information.

[0009] In one embodiment, calculating the scheduling fit of each candidate doctor includes: Obtain the network quality parameters and device status parameters of each candidate doctor, generate a network quality adaptation score based on the network quality parameters, and generate a device status adaptation score based on the device status parameters; Determine whether the corrected probability tendency value in the referral intention information exceeds a preset threshold; If the preset threshold is exceeded, the real-time resource status of the candidate doctor's department and the candidate doctor's own treatment load are obtained to generate a referral and connection matching score. If the preset threshold is not exceeded, the referral and connection adaptation score will be set to the default value. Calculate the difference between the duration of the available consultation time slot for the candidate doctor and the estimated consultation time, and generate a time slot matching score based on the duration difference; Obtain the pre-defined specialty description text for each candidate doctor, calculate the semantic similarity between the specialty description text and the disease description information, and generate a specialty matching score based on the semantic similarity. The scheduling fit score is obtained by weighted summing of the network quality fit score, the device status fit score, the time period fit score, the specialty fit score, and the referral and connection fit score.

[0010] In one embodiment, the real-time resource status of the candidate doctor's department and the candidate doctor's own patient load are obtained to generate a referral and continuation adaptation score, including: The system allows users to query the current number of available beds in the department of a candidate doctor through the hospital information system interface, as well as the number of beds expected to be available within a specified future time period. Query the number of patient admissions that a candidate doctor has confirmed for a specified period of time in the future; Based on the number of admission tasks and the historical average processing time of each admission task, the expected workload saturation of the candidate doctor in the specified future time period is calculated. Based on the current number of available beds, the expected number of beds to be freed up, and the expected workload, a comprehensive assessment is made as to whether the candidate doctor has the bed and energy conditions to receive referred patients. When both bed availability and capacity are met, the maximum referral and continuation suitability score is given. If either condition is not met, the referral and continuation suitability score is reduced according to the degree of non-compliance.

[0011] In one embodiment, sending preset data generated based on the patient's medical data to the candidate doctor to put the candidate doctor into a pre-preparation state includes: Send a pre-set data packet containing patient medical record summaries and medical image thumbnails to the alternative doctor's terminal, so that the alternative doctor's terminal can complete data caching in the background; A low-power signaling keep-alive channel is established between the candidate doctor terminal and the consultation server to keep the candidate doctor terminal in an active link state; A standby status prompt is displayed on the terminal interface of the alternative doctor. The display area of ​​the standby status prompt does not overlap with the display area of ​​the original work task operation interface of the alternative doctor's terminal, and the alternative doctor is allowed to operate its original work task. In the pre-preparation state, the audio and video acquisition module of the alternative doctor terminal is not turned on, and no audio and video data streams are sent to the consultation room.

[0012] In one embodiment, the continuous monitoring of the consultation status of the selected doctor includes: continuously collecting network latency, packet loss rate, and available bandwidth of the selected doctor's terminal to generate a network quality score; continuously collecting the working status of the audio and video acquisition device and the processing resource utilization rate of the selected doctor's terminal to generate a device operation score; and weighting and summing the network quality score and the device operation score to obtain a comprehensive consultation status value. When it is detected that the consultation status of the primary physician does not meet the preset conditions, the current consultation is switched to the alternative physician who is in the pre-ready state, including: When the comprehensive consultation status value is lower than the preset safety threshold, the current network quality score and device operation score of the candidate doctor terminal are obtained through the low-power signaling keep-alive channel. When the current network quality score and device operation score of the alternative doctor terminal meet the preset connection conditions, an activation command is sent through the low-power signaling keep-alive channel to open the audio and video channel of the alternative doctor terminal and switch the consultation data stream from the primary doctor terminal to the alternative doctor terminal. Before the switch is completed, a switch prompt message is sent to the primary doctor's terminal.

[0013] In one embodiment, the method further includes: During the consultation, the consultation audio is transcribed in real time, and semantic recognition is performed on the transcribed text. When a semantic fragment representing a referral decision is identified from the transcribed text, the system queries whether the primary physician is qualified to admit the patient. If the primary physician does not meet the acceptance criteria, then check whether the alternative physicians meet the acceptance criteria. If the candidate doctor also does not meet the receiving conditions, then a supplementary doctor who meets the receiving conditions will be selected from the registered doctors in the medical alliance, and a receiving preparation list containing the patient's diagnosis and treatment data and referral suggestions will be sent to the supplementary doctor's terminal. Before the consultation ends, a referral guidance plan containing recommended recipient information is generated based on the query results of the receiving criteria.

[0014] Furthermore, to achieve the above objectives, this application also proposes a dynamic scheduling system for remote consultation physician resources for two-way referrals within medical consortia. The system includes a memory, a processor, and a dynamic scheduling program for remote consultation physician resources for two-way referrals within medical consortia, stored in the memory and executable on the processor. This program is configured to implement the steps of the aforementioned dynamic scheduling method for remote consultation physician resources for two-way referrals within medical consortia.

[0015] The proposed method and system for dynamic scheduling of remote consultation physician resources for two-way referrals within medical consortia determines available consultation time slots by acquiring current status data and historical behavior data of registered physicians within the medical consortium, analyzes the referral intent information in the consultation request, determines the primary and backup physicians based on scheduling suitability, and achieves seamless switching in abnormal states. This effectively solves the problems of physician status misjudgment, fragmented referral processes, and consultation interruptions, and can improve the efficiency of resource collaboration within medical consortia and the patient referral experience. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the method for dynamic scheduling of remote consultation physician resources for two-way referral within a medical consortium, as described in this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of this application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be understood that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0022] In existing technologies, remote consultation doctor scheduling relies solely on the doctor's online status, failing to perceive the doctor's actual working context. This results in long doctor readiness times and extended patient waiting times. Furthermore, the consultation scheduling is disconnected from the two-way referral process, failing to consider patient referral needs in advance, leading to poor coordination between consultation and admission, and low referral efficiency. Moreover, when a consulting doctor's consultation is interrupted due to network or equipment failure, the lack of an effective pre-set continuation mechanism exacerbates the impact of consultation interruptions.

[0023] Based on this, this application provides a method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia, referring to... Figure 1 The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia includes steps S100 to S600, wherein: Step S100: Obtain the current status data and historical behavior data of registered doctors within the medical consortium; based on the current status data and historical behavior data, determine the consultation time period for each doctor within the future time window. Step S200: Receive a remote consultation request, obtain the patient's medical data contained in the consultation request, extract the request features from the consultation request, parse the information attached to the consultation request, and obtain referral intention information reflecting the patient's subsequent medical needs. Step S300: Select candidate doctors based on the request features, calculate the scheduling suitability of each candidate doctor by combining the available consultation time slots and the referral intention information of each candidate doctor, and determine the primary doctor and at least one alternative doctor based on the scheduling suitability. Step S400: Send the patient's medical data to the primary physician to prepare for consultation, and send preset data generated based on the patient's medical data to the alternative physician to put the alternative physician into a pre-preparation state. Step S500: During the consultation process, the consultation status of the primary physician is continuously monitored. When it is detected that the consultation status of the primary physician does not meet the preset conditions, the current consultation is switched to the alternative physician who is in the pre-preparation state. Step S600: Obtain the actual execution data after the consultation ends, and use the actual execution data to make feedback adjustments to the process of determining the consultation time period, the process of parsing the referral intention information, and the process of calculating the scheduling adaptability.

[0024] In this embodiment, two-way referral within the medical consortium refers to the bidirectional flow of patients between different levels of medical institutions within the consortium, achieving optimized allocation of medical resources and hierarchical diagnosis and treatment. Remote consultation refers to the use of information technology to enable medical personnel in different geographical locations to consult on a patient's condition and provide diagnostic and treatment suggestions. Current status data refers to the doctor's real-time work status and environmental parameters at a given moment, such as the tasks the doctor is currently handling, the network connection quality of their terminal device, and the device's operational status. Historical behavioral data refers to the doctor's work patterns and system interaction records over a past period, such as the time required for the doctor to complete tasks, the delay in responding to consultation requests, and the historical network quality and operational status of their terminal device. Available consultation time periods refer to the time periods within the future when the doctor is actually capable of conducting remote consultations, taking into account their work schedule, cognitive transition needs, and terminal device and network conditions.

[0025] In this embodiment, request features refer to key information extracted from the remote consultation request that describes the patient's condition and consultation needs, such as the specialist the patient requires, the estimated consultation duration, and a detailed description of the condition. Referral intention information refers to information obtained by parsing the information accompanying the consultation request, reflecting the patient's potential need for further referral to a higher-level hospital or specific department after the remote consultation, including referral tendency, predicted receiving department, and required supporting conditions. Scheduling suitability refers to the degree of matching between the doctor and a specific remote consultation request, comprehensively evaluated by the system based on multiple factors. The higher the suitability value, the more suitable the doctor is to handle the consultation request.

[0026] In this embodiment, pre-set data refers to data sent in advance to the candidate doctor while the primary doctor is conducting the consultation, allowing the candidate doctor to understand the patient's condition and prepare accordingly. Examples include patient medical record summaries and medical image thumbnails. Pre-preparation status refers to the state in which the candidate doctor, after receiving the pre-set data, makes preliminary preparations for potential consultation follow-up tasks without interfering with their original work, including data caching and link keep-alive. Consultation status refers to the real-time operational status of the primary doctor's terminal device and network connection during the consultation process, such as network latency, packet loss rate, available bandwidth, and the working status of audio and video acquisition equipment. Actual execution data refers to the real data recorded by the system after the remote consultation, regarding the consultation process, doctor performance, and the patient's subsequent treatment path, such as consultation duration, doctor response time, and whether the patient was actually referred.

[0027] In this embodiment, the current status data and historical behavior data of registered doctors within the medical consortium are first acquired. Current status data may include information about the tasks the doctor is currently performing, network quality parameters of their terminal device, and device status parameters. For example, information such as the applications the doctor is using, real-time bandwidth and latency of the network connection, and CPU utilization can be collected in real time through the client program on the doctor's workstation. Historical behavior data may include records of the time spent completing tasks in the past, records of delays in responding to consultation requests, historical network quality records of their terminal device, and historical device operating status records. For example, the system can record the timestamp of each task completed by the doctor, as well as the time interval from receiving the consultation notification to the actual start of the consultation. Based on the acquired current status data and historical behavior data, the system can determine the available consultation time slots for each doctor within a future time window. For example, unused time slots in the doctor's schedule can simply be marked as available consultation time slots.

[0028] In this embodiment, upon receiving a remote consultation request, the system retrieves the patient's medical data contained within the request. This data may include the patient's medical records, examination reports, imaging data, etc. Simultaneously, the system extracts request features from the consultation request; for example, it may extract only the specialist information required by the patient. Furthermore, the system parses other information accompanying the consultation request to obtain referral intention information reflecting the patient's subsequent treatment pathway needs. For example, primary care physicians can manually select the "Consider referral" option and fill in a simple referral intention when submitting a consultation request.

[0029] In this embodiment, the system filters candidate doctors based on the request characteristics. For example, it can filter doctors from the doctor resource pool based on the specialty specified in the request. Next, the system calculates the scheduling suitability of each candidate doctor by combining their available consultation time slots and referral intention information. For example, it can simply use whether the doctor is online and whether they belong to the required specialty as criteria, assigning a fixed suitability value to doctors who meet the conditions. Based on the calculated scheduling suitability, the system determines one primary doctor and at least one backup doctor. For example, the doctor with the highest suitability can be selected as the primary doctor, without considering the selection of backup doctors.

[0030] In this embodiment, after determining the primary and backup doctors, the system sends the patient's medical data to the primary doctor, allowing them to review it in advance and prepare for the consultation. For example, the complete patient medical records and imaging data can be sent to the primary doctor's terminal. Simultaneously, the system sends preset data generated based on the patient's medical data to the backup doctor, enabling them to enter a pre-preparation state. For example, a notification can be sent to the backup doctor informing them that they may need to take over the consultation, without providing any patient medical data.

[0031] In this embodiment, the system continuously monitors the consultation status of the primary physician during the consultation process. For example, it can check periodically whether the network connection of the primary physician's terminal is interrupted. When it is detected that the consultation status of the primary physician does not meet preset conditions, such as a network connection interruption, the system will switch the current consultation to the backup physician who is in a pre-ready state. For example, a human operator can manually notify the backup physician to start taking over the consultation after discovering that the primary physician has interrupted the consultation.

[0032] In this embodiment, after the consultation, the system acquires the actual execution data. This data may include the actual consultation duration, doctor's response time, and whether the patient was subsequently referred to another doctor. For example, only the start and end times of the consultation may be recorded. The system uses this data to provide feedback and adjustments to the process of determining the available consultation time slots, parsing the referral intention information, and calculating the scheduling suitability. For example, the system administrator may periodically review the data manually and adjust the scheduling parameters based on experience.

[0033] In this embodiment, by comprehensively sensing the doctor's actual readiness status, proactively considering patient referral needs, and pre-setting consultation continuity mechanisms, the problems of long doctor readiness times, poor coordination between consultation and admission, and exacerbated impacts of consultation interruptions in traditional scheduling methods are effectively solved. This improves the efficiency and stability of remote consultations, optimizes the two-way referral process within the medical consortium, and ensures the continuity and timeliness of patient care.

[0034] In some of the embodiments described above in this application, although the current status data and historical behavior data of registered doctors within the medical consortium are proposed, and the available consultation time slots for each doctor within a future time window are determined based on this data, judging availability solely based on a doctor's schedule or simple busy / idle status may not accurately reflect the doctor's actual consultation ability and status. For example, a doctor may have just completed a time-consuming task and needs a certain cognitive transition time before engaging in a new consultation; or their terminal equipment or network condition may be poor, failing to meet the minimum technical requirements for remote consultation. This may lead to inaccurate scheduling, affecting consultation efficiency and quality, and even causing interruptions during the consultation process, thus reducing the experience for both patients and doctors.

[0035] To address this, this application further proposes a more refined method for determining the consultation periods available for each doctor within a future time window. This method first acquires the doctor's current status data and historical behavior data. The current status data includes information on the tasks the doctor is currently performing, terminal network quality parameters, and terminal device status parameters. The historical behavior data includes records of doctor task switching time, consultation response latency, historical network quality records of the doctor's terminal, and historical device operating status records.

[0036] In this embodiment, the information on the tasks currently being performed by the doctor can be obtained in real time from the hospital information system (HIS), electronic medical record system (EMR), or doctor scheduling system. For example, the doctor may be conducting outpatient visits, ward rounds, surgery, or writing medical records. Terminal network quality parameters refer to the network environment quality indicators of the terminal device used by the doctor for remote consultation, such as real-time bandwidth, network latency, packet loss rate, and jitter. These parameters can be collected in real time through the network monitoring module built into the terminal device or dedicated network diagnostic tools. Terminal device status parameters refer to the operating status of the doctor's terminal device, such as CPU utilization, memory usage, the operating status of audio and video acquisition devices such as cameras and microphones, battery level, and storage space. These parameters can be obtained through API interfaces provided by the operating system or device management software.

[0037] In this embodiment, historical behavioral data refers to the doctor's behavioral pattern data accumulated by the system over a long period. Doctor task switching time records refer to the average time or distribution pattern spent by a doctor from completing one task to starting another (especially switching from a non-consultation task to a consultation task), reflecting the time required for cognitive transitions between different tasks. Consultation response latency records refer to the average response time from when a doctor receives a consultation request to when the consultation actually begins. Historical network quality records and historical device operation status records of the doctor's terminal are used to analyze and predict the network and device availability trends of the doctor's terminal at a future time period.

[0038] In this embodiment, when determining the available consultation time for each doctor within a future time window, the estimated completion time of the current task is first calculated based on the currently executing task information and the preset historical average processing time for each task type. For example, if a doctor is performing an outpatient task with an average processing time of 30 minutes and has already worked for 10 minutes, it is estimated that it will take another 20 minutes to complete. Next, based on the task switching time record, the time from when the doctor completes the current task to when the cognitive state transition is completed is determined as the cognitive transition time. This time can be a fixed value, or it can be an average value or a predicted value dynamically calculated based on historical data. The sum of the estimated completion time and the cognitive transition time is taken as the doctor's initial available time. This means that the doctor not only needs to complete the current task but also needs to allow a buffer period to adjust their state.

[0039] In this embodiment, starting from the initial available time, the system excludes unavailable time slots already scheduled in the doctor's subsequent schedule, such as pre-booked surgeries, meetings, or personal rest time, thus obtaining the initial available consultation time slots. Based on this, to ensure the smooth conduct of remote consultations, the system uses the terminal network quality parameters and terminal device status parameters to verify the availability of the initial available consultation time slots. Specifically, the system removes sub-time slots where network conditions do not meet the minimum requirements for consultation (e.g., real-time bandwidth below a certain threshold, excessively high packet loss rate) or device conditions do not meet the minimum requirements for consultation (e.g., excessively high CPU utilization, camera malfunction) from the initial available consultation time slots, ultimately obtaining the available consultation time slots filtered by network and device conditions.

[0040] In this embodiment, by considering the estimated completion time of the doctor's current task and the necessary cognitive transition time, scheduling is avoided before the doctor is truly ready, thereby reducing the risk of consultation delays and interruptions. Simultaneously, availability verification is performed by combining terminal network quality and device status parameters to ensure that the doctor's technical environment meets the minimum requirements for a remote consultation when scheduled, effectively preventing consultation interruptions or quality degradation caused by technical issues such as network lag or equipment failure. This refined scheduling method not only improves the success rate and efficiency of remote consultations but also enhances the consultation experience for both patients and doctors, making the scheduling of doctor resources within the medical consortium more intelligent and user-friendly, thus better supporting the remote consultation needs of two-way referrals.

[0041] In some of the embodiments described above in this application, when determining the available consultation time slots for doctors, the availability of the initial available consultation time slots is verified using terminal network quality parameters and terminal device status parameters. However, these parameters typically reflect the current or instantaneous state. For network and device conditions over a longer period in the future, judging based solely on instantaneous data may be inaccurate, leading to network interruptions or device malfunctions during actual consultations, thus affecting the quality and efficiency of consultations.

[0042] In response, this application further proposes a specific method for verifying the availability of the initial consultation period using the terminal network quality parameters and terminal device status parameters. This method includes: obtaining the network quality change trend curve of the doctor's terminal within a historical time period and the device operation status change trend curve within the historical time period; calculating the predicted network quality value at each time point within the initial consultation period based on the network quality change trend curve; calculating the predicted device status value at each time point within the initial consultation period based on the device operation status change trend curve; and removing sub-periods where the predicted network quality value does not meet the minimum network requirements for remote consultation, and sub-periods where the predicted device status value does not meet the minimum device requirements for remote consultation, from the initial consultation period to obtain the consultation period.

[0043] In this embodiment, to accurately assess the availability of the doctor's terminal in the future, the method first acquires network quality data and device operating status data of the doctor's terminal over a past period. Network quality data may include, but is not limited to, metrics such as bandwidth, latency, packet loss rate, and jitter, while device operating status data may cover CPU utilization, memory usage, storage space, battery level, device temperature, and the operational stability of critical applications (such as consultation software). This historical data is collected through continuous monitoring, periodic sampling, or event-triggered recording, and processed to form time-series data to reflect its trends over time. For example, the system can record network quality and device status at regular time intervals (e.g., 5 minutes, 15 minutes) and store them in a database for subsequent trend analysis.

[0044] In this embodiment, after obtaining the historical network quality trend curve, the system uses a prediction algorithm to predict the network quality during the initial consultation period. This can employ various time series prediction models, such as the Autoregressive Moving Average (ARIMA) model, exponential smoothing, Kalman filtering, or machine learning-based methods (such as Recurrent Neural Networks (RNNs) and Long Short-Term Memory (LSTM) networks). Through these algorithms, the system can learn the patterns of network quality changes based on historical data and infer key network indicators such as the expected bandwidth, latency, and packet loss rate of the doctor's terminal at different time points during the initial consultation period. These predicted values ​​will provide a forward-looking basis for subsequent availability verification.

[0045] In this embodiment, similar to network quality prediction, the system also predicts the device status of the doctor's terminal during the initial consultation period based on historical device operating status trend curves. Prediction methods can also include time series analysis, regression analysis, or machine learning models. For example, the system can predict whether the device's CPU load will be too high, whether memory will be insufficient, or whether the consultation application might crash at a specific time point. These predictions help the system anticipate whether the device can operate stably during future consultations, thereby avoiding consultation interruptions due to insufficient device performance or malfunctions.

[0046] In this embodiment, after obtaining the predicted network quality and device status values ​​at each time point within the initial consultation period, the system compares these predicted values ​​with preset minimum requirements for remote consultation. The minimum network requirements for remote consultation include minimum bandwidth (e.g., video consultation requires at least 2Mbps uplink and downlink bandwidth), maximum latency (e.g., no more than 150ms), and maximum packet loss rate (e.g., no more than 1%). Minimum device requirements for remote consultation may include CPU idle rate, available memory, storage space, and the stable operation of the consultation software. Any sub-period with predicted values ​​lower than the minimum network or device requirements will be identified as unsuitable for remote consultation and precisely removed from the initial consultation period. Through this refined filtering process, the final consultation period will be a reliable period where the doctor's terminal meets the remote consultation requirements in terms of both network and device conditions.

[0047] In this embodiment, through the above-described technical solution, this method not only relies on the instantaneous or current network and device status for availability verification, but also introduces the analysis of historical data and the prediction of future status. This allows the system to more accurately predict whether the network connection and device performance of the doctor's terminal can continuously meet the stringent requirements of remote consultation during the initial consultation period in the future. By eliminating sub-periods where the predicted network quality or device status is substandard, this method improves the reliability and stability of the determined consultation period. This effectively avoids situations where consultation quality declines, is interrupted, or even fails due to sudden network interruptions or device performance degradation during the consultation process, thereby ensuring the smooth conduct of remote consultations, improving the efficiency of doctors' consultations, and enhancing the patient's treatment experience. At the same time, this forward-looking verification mechanism also provides a more robust technical guarantee for remote consultations in two-way referrals within medical consortia, ensuring the effective scheduling and utilization of medical resources.

[0048] In some of the embodiments described above in this application, although the patient treatment data and request features contained in the consultation request can be used to initially screen doctors and attempt to analyze referral intention information, in actual operation, it is difficult to accurately and comprehensively capture the deep needs of the patient's subsequent treatment path based solely on simple information extraction and analysis. In particular, the accuracy and reliability of key information such as whether a referral is needed, which department to refer to, and the required supporting conditions are often insufficient, which may lead to a mismatch between doctor scheduling and the patient's actual needs, affecting consultation efficiency and the smoothness of subsequent treatment.

[0049] To address this, this application further proposes a method for parsing information accompanying consultation requests to obtain referral intent information reflecting the patient's subsequent treatment pathway needs. The request features include the required specialty, estimated consultation duration, and a description of the patient's condition. Specifically, the method includes: First, key diagnostic and treatment description fields are extracted from the referral request form and medical record text attached to the consultation request. The required specialty refers to the professional field that the doctor needs to have for the patient's consultation, such as cardiology or neurosurgery. This information can be obtained from the patient's chief complaint, preliminary diagnosis, or departmental suggestions in the referral request form. The estimated consultation duration refers to the approximate time required to complete this remote consultation, which can be preset based on the complexity of the patient's condition, the consultation duration of similar cases in the past, or the doctor's experience. The condition description information details the patient's symptoms, signs, medical history, examination results, etc., and is the core basis for the doctor to understand the patient's condition; it is usually derived from medical record text, examination reports, etc. When extracting key diagnostic and treatment description fields, Natural Language Processing (NLP) techniques, such as Named Entity Recognition (NER) or keyword extraction, can be used to identify core words, phrases, or sentences related to disease diagnosis, treatment, prognosis, and referral intention from referral application forms (containing structured or semi-structured information such as basic patient information, preliminary diagnosis, referral purpose, and recommended referral departments) and medical record texts (containing unstructured text information such as chief complaint, present illness, past medical history, physical examination, auxiliary examinations, diagnosis, and treatment plan). For example, disease names, symptom descriptions, abnormal test results, and doctor's recommendations (such as "recommendation to a higher-level hospital" or "further specialist treatment required") can be extracted.

[0050] Secondly, semantic analysis is performed on the key diagnostic and treatment description fields to identify referral tendency expressions contained therein. Semantic analysis can further utilize NLP techniques, such as text classification, sentiment analysis, or intent recognition, to achieve a deeper understanding of the extracted key fields. Referral tendency expressions refer to words or phrases that explicitly or implicitly indicate a willingness, necessity, or direction of referral, such as "complex and difficult cases," "specialist consultation," "higher-level hospital," "surgical evaluation," "bed shortage," and "unmanageable." This typically requires constructing a knowledge graph or dictionary containing referral-related vocabulary, phrases, and their semantic weights.

[0051] Next, the referral tendency expression is vectorized to obtain the semantic vector corresponding to the referral tendency expression of the current request. Vectorization converts the identified referral tendency expression into a machine-understandable numerical vector form. Common methods include word embeddings (such as Word2Vec and GloVe), sentence embeddings (such as Sentence-BERT), or Transformer-based models (such as BERT and RoBERTa). These models can capture the semantic information of words or phrases and represent them in a multi-dimensional space. The resulting semantic vector can quantitatively represent the referral tendency of the current consultation request, making subsequent calculations and comparisons possible.

[0052] Based on this, an initial probability propensity value is generated, indicating whether a patient needs to be referred to a higher-level hospital, based on the aforementioned referral propensity expression. This initial probability propensity value can be generated using a machine learning model (such as logistic regression, support vector machine, or neural network), taking the vectorized referral propensity expression as input and outputting a probability value between 0 and 1, representing the likelihood that the patient needs to be referred to a higher-level hospital. The model's training data can come from explicit referral recommendations from doctors or actual referral results in historical cases.

[0053] Subsequently, the system retrieves the actual referral execution records of cases within the medical consortium whose semantic vectors corresponding to the referral tendency expressions of historical cases are less than a preset distance threshold compared to the semantic vectors corresponding to the referral tendency expressions of the current request. Here, the semantic vector distance can be obtained by calculating the distance between the semantic vectors of the referral tendency of the current request and the semantic vectors of the referral tendency of historical cases (e.g., cosine similarity, Euclidean distance, etc.). The preset distance threshold is used to filter out historical cases that are highly similar to the current request in terms of referral tendency. For these similar historical cases, the system queries whether a referral actually occurred, as well as information such as the referral destination and department; these records reflect real-world referral decisions.

[0054] Then, the initial propensity propensity value is corrected using the actual referral execution records to obtain a corrected propensity propensity value. The correction process incorporates the actual referral results of similar historical cases to adjust the initial propensity propensity value. For example, if a large number of similar historical cases ultimately resulted in referrals, the initial propensity propensity value can be increased; conversely, it can be decreased. This can be achieved through Bayesian correction, weighted averaging, or other statistical methods to make the probability value more closely reflect reality.

[0055] Simultaneously, based on the receiving department requirements and monitoring conditions contained in the key treatment description fields, a predicted set of receiving departments and their required supporting conditions is generated. Receiving department requirements refer to the specialist departments the patient may need to be transferred to, identified from the key treatment description fields, such as "cardiovascular medicine" or "orthopedics." This can be achieved through keyword matching, entity links, or more complex classification models. Monitoring conditions refer to the specific medical conditions or equipment the patient may require after transfer, such as "ICU bed," "ventilator support," or "special isolation ward." Combining the identified departments and conditions into a set provides specific guidance for subsequent physician scheduling and transfer arrangements.

[0056] Finally, the corrected propensity score and the predicted set of receiving departments and required supporting conditions are used as the referral intention information. The final referral intention information is a structured data packet that contains the quantitative probability of patient referral (corrected propensity score) and specific referral targets (predicted set of receiving departments and required supporting conditions), providing a comprehensive and accurate basis for subsequent doctor scheduling and referral decisions.

[0057] In this embodiment, through the above technical solution, this application can perform in-depth analysis of the information accompanying the consultation request, overcoming the inaccuracy of traditional methods in identifying the patient's subsequent treatment path needs (especially referral intentions). By introducing semantic analysis, vectorization processing, and a probability correction mechanism based on historical actual referral execution records, a more accurate and reliable semantic vector and corrected probability tendency value corresponding to the referral tendency expression can be generated. Simultaneously, combined with key treatment description fields, the system can specifically predict the set of receiving departments and the required supporting conditions, ensuring that the obtained referral intention information not only quantifies the possibility of referral but also clarifies the specific direction and conditions of referral. This allows the system to fully consider the patient's deep referral needs when screening candidate doctors and calculating scheduling suitability, thereby achieving more accurate matching and scheduling of doctor resources. This effectively avoids resource mismatch and treatment process interruptions caused by unclear referral intentions or incomplete information, improving the efficiency of remote consultations and the smoothness of the patient's subsequent treatment.

[0058] While the above-described implementations have proposed a basic framework for selecting candidate doctors based on request characteristics and calculating scheduling suitability by combining available consultation time slots and referral intentions, practical applications still face challenges in comprehensively and accurately assessing the match between candidate doctors and remote consultation requests, especially considering diverse factors such as network equipment conditions, doctors' own specialties, and patients' subsequent referral needs. Insufficiently precise scheduling suitability calculations may lead to selected doctors encountering technical obstacles during consultations or being unable to effectively handle patients' subsequent treatment pathways, impacting consultation quality and efficiency.

[0059] To address this, this application further proposes a method for calculating the scheduling suitability of each candidate doctor. This method includes: obtaining network quality parameters and device status parameters for each candidate doctor; generating a network quality suitability score based on the network quality parameters; generating a device status suitability score based on the device status parameters; determining whether the corrected probability tendency value in the referral intention information exceeds a preset threshold; if it exceeds the preset threshold, obtaining the real-time resource status of the candidate doctor's department and the candidate doctor's own patient load, and generating a referral continuation suitability score; if it does not exceed the preset threshold, then... The referral and continuation adaptation score is set to the default value; the difference between the duration of the available consultation time slot for a candidate doctor and the estimated consultation time slot is calculated, and a time slot adaptation score is generated based on the time slot difference; the preset specialty direction description text for each candidate doctor is obtained, and the semantic similarity between the specialty direction description text and the disease description information is calculated, and a specialty adaptation score is generated based on the semantic similarity; the network quality adaptation score, the device status adaptation score, the time slot adaptation score, the specialty adaptation score, and the referral and continuation adaptation score are weighted and summed to obtain the scheduling adaptation degree.

[0060] In this embodiment, the process of acquiring network quality parameters and device status parameters for each candidate doctor, generating network quality adaptation scores based on the network quality parameters, and generating device status adaptation scores based on the device status parameters aims to assess the stability of the technical environment for candidate doctors to conduct remote consultations. Network quality parameters may include, but are not limited to, real-time bandwidth, network latency, and packet loss rate, which can be obtained through the system interface of the doctor's terminal or network monitoring tools. Device status parameters may include CPU utilization, memory usage, the working status of peripherals such as cameras / microphones, and battery level, which can be obtained through the operating system API or device management module of the doctor's terminal. Based on these parameters, a series of thresholds or scoring functions can be set to map the original parameter values ​​to network quality adaptation scores and device status adaptation scores between 0 and 100. For example, when the network bandwidth is below a certain minimum requirement, the network quality adaptation score may be 0; when the bandwidth is above a certain ideal value, the score may be 100; and when it is between these two values, the score increases linearly or non-linearly with the bandwidth. The generation method for device status adaptation scores is similar, ensuring that the doctor's terminal has a stable hardware and software environment for conducting remote consultations.

[0061] In this embodiment, the determination of whether the corrected probability propensity value in the referral intention information exceeds a preset threshold is used to identify whether the patient has a strong need for referral. The corrected probability propensity value in the referral intention information reflects the likelihood that the patient needs to be referred to a higher-level hospital, and this value is typically between 0 and 1. The preset threshold is an empirical value or a threshold obtained through training with historical data, such as 0.6 or 0.7. If the probability propensity value exceeds the preset threshold, it indicates that the patient has a high willingness to be referred, and in this case, the referral capacity of the doctor and their department needs to be carefully considered when scheduling doctors.

[0062] In this embodiment, if the preset threshold is exceeded, the real-time resource status of the candidate doctor's department and the candidate doctor's own patient load are obtained to generate a referral and continuation suitability score. When a patient has a strong intention to be referred, it is necessary to assess whether the candidate doctor and their department have the conditions to receive the patient. The real-time resource status of the department may include the current number of available beds, the number of beds expected to be vacated in the future, and the department's medical staff configuration. The candidate doctor's own patient load may include the number of patients they are currently handling, scheduled surgeries or treatments, and expected workload. This information can be obtained through the interfaces of the hospital information system, electronic medical record system, or scheduling system. Based on this data, the referral capacity of the doctor and their department can be comprehensively evaluated, and a referral and continuation suitability score can be generated. For example, when the department has sufficient beds and the doctor's patient load is low, the score is high; conversely, it is low.

[0063] In this embodiment, if the preset threshold is not exceeded, the referral and connection adaptation score is set to a default value. When the patient's referral intention is weak, i.e., the corrected probability tendency value does not exceed the preset threshold, the importance of the referral and connection adaptation score decreases. In this case, to simplify calculations and avoid unnecessary interference, the score can be set to a default value, such as a medium score or zero, indicating that under the current circumstances, referral capacity is not the main consideration in scheduling decisions.

[0064] In this embodiment, when calculating the difference between the available consultation time slot and the estimated consultation time slot for a candidate doctor, and generating a time slot adaptation score based on this difference, this step aims to assess the degree of matching between the available consultation time of the candidate doctor and the actual consultation time requirement. The available consultation time slot is the total time a doctor can conduct a consultation within a future time window, and the estimated consultation time slot is the expected consultation time required in a remote consultation request. The difference between the two is calculated, for example, by subtracting the estimated time slot from the available time slot. Based on this difference, a time slot adaptation score can be generated. For example, the score is highest when the available time slot is slightly greater than or equal to the estimated time slot; when the available time slot is much greater than the estimated time slot, there may be resource waste, and the score decreases slightly; when the available time slot is less than the estimated time slot, the score decreases significantly.

[0065] In this embodiment, when obtaining the pre-set specialty description text for each candidate doctor, calculating the semantic similarity between the specialty description text and the patient's condition description information, and generating a specialty matching score based on the semantic similarity, this step aims to evaluate the degree of matching between the candidate doctor's professional expertise and the patient's condition. The pre-set specialty description text for each candidate doctor can originate from doctor registration information, personal profile, professional title information, or a list of diseases they are skilled in. The patient's condition description information originates from patient treatment data in a remote consultation request. Natural language processing techniques, such as word vector models, topic models, or text similarity algorithms, are used to calculate the semantic similarity between the doctor's specialty description text and the patient's condition description information. A higher similarity indicates a better match between the doctor's expertise and the patient's condition, thus generating a higher specialty matching score.

[0066] In this embodiment, the network quality adaptation score, device status adaptation score, time period adaptation score, specialty adaptation score, and referral continuation adaptation score are weighted and summed to obtain the scheduling adaptation degree. This is the core step in comprehensively evaluating the scheduling adaptation degree of candidate doctors. Each of the above adaptation scores—network quality adaptation score, device status adaptation score, time period adaptation score, specialty adaptation score, and referral continuation adaptation score—is multiplied by a preset weighting coefficient, and then summed. The weighting coefficients can be adjusted according to actual business needs, consultation type, and the urgency of the patient's condition. For example, for urgent consultations, the weight of the time period adaptation score may be higher; for complex and rare diseases, the weight of the specialty adaptation score may be higher; and for patients with a clear intention to be referred, the weight of the referral continuation adaptation score will be significantly increased. Through weighted summation, a comprehensive scheduling adaptation degree can be obtained, which can fully reflect the matching degree between candidate doctors and remote consultation requests.

[0067] In this embodiment, by introducing multiple evaluation indicators such as network quality matching score, device status matching score, time period matching score, specialty matching score, and referral continuation matching score, and performing weighted summation, this application can more comprehensively and accurately assess the matching degree between candidate doctors and remote consultation requests. This not only ensures the technical stability of the consultation process and reduces the risk of consultation interruption due to network or equipment problems, but also effectively identifies and prioritizes doctors who are highly matched in specialty and have the ability to handle subsequent patient referrals. Especially for patients with a clear intention to be referred, this method can pre-screen doctors with the corresponding departmental resources and treatment capacity, thereby optimizing the patient's treatment path, improving the efficiency and success rate of two-way referrals, avoiding secondary scheduling or referral delays caused by doctor mismatch or insufficient resources, and improving the service quality and patient satisfaction of remote consultations within the medical consortium.

[0068] In some of the embodiments described above in this application, to more accurately assess the suitability of candidate physicians for patients intending to be referred, a referral suitability score is generated based on the real-time resource status of the candidate physician's department and the candidate physician's own patient load. However, in practice, how to specifically and quantitatively assess these resource statuses and patient loads to ensure that the generated suitability score truly reflects the physician's ability to receive referred patients is a problem that requires careful consideration. Inaccurate assessment may lead to low referral matching efficiency, or even situations where physicians are unable to receive patients due to insufficient beds or manpower, affecting the patient's subsequent treatment pathway.

[0069] To address this, this application further proposes a specific method for obtaining the real-time resource status of the candidate doctor's department and the candidate doctor's own patient load, and generating a referral and admission matching score. This method first queries the number of currently available beds in the candidate doctor's department, as well as the number of beds expected to become available within a specified future time period, through the hospital information system interface. Specifically, the system integrates with the hospital's existing information system (such as HIS or EMR systems) and obtains the department's bed occupancy status in real time through a preset interface protocol (such as API calls or the HL7 data exchange standard). Simultaneously, the system analyzes the expected discharge time of admitted patients to predict the bed resources that may become available within a specific future time window. This allows the system to dynamically grasp the department's bed capacity, providing fundamental data for referral decisions.

[0070] Secondly, the system will query the number of confirmed admissions for candidate doctors within a specified future time period. This includes the number of inpatients the doctor has already admitted or is about to admit; this information is also stored in the hospital information system or the doctor's personal scheduling system. By obtaining this data, a preliminary understanding of the doctor's basic workload in the coming period can be obtained.

[0071] Based on this, the system calculates the candidate doctor's expected workload saturation within the specified future time period, using the number of admission tasks and the historical average processing time for each task. Specifically, the system maintains a historical database recording the average processing time or average length of stay for different types of admission tasks (e.g., inpatients with different diseases). Then, the system multiplies and sums the number of each confirmed admission task for the candidate doctor with its corresponding historical average processing time to obtain the total working time the doctor is expected to invest within the specified future time period. Comparing this total working time with the doctor's total available working time within that time period calculates their expected workload saturation. This saturation value directly reflects the doctor's remaining energy for handling new tasks in the future.

[0072] In this embodiment, the system comprehensively determines whether a candidate doctor possesses the necessary bed capacity and workload to receive referred patients based on the current number of available beds, the expected number of beds to be vacated, and the expected workload level. This determination process involves preset business rules and logic. For example, the bed capacity requirement stipulates that the current or expected number of available beds must reach a certain minimum threshold to ensure that patients have physical space to stay. The workload requirement stipulates that the doctor's expected workload level must be below a certain upper limit threshold to ensure that the doctor has sufficient energy to handle newly referred patients. Only when both of these core conditions are met is the doctor considered to have the basic ability to receive referred patients.

[0073] Finally, based on the comprehensive assessment, the system generates a referral suitability score. Specifically, when both bed availability and workload conditions are met, the system assigns the maximum referral suitability score, indicating that the doctor is highly suitable for receiving referred patients. If either condition is not met, the system reduces the referral suitability score according to the degree of dissatisfaction. For example, if the number of available beds is slightly below a threshold, or the expected workload is slightly above a threshold, the score will be appropriately reduced; if the conditions are severely unmet, the score will be significantly reduced, possibly even to zero. This reduction mechanism ensures that the suitability score accurately reflects the doctor's actual ability and willingness to receive referred patients.

[0074] In this embodiment, the present application overcomes the limitations of relying solely on rough resource status and patient load assessments. Through deep integration with the hospital information system, it obtains real-time information on departmental bed resources (including current availability and future expected availability), and combines this with doctors' confirmed patient assignments and historical processing times to accurately calculate their expected workload saturation. The system can comprehensively and quantitatively assess the "bed availability" and "capacity" of candidate doctors in accepting referred patients. This refined assessment mechanism ensures that the generated referral matching score accurately reflects the doctor's actual receiving capacity. When a doctor has sufficient bed availability and capacity, the system assigns them the highest matching score, prioritizing their recommendation to patients requiring referral; conversely, the score is lowered according to the degree of inadequacy. This not only improves the success rate and efficiency of two-way referrals after remote consultations, avoiding referral failures or delays due to resource mismatch, but also optimizes the allocation of medical resources within the medical consortium, ensuring that patients are referred to doctors truly capable of receiving and providing subsequent medical services, thereby guaranteeing the continuity and quality of patient care.

[0075] In some of the embodiments described above in this application, in order to deal with possible abnormal situations during the consultation of the primary physician, the system will identify a backup physician and send preset data to it, putting it into a pre-preparation state. However, if only the preset data is sent, it may not be possible to ensure that the backup physician can quickly and seamlessly take over the consultation when needed, while avoiding excessive occupation of the backup physician's terminal resources or interference with its normal work during the pre-preparation stage.

[0076] To address this, this application further proposes a specific method for sending pre-configured data generated based on patient medical data to a candidate doctor, enabling the candidate doctor to enter a pre-preparation state. This method includes sending a pre-configured data package containing a patient medical record summary and medical image thumbnails to the candidate doctor's terminal, allowing the candidate doctor's terminal to perform data caching in the background. Specifically, the patient medical record summary can be a structured text file containing the patient's key diagnostic information, past medical history, current symptoms, and preliminary diagnostic results, allowing the candidate doctor to quickly understand the patient's basic condition. The medical image thumbnails refer to compressed, low-resolution preview versions of medical images (such as X-rays, CT scans, MRI images, etc.), which are sufficient for the candidate doctor to gain a preliminary impression of the patient's imaging findings. The pre-configured data package integrates and packages this key information. By performing data caching in the background, the candidate doctor's terminal can pre-download and store this necessary data locally without interfering with the doctor's current operation, ensuring immediate access during consultation switching and avoiding disruption to the continuity of the consultation due to data loading delays.

[0077] Furthermore, this application proposes establishing a low-power signaling keep-alive channel between the candidate doctor's terminal and the consultation server to keep the candidate doctor's terminal in an active link state. The low-power signaling keep-alive channel can employ lightweight communication protocols, such as MQTT or WebSocket with a minimum heartbeat mechanism, to minimize network bandwidth and terminal power consumption. By maintaining this active link state, the consultation server can quickly send instructions or status updates to the candidate doctor's terminal without re-establishing a connection, thus providing a foundation for rapid response in subsequent consultation switching operations.

[0078] In this embodiment, to indicate the standby status of the candidate doctor without affecting their normal work, this application proposes displaying a standby status prompt on the candidate doctor's terminal interface. The display area of ​​the standby status prompt does not overlap with the display area of ​​the candidate doctor's original work task interface, and allows the candidate doctor to continue operating their original work tasks. The standby status prompt can be a small, inconspicuous notification icon, a floating widget, or a system status bar indicator. Its display area is designed not to obscure key information or interactive elements of other applications being used by the candidate doctor, ensuring that the doctor can continue processing their daily work tasks without feeling disturbed or distracted.

[0079] Furthermore, in the pre-preparation state, the audio and video capture module of the candidate doctor's terminal is not activated and does not send audio and video data streams to the consultation room. This means that the camera and microphone hardware of the candidate doctor's terminal are inactive and will not transmit any audio or video data to the consultation server. This measure effectively avoids unnecessary bandwidth consumption, processing resource consumption, and potential privacy risks during the selection phase. The audio and video capture module will only be activated when the candidate doctor is officially activated to take over the consultation.

[0080] In this embodiment, through the above technical solution, the system can ensure that when the alternative doctor enters the pre-ready state, it can not only pre-acquire and cache key patient diagnosis and treatment data, but also maintain rapid communication with the consultation server through a low-power signaling keep-alive channel. Simultaneously, the non-intrusive standby status prompts and the shutdown of the audio and video acquisition modules greatly reduce the consumption of alternative doctor terminal resources (such as network bandwidth, processor, and battery) and avoid interference with their normal operation. This allows the alternative doctor to maintain a high state of readiness without affecting their own efficiency. Once the primary doctor's consultation status becomes abnormal, the alternative doctor can quickly and seamlessly take over the consultation, greatly improving the stability and continuity of remote consultations and ensuring the smooth progress of the patient's diagnosis and treatment process.

[0081] In some of the embodiments described above in this application, although a primary physician is pre-selected for remote consultation and backup physicians are put into a pre-ready state to deal with emergencies, the network status or device performance of the primary physician's terminal may fluctuate during the actual consultation process, leading to a decline in consultation quality or even interruption. This can seriously affect the patient's treatment experience and consultation efficiency. How to accurately assess the consultation status of the primary physician in real time, and smoothly and seamlessly switch the consultation task to a backup physician when the primary physician fails to meet requirements, is a key challenge in ensuring the continuity and stability of remote consultations.

[0082] To address this, this application further proposes continuous monitoring of the consultation status of the primary physician, including: continuously collecting network latency, packet loss rate, and available bandwidth of the primary physician's terminal to generate a network quality score; continuously collecting the working status and processing resource utilization of the audio and video acquisition devices of the primary physician's terminal to generate a device operation score; weighting and summing the network quality score and the device operation score to obtain a comprehensive consultation status value; when the consultation status of the primary physician is detected to be unsatisfactory, switching the current consultation to the backup physician in a pre-ready state, including: when the comprehensive consultation status value is lower than a preset safety threshold, obtaining the current network quality score and device operation score of the backup physician's terminal through the low-power signaling keep-alive channel; when the current network quality score and device operation score of the backup physician's terminal meet the preset connection conditions, sending an activation command through the low-power signaling keep-alive channel to open the audio and video channel of the backup physician's terminal and switch the consultation data stream from the primary physician's terminal to the backup physician's terminal; and sending a switching prompt message to the primary physician's terminal before the switching is completed.

[0083] In this embodiment, continuous monitoring of the selected physician's consultation status aims to grasp the environmental quality and equipment performance during remote consultations in real time, ensuring smooth consultations. The system periodically, or during consultation data transmission, probes the network connection between the selected physician's terminal and the consultation server via network protocols, continuously collecting data on the selected physician's terminal's network latency, packet loss rate, and available bandwidth. These indicators are comprehensively calculated using a preset algorithm (e.g., weighted averaging after normalization, or grading based on thresholds) to generate a quantified network quality score, which directly reflects the current network environment's support for remote consultations. Simultaneously, the system monitors the hardware status of the selected physician's terminal, such as whether audio / video acquisition devices like cameras and microphones are working properly and whether they are occupied, and monitors the terminal's CPU, memory, and other processing resource usage to assess its ability to process consultation data streams. This continuous collection of the selected physician's terminal's audio / video acquisition device status and processing resource usage generates a device operation score. This device status and resource usage data are also converted into a device operation score using a preset scoring model to assess whether the terminal device can stably support high-quality remote consultations. To comprehensively reflect the consultation status of the selected physician, the system will weight and sum the generated network quality score and equipment performance score according to their importance to the consultation quality, assigning different weights to each to obtain a comprehensive consultation status value. This comprehensive consultation status value is a single indicator that can comprehensively measure the current consultation environment and equipment performance of the selected physician.

[0084] In this embodiment, when the consultation status of the primary physician is detected to be unsatisfactory, the current consultation is switched to the backup physician who is in a pre-ready state. This mechanism ensures that the backup physician can be activated promptly and effectively to continue the consultation when the primary physician's consultation environment deteriorates, thus guaranteeing the continuity of the consultation. The system continuously compares the comprehensive consultation status value of the primary physician with a preset safety threshold. Once the comprehensive consultation status value falls below the preset safety threshold, it indicates that the primary physician's consultation environment is no longer suitable for continuing a high-quality consultation. At this time, the system immediately sends a request to the backup physician's terminal through the previously established low-power signaling keep-alive channel to obtain its latest network quality score and device operation score to assess whether the backup physician meets the conditions for continuing the consultation. After confirming that the current network quality score and device operation score of the backup physician's terminal both meet the preset connection conditions (e.g., network latency is below a certain value, and device resource utilization is within the normal range), the system sends an activation command to the backup physician's terminal through the low-power signaling keep-alive channel. This command triggers the backup doctor's terminal to activate its audio and video capture module and establish a full-featured audio and video channel with the consultation server. Simultaneously, the consultation server smoothly switches the current consultation data stream (including patient audio and video, treatment data, etc.) from the primary doctor's terminal to the backup doctor's terminal, achieving seamless consultation continuity. To inform the primary doctor that the consultation is about to be switched, the system sends a switching notification to the primary doctor's terminal before the data stream switching operation is complete. This notification can be displayed as a pop-up window, text notification, or voice prompt, informing the primary doctor that the consultation will soon be taken over by the backup doctor, allowing the primary doctor to prepare for the handover or understand the current situation, avoiding confusion caused by sudden interruption.

[0085] In this embodiment, through the above technical solution, this application can achieve real-time and refined monitoring of the consultation status of the primary physician, and promptly detect network or device anomalies. When the consultation status of the primary physician does not meet the preset conditions, the system can intelligently assess the succession capability of the alternative physician, and utilize a low-power signaling keep-alive channel to achieve a rapid and smooth switch of the consultation data stream from the primary physician to the alternative physician. This improves the stability and reliability of remote consultations, effectively avoids consultation interruptions caused by sudden conditions of the primary physician, ensures the continuity of the patient's treatment process, optimizes the consultation experience for both doctors and patients, and improves the utilization efficiency of physician resources, ensuring the quality and efficiency of the two-way referral remote consultation service within the medical consortium.

[0086] In some of the embodiments described above in this application, a method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia is proposed. This method can efficiently schedule physician resources and ensure the continuity of consultations. However, during remote consultations, when a doctor determines that a referral is necessary based on the patient's condition, how to quickly and accurately identify doctors or departments with the necessary receiving capabilities and provide timely referral guidance to avoid information lag and untimely resource matching after the referral decision is a challenge faced by current technical solutions.

[0087] To address this, this application further proposes a method for real-time transcription of consultation audio during the consultation process, followed by semantic recognition of the transcribed text. When a semantic segment representing a referral decision is identified from the transcribed text, the application queries whether the primary physician meets the criteria for admitting the patient. If the primary physician does not meet the criteria, the application queries whether the alternative physician meets the criteria. If the alternative physician also does not meet the criteria, a supplementary physician meeting the criteria is selected from the registered physicians within the medical consortium, and a readiness list containing the patient's medical data and referral recommendations is sent to the supplementary physician's terminal. Before the consultation ends, a referral guidance scheme containing recommended recipient information is generated based on the query results for the admission criteria.

[0088] In this embodiment, during the consultation process, the system can transcribe the doctor's and patient's consultation speech in real time. This transcription process utilizes advanced Automatic Speech Recognition (ASR) technology to accurately convert spoken communication into text. Subsequently, the system performs semantic recognition on these transcribed texts, analyzing their meaning and underlying intent using Natural Language Processing (NLP) technology. For example, it can identify keywords, phrases, or sentence structures that may suggest the patient's potential need for referral or specific referral requirements, such as "recommendation to a higher-level hospital," "needs inpatient observation," or "our facilities are insufficient." This aims to capture the progress of the consultation and potential referral intentions in real time, providing structured data for subsequent decision-making.

[0089] In this embodiment, when the system identifies semantic fragments representing referral decisions from the transcribed text—for example, when the semantic recognition module detects preset referral-related keywords or semantic patterns—it triggers subsequent referral condition judgment and doctor matching processes. This ensures that the system can dynamically respond to referral needs arising during consultations, rather than waiting for manual judgment after the consultation ends.

[0090] Once a referral decision is identified, the system first checks whether the selected physician is qualified to admit the patient. This typically involves accessing the hospital information system (HIS) or resource management system of the selected physician's hospital via an interface to obtain information such as the real-time bed availability, specialty scope, current workload, and availability of resources for the physician's department. Prioritizing the selection of the selected physician aims to streamline the referral process; if the physician is qualified, the patient can be admitted directly, improving efficiency.

[0091] In this embodiment, if the primary physician does not meet the acceptance criteria, the system will further query whether the alternative physicians meet the acceptance criteria. Similar to querying the primary physician, the system will query the resource status and treatment capacity of the hospital or department where the alternative physicians are located through an interface. Since the alternative physicians are already in a pre-preparation state before the consultation begins, the system may already have a preliminary understanding of their information, which helps to improve query efficiency and expand the scope of recipients, thereby increasing the referral success rate.

[0092] In this embodiment, if the candidate doctor also does not meet the receiving criteria, the system will further expand the search scope to screen supplementary doctors who meet the receiving criteria from all registered doctors within the medical consortium. The screening process will comprehensively consider information such as the patient's condition description, required specialty, and monitoring conditions, and match them in the doctor database within the medical consortium. Screening criteria may include the doctor's specialty, professional title, hospital level, department's capacity, and current workload. Once a suitable supplementary doctor is selected, the system will generate a "receiving preparation list" containing the patient's key medical data (such as medical record summary, imaging report, preliminary diagnosis, etc.) and referral suggestions, and send it to the supplementary doctor's terminal via push notification, email, or system notification, so that the doctor can understand the patient's situation in advance and assess the possibility of receiving the patient, ensuring that the patient can find a suitable recipient.

[0093] Finally, before the consultation concludes, the system will generate a referral guidance plan based on the query results of the aforementioned receiving criteria, including information on the suggested receiving hospital. This plan can be a structured document or electronic information, containing the suggested receiving doctor or department (which may be one or more of the primary, alternative, or supplementary doctors), the contact information of the receiving hospital, a list of materials required for the referral, a referral process guide, and the estimated waiting time. This plan can be displayed directly to the primary doctor on the consultation system interface, or sent to the patient or their family via SMS, app push notifications, or other means.

[0094] Through the aforementioned technical solution, this application can capture the doctor's referral decision intention in real time during the consultation process, thereby avoiding the lag in manual judgment and information transmission after the consultation. Based on the identified referral intention, the system can proactively query the acceptance conditions of the primary doctor, alternative doctors, and even supplementary doctors within the entire medical consortium, achieving rapid matching and efficient scheduling of referral resources. Especially when the primary or alternative doctor does not meet the acceptance conditions, it can quickly screen suitable supplementary doctors and send a preparation list in advance, greatly shortening the patient's waiting time for referral. Finally, before the consultation ends, a referral guidance plan containing suggested recipient information is generated, providing patients with a clear and convenient referral path, improving the efficiency of two-way referrals within the medical consortium and the patient's medical experience, and effectively solving the problems of information silos and resource matching after referral decisions.

[0095] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia. Any simple modifications based on this technical concept are within the scope of protection of this application.

[0096] This application also provides a dynamic scheduling system for remote consultation physician resources for two-way referral within medical consortia. The system includes a memory, a processor, and a dynamic scheduling program for remote consultation physician resources for two-way referral within medical consortia, stored in the memory and executable on the processor. The program is configured to implement the steps of the aforementioned dynamic scheduling method for remote consultation physician resources for two-way referral within medical consortia.

[0097] The remote consultation physician resource dynamic scheduling system for two-way referral within medical consortia provided in this application adopts the remote consultation physician resource dynamic scheduling method for two-way referral within medical consortia in the above embodiments, which can improve the efficiency of resource collaboration within medical consortia. Compared with the prior art, the beneficial effects of the remote consultation physician resource dynamic scheduling system for two-way referral within medical consortia provided in this application are the same as the beneficial effects of the remote consultation physician resource dynamic scheduling method for two-way referral within medical consortia provided in the above embodiments, and other technical features of the remote consultation physician resource dynamic scheduling system for two-way referral within medical consortia are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0098] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0099] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. All equivalent structural transformations made under the technical concept of this application using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of this application.

Claims

1. A method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia, characterized in that, The method includes: Obtain the current status data and historical behavior data of registered doctors within the medical consortium, and determine the consultation time periods for each doctor within the future time window based on the current status data and historical behavior data; Receive a remote consultation request, obtain the patient's diagnosis and treatment data contained in the consultation request, extract the request features from the consultation request, parse the information attached to the consultation request, and obtain referral intention information reflecting the patient's needs for subsequent diagnosis and treatment pathways; Candidate doctors are selected based on the request features. The scheduling suitability of each candidate doctor is calculated by combining the available consultation time slots and the referral intention information of each candidate doctor. Based on the scheduling suitability, the primary doctor and at least one alternative doctor are determined. The patient's medical data is sent to the primary physician to prepare for the consultation, and preset data generated based on the patient's medical data is sent to the alternative physicians to put them into a pre-preparation state. During the consultation, the consultation status of the primary physician is continuously monitored. When it is detected that the consultation status of the primary physician does not meet the preset conditions, the current consultation is switched to the alternative physician who is in the pre-preparation state. The actual execution data after the consultation is completed is obtained, and the actual execution data is used to make feedback adjustments to the process of determining the consultation time period, the process of parsing the referral intention information, and the process of calculating the scheduling adaptability.

2. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 1, characterized in that, The current status data includes information on the tasks the doctor is currently performing, terminal network quality parameters, and terminal device status parameters. The historical behavior data includes records of doctor task switching time, consultation response delay, historical network quality records of the doctor's terminal, and historical device operation status records. Determine the available consultation periods for each doctor within the future time window, including: Based on the currently executing task information and the preset historical average processing time for each task type, the estimated completion time of the current task is calculated. Based on the task switching time record, the time from when the doctor completes the current task to when the cognitive state is switched is determined, which is taken as the cognitive transition time. The sum of the expected completion time and the cognitive transition duration is taken as the doctor's initial available time; Starting from the initial available time, exclude the unavailable task time slots already scheduled in the doctor's subsequent schedule to obtain the initial available consultation time slots; Using the terminal network quality parameters and terminal device status parameters, the availability of the initial consultation period is verified. Sub-periods that do not meet the minimum consultation requirements due to network or device conditions are removed from the initial consultation period, resulting in the consultation period after filtering by network and device conditions.

3. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 2, characterized in that, The availability of the initial consultation period is verified using the terminal network quality parameters and terminal device status parameters, including: Obtain the network quality change trend curve of the doctor's terminal within a historical time period and the device operation status change trend curve within the historical time period; Based on the network quality change trend curve, the predicted network quality values ​​at each time point within the initial consultation period are obtained. Based on the trend curve of the equipment's operating status change, the predicted values ​​of the equipment status at each time point within the initial consultation period are obtained. The sub-periods in which the predicted network quality value does not meet the minimum network requirements for remote consultation, and the sub-periods in which the predicted device status value does not meet the minimum device requirements for remote consultation, are removed from the initial consultation-available period to obtain the consultation-available period.

4. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 1, characterized in that, The request features include the required specialty, estimated consultation duration, and a description of the patient's condition; parsing the information attached to the consultation request to obtain referral intention information reflecting the patient's subsequent treatment pathway needs includes: Extract key treatment description fields from the referral application form and medical record text attached to the consultation request; Semantic analysis was performed on the key diagnosis and treatment description fields to identify the referral tendency expressions contained therein; The referral tendency expression is vectorized to obtain the semantic vector corresponding to the referral tendency expression of the current request; Based on the aforementioned referral propensity expression, an initial probability propensity value is generated indicating whether the patient needs to be referred to a higher-level hospital; Obtain the actual referral execution records of cases in the medical consortium whose semantic vectors corresponding to the referral tendency expression of historical cases are less than a preset distance threshold from the semantic vectors corresponding to the referral tendency expression of the current request. The initial probability propensity value is corrected using the actual referral execution records to obtain the corrected probability propensity value; And based on the receiving department requirements and monitoring conditions contained in the key diagnosis and treatment description fields, generate a predicted set of receiving departments and the required supporting conditions; The corrected probability tendency value, the predicted set of receiving departments, and the required supporting conditions are used as the referral intention information.

5. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 4, characterized in that, Calculate the scheduling fit for each candidate doctor, including: Obtain the network quality parameters and device status parameters of each candidate doctor, generate a network quality adaptation score based on the network quality parameters, and generate a device status adaptation score based on the device status parameters; Determine whether the corrected probability tendency value in the referral intention information exceeds a preset threshold; If the preset threshold is exceeded, the real-time resource status of the candidate doctor's department and the candidate doctor's own treatment load are obtained to generate a referral and connection matching score. If the preset threshold is not exceeded, the referral and connection adaptation score will be set to the default value. Calculate the difference between the duration of the available consultation time slot for the candidate doctor and the estimated consultation time, and generate a time slot matching score based on the duration difference; Obtain the pre-defined specialty description text for each candidate doctor, calculate the semantic similarity between the specialty description text and the disease description information, and generate a specialty matching score based on the semantic similarity. The scheduling fit score is obtained by weighted summing of the network quality fit score, the device status fit score, the time period fit score, the specialty fit score, and the referral and connection fit score.

6. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 5, characterized in that, Obtain the real-time resource status of the candidate doctor's department and the candidate doctor's own patient load, and generate a referral and continuation suitability score, including: The system allows users to query the current number of available beds in the department of a candidate doctor through the hospital information system interface, as well as the number of beds expected to be available within a specified future time period. Query the number of patient admissions that a candidate doctor has confirmed for a specified period of time in the future; Based on the number of admission tasks and the historical average processing time of each admission task, the expected workload saturation of the candidate doctor in the specified future time period is calculated. Based on the current number of available beds, the expected number of beds to be freed up, and the expected workload, a comprehensive assessment is made as to whether the candidate doctor has the bed and energy conditions to receive referred patients. When both bed availability and capacity are met, the maximum referral and continuation suitability score is given. If either condition is not met, the referral and continuation suitability score is reduced according to the degree of non-compliance.

7. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 1, characterized in that, Sending preset data generated based on the patient's medical data to the candidate physicians to put them into a pre-preparation state includes: Send a pre-set data packet containing patient medical record summaries and medical image thumbnails to the alternative doctor's terminal, so that the alternative doctor's terminal can complete data caching in the background; A low-power signaling keep-alive channel is established between the candidate doctor terminal and the consultation server to keep the candidate doctor terminal in an active link state; A standby status prompt is displayed on the terminal interface of the alternative doctor. The display area of ​​the standby status prompt does not overlap with the display area of ​​the original work task operation interface of the alternative doctor's terminal, and the alternative doctor is allowed to operate its original work task. In the pre-preparation state, the audio and video acquisition module of the alternative doctor terminal is not turned on, and no audio and video data streams are sent to the consultation room.

8. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 7, characterized in that, The continuous monitoring of the consultation status of the selected doctor includes: continuously collecting network latency, packet loss rate, and available bandwidth of the selected doctor's terminal to generate a network quality score; continuously collecting the working status of the audio and video acquisition equipment and the processing resource utilization rate of the selected doctor's terminal to generate a device operation score; and weighting and summing the network quality score and the device operation score to obtain a comprehensive consultation status value. When it is detected that the consultation status of the primary physician does not meet the preset conditions, the current consultation is switched to the alternative physician who is in the pre-ready state, including: When the comprehensive consultation status value is lower than the preset safety threshold, the current network quality score and device operation score of the candidate doctor terminal are obtained through the low-power signaling keep-alive channel. When the current network quality score and device operation score of the alternative doctor terminal meet the preset connection conditions, an activation command is sent through the low-power signaling keep-alive channel to open the audio and video channel of the alternative doctor terminal and switch the consultation data stream from the primary doctor terminal to the alternative doctor terminal. Before the switch is completed, a switch prompt message is sent to the primary doctor's terminal.

9. The method for dynamic scheduling of remote consultation physician resources for two-way referral within medical consortia as described in claim 1, characterized in that, The method further includes: During the consultation, the consultation audio is transcribed in real time, and semantic recognition is performed on the transcribed text. When a semantic fragment representing a referral decision is identified from the transcribed text, the system queries whether the primary physician is qualified to admit the patient. If the primary physician does not meet the acceptance criteria, then check whether the alternative physicians meet the acceptance criteria. If the candidate doctor also does not meet the receiving conditions, then a supplementary doctor who meets the receiving conditions will be selected from the registered doctors in the medical alliance, and a receiving preparation list containing the patient's diagnosis and treatment data and referral suggestions will be sent to the supplementary doctor's terminal. Before the consultation ends, a referral guidance plan containing recommended recipient information is generated based on the query results of the receiving criteria.

10. A dynamic scheduling system for remote consultation physician resources for two-way referral within medical consortia, characterized in that: The remote consultation doctor resource dynamic scheduling system for two-way referral within a medical consortium includes: a memory, a processor, and a remote consultation doctor resource dynamic scheduling program for two-way referral within a medical consortium stored in the memory and executable on the processor. The remote consultation doctor resource dynamic scheduling program for two-way referral within a medical consortium is configured to implement the steps of the remote consultation doctor resource dynamic scheduling method for two-way referral within a medical consortium as described in any one of claims 1 to 9.

Images