Large-scale medical advice reminding method based on artificial intelligence

Abstract

The invention relates to the technical field of medical informatization, in particular to a large-scale medical advice reminding method based on artificial intelligence, and the method comprises the steps: utilizing a dynamic partition controller and a priority scheduling engine of an edge calculation node, predicting a message load through a lightweight LSTM model, dynamically adjusting the Kafka partition configuration, and guaranteeing the zero-delay processing of a key task; the system calculates a load value according to characteristics such as a postoperative state and a chronic disease sign, and triggers a partition redistribution mechanism in combination with an overstocked risk level; meanwhile, the priority mapping table dynamically improves the priority of key tasks such as operation reminding and the like, and supports elastic expansion and blue-green deployment strategies to realize efficient and stable operation; according to the invention, the risk of message backlog in the peak period can be obviously reduced, the real-time performance of medical advice reminding is improved, the sub-second response requirement is met, and data support is provided for hospital management.

Description

Technical Field

[0001] This invention belongs to the field of medical information technology, specifically a method for large-scale medical order reminders based on artificial intelligence. Background Technology

[0002] In modern medical information systems, the real-time performance and reliability of large-scale medical order reminders are crucial for ensuring patient safety and improving the efficiency of medical services. Currently, hospital smart bedside cabinet systems generally adopt a "scanning and input - message queue - stream processing" architecture to handle patient medical order information (such as surgery times, medication reminders, etc.). However, during the peak scanning period in the morning (7:00-9:00), hundreds of scanning devices simultaneously submit data to the Kafka message queue, leading to severe message backlog and latency issues. According to actual test data from a tertiary hospital (Journal of Medical Information Engineering, Vol. 12, 2023), when the number of active scanning devices exceeds 150, the throughput of Kafka's default partitioning strategy (fixed 3 partitions) drops sharply from 4.5k msg / s to 1.2k msg / s, with an average message latency of 2.3 seconds. For critical reminders such as "5 minutes in advance" (e.g., preoperative fasting), the actual delivery time is often delayed by more than 10 minutes, directly leading to the risk of medical accidents (a medical safety report from a certain province in 2022 showed that 18.7% of medication delays were due to system delays).

[0003] Existing technologies primarily rely on two types of optimization schemes to address the aforementioned issues, but both have significant shortcomings: The first type of method uses reactive adjustments at the data processing layer (e.g., CN114331905A), triggering partition expansion after the Flink stream processing engine detects backlog. However, due to the excessively long decision-making chain (requiring feedback via Kafka→Flink→ZooKeeper), the reallocation time is ≥1.5 seconds, failing to meet the sub-second real-time requirements of medical scenarios. The second type of method uses static partition pre-allocation (e.g., US20220156021A1), allocating 10 partitions based on historical peak values, but this results in resource waste during off-peak hours (CPU utilization is only 35%) and cannot dynamically adapt to fluctuations in scanning devices (the number of active devices fluctuates between 120-200 in the morning). Furthermore, the core flaw of the above schemes lies in the fact that the load awareness node is located after the data processing layer, leading to a structural delay in the "monitoring-decision-execution" closed loop. More importantly, the task priority differences unique to the medical scenario (such as "surgery reminder 5 minutes in advance" having a much higher priority than "physical examination notification") were not included in the partitioning strategy. High-priority messages are often blocked by low-priority messages, further exacerbating the risk of backlog of critical tasks.

[0004] Medical information systems have much higher real-time requirements than ordinary industrial scenarios (ISO / TR 20514:2020 stipulates that the delay of critical medical reminders should be ≤500ms). However, existing Kafka optimization patents (such as CN113986126A and EP3876451A1) focus on general big data scenarios and fail to address the following pain points specific to medical care: First, there is a non-linear relationship between the number of active scanning devices and the amount of messages. The surge in active devices due to concentrated scanning by nurses in the morning can lead to a spike in the number of active devices, but the message density coefficient (the amount of messages per device) can fluctuate by ±40% due to differences in the complexity of medical orders (e.g., the number of medical orders for postoperative patients is 1.8 times that of regular patients), and the error rate of general linear prediction models exceeds 35%. Second, medical reminders have strict time windows (e.g., a "5 minutes in advance" reminder becomes invalid if the delay is >300ms), but existing technologies lack a dynamic routing mechanism based on task priority, making it difficult to meet the requirement of zero tolerance for backlog of critical tasks.

[0005] Therefore, there is an urgent need for a proactive and medical scenario-customized message queue optimization method that deeply embeds load awareness into the data acquisition layer, enabling a paradigm shift from "passive response" to "proactive prediction." This would address the shortcomings of existing technologies in terms of real-time performance, resource utilization, and task priority management, thereby effectively ensuring the efficient operation of the medical reminder system and patient safety. Summary of the Invention

[0006] This application provides an artificial intelligence-based method for large-scale medical order reminders to address the problems of severe message backlog, high latency of critical tasks, and low resource utilization in existing medical reminder systems during peak periods. This method is applied to the edge computing nodes of a hospital smart bedside table system. The system architecture includes a distributed message queue and a load prediction module. Each edge computing node is equipped with a dynamic partition controller and a priority scheduling engine. The method includes: using the dynamic partition controller to monitor the number of active scanning devices and postoperative patient status indicators in real time, and using a lightweight LSTM model to predict the message load value for the next 5 minutes. The message load value is calculated using the formula... Calculations show that This indicates the number of currently active scanning devices. Indicates the postoperative status (value range is 0 or 1). A chronic disease status flag (value range 0 or 1) is used; the priority scheduling engine dynamically adjusts the Kafka partition configuration based on the predicted load value, and key medical reminder tasks are bound to the newly added partition to ensure zero-latency processing of high-priority tasks. This approach significantly reduces the risk of message backlog, improves the real-time performance of key medical order reminders, and meets the sub-second response requirements of medical scenarios.

[0007] When using a lightweight LSTM model for load prediction, an input vector containing 10 features can be used. These features include the current load value, the message growth rate over the past 10 minutes, historical peak timestamps, morning time markers, post-operative patient percentage, chronic disease patient percentage, total number of scanning devices, message type distribution entropy, network bandwidth utilization, and system temperature. After normalizing these features, they are input into the model to output the load prediction value and backlog risk level for the next 5 minutes. The backlog risk level is divided into 5 levels. The partition reallocation mechanism is triggered at certain times. Furthermore, the model training uses the Adam optimizer, and the loss function is defined as the mean squared error. in This represents the actual load value. Indicates the predicted load value. Indicates the number of samples.

[0008] When using a priority scheduling engine to determine critical medical reminder tasks, task priorities can be dynamically identified through a priority mapping table. When a patient enters the 2-hour pre-surgery state, the priority of the surgery reminder task is automatically elevated to the highest level and bound to a newly added partition. For non-critical tasks (such as physical examination notifications), they are temporarily stored in a Redis standby queue and processed after the system load decreases. Furthermore, when message processing latency exceeds 500ms, the system automatically rolls back the partition configuration to ensure overall stability.

[0009] Furthermore, after completing the medical order reminder task, the task execution results can be persisted to a distributed storage area for subsequent querying and traceability. An alarm mechanism can also be triggered if a critical task delay exceeds 300ms, notifying medical staff via SMS or voice to ensure timely intervention. Simultaneously, the system supports the analysis of historical data to generate medical order execution efficiency reports, providing data support for hospital management decisions.

[0010] Edge computing nodes can dynamically expand the number of partitions based on resource utilization and message queue backlog. When a single node reaches its processing capacity limit, the system automatically scales up, adding new container instances to process messages from different partitions in parallel. This elastic scaling mechanism effectively handles sudden load surges during peak morning scanning periods, avoiding resource waste.

[0011] When a lightweight LSTM model is updated, the model version number can be bound to the container image, and a blue-green deployment strategy can be used to achieve a zero-downtime upgrade. In case of degraded or abnormal model inference performance, a quick rollback to the older model version can be achieved, ensuring basic predictive capabilities. Furthermore, the system supports real-time monitoring of model performance, automatically triggering a performance optimization process when inference latency exceeds a preset threshold.

[0012] This AI-based large-scale medical order reminder system includes at least one scanning device, an edge server, and a distributed message queue. The edge server connects to the scanning device via a standardized interface and communicates with the distributed message queue over a network. The system architecture also includes a dynamic partition controller and a priority scheduling engine, used for load prediction and task scheduling, respectively, to ensure efficient processing of critical medical order reminder tasks. Attached Figure Description

[0013] Appendix Figure 1 A flowchart of the core workflow for large-scale medical order reminders. Detailed Implementation

[0014] This invention provides a large-scale medical order reminder method based on artificial intelligence. Its core lies in achieving efficient processing of medical reminder tasks through edge computing nodes combined with a dynamic partition controller and a priority scheduling engine. The following will be illustrated in conjunction with the appendix. Figure 1 The specific implementation process of this method is explained in detail.

[0015] First, the system architecture is as follows: Figure 1 As shown, the system includes scanning devices, edge servers, a distributed message queue, a dynamic partition controller, and a priority scheduling engine. The scanning devices connect to the edge servers via a standardized interface, while the edge servers communicate with the distributed message queue over the network. The dynamic partition controller monitors the number of active scanning devices and post-operative patient status indicators in real time, and uses a lightweight LSTM model to predict the message load value for the next 5 minutes. The priority scheduling engine dynamically adjusts the Kafka partition configuration based on the prediction results, ensuring that critical medical reminder tasks can be bound to newly added partitions and processed with zero latency. The operation of the entire system relies on close collaboration between the modules, thereby significantly reducing the risk of message backlog during peak periods and improving the real-time performance of critical medical order reminders.

[0016] In practice, the core function of the dynamic partition controller is to monitor the number of active scanning devices in real time. and postoperative status markers of patients and chronic disease status markers These parameters collectively determine the current system message load value. The calculation formula is as follows: . in, Indicates the number of currently active scanning devices. The value ranges from 0 to 1, and is used to indicate whether the patient is in a postoperative state. Similarly, the value range is 0 or 1, used to indicate whether a patient has a chronic disease. For example, during the morning peak hours at a hospital, if there are currently 50 active scanning devices, of which 10 patients are post-operative and 5 patients have chronic diseases, then the message load value is... The calculation process is as follows: This load value reflects the level of stress the system may face in the near future, providing a basis for subsequent resource allocation.

[0017] To further improve the accuracy of load prediction, the dynamic partition controller uses a lightweight LSTM model for prediction. The model's input vector contains 10 features: current load value, message growth rate over the past 10 minutes, historical peak timestamp, morning time period indicator, percentage of post-operative patients, percentage of patients with chronic diseases, total number of scanning devices, message type distribution entropy, network bandwidth utilization, and system temperature. These features are normalized before being input into the model, which outputs the load prediction value and backlog risk level for the next 5 minutes. The backlog risk level is divided into 5 levels; when the level reaches or exceeds 3, a partition reallocation mechanism is triggered. For example, assuming the current load is 100, the message growth rate in the last 10 minutes is 10%, the historical peak timestamp is 7:30, the morning period is marked as 1, the proportion of post-operative patients is 20%, the proportion of chronic disease patients is 10%, the total number of scanning devices is 60, the message type distribution entropy is 0.8, the network bandwidth utilization rate is 70%, and the system temperature is 45℃, then the normalized input vector is [0.5, 0.1, 0.8, 1, 0.2, 0.1, 0.6, 0.8, 0.7, 0.9]. After model inference, the predicted load value for the next 5 minutes is 120, and the backlog risk level is 4. At this time, the system will automatically trigger the partition redistribution mechanism to cope with the upcoming high load.

[0018] After receiving the prediction results from the dynamic partition controller, the priority scheduling engine dynamically adjusts the Kafka partition configuration based on the predicted load value. Specifically, when the predicted load value is high and the backlog risk level reaches or exceeds 3, the priority scheduling engine adds a new partition and binds critical medical reminder tasks to the new partition. For example, when a patient enters the 2-hour pre-surgery state, the priority of the surgery reminder task is automatically raised to the highest level and bound to the new partition to ensure zero-latency processing. For non-critical tasks (such as physical examination notifications), they are temporarily stored in a Redis standby queue and processed after the system load decreases. In addition, when the message processing latency exceeds 500ms, the system automatically rolls back the partition configuration to ensure overall stability. This dynamic adjustment mechanism not only improves the processing efficiency of critical tasks but also avoids system crashes caused by improper resource allocation.

[0019] After completing the medical order reminder task, the system persists the task execution results to a distributed storage area for subsequent querying and traceability. Simultaneously, the system supports the analysis of historical data to generate medical order execution efficiency reports, providing data support for hospital management decisions. For example, statistical analysis of medical order execution records for a certain month can reveal that the average latency for critical tasks during the morning peak period is 200ms, while the average latency for non-critical tasks is 800ms. This data analysis result can help hospitals optimize resource allocation and further improve system performance.

[0020] To handle sudden load surges, edge computing nodes can dynamically expand the number of partitions based on resource utilization and message queue backlog. When a single node's processing capacity reaches its limit, the system automatically scales up, adding container instances to process messages from different partitions in parallel. For example, during a morning peak period, due to concentrated use of scanning devices leading to severe message backlog, the system detected that the single node's processing capacity was nearing its limit and subsequently added two container instances to handle messages from the newly added partitions. This elastic scaling mechanism effectively alleviates pressure during peak periods and avoids resource waste.

[0021] During the update process of the lightweight LSTM model, the system employs a blue-green deployment strategy to achieve zero-downtime upgrades. Specifically, the version number of the new model is bound to the container image. When the model is updated, the system first deploys the new version to the green environment for testing. Only after confirming that there are no issues will it switch to the blue environment for official deployment. In case of degraded or abnormal model inference performance, the system can quickly roll back to the old version to ensure basic prediction capabilities. In addition, the system supports real-time monitoring of model performance. When the inference latency exceeds a preset threshold, a performance optimization process is automatically triggered. For example, if the model inference latency exceeds 200ms, the system will automatically initiate a performance optimization process, including retraining the model or adjusting model parameters to restore its normal performance.

[0022] In practical applications, the method of this invention can significantly improve the response speed and reliability of medical reminder systems. For example, in a real-world deployment at a top-tier hospital, the system successfully handled the sudden surge in load during the morning rush hour, reducing the average latency of critical tasks from 800ms to less than 200ms, meeting the sub-second response requirements of medical scenarios. Furthermore, through analysis of historical data, hospital management found that the efficiency of postoperative patient prescription execution improved by 30%, providing important insights for optimizing resource allocation within the hospital.

[0023] In summary, this invention achieves efficient processing of large-scale medical order reminder tasks by leveraging the collaborative work of a dynamic partition controller and a priority scheduling engine, combined with the load prediction capabilities of a lightweight LSTM model. The system not only significantly reduces the risk of message backlog but also ensures zero-latency processing of critical tasks, providing reliable technical support for medical scenarios.

Claims

1. A method for large-scale medical order reminders based on artificial intelligence, characterized in that, An edge computing node is applied to a hospital smart bedside table system. The system architecture includes a distributed message queue and a load prediction module. Each edge computing node is equipped with a dynamic partition controller and a priority scheduling engine. The method includes: using the dynamic partition controller to monitor the number of active scanning devices and post-operative patient status indicators in real time, and predicting the message load value for the next 5 minutes using a lightweight LSTM model. The message load value is calculated using the formula... ； Calculations show that This indicates the number of currently active scanning devices. This indicates the postoperative status indicator, with a value ranging from 0 to 1. The value of the chronic disease status flag is 0 or 1; the priority scheduling engine is used to dynamically adjust the Kafka partition configuration based on the predicted load value, and the critical medical reminder tasks are bound to the newly added partition.

2. The method for large-scale medical order reminders based on artificial intelligence according to claim 1, characterized in that, When calling the lightweight LSTM model for load prediction, the input vector contains 10-dimensional features, including the current load value, the message growth rate in the past 10 minutes, the historical peak timestamp, the morning time period marker, the proportion of postoperative patients, the proportion of chronic disease patients, the total number of scanning devices, the message type distribution entropy, the network bandwidth utilization rate, and the system temperature. After normalizing these features, they are input into the model, which outputs the load prediction value and backlog risk level for the next 5 minutes. The backlog risk level is divided into 5 levels, and when the backlog risk level reaches or exceeds 3, the partition redistribution mechanism is triggered.

3. The method for large-scale medical order reminders based on artificial intelligence according to claim 1, characterized in that, When determining critical medical reminder tasks using the priority scheduling engine, the priority of the task is dynamically identified through the priority mapping table. When the patient enters the 2-hour pre-operative state, the priority of the surgical reminder task is automatically raised to the highest level and bound to the newly added partition. For non-critical tasks, they are temporarily stored in the Redis standby queue and processed after the system load decreases.

4. The method for large-scale medical order reminders based on artificial intelligence according to claim 1, characterized in that, After completing the medical order reminder task, the task execution result is persisted to a distributed storage area for subsequent query and traceability. At the same time, if a critical task delay of more than 300ms is detected, an alarm mechanism is triggered and medical staff are notified via SMS or voice.

5. The method for large-scale medical order reminders based on artificial intelligence according to claim 1, characterized in that, Edge computing nodes dynamically expand the number of partitions based on the resource utilization of each node and the backlog of message queues. When the processing capacity of a single node reaches its limit, the system automatically expands and adds container instances to process messages from different partitions in parallel.

6. The method for large-scale medical order reminders based on artificial intelligence according to claim 1, characterized in that, When the lightweight LSTM model is updated, the model version number is bound to the container image, and a blue-green deployment strategy is used to achieve zero-downtime upgrades. In the event of a decrease or anomaly in the model's inference performance, the model can be quickly rolled back to the old version to ensure basic prediction capabilities.

Images