Online inquiry data intelligent analysis system based on big data

Abstract

The invention belongs to the technical field of online inquiry, and provides an online inquiry data intelligent analysis system based on big data, which aims to solve the problems of slow response of emergency scenes and waste of non-emergency scene resources, and comprises three core modules: a data feature acquisition module, a medical keyword library identification character emergency keyword classification module, a medical keyword database analysis module and a data processing module, a lightweight 1D-CNN is used for recognizing the emergency probability of the physiological signal and grading the emergency probability, the three are fused after periodic data are processed, and real-time stream / periodic static data are recognized; the strategy rule base construction and dynamic updating module is used for establishing an emergency degree-data type-resource response two-dimensional rule base based on the grading result and the data type, storing the rule base in a Redis cluster and setting the rule base in an online updating mechanism; the medical resource pool dynamic scheduling and management module manages doctors / computing power pools in a layered manner and dynamically allocates resources according to a rule base; and efficient response of emergency treatment and accurate utilization of medical resources are realized.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of online consultation, and in particular to an online consultation data intelligent analysis system based on big data. BACKGROUND

[0002] With the rapid development of Internet medical treatment, online consultation has become an important supplement to medical services due to its convenience and timeliness, and is widely used in the follow-up of chronic diseases, daily health consultation and preliminary screening of emergency situations. However, the current online consultation data intelligent analysis system still has many technical defects, which cannot meet the clinical actual needs: Multi-modal consultation data processing is not accurate, and the emergency degree is large: online consultation data covers multi-modal data such as text complaints (such as patient symptom description), time-series physiological signals (such as electrocardiogram, blood pressure waveform), periodic static data (such as weekly blood glucose records of patients with chronic diseases), etc. The existing system mainly processes single type of data (such as relying on text keywords to determine the emergency degree), and does not realize the fusion of multi-modal data, which is easy to cause emergency degree misjudgment due to one-sided information - for example, only through the "chest tightness" text description, the ordinary symptom is misjudged, the ST segment elevation signal of electrocardiogram is missed in the judgment of acute myocardial infarction, or the periodic blood glucose fluctuation of patients with chronic diseases is misjudged as an emergency, causing invalid calling of medical resources.

[0003] Resource response strategy is rigid, and emergency delay and resource waste coexist: the existing system mainly adopts fixed resource allocation mode, and lacks dynamic adaptation mechanism of "scene-resource". On the one hand, emergency scenes (such as sudden chest pain) need to respond in seconds, but fixed flow processing link (such as redundant disk storage and full model reasoning) leads to delay of more than 30 seconds, which delays the treatment; on the other hand, non-emergency scenes (such as common cold consultation and chronic disease routine follow-up) excessively pursue real-time, occupy high computing power resources (such as GPU) and high seniority doctor time, which causes idle rate of computing power more than 60%, mismatch of doctor resources, and increases medical cost.

[0004] The rule base lacks dynamic updating ability and has poor adaptability: the resource scheduling rules of the existing system are mainly static configuration (such as fixed "emergency corresponding to chief physician"), which cannot adapt to the changes of clinical scenes in real time - for example, the new emergency type (such as new respiratory emergency) is not included in the keyword library, and the doctor scheduling adjustment leads to the offline of high seniority doctors, the system cannot update the rules in time, and still allocates resources according to the old strategy, which further aggravates the emergency response delay and resource waste problem.

[0005] In summary, it is urgent to develop an online consultation data intelligent analysis system which can accurately process multi-modal data, dynamically adapt to scene demand and realize efficient scheduling of resources, in order to solve the above technical problems.

[0006] Therefore, the present application provides an online consultation data intelligent analysis system based on big data. SUMMARY

[0007] To make up for the deficiencies of the prior art, at least one technical problem raised in the background art is solved.

[0008] The technical scheme adopted by the present application to solve its technical problems is: One of the purposes of the present application is to provide an online consultation data intelligent analysis system based on big data, comprising: The data feature acquisition module: constructs a medical keyword library, identifies medical emergency keywords in online consultation text data, processes according to the identification results, identifies the probability of emergency in the time sequence physiological signal in the online consultation text by designing a lightweight 1D-CNN model, and processes according to the probability of emergency; identify periodic data in online consultation text and process, and fuse Chinese data and time sequence physiological signal to identify real-time flow data and periodic static data two online consultation text data types; The strategy rule library construction and dynamic updating module: based on the hierarchical processing results and the online consultation text data type, constructs the emergency degree-data type-resource response strategy rule library, and sets an online updating mechanism for the emergency degree-data type-resource response strategy rule library to cope with high concurrency scenarios; The medical resource pool dynamic scheduling and management module: establishes a doctor resource pool management and dynamic allocation mechanism, and dynamically allocates doctor resources in combination with the emergency degree-data type-resource response strategy rule library, establishes a hierarchical and containerized management mechanism for the computing power resource pool to meet the computing power resource demand in the emergency degree-data type-resource response strategy rule library.

[0009] As a further improved scheme, the specific process of identifying medical emergency keywords in online consultation text data according to the identification results and processing according to the identification results is: According to the historical online consultation text data, extract medical emergency keywords; And use Trie tree data structure to store medical emergency keywords, insert all medical emergency keywords in medical keyword library into Trie tree; each node of Trie tree stores 1 character, the path from root node to leaf node constitutes complete keyword, realizes linear time complexity matching of text medical emergency keywords, ensures millisecond level matching speed; the leaf node additionally records the emergency degree weight and associated medical emergency name of the medical emergency keyword; First, preprocess the Chinese data in the patient's online consultation text, remove punctuation, stop words, and keep core medical words; Using the Trie tree matching method, the core medical terms in the preprocessed online consultation text are sequentially input into the Trie tree to match all medical emergency keywords and their urgency weights in the online consultation. The urgency weights of all medical emergency keywords are summed. If the total number of medical emergency keywords is greater than or equal to 0.8, it is marked as the highest priority; If the total number of medical emergency keywords is less than 0.8 and greater than or equal to 0.3, it is marked as medium priority; If the total number of medical emergency keywords is less than 0.3, it is marked as low priority.

[0010] As a further improvement, the specific process for identifying the probability of acute conditions in temporal physiological signals within online consultation text is as follows: Temporal physiological signals include, but are not limited to: electrocardiogram, blood pressure waveform, and blood oxygen saturation curve; Preprocessing of temporal physiological signals involves capturing a 30-second sliding time window in real time, normalizing the waveform data within the sliding time window, mapping the data to the [−1,1] interval, and eliminating baseline drift and dimensional differences among different patients and devices. Normalized temporal physiological signals are used as input to a lightweight 1D-CNN model; The lightweight 1D-CNN model consists of 3 convolutional layers, 2 max pooling layers, and the final output layer uses the sigmoid activation function to output the probability of whether it is an acute condition.

[0011] As a further improvement, the specific process of grading based on the probability of an emergency is as follows: A lightweight 1D-CNN model was trained using temporal physiological signals from historical online medical consultation texts. The accuracy of the lightweight 1D-CNN model was verified using a test set, and it met the accuracy requirements. Among them, the lightweight 1D-CNN model has fewer than 100,000 parameters, ensuring that the inference time for a single sample is within the preset time. If the acute probability output by the lightweight 1D-CNN model is greater than or equal to 0.8, it is marked as the highest priority; If the acute probability output by the lightweight 1D-CNN model is greater than or equal to 0.3 and less than 0.8, it is marked as medium priority; if the acute probability output by the lightweight 1D-CNN model is less than 0.3, it is marked as low priority.

[0012] As a further improvement, the specific process of identifying periodic data in online consultation texts and performing hierarchical processing is as follows: Periodic data, including but not limited to: weekly blood glucose and blood pressure records of patients with chronic diseases; extracting the upload timestamps of periodic data from patients' online consultation texts and parsing them into year-month-day format; Obtain the upload timestamps of the patient's last 10 similar data uploads, and calculate the time interval between two adjacent uploads; If the time interval between three consecutive uploads follows a fixed periodic pattern, the data is considered periodic; otherwise, it is considered non-periodic. Obtain the patient's three most recent periodic data of the same type; Calculate the standard deviation of these three periodic data points, and simultaneously check if there are any critical values ​​among these three periodic data points: if any periodic data point is greater than or equal to the first critical value, or less than or equal to the second critical value, then trigger the critical value flag; If the periodic data in the online consultation text is periodic and there are no critical values, and the standard deviation is less than the standard deviation threshold, it is marked as medium priority; If the standard deviation of periodic data in the online consultation text is greater than or equal to the standard deviation threshold or there is a critical value, it is marked as the highest priority; If the periodic data in the online consultation text is non-periodic but contains critical values, it is marked as the highest priority.

[0013] As a further improvement, the specific process of fusing Chinese character data and temporal physiological signals to identify two types of online consultation text data—real-time streaming data and periodic static data—is as follows: The feature vectors of text data and physiological signals are mapped to the same dimension through a linear transformation layer, resulting in... , ; Calculate the attention weights of text data and physiological signals to obtain the attention weights of text data and physiological signals. , ; The attention weights of text data and physiological signals are fused into a feature vector: ; The fused feature vectors are input into the Softmax classification layer in a lightweight 1D-CNN model, which outputs type labels for real-time streaming data or periodic static data.

[0014] As a further improvement, the specific process of constructing the urgency-data type-resource response strategy rule base is as follows: An urgency-data type-resource response policy rule base is constructed, using RedisCluster as the storage engine, and a refined key-value data model is designed. The key of the urgency-data type-resource response strategy rule base adopts a string combination of urgency priority and data type to cover the scenario division of both urgency and data type. Highest priority – real-time stream: for emergency diagnosis scenarios; Medium priority - periodic static: corresponds to routine follow-up scenarios for chronic diseases; Low priority - periodic static: corresponds to ordinary non-emergency scenarios; The value, in JSON format, contains the following key fields: Prioritize physician resources: Clearly define the physician ranks that need to be deployed to ensure that senior physicians are given priority in emergency scenarios; Response time requirements: Define the maximum time required for doctors to complete a response, matching the timeliness requirements of different scenarios; Computing resource requirements: Specify the required computing power type and resource pool to achieve precise scheduling of computing power; Result presentation format: Define the output method of diagnostic results to meet the information transmission needs of different scenarios; Doctor resource pool identifier: Associated with specific doctor groups, providing precise targets for doctor allocation in the dynamic scheduling and management module of the medical resource pool; Computing resource pool identifier: Associated with specific computing power groups, providing a direct basis for computing power scheduling in the dynamic scheduling and management module of the medical resource pool; Notification triggering method: Define the notification channels between doctors and patients to ensure timely response; A Redis Cluster with 3 masters and 3 slaves is deployed, and data sharding is performed using consistent hashing to avoid single-node hotspots and performance bottlenecks; RDB and AOF hybrid persistence is enabled to ensure that rules are not lost after service restart; the heartbeat detection interval between cluster nodes is set to 100ms to ensure rapid detection and switching of faulty nodes.

[0015] As a further improvement, the specific process of setting the online update mechanism for the urgency-data type-resource response strategy rule base is as follows: Develop a web-based management interface to support operations and maintenance personnel or clinical experts in the full lifecycle management of rules in the urgency-data type-resource response strategy rule base, including adding, modifying, deleting, and querying rules. Adding a new rule: Users select the urgency priority and data type from the drop-down list, fill in all the Value fields for doctor resource priority and response time requirements, and then submit to trigger the rule synchronization process; Rule modification: After retrieving the target rule by combining keys, you can modify any value field. After submission, the corresponding value in Redis will be updated in real time. Rule deletion: After locating the target rule by key combination, confirm the deletion operation, and the corresponding key-value pair will be immediately removed from Redis; Rule Query: Supports fuzzy / precise queries by urgency priority, data type, or key combination, and displays all policies in the current rule base.

[0016] As a further improvement, the specific process of dynamically allocating doctor resources is as follows: Based on the doctor resource priority dynamically allocated according to the urgency-data type-resource response strategy rule base, doctors are divided into three target resource pools: Chief Physician Pool: Includes physicians with senior professional titles and experience in emergency and critical care, covering cardiology and emergency departments; Attending Physician Pool: Includes doctors with intermediate professional titles and the ability to manage common and chronic diseases, covering internal medicine and general practice; The resident physician pool includes doctors with junior professional titles who are responsible for routine consultations and follow-ups; each resource pool is associated with the doctor resource priority field in the urgency-data type-resource response strategy rule base to ensure that strategy instructions can accurately target the target pool. Employing WebSocket long-lived connections and heartbeat detection technology, the system monitors doctors' online status and current workload in real time. Establish a WebSocket persistent connection for each doctor's workstation. The server sends a heartbeat packet to the client every 5 seconds. If no response is received from the client for 3 consecutive times, the doctor is marked as offline. If a response is received, the doctor is marked as online. When a doctor sees a patient, the workbench sends a start signal to the server; when the patient finishes the consultation or the doctor marks the consultation as complete, a finish signal is sent; the server counts the number of patients each doctor is seeing in real time as a load indicator. Select doctors from the target resource pool who are currently online and have the lowest workload; If all doctors in the target resource pool are under high load, load preemption will be triggered: Select the doctor with the highest load in the target resource pool who is treating patients in non-emergency scenarios, and push an emergency task preemption prompt to their workbench. If a doctor confirms the transfer, the system automatically assigns the current non-emergency patient to the doctor with the second lowest load in the same target resource pool, and immediately assigns the emergency patient to that doctor; if the doctor refuses the transfer, the system continues to screen other doctors in the same pool; if there are no available doctors in the entire pool, cross-target resource pool scheduling is triggered, and a senior doctor with emergency capabilities is selected from the attending physician pool for temporary support.

[0017] As a further improvement, the specific process for establishing a hierarchical and containerized management mechanism for computing resource pools is as follows: Based on the computing resource requirements in the urgency-data type-resource response strategy rule base, computing power is divided into three computing resource pools: Dedicated GPU resource pool: reserved for the highest priority - real-time streaming scenarios, including 4 NVIDIA T4 GPUs; each GPU is divided into 4 dedicated cores through Kubernetes container orchestration technology, and a GuaranteedQoS-level Pod is created for each dedicated core, with a GPU limit of 0.25 cores; Shared CPU resource pool: for medium-priority - periodic static scenarios, containing a 16-core Intel Xeon CPU; through container sharing mechanism, it allows multiple regular tasks to share CPU threads in a time-sharing manner; Idle CPU resource pool: for low-priority, periodic static scenarios, it utilizes the idle computing power period from 1:00 AM to 3:00 AM and includes an 8-core Intel Xeon CPU. Containerized scheduling and resource isolation utilize Kubernetes for containerized management of computing resources. Create a Guaranteed QoS-level Pod for each dedicated core in the dedicated GPU resource pool, setting a CPU limit of 0.25 cores and a GPU limit of 1 core; Create a Burstable QoS-level Pod for the shared CPU resource pool, set CPU requests to 0.1 cores and CPU limits to 0.5 cores, and allow tasks to burst to higher computing power when idle; Create Pods with BestEffort QoS level for the CPU resource pool during idle periods, without setting fixed computing power limits; If it is a dedicated GPU core, the K8s scheduler selects an idle Guaranteed Pod from the dedicated GPU resource pool, submits the lightweight 1D-CNN model inference task to the Pod, and binds the GPU core; If it is a shared CPU thread, the scheduler selects a Burstable Pod from the shared CPU resource pool and submits the task to the Pod with the lowest load based on the current computing power load; If it is a CPU thread during an idle period, the scheduler will put the task into the delayed task queue, set the trigger time to 2:00 AM, and dynamically select the time with the lowest load based on the computing power load monitored by Prometheus during the idle period. The default fallback time is 2:00 AM, at which time it will be submitted to the BestEffort Pod in the idle resource pool. During task execution, the Pod status is monitored via Kubernetes probes; if the Pod is abnormal, the Pod is immediately restarted and the task is rescheduled. Once the task is completed, Kubernetes automatically releases the Pod resources for use by subsequent tasks.

[0018] The second objective of this invention is to provide an intelligent analysis method for online medical consultation data based on big data, including: S1: Construct a medical keyword database to identify medical emergency keywords in the text data of online consultations. Based on the identification results, perform hierarchical processing. Design a lightweight 1D-CNN model to identify the probability of emergencies in the temporal physiological signals of online consultations and perform hierarchical processing according to the probability of emergencies. Identify periodic data in online consultations and perform hierarchical processing. Merge Chinese text data and temporal physiological signals to identify two types of online consultation text data: real-time streaming data and periodic static data. S2: Based on the hierarchical processing results and the data types of online consultation text, construct an urgency-data type-resource response strategy rule base, and set up an online update mechanism for the urgency-data type-resource response strategy rule base to cope with high concurrency scenarios; S3: Establish a doctor resource pool management and dynamic allocation mechanism, and dynamically allocate doctor resources in conjunction with the urgency-data type-resource response strategy rule base. Establish a hierarchical and containerized management mechanism for the computing power resource pool to meet the computing power resource requirements in the urgency-data type-resource response strategy rule base.

[0019] The beneficial effects of this invention are as follows: Improve the accuracy of disease urgency assessment and reduce the risk of misjudgment: Through the data feature acquisition module, multimodal fusion processing of text data, time-series physiological signals and periodic data is achieved, and real-time streaming / periodic static data types are identified. This avoids the one-sidedness of information caused by a single data modality, making the urgency classification more comprehensive and accurate, and providing a reliable basis for subsequent resource allocation.

[0020] Based on the strategy rule base construction and dynamic update module, the rule base is built with two dimensions: urgency and data type. Combined with the Redis Cluster distributed cluster, it ensures millisecond-level queries under high concurrency, and the online update mechanism adapts to changes in clinical scenarios. The medical resource pool dynamic scheduling and management module allocates doctors and computing resources in a hierarchical manner, which not only ensures a response time of ≤30 seconds in emergency scenarios, but also reduces the idle rate of computing power and the mismatch of doctor resources in non-emergency scenarios, thereby reducing the waste of medical resources. Attached Figure Description

[0021] The invention will now be further described with reference to the accompanying drawings.

[0022] Figure 1 This is a system module diagram of the online consultation data intelligent analysis system based on big data, which is the subject of this invention. Figure 2This is a flowchart of the steps of the intelligent analysis method for online consultation data based on big data according to the present invention. Detailed Implementation

[0023] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0024] Example 1 like Figure 1 As shown in the embodiment of the present invention, the online consultation data intelligent analysis system based on big data includes: Data Feature Acquisition Module: Constructs a medical keyword database to identify medical emergency keywords in Chinese text data of online consultations. Based on the identification results, it performs hierarchical processing. By designing a lightweight 1D-CNN model, it identifies the probability of emergency in temporal physiological signals in online consultations and performs hierarchical processing based on the probability of emergency. It also identifies periodic data in online consultations and performs hierarchical processing. Furthermore, it fuses Chinese text data and temporal physiological signals to identify two types of online consultation text data: real-time streaming data and periodic static data. For medical emergency keywords in online consultation text data, building a medical keyword database is fundamental to quickly identifying these keywords. The specific process for building this database is as follows: The medical keyword database was built by extracting medical emergency keywords from text data in historical online consultations. For example, it covers more than 500 medical emergency keywords such as "chest pain", "difficulty breathing", "loss of consciousness" and "massive bleeding". The system employs a Trie tree data structure to store medical emergency keywords. All medical emergency keywords from the medical keyword database (such as "sudden chest pain," "ventricular fibrillation," and "progressive dyspnea") are inserted into the Trie tree. Each node in the Trie tree stores one character, and the path from the root node to a leaf node constitutes a complete keyword, achieving linear time complexity matching of text-based medical emergency keywords and ensuring millisecond-level matching speed. The leaf nodes additionally record the urgency weight of the medical emergency keywords (e.g., "ST segment elevation" has a weight of 1.0, "chest tightness" has a weight of 0.7, and "fatigue" has a weight of 0.2; this invention does not limit the urgency weight) and the associated medical emergency names (e.g., "sudden chest pain," "ventricular fibrillation," and "progressive dyspnea"). After constructing the medical keyword database, it is necessary to quickly identify medical emergency keywords in online consultation texts to rapidly identify patient symptoms. Based on the identification results, the keywords are then categorized. The specific categorization process is as follows: For example, in the patient's online consultation text: "The patient is a 56-year-old male who suddenly experienced crushing chest pain 10 minutes ago, accompanied by profuse sweating, and reported feeling like he was about to die." First, the text data in the patient's online consultation text is preprocessed to remove punctuation and stop words (such as "patient" and "self-report"), while retaining core medical terms: "sudden onset", "crushing chest pain", "profuse sweating", and "sense of impending death". Using the Trie tree matching method, the core medical terms in the preprocessed online consultation text are sequentially input into the Trie tree to match all medical emergency keywords in the online consultation, such as "crushing chest pain" and the urgency weight (urgency weight 1.0) of the medical emergency keywords, such as "sense of impending death" (associated with acute myocardial infarction, urgency weight 1.0). The urgency weights of all medical emergency keywords are summed. If the total number of medical emergency keywords is greater than or equal to 0.8, it is marked as the highest priority; If the total number of medical emergency keywords is less than 0.8 and greater than or equal to 0.3, it is marked as medium priority; If the total number of medical emergency keywords is less than 0.3, it will be marked as low priority; For time-series physiological signals in online consultation texts, a lightweight model needs to be designed to quickly identify these signals, determine the probability of an emergency, and then classify the emergency probabilities identified by the lightweight model. The specific implementation process is as follows: Temporal physiological signals include, but are not limited to, electrocardiograms (ECGs), blood pressure waveforms, and blood oxygen saturation curves. These signals are highly real-time and share the common characteristic of being waveform-like curves, making them difficult to identify. In some embodiments, millisecond-level emergency feature identification is required. Taking an ECG as an example, the implementation details are as follows: First, the temporal physiological signals are preprocessed by capturing a 30-second sliding time window in real time (with a window step of 1 second to ensure continuous monitoring without omission). The waveform data within the sliding time window is normalized and mapped to the [−1,1] interval to eliminate baseline drift and dimensional differences between different patients and different devices. Normalized temporal physiological signals are used as input to a lightweight 1D-CNN model; Secondly, a lightweight 1D-CNN model is designed, consisting of 3 convolutional layers (with kernel sizes of 64, 32, and 16, and stride of 1 for each layer), 2 max pooling layers (with a pooling kernel size of 2), and the final output layer is a sigmoid activation function (outputting the probability of whether it is an emergency, such as the probability of myocardial infarction, ventricular fibrillation, etc.). A lightweight 1D-CNN model was trained using temporal physiological signals from historical online medical consultation texts. The accuracy of the lightweight 1D-CNN model was verified using a test set, and it met the accuracy requirements (test set accuracy must be greater than 92%). Among them, the lightweight 1D-CNN model has fewer than 100,000 parameters, ensuring that the inference time for a single sample is within a preset time (e.g., inference time is less than 20ms). If the acute probability output by the lightweight 1D-CNN model is greater than or equal to 0.8, it is marked as the highest priority; If the acute probability output by the lightweight 1D-CNN model is greater than or equal to 0.3 and less than 0.8, it is marked as medium priority; if the acute probability output by the lightweight 1D-CNN model is less than 0.3, it is marked as low priority. For periodic data in online consultation texts, it is necessary to identify and classify them. The specific identification process is as follows: Periodic data, including but not limited to: weekly blood glucose and blood pressure records for patients with chronic diseases; urgency needs to be analyzed by combining time patterns and historical fluctuations. The implementation steps are as follows: Extract the upload timestamps of periodic data from patients' online consultation texts and parse them into year-month-day format; Obtain the upload timestamps of the patient's last 10 similar data uploads, and calculate the time interval between two adjacent uploads; If the time interval between three consecutive uploads follows a fixed periodic pattern, such as (the upload pattern for blood glucose is 7 days ± 1 day), then it is considered periodic data; otherwise, it is considered non-periodic data. Obtain the patient's three most recent periodic data of the same type (such as fasting blood glucose values ​​over the past three weeks). Calculate the standard deviation of these three periodic data points, and simultaneously detect whether there are any critical values ​​in these three periodic data points: taking blood glucose as an example, if any periodic data point is greater than or equal to the first critical value (high critical value, such as 16.7 mmol / L); or less than or equal to the second critical value (low critical value, such as 3.9 mmol / L), then a critical value marker is triggered; If the periodic data in the online consultation text is periodic and there are no critical values, and the standard deviation is less than the standard deviation threshold (e.g., the blood glucose threshold is set to 2 mmol / L), then it is marked as medium priority. If the standard deviation of periodic data in the online consultation text is greater than or equal to the standard deviation threshold or there is a critical value, it is marked as the highest priority; If the periodic data in the online consultation text is non-periodic but contains critical values, it is marked as the highest priority; The first critical value, the second critical value, and the standard deviation threshold are all reference values ​​set by those skilled in the industry based on historical experience, and this invention does not limit them; After completing the identification and classification of medical emergency keywords in the text data of online consultations and the identification and classification of emergency probabilities in the temporal physiological signals, in order to more comprehensively and accurately determine the urgency of the patient's condition, it is necessary to fuse the classification results of the text data and the temporal physiological signal data. The reason is that textual data can reflect the condition from the perspective of the patient's subjective description of symptoms, while time-series physiological signal data reflects the body's condition from the perspective of objective physiological indicator waveforms. Combining the two can reduce the misjudgment that may occur with a single data modality, thus providing a more reliable basis for subsequent decisions such as the reasonable allocation of doctors' response speed. The specific fusion process is as follows: The feature vectors of text data and physiological signals (dimensions of 192 and 64, respectively) were processed as follows: the feature vector of text data was preprocessed by constructing a medical keyword database, segmented into words in the medical field, and then processed by medical pre-trained word vector mapping, TextCNN model for feature extraction, and global max pooling to obtain a 192-dimensional feature vector; the feature vector of physiological signals (such as electrocardiogram) was truncated by a 30-second sliding window, normalized, and then processed by a lightweight 1D-CNN model for feature extraction and mapping by a fully connected layer to obtain a 64-dimensional feature vector. By mapping it to the same dimension (e.g., 64) through a linear transformation layer, we obtain... , ; Calculate the attention weights of text data and physiological signals to obtain the attention weights of text data and physiological signals. , ; The attention weights of text data and physiological signals are fused into a feature vector: ; The fused feature vectors are input into the Softmax classification layer in the lightweight 1D-CNN model, which outputs type labels for real-time streaming data or periodic static data. The classification task is trained using the cross-entropy loss function, and the classification accuracy on the test set is ≥95%.

[0025] The strategy rule base construction and dynamic update module: Based on the hierarchical processing results and the online consultation text data type, it constructs an urgency-data type-resource response strategy rule base, and sets up an online update mechanism for the urgency-data type-resource response strategy rule base to cope with high concurrency scenarios; The urgency-data type-resource response strategy rule base is the core of this step. It needs to meet the requirements of millisecond-level query, online non-downtime updates, and accurate mapping of multi-dimensional strategies. It adopts a technical architecture with distributed key-value storage, a visual management interface, and a real-time synchronization mechanism. The specific implementation is as follows: To ensure query efficiency and rule scalability in high-concurrency scenarios, an urgency-data type-resource response policy rule base is constructed. A RedisCluster distributed cluster is used as the storage engine for this rule base, and a refined Key-Value data model is designed. The key of the urgency-data type-resource response strategy rule base adopts a string combination of urgency priority and data type to cover the scenario division of both urgency and data type, and avoid resource mismatch caused by a single dimension. Highest priority - real-time stream: for emergency medical scenarios (such as real-time electrocardiogram and symptom text of a patient experiencing sudden chest pain); Medium priority - periodic static: corresponds to routine follow-up scenarios for chronic diseases (such as weekly blood glucose monitoring data for diabetic patients). Low priority - periodic static: corresponds to ordinary non-emergency scenarios (such as historical consultation records for the common cold).

[0026] This two-dimensional combination ensures that the most suitable resource strategy can be matched for specific scenarios such as high urgency but not real-time streaming, and low urgency but requiring timely attention.

[0027] Value uses JSON format and encapsulates core scheduling fields such as doctor resources, response time, computing power resources, result presentation, and notification method, providing ready-to-use instructions for subsequent execution steps; The value, in JSON format, contains the following key fields: Prioritize physician resources: Clearly define the physician ranks that need to be dispatched (such as "Chief Physician", "Attending Physician", "Resident Physician") to ensure that senior physicians are given priority in emergency scenarios; Response time requirements: Define the maximum time required for doctors to complete a response (e.g., "≤30 seconds", "≤2 hours", "≤24 hours") to match the timeliness requirements of different scenarios; Computing resource requirements: Specify the required computing power type and resource pool (such as "dedicated GPU core", "shared CPU thread", "idle period CPU thread") to achieve precise scheduling of computing power; Results presentation format: Define the output method of diagnostic results (such as "pop-up window + red alert 'whether to send to hospital' conclusion", "web-based trend report", "daily summary email") to meet the information delivery needs of different scenarios; Doctor resource pool identifier: Associated with specific doctor groups (e.g., "chief_physician_pool" corresponds to the chief physician pool), providing precise targets for doctor allocation in the dynamic scheduling and management module of the medical resource pool; Computing resource pool identifier: Associated with specific computing power groups (such as "exclusive_gpu_pool" corresponding to a dedicated GPU resource pool), providing a direct basis for computing power scheduling in the dynamic scheduling and management module of the medical resource pool; Notification triggering methods: Define notification channels for doctors and patients (such as "WebSocket real-time pop-up", "email push", "SMS reminder") to ensure timely response.

[0028] A Redis Cluster with 3 masters and 3 slaves is deployed, and data sharding is performed through consistent hashing to avoid single-node hotspots and performance bottlenecks; hybrid persistence of RDB (snapshot) and AOF (AppendOnlyFile) is enabled to ensure that rules are not lost after service restart; the heartbeat detection interval between cluster nodes is set to 100ms to ensure rapid detection and switching of faulty nodes, achieving "99.99% availability" and meeting the high reliability requirements of medical scenarios; Having completed the storage architecture and core data model design of the urgency-data type-resource response strategy rule base, ensuring high reliability and high-concurrency query capabilities, to cope with dynamic changes in clinical scenarios such as the addition of new emergency types, adjustments to doctor scheduling, and optimization of computing power allocation, an efficient online update mechanism needs to be designed for this rule base. This mechanism will enable online modification of the urgency-data type-resource response strategy rule base, with real-time effects and no system restart required. The implementation method is described in detail below: Develop a web-based management interface to support operations and maintenance personnel or clinical experts in the full lifecycle management of rules in the urgency-data type-resource response strategy rule base, including adding, modifying, deleting, and querying rules. Adding a rule: Users select the urgency priority and data type from the drop-down list, fill in all Value fields for doctor resource priority and response time requirements, and then submit the rule to trigger the rule synchronization process (synchronize to all nodes of RedisCluster to ensure the consistency of rules in the distributed cluster; if the synchronization times out, it will retry 3 times; if it fails, an alarm will be pushed to the operation and maintenance platform). Rule modification: After querying the target rule by key combination, you can modify any value field (such as compressing the response time of "highest priority - real-time stream" from "≤30 seconds" to "≤25 seconds"). After submission, the corresponding value in Redis will be updated in real time. Rule deletion: After locating the target rule by key combination, confirm the deletion operation, and the corresponding key-value pair will be immediately removed from Redis; Rule Query: Supports fuzzy / precise queries by urgency priority, data type, or key combination, and displays all policies in the current rule base for easy manual verification and adjustment.

[0029] The Medical Resource Pool Dynamic Scheduling and Management Module establishes a doctor resource pool management and dynamic allocation mechanism, and dynamically allocates doctor resources in conjunction with the urgency-data type-resource response strategy rule base. It also establishes a hierarchical and containerized management mechanism for the computing power resource pool to meet the computing power resource requirements in the urgency-data type-resource response strategy rule base. Based on the doctor resource priority dynamically allocated according to the urgency-data type-resource response strategy rule base, doctors are divided into three target resource pools: Chief Physician Pool: Includes physicians with senior professional titles and experience in emergency and critical care, covering cardiology and emergency departments; Attending Physician Pool: Includes doctors with intermediate professional titles and the ability to manage common and chronic diseases, covering internal medicine and general practice; The resident physician pool includes junior-level physicians responsible for routine consultations and follow-ups; each resource pool (chief physician pool, attending physician pool, and resident physician pool) is associated with the physician resource priority field in the urgency-data type-resource response strategy rule base to ensure that strategy instructions can accurately target the target pool. Employing WebSocket long-lived connections and heartbeat detection technology, the system monitors doctors' online status and current workload in real time. Online status detection: A WebSocket long connection is established for each doctor's workstation (PC / mobile). The server sends a heartbeat packet to the client every 5 seconds. If no response is received from the client for 3 consecutive times, the doctor is marked as offline; if a response is received, the doctor is marked as online. Current load statistics: When a doctor sees a patient, the workbench sends a start signal to the server; when the patient finishes the consultation or the doctor marks the consultation as complete, a finish signal is sent; the server counts the number of patients each doctor is seeing in real time as a load indicator (e.g., "Chief Physician A is seeing 2 patients"). Select the online doctors with the lowest current load from the target resource pool (such as the chief physician pool). For example, if there are 5 online doctors in the chief physician pool with loads of 0, 1, 1, 2, and 2 respectively, then prioritize the doctor with a load of 0. If all doctors in the target resource pool are under high load (the load of all online doctors in the chief physician pool is ≥2), then load preemption will be triggered: Select the doctor with the highest workload in the target resource pool who is treating patients in non-emergency scenarios, and push an emergency task takeover prompt to their workbench (such as a pop-up window displaying "There are emergency patients who need to be treated first. Do you want to transfer the current non-emergency patients to other doctors?"). If a doctor confirms the transfer, the system automatically assigns the current non-emergency patient to the doctor with the second lowest workload within the same target resource pool, and immediately assigns that doctor to the emergency patient; if the doctor refuses the transfer, the system continues to filter other doctors in the same pool; if there are no available doctors in the entire pool, cross-target resource pool scheduling is triggered, and a senior doctor with emergency capabilities is selected from the attending physician pool for temporary support (the 'emergency qualification tag' is 'yes', and this tag is added to eligible doctors when the doctor resource pool is initialized); After the doctor assignment is completed, a doctor assignment certificate is generated, which includes the patient ID, doctor ID, assignment time, urgency level, and strategy source information. This certificate is stored in a distributed database (such as MySQLCluster) for subsequent feedback and auditing. To ensure that doctors can see patients within the required response time, an emergency pop-up window is pushed to the target doctor's workbench. This pop-up includes the patient's basic desensitized information, core symptoms (such as sudden chest pain for 20 minutes), a preliminary judgment from a lightweight 1D-CNN model (such as suspected myocardial infarction), and a countdown timer indicating that the doctor needs to see the patient within 30 seconds. If the doctor's workbench is unresponsive (e.g., no action is taken within 10 seconds after the pop-up appears), a text message will be sent to the doctor's mobile phone (remaining response time = rule base required response time - time already consumed, e.g., 10 seconds of the total 30-second response time has been consumed, 20 seconds remain). The message will be: There is an emergency patient waiting to be seen on the online consultation platform. Patient ID: XXX, core symptom: sudden chest pain. Please log in to the workbench immediately. If a doctor clicks the pop-up consultation button within the required response time (e.g., within 30 seconds), it will be marked as an on-time response; If no action is taken within a timeout period (e.g., 30 seconds), it is marked as a timeout response, triggering load preemption (reassigning the patient to other doctors in the same pool). A hierarchical and containerized management mechanism for computing resource pools is established to meet the computing resource requirements in the urgency-data type-resource response strategy rule base. The specific implementation process is as follows: Based on the computing resource requirements in the urgency-data type-resource response strategy rule base, computing power is divided into three computing resource pools: Dedicated GPU resource pool: reserved for the highest priority - real-time streaming scenarios, including 4 NVIDIA T4 GPUs; each GPU is divided into 4 dedicated cores through Kubernetes (K8s) container orchestration technology, and a Guaranteed QoS level Pod (container group) is created for each dedicated core, with a GPU limit of 0.25 cores set to ensure that emergency tasks have exclusive computing power; Shared CPU resource pool: for medium-priority - periodic static scenarios, containing a 16-core Intel Xeon CPU; through container sharing mechanism, it allows multiple regular tasks to share CPU threads in a time-sharing manner; Idle CPU resource pool: This pool is for low-priority, periodic static scenarios with off-peak scheduling, utilizing the idle computing power period from 1:00 AM to 3:00 AM. It includes an 8-core Intel Xeon CPU (physically isolated from the shared pool to avoid affecting regular tasks). Containerized scheduling and resource isolation utilize Kubernetes for containerized management of computing resources. Create a Guaranteed QoS-level Pod (container group) for each dedicated core of the dedicated GPU resource pool, and set a CPU limit of 0.25 cores and a GPU limit of 1 core to ensure that the computing power of the emergency task is not interfered with by other tasks; Create a Burstable QoS-level Pod for the shared CPU resource pool, set CPU requests to 0.1 cores and CPU limits to 0.5 cores, allowing tasks to burst to higher computing power when idle, and ensuring that the limits are kept within a reasonable range when busy; Create BestEffort QoS-level Pods for the CPU resource pool during idle periods, without setting fixed computing power limits, and fully utilize idle resources; If it is a dedicated GPU core, the K8s scheduler selects an idle Guaranteed Pod from the dedicated GPU resource pool, submits the lightweight 1D-CNN model inference task to the Pod, binds the GPU core, and ensures that the task has exclusive computing power; If it is a shared CPU thread, the scheduler selects a Burstable Pod from the shared CPU resource pool and submits the task to the Pod with the lowest load based on the current computing power load (monitored by Prometheus); If it is a CPU thread during an idle period, the scheduler will put the task into the delayed task queue and set the trigger time to 2:00 AM. Based on the computing load during the idle period (1:00-3:00) monitored by Prometheus, it will dynamically select the time point with the lowest load (such as 1:30) to trigger. The default fallback time is 2:00 AM, at which time it will be submitted to the BestEffort Pod in the idle resource pool. During task execution, the Pod status is monitored using K8s probes (LivenessProbe, ReadinessProbe); if the Pod is abnormal (such as GPU failure), the Pod is immediately restarted and the task is rescheduled. Once the task is completed (such as generating a "whether to send to the hospital" conclusion), K8s automatically releases Pod resources for subsequent tasks, ensuring the recycling of computing resources; Example 2 Based on Example 1, this invention provides an intelligent analysis method for online medical consultation data based on big data, including: S1: Construct a medical keyword database to identify medical emergency keywords in the text data of online consultations. Based on the identification results, perform hierarchical processing. Design a lightweight 1D-CNN model to identify the probability of emergencies in the temporal physiological signals of online consultations and perform hierarchical processing according to the probability of emergencies. Identify periodic data in online consultations and perform hierarchical processing. Merge Chinese text data and temporal physiological signals to identify two types of online consultation text data: real-time streaming data and periodic static data. S2: Based on the hierarchical processing results and the data types of online consultation text, construct an urgency-data type-resource response strategy rule base, and set up an online update mechanism for the urgency-data type-resource response strategy rule base to cope with high concurrency scenarios; S3: Establish a doctor resource pool management and dynamic allocation mechanism, and dynamically allocate doctor resources in conjunction with the urgency-data type-resource response strategy rule base. Establish a hierarchical and containerized management mechanism for the computing power resource pool to meet the computing power resource requirements in the urgency-data type-resource response strategy rule base.

[0030] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. An online consultation data intelligent analysis system based on big data, characterized by: include: Data Feature Acquisition Module: Constructs a medical keyword database, identifies medical emergency keywords in the text data of online consultations, and performs hierarchical processing based on the identification results. By designing a lightweight 1D-CNN model, it identifies the probability of emergencies in the temporal physiological signals of online consultations and performs hierarchical processing based on the probability of emergencies. It also identifies periodic data in online consultations, performs hierarchical processing, and fuses Chinese text data and temporal physiological signals to identify two types of online consultation text data: real-time streaming data and periodic static data. The strategy rule base construction and dynamic update module: Based on the hierarchical processing results and the online consultation text data type, it constructs an urgency-data type-resource response strategy rule base, and sets up an online update mechanism for the urgency-data type-resource response strategy rule base to cope with high concurrency scenarios; The Medical Resource Pool Dynamic Scheduling and Management Module establishes a doctor resource pool management and dynamic allocation mechanism, and dynamically allocates doctor resources in conjunction with the urgency-data type-resource response strategy rule base. It also establishes a hierarchical and containerized management mechanism for the computing power resource pool to meet the computing power resource requirements in the urgency-data type-resource response strategy rule base.

2. The online consultation data intelligent analysis system based on big data according to claim 1, characterized in that: The specific process of identifying medical emergency keywords in the text data of online consultations and performing hierarchical processing based on the identification results is as follows: Extract medical emergency keywords from text data in historical online consultations; The system uses a Trie tree data structure to store medical emergency keywords. All medical emergency keywords in the medical keyword library are inserted into the Trie tree. Each node of the Trie tree stores one character. The path from the root node to the leaf node constitutes a complete keyword, achieving linear time complexity matching of text medical emergency keywords and ensuring millisecond-level matching speed. The leaf nodes additionally record the urgency weight of the medical emergency keywords and the associated medical emergency name. First, the text data in the patient's online consultation text is preprocessed to remove punctuation and stop words, while retaining core medical vocabulary; Using the Trie tree matching method, the core medical terms in the preprocessed online consultation text are sequentially input into the Trie tree to match all medical emergency keywords and their urgency weights in the online consultation. The urgency weights of all medical emergency keywords are summed. If the total number of medical emergency keywords is greater than or equal to 0.8, it is marked as the highest priority; If the total number of medical emergency keywords is less than 0.8 and greater than or equal to 0.3, it is marked as medium priority; If the total number of medical emergency keywords is less than 0.3, it is marked as low priority.

3. The intelligent analysis system for online medical consultation data based on big data according to claim 1, characterized in that: The specific process for identifying the probability of acute conditions in temporal physiological signals within online consultation text is as follows: Temporal physiological signals include, but are not limited to: electrocardiogram, blood pressure waveform, and blood oxygen saturation curve; Preprocessing of temporal physiological signals involves capturing a 30-second sliding time window in real time, normalizing the waveform data within the sliding time window, mapping the data to the [−1,1] interval, and eliminating baseline drift and dimensional differences among different patients and devices. Normalized temporal physiological signals are used as input to a lightweight 1D-CNN model; The lightweight 1D-CNN model consists of 3 convolutional layers, 2 max pooling layers, and the final output layer uses the sigmoid activation function to output the probability of whether it is an acute condition.

4. The online consultation data intelligent analysis system based on big data according to claim 1, characterized in that: The specific process for grading cases based on the probability of emergency is as follows: A lightweight 1D-CNN model was trained using temporal physiological signals from historical online medical consultation texts. The accuracy of the lightweight 1D-CNN model was verified using a test set, and it met the accuracy requirements. Among them, the lightweight 1D-CNN model has fewer than 100,000 parameters, ensuring that the inference time for a single sample is within the preset time. If the acute probability output by the lightweight 1D-CNN model is greater than or equal to 0.8, it is marked as the highest priority; If the acute probability output by the lightweight 1D-CNN model is greater than or equal to 0.3 and less than 0.8, it is marked as medium priority; if the acute probability output by the lightweight 1D-CNN model is less than 0.3, it is marked as low priority.

5. The intelligent analysis system for online medical consultation data based on big data according to claim 1, characterized in that: The specific process of identifying periodic data in online consultation texts and performing hierarchical processing is as follows: Periodic data, including but not limited to: weekly blood glucose and blood pressure records of patients with chronic diseases; extracting the upload timestamps of periodic data from patients' online consultation texts and parsing them into year-month-day format; Obtain the upload timestamps of the patient's last 10 similar data uploads, and calculate the time interval between two adjacent uploads; If the time interval between three consecutive uploads follows a fixed periodic pattern, the data is considered periodic; otherwise, it is considered non-periodic. Obtain the patient's three most recent periodic data of the same type; Calculate the standard deviation of these three periodic data points, and at the same time check whether there is a critical value among these three periodic data points: if any periodic data point is greater than or equal to the first critical value; If the value is less than or equal to the second critical value, then the critical value flag is triggered; If the periodic data in the online consultation text is periodic and there are no critical values, and the standard deviation is less than the standard deviation threshold, it is marked as medium priority; If the standard deviation of periodic data in the online consultation text is greater than or equal to the standard deviation threshold or there is a critical value, it is marked as the highest priority; If the periodic data in the online consultation text is non-periodic but contains critical values, it is marked as the highest priority.

6. The intelligent analysis system for online medical consultation data based on big data according to claim 1, characterized in that: The specific process of fusing Chinese character data and temporal physiological signals to identify two types of online consultation text data—real-time streaming data and periodic static data—is as follows: The feature vectors of text data and physiological signals are mapped to the same dimension through a linear transformation layer, resulting in... , ; Calculate the attention weights of text data and physiological signals to obtain the attention weights of text data and physiological signals. , ; The attention weights of text data and physiological signals are fused into a feature vector: ; The fused feature vectors are input into the Softmax classification layer in a lightweight 1D-CNN model, which outputs type labels for real-time streaming data or periodic static data.

7. The online consultation data intelligent analysis system based on big data according to claim 1, characterized in that: The specific process for constructing the urgency-data type-resource response strategy rule base is as follows: An urgency-data type-resource response policy rule base is constructed, using RedisCluster as the storage engine, and a refined key-value data model is designed. The key of the urgency-data type-resource response strategy rule base adopts a string combination of urgency priority and data type to cover the scenario division of both urgency and data type. Highest priority – real-time stream: for emergency diagnosis scenarios; Medium priority - periodic static: corresponds to routine follow-up scenarios for chronic diseases; Low priority - periodic static: corresponds to ordinary non-emergency scenarios; The value, in JSON format, contains the following key fields: Prioritize physician resources: Clearly define the physician ranks that need to be deployed to ensure that senior physicians are given priority in emergency scenarios; Response time requirements: Define the maximum time required for doctors to complete a response, matching the timeliness requirements of different scenarios; Computing resource requirements: Specify the required computing power type and resource pool to achieve precise scheduling of computing power; Result presentation format: Define the output method of diagnostic results to meet the information transmission needs of different scenarios; Doctor resource pool identifier: Associated with specific doctor groups, providing precise targets for doctor allocation in the dynamic scheduling and management module of the medical resource pool; Computing resource pool identifier: Associated with specific computing power groups, providing a direct basis for computing power scheduling in the dynamic scheduling and management module of the medical resource pool; Notification triggering method: Define the notification channels between doctors and patients to ensure timely response; A Redis Cluster with 3 masters and 3 slaves is deployed, and data sharding is performed using consistent hashing to avoid single-node hotspots and performance bottlenecks; hybrid persistence of RDB and AOF is enabled to ensure that rules are not lost after service restart; Set the heartbeat detection interval between cluster nodes to 100ms to ensure rapid detection and switching of faulty nodes.

8. The online consultation data intelligent analysis system based on big data according to claim 1, characterized in that: The specific process for setting the online update mechanism of the urgency-data type-resource response strategy rule base is as follows: Develop a web-based management interface to support operations and maintenance personnel or clinical experts in the full lifecycle management of rules in the urgency-data type-resource response strategy rule base, including adding, modifying, deleting, and querying rules. Adding a new rule: Users select the urgency priority and data type from the drop-down list, fill in all the Value fields for doctor resource priority and response time requirements, and then submit to trigger the rule synchronization process; Rule modification: After retrieving the target rule by combining keys, you can modify any value field. After submission, the corresponding value in Redis will be updated in real time. Rule deletion: After locating the target rule by key combination, confirm the deletion operation, and the corresponding key-value pair will be immediately removed from Redis; Rule Query: Supports fuzzy / precise queries by urgency priority, data type, or key combination, and displays all policies in the current rule base.

9. The online consultation data intelligent analysis system based on big data according to claim 1, characterized in that: The specific process of dynamically allocating doctor resources is as follows: Based on the doctor resource priority dynamically allocated according to the urgency-data type-resource response strategy rule base, doctors are divided into three target resource pools: Chief Physician Pool: Includes physicians with senior professional titles and experience in emergency and critical care, covering cardiology and emergency departments; Attending Physician Pool: Includes doctors with intermediate professional titles and the ability to manage common and chronic diseases, covering internal medicine and general practice; The resident physician pool includes doctors with junior professional titles who are responsible for routine consultations and follow-ups; each resource pool is associated with the doctor resource priority field in the urgency-data type-resource response strategy rule base to ensure that strategy instructions can accurately target the target pool. Employing WebSocket long-lived connections and heartbeat detection technology, the system monitors doctors' online status and current workload in real time. Establish a WebSocket long connection for each doctor's workstation, with the server sending a heartbeat packet to the client every 5 seconds; If no response is received from the client three times in a row, the doctor is marked as offline; if a response is received, the doctor is marked as online. When a doctor sees a patient, the workbench sends a start signal to the server; when the patient finishes the consultation or the doctor marks the consultation as complete, a finish signal is sent; the server counts the number of patients each doctor is seeing in real time as a load indicator. Select doctors from the target resource pool who are currently online and have the lowest workload; If all doctors in the target resource pool are under high load, load preemption will be triggered: Select the doctor with the highest load in the target resource pool who is treating patients in non-emergency scenarios, and push an emergency task preemption prompt to their workbench. If a doctor confirms the transfer, the system will automatically assign the current non-emergency patient to the doctor with the second lowest load in the same target resource pool, and immediately assign the emergency patient to that doctor. If a doctor refuses to transfer, the system continues to screen other doctors in the same pool; if there are no available doctors in the entire pool, cross-target resource pool scheduling is triggered, and a senior doctor with emergency care capabilities is selected from the attending physician pool for temporary support.

10. The intelligent analysis system for online medical consultation data based on big data according to claim 1, characterized in that: The specific process for establishing the hierarchical and containerized management mechanism for the computing power resource pool is as follows: Based on the computing resource requirements in the urgency-data type-resource response strategy rule base, computing power is divided into three computing resource pools: Dedicated GPU resource pool: reserved for the highest priority - real-time streaming scenarios, including 4 NVIDIA T4 GPUs; each GPU is divided into 4 dedicated cores through Kubernetes container orchestration technology, and a Guaranteed QoS-level Pod is created for each dedicated core, with a GPU limit of 0.25 cores; Shared CPU resource pool: for medium-priority - periodic static scenarios, containing a 16-core Intel Xeon CPU; through container sharing mechanism, it allows multiple regular tasks to share CPU threads in a time-sharing manner; Idle CPU resource pool: for low-priority, periodic static scenarios, it utilizes the idle computing power period from 1:00 AM to 3:00 AM and includes an 8-core Intel Xeon CPU. Containerized scheduling and resource isolation utilize Kubernetes for containerized management of computing resources. Create a Guaranteed QoS-level Pod for each dedicated core in the dedicated GPU resource pool, setting a CPU limit of 0.25 cores and a GPU limit of 1 core; Create a Burstable QoS-level Pod for the shared CPU resource pool, set CPU requests to 0.1 cores and CPU limits to 0.5 cores, and allow tasks to burst to higher computing power when idle; Create Pods with BestEffort QoS level for the CPU resource pool during idle periods, without setting fixed computing power limits; If it is a dedicated GPU core, the K8s scheduler selects an idle Guaranteed Pod from the dedicated GPU resource pool, submits the lightweight 1D-CNN model inference task to the Pod, and binds the GPU core; If it is a shared CPU thread, the scheduler selects a Burstable Pod from the shared CPU resource pool and submits the task to the Pod with the lowest load based on the current computing power load; If it is a CPU thread during an idle period, the scheduler will put the task into the delayed task queue, set the trigger time to 2:00 AM, and dynamically select the time with the lowest load based on the computing power load monitored by Prometheus during the idle period. The default fallback time is 2:00 AM, at which time it will be submitted to the BestEffort Pod in the idle resource pool. During task execution, the Pod status is monitored via Kubernetes probes; if the Pod is abnormal, the Pod is immediately restarted and the task is rescheduled. Once the task is completed, Kubernetes automatically releases the Pod resources for use by subsequent tasks.

Images