Diabetic patient comprehensive data monitoring method based on deep learning

Abstract

The invention relates to the technical field of medical monitoring, and particularly discloses a diabetic comprehensive data monitoring method based on deep learning. The method aims at solving the technical problems that due to the fact that a fixed alarm threshold value is used in a traditional blood glucose monitoring system, when a nurse works in a high-load mode, alarm overload occurs, workflow is interfered, and response to a real high-risk event is delayed. According to the technical scheme, the method is characterized in that multi-source data such as nurse operation frequency, patient blood sugar sequences and sleep stages and medical rules in a knowledge graph are captured in real time; calculating a nurse task count based on the operation frequency and mapping the nurse task count to a task magnitude, generating a'nurse load-patient risk 'dynamic weight matrix in combination with knowledge graph coding, and meanwhile, analyzing a blood glucose time sequence mode by introducing a recurrent neural network taking the nurse task count as a feature, and generating a load sensing type anomaly probability; the dynamic weight matrix and the abnormal probability are integrated, a real-time load threshold value is dynamically generated according to the current task count of a nurse to calculate an event risk value, and only when the event risk value exceeds the dynamic threshold value, it is judged that the event is a real hypoglycemia event needing to be responded immediately, and an alarm is pushed to a nurse terminal. The system is mainly used for hospitalized wards of hospitals, especially in night shift scenes, and intelligent and load-adaptive precise monitoring of the state of the diabetic patient is realized.

Description

Technical Field

[0001] This invention relates to the field of comprehensive data monitoring technology for diabetic patients, and in particular to a method for comprehensive data monitoring of diabetic patients based on deep learning. Background Technology

[0002] Diabetic patients, especially hospitalized patients, require continuous and precise monitoring of their blood glucose levels to prevent acute complications such as hypoglycemia and ensure patient safety. In clinical nursing, continuous glucose monitoring (CGM) devices have become essential monitoring tools. They automatically collect data on interstitial fluid glucose concentration at a high frequency (e.g., every 5 minutes) and convert it into blood glucose values, forming a blood glucose sequence. Based on this real-time data, clinical monitoring systems are designed to automatically issue alarms when blood glucose levels reach preset danger thresholds, prompting healthcare professionals to intervene promptly.

[0003] Currently, common continuous glucose monitoring (CGM) systems for diabetes patients rely on preset, fixed blood glucose concentration thresholds for their core alarm logic. Specifically, the system continuously receives blood glucose sequence data from the CGM monitor and compares each newly acquired blood glucose value in real time with a pre-set, uniform low-glucose alarm threshold (e.g., 3.9 mmol / L). Once the system detects that a blood glucose level is below this fixed threshold, it determines it as a hypoglycemic event and indiscriminately sends a visual, audible, or vibration alarm to the on-duty nurse's mobile terminal. This technical solution treats blood glucose data as the sole basis for triggering the alarm, and its alarm triggering mechanism is static and singular.

[0004] However, the inventors of this application have discovered the following technical problems with the prior art:

[0005] Because the alarm triggering mechanism relies solely on a static comparison of blood glucose data with a fixed threshold, completely neglecting the crucial contextual factor of nurses' real-time workload, the system generates numerous non-emergency alarms under high-load nursing scenarios. This disrupts nurses' workflows and may cause delays in responding to genuine high-risk events. In other words, existing technology lacks a means to dynamically adjust alarm sensitivity and priority based on nurses' real-time workload; its alarm logic is isolated and cannot be coordinated with the nursing work status. Summary of the Invention

[0006] This invention provides a comprehensive data monitoring method for diabetic patients based on deep learning. The technical problem to be solved is that the existing technology lacks a technical means to dynamically adjust the alarm sensitivity and priority according to the nurse's real-time workload. Its alarm logic is isolated and cannot achieve coordination with the nursing work status.

[0007] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows:

[0008] A deep learning-based method for comprehensive data monitoring of diabetic patients, the method being executed by a processor, includes the following steps:

[0009] Step S10: Real-time capture of operation frequency data from nurses' mobile terminals, blood glucose sequence data from continuous glucose monitors, sleep stage data from patients' sleep monitors, and the nighttime risk stratification rule base stored in the knowledge graph;

[0010] Step S20: Calculate the nurse's current task count based on the operation frequency data and map the nurse's current task count to the task level; determine the patient's current sleep stage based on the sleep stage data; fuse the nighttime risk stratification rule base encoding to generate a nurse load-patient risk dynamic weight matrix to embed the nurse's current task count and the patient's current sleep stage; and simultaneously analyze the temporal fluctuation pattern of the blood glucose sequence data through a recurrent neural network to generate a load-aware anomaly probability, wherein the nurse's current task count is used as the input feature of the recurrent neural network.

[0011] Step S30: Calculate the event risk value based on the nurse load-patient risk dynamic weight matrix, the load threshold rules in the nighttime risk stratification rule base, and the load-aware abnormal probability. The real-time load threshold is dynamically generated based on the nurse's current task count. When the event risk value exceeds the real-time load threshold, it is determined to be a real hypoglycemic event that requires immediate response; otherwise, it is determined to be a physiological blood glucose fluctuation that can be delayed.

[0012] Step S40: When a genuine hypoglycemic event requiring immediate response is determined, a vibration alarm carrying patient identification information is pushed to the nurse's mobile terminal.

[0013] The beneficial effects of this invention are as follows:

[0014] Compared with existing technologies, the deep learning-based comprehensive data monitoring method for diabetic patients provided by this invention has the following beneficial effects:

[0015] 1. This invention effectively solves the core problems of alarm overload and response delay by integrating multi-source physiological data and dynamic risk assessment.

[0016] Unlike existing technologies that trigger alarms solely based on fixed blood glucose thresholds, this invention innovatively introduces nurses' real-time workload as a core decision variable and constructs a dynamic weight matrix of "nurse workload - patient risk." By mapping nurses' real-time operation frequency data to task counts and magnitudes, and combining this with medical rules from a knowledge graph, the system can dynamically adjust alarm sensitivity and real-time alarm thresholds for different patients. When nurses are under high workload, the system automatically raises the alarm threshold, prioritizing the push of the highest-risk events, thereby significantly suppressing false alarms caused by non-urgent physiological fluctuations. This fundamentally avoids the interference of traditional static threshold systems generating a large number of invalid alarms during busy periods, ensuring that limited nursing resources can be concentrated and quickly responded to real critical events, thus shortening response time.

[0017] 2. This invention expands upon single blood glucose monitoring to multi-dimensional metabolic risk assessment, improving the comprehensiveness and accuracy of early warning.

[0018] Existing technologies typically focus only on a single indicator, blood glucose. This invention simultaneously captures blood glucose, blood pressure, and blood lipid data from a continuous glucose monitor, a smart blood pressure monitor, and a portable lipid analyzer, and then aligns and cleans the data using timestamps to create a comprehensive health record. An analysis is performed using a model capable of resolving multi-parameter time-series dependencies (such as an extended recurrent neural network) to generate a comprehensive abnormality probability and risk score that integrates information from multiple physiological indicators. This design enables the system to identify hidden risks where blood glucose levels have not yet reached traditional alarm thresholds, but are accompanied by compensatory responses such as abnormal blood pressure or heart rate. This allows for earlier and more comprehensive warnings of potential metabolic disorders, improving the monitoring accuracy for patients with complex conditions (such as those with hypertension and hyperlipidemia).

[0019] 3. This invention integrates anthropometry data and links it to a knowledge graph, thereby achieving personalized monitoring strategies and a closed loop for health management.

[0020] Unlike existing technologies that fail to adequately consider individual patient differences, this invention automatically acquires patient height and weight data from electronic medical records and smart devices, calculates a standardized BMI index, and uses it as a key individual characteristic parameter. This parameter is fed back into a knowledge graph to optimize risk stratification thresholds for different BMI groups (e.g., setting more conservative alarm thresholds for obese patients). Simultaneously, based on a personalized rule base within the knowledge graph, the system can automatically push specific health recommendations (such as dietary and exercise guidance) related to the patient's BMI and blood glucose patterns when the event is determined to be a physiological fluctuation that can be delayed. This not only transforms non-emergency events into health education opportunities, improving patient compliance, but also achieves a closed loop from "passive alarm" to "proactive personalized health management," enabling the monitoring system to adapt to individual needs.

[0021] 4. This invention improves the collaborative efficiency of data management and the accessibility of the system by building a secure mini-program integration platform.

[0022] Existing systems typically restrict data access to ward workstations, limiting the flexibility of remote management for doctors. This invention addresses this by constructing a mini-program access interface layer based on RESTful APIs and secure authentication mechanisms. This layer securely and encryptedly synchronizes real-time data, alarm records, and personalized suggestions generated by the core monitoring system to a mobile mini-program. Doctors can remotely view interactive data charts, review system alarm decisions, and even proactively initiate risk assessment requests via the mini-program, enabling collaborative monitoring across time and space. Simultaneously, doctors' operation logs on the mini-program are transmitted back to the central system, providing real clinical behavioral data for optimizing core algorithms (such as nurse workload assessment models). This forms a closed-loop data flow that empowers both the front-end application and the back-end core, significantly improving the efficiency of clinical data management and utilization. Attached Figure Description

[0023] Figure 1 This is a logic flowchart of the present invention;

[0024] Figure 2 The specific steps for capturing data in real time. Detailed Implementation

[0025] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings. Identical components are indicated by the same reference numerals.

[0026] It should be noted that the terms “front,” “back,” “left,” “right,” “up,” and “down” used in the following description refer to the directions shown in the attached diagram, while the terms “inside” and “outside” refer to the directions toward or away from the geometric center of a specific component, respectively.

[0027] To make the content of this invention easier to understand, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings.

[0028] A deep learning-based method for comprehensive data monitoring of diabetes patients includes the following steps:

[0029] Step S10: Real-time capture of operation frequency data from nurses' mobile terminals, blood glucose sequence data from continuous glucose monitors, sleep stage data from patients' sleep monitors, and the nighttime risk stratification rule base stored in the knowledge graph;

[0030] This step aims to synchronously collect various types of data required for monitoring from multiple sources, building a complete data foundation for subsequent comprehensive analysis. Specifically, the operation frequency data refers to data obtained by monitoring touchscreen clicks, physical button presses, and application switching events on the nurse's mobile terminal, counting the number of operations per minute to quantify the nurse's workload. The blood glucose sequence data refers to the blood glucose concentration values ​​automatically sampled and transmitted every 5 minutes by a continuous glucose monitor worn by the patient, forming a sequence that changes over time. The sleep stage data refers to the patient's current sleep stage, such as REM (light sleep) or non-REM (deep sleep), identified by processing and analyzing the EEG and body movement signals collected by the patient's sleep monitor. The nighttime risk stratification rule base refers to a set of diabetes nighttime risk assessment rules stored in the form of "entity-relationship-entity" triples, retrieved from a pre-built medical knowledge graph. These data collectively constitute a multi-dimensional, real-time updated monitoring context.

[0031] Step S20: Calculate the nurse's current task count based on the operation frequency data and map the nurse's current task count to the task level; determine the patient's current sleep stage based on the sleep stage data; fuse the nighttime risk stratification rule base encoding to generate a nurse load-patient risk dynamic weight matrix to embed the nurse's current task count and the patient's current sleep stage; and simultaneously analyze the temporal fluctuation pattern of the blood glucose sequence data through a recurrent neural network to generate a load-aware anomaly probability, wherein the nurse's current task count is used as the input feature of the recurrent neural network.

[0032] This step is the core data fusion and intelligent analysis stage, aiming to combine nurse status, patient physiological status, and medical knowledge for risk assessment. First, the operation frequency data is continuously monitored and processed using counting logic to obtain the nurse's current task count, reflecting the immediate workload level, and categorized into specific task levels (e.g., low, medium, high). Second, the patient's current sleep stage (deep sleep or light sleep) is determined. The key innovation lies in constructing a dynamic weight matrix for nurse workload and patient risk. The encoding process of this matrix utilizes knowledge from the nighttime risk stratification rule base, enabling the weight values ​​in the matrix to dynamically reflect the differences in risk sensitivity corresponding to different nurse workload levels and different patient sleep stages. For example, when a nurse is under high workload and the patient is in deep sleep, the system automatically lowers the alarm weight for the patient's blood glucose fluctuations using this matrix. In parallel, a recurrent neural network, a deep learning model, is used to perform time-series analysis on the blood glucose sequence data, learning normal and abnormal patterns of blood glucose changes.

[0033] Step S30: Calculate the event risk value based on the nurse load-patient risk dynamic weight matrix, the load threshold rules in the nighttime risk stratification rule base, and the load-aware abnormal probability. The real-time load threshold is dynamically generated based on the nurse's current task count. When the event risk value exceeds the real-time load threshold, it is determined to be a real hypoglycemic event that requires immediate response; otherwise, it is determined to be a physiological blood glucose fluctuation that can be delayed.

[0034] This step completes the final risk decision, adapted to nurse workload. The event risk value is a comprehensive score calculated by combining the nurse workload-patient risk dynamic weight matrix, reflecting individualized risk weights, with the workload-perceived abnormality probability, reflecting the degree of abnormality in blood glucose fluctuations, according to preset rules (e.g., weighted summation). The workload threshold rule is part of the nighttime risk stratification rule base, defining the mapping relationship between the nurse's current task count and the alarm trigger threshold (i.e., the real-time workload threshold). Its core principle is: the busier the nurse (the higher the task count), the higher the alarm threshold should be, allowing only more dangerous events to trigger alarms, thus avoiding excessive interference from non-emergency alarms. Specifically, the calculated event risk value is compared with the dynamically generated real-time workload threshold. If the threshold is exceeded, it is classified as a genuine hypoglycemic event requiring immediate attention; if not exceeded, it is classified as a physiological blood glucose fluctuation that can be temporarily deferred. This mechanism directly solves the "alarm fatigue" problem caused by alarm overload in clinical practice.

[0035] Step S40: When a genuine hypoglycemic event requiring immediate response is determined, a vibration alarm carrying patient identification information is pushed to the nurse's mobile terminal.

[0036] This step is the execution phase of the decision-making process, enabling precise alarm activation. This step is only executed when the judgment result of step S30 is "a genuine hypoglycemic event requiring immediate response." The system generates a data packet containing identifying information such as the patient's bed number and name, and sends it to the nurse's mobile terminal via a wireless network, triggering a vibration alert. This design ensures that nurses are only interrupted by truly critical events, and the vibration pattern is suitable for quiet nighttime environments, avoiding potential interference from audible and visual alarms. This step, together with the data capture and intelligent analysis steps at the front end of the technical solution, forms a complete closed loop, translating the conclusions of dynamic risk assessment into concrete clinical interventions that reduce unnecessary interference.

[0037] Furthermore, the real-time data capture in step S10 includes the following specific steps:

[0038] Step S11: Extract the operation frequency data from the user interaction log of the nurse's mobile terminal in real time. The sampling period for the operation frequency data is 1 minute.

[0039] This sub-step specifically defines the method for acquiring the operation frequency data. The system deploys a monitoring program at the operating system level of the nurse's mobile terminal to continuously record all user interaction events (such as screen touches, button presses, and application switching). At the end of each minute, these events are counted to obtain the operation frequency data for that minute. Setting a 1-minute sampling period is based on a balance chosen from clinical observations: a period that is too short is easily affected by accidental operations, while a period that is too long cannot reflect rapid changes in the nurse's workload in a timely manner. This data serves as the initial basis for subsequent quantification of the nurse's workload.

[0040] Step S12: Receive the blood glucose sequence data from the continuous glucose monitor. The blood glucose sequence data is a data packet of blood glucose values ​​transmitted every 5 minutes. The blood glucose sequence data is stored in the buffer and timestamped with the operation frequency data.

[0041] This sub-step specifically defines the method for acquiring and synchronizing the blood glucose sequence data. Every 5 minutes, the continuous glucose monitor sends a data packet containing a precise timestamp, patient ID, and blood glucose concentration value via wireless means such as Bluetooth. The system temporarily stores this data in a buffer (such as a circular queue) at a central server or gateway. A key operation is timestamp alignment: the system associates the operation frequency data each minute with all blood glucose sequence data received within the same minute using their timestamps. This ensures that in subsequent analysis, "whether the nurse is busy at a certain moment" and "the patient's blood glucose value at the same moment" can accurately correspond, which is the foundation for achieving load-aware analysis.

[0042] Step S13: Collect raw data of brain wave signals and body movement signals from the patient's sleep monitor, and preprocess the brain wave signals and body movement signals to output the sleep stage data;

[0043] This sub-step specifically defines the process for generating the sleep stage data. A sleep monitor worn by the patient (usually a headband or wristband) continuously collects high-frequency raw EEG signals and raw body movement signals generated by a triaxial accelerometer. The system first preprocesses these raw signals, including using a bandpass filter to filter out noise such as power grid interference, and then extracts features from the cleaned signals (such as the power of EEG in specific frequency bands, and the amplitude and frequency of body movements). Finally, these features are input into a pre-trained sleep staging classification model (such as a support vector machine), which outputs the patient's current sleep stage, i.e., the sleep stage data.

[0044] Step S14: Retrieve the nighttime risk stratification rule base from the knowledge graph database. The nighttime risk stratification rule base stores medical knowledge about the nighttime risk of diabetes in the form of triples.

[0045] This sub-step defines how to acquire structured medical knowledge. A knowledge graph is a technology that stores knowledge using a graph structure, where knowledge exists in the form of "entity-relationship-entity" triples (e.g., "deep sleep - reduced - hypoglycemia risk"). The system queries and retrieves all rules related to nighttime diabetes monitoring from the knowledge graph database via an application programming interface (API), forming the nighttime risk stratification rule base. These rules translate clinical guidelines and expert experience into a machine-understandable and computable form.

[0046] Step S15: Align the operation frequency data, the blood glucose sequence data, the sleep stage data, and the nighttime risk stratification rule base using timestamps and perform an integrity check.

[0047] This sub-step is the final quality control step before data fusion. The system aligns the operation frequency data, blood glucose sequence data, and sleep stage data from different independent devices with different timestamps using a unified time base (such as server time) to ensure they reflect the context of the same time segment. Simultaneously, integrity checks are performed to check for missing key data items. For example, it checks whether a patient lacks blood glucose data across multiple consecutive sampling cycles. Severely missing or misaligned data packets are discarded, and only complete, synchronized, high-quality data streams are delivered to subsequent analysis steps, thereby ensuring the reliability of decisions.

[0048] Furthermore, the calculation of the nurse's current task count based on the operation frequency data in step S20 includes the following specific steps:

[0049] Step S21: Monitor the operation frequency data in real time, set an initial value for the task count, increment the task count when the operation frequency data is continuously higher than the first threshold, and decrement the task count when the operation frequency data is continuously lower than the second threshold.

[0050] This sub-step transforms the raw, once-per-minute operation frequency data into a current task count that smoothly reflects the changing trend of nurses' workload. The initial value of the task count is typically set to 0, representing an idle state. The system sets two thresholds: a higher first threshold (e.g., 5 times / minute) represents entering a busy state, and a lower second threshold (e.g., 2 times / minute) represents entering an idle state. Continuous monitoring is used to avoid misjudgments caused by instantaneous fluctuations: the task count is increased by one level only when the operation frequency data is above the first threshold for several consecutive periods (e.g., 3 minutes); conversely, the task count is decreased by one level only after it has been below the second threshold for a certain period. This results in a relatively stable workload indicator that reflects the nurse's recent workload intensity.

[0051] Example: The nurse's operation frequency during the period 00:01-00:03 was 7, 6, and 8 times / minute, respectively, all exceeding the first threshold of 5. The system determines that the "consistently higher than" condition is met and increases the task count from 0 to 1.

[0052] Step S22: Map the nurse's current task count to the task level, and embed the task level into the encoding process of the nurse's workload-patient risk dynamic weight matrix;

[0053] This sub-step assigns semantic labels to workload status and integrates them into the core risk assessment model. The task load level is a segmented classification of the nurse's current task count; for example, a count of 0-2 is defined as "low workload," 3-4 as "medium workload," and 5 or above as "high workload." This classification more intuitively describes the nurse's workload level. The innovation lies in using this classification result (task load level) as a key input dimension for constructing the nurse workload-patient risk dynamic weight matrix. During matrix encoding, different task load levels directly affect the risk weight value of each patient in the matrix, thereby enabling dynamic adjustment of the monitoring sensitivity for all patients at the system level based on the nurse's workload.

[0054] Step S23: Synchronously input the nurse's current task count into the recurrent neural network as the input feature of the load-aware anomaly probability;

[0055] This sub-step represents another technical approach to achieving "load-aware" analysis. Recurrent neural networks typically only analyze the temporal patterns of blood glucose data itself. The innovation of this method lies in using the nurse's current task count, representing the external environment (nurse's state), as an additional feature vector, inputting it into the network along with the blood glucose time-series data. This allows the neural network to establish a correlation between "nurse load" and "blood glucose anomaly criteria" during the learning process. When the input task count is high, the network's internal parameters adaptively adjust, exhibiting a higher "tolerance" for certain non-urgent blood glucose fluctuation patterns (such as slow declines).

[0056] Step S24: Process the temporal dependency relationship through the gating mechanism of the recurrent neural network to generate the load-aware anomaly probability, wherein the gating mechanism integrates the nighttime risk stratification rule base to optimize network parameters;

[0057] This sub-step describes in detail how neural networks generate probabilistic outputs and integrate medical knowledge. Recurrent neural networks (such as LSTM) control the flow and memory of information through their internal gating mechanisms (input gate, forget gate, output gate), thereby effectively handling long-term dependencies in time-series data such as blood glucose. The network ultimately transforms the analysis results into a probability value between 0 and 1 through an output layer (such as a Softmax layer), i.e., the load-aware anomaly probability. A further innovation lies in using knowledge from the nighttime risk stratification rule base to constrain or guide the training process during neural network training. For example, lower anomaly label weights are assigned to data samples that conform to the rule of "slow blood glucose decrease during deep sleep," thus embedding medical logic into the trained network parameters themselves, improving the model's interpretability and clinical rationality.

[0058] Step S25: Periodically update the nurse's current task count based on the filtered operation frequency data, and synchronously input the updated nurse's current task count into the nurse load-patient risk dynamic weight matrix and the recurrent neural network.

[0059] This sub-step ensures the timeliness and stability of the nurse's current task count. The system periodically (e.g., every 2 minutes) re-executes the calculation logic of step S21, but the operation frequency data used for the calculation is first filtered through moving averages and other methods to eliminate occasional click noise, resulting in smoother load data that better reflects the true trend. The updated nurse's current task count is immediately synchronized to two core modules: one for recoding the nurse load-patient risk dynamic weight matrix, and the other as new feature values ​​input to the recurrent neural network for real-time inference. This ensures that the entire system can respond quickly and consistently to changes in nurse load status.

[0060] Furthermore, the step S20, which involves integrating the nighttime risk stratification rule base encoding to generate the nurse workload-patient risk dynamic weight matrix, includes the following specific steps:

[0061] Step S26: Load the nighttime risk stratification rule base and construct a graph neural network model, where nodes represent patient risk factors and edges represent the strength of risk association;

[0062] This sub-step involves modeling preparation for constructing a dynamic weight matrix. Based on the knowledge in the nighttime risk stratification rule base, the system constructs an initial graph neural network model. In this graph, each patient is a node, and the node's attributes include various risk factors for that patient, such as current blood glucose level, sleep stage, and whether there are complications. The edges between nodes in the graph represent the associations between different risk factors or between different patients' risk states, and the edge weights represent the strength of the associations. This relationship information comes from the rules in the knowledge graph.

[0063] Step S27: Embed the nurse's current task count as a global feature into the node feature vector, and use the patient's current sleep stage as an edge weight adjustment factor to achieve feature fusion through a graph convolutional layer;

[0064] This sub-step is a key operation for injecting real-time dynamic information into a static knowledge graph. The nurse's current task count is a global variable; it is not specific to any particular patient but affects risk assessment for all patients. The system uses graph convolution operations to "propagate" this global feature and "embed" it into the feature vector of each patient node in the graph, allowing each node to perceive the current nurse workload level. Simultaneously, the patient's current sleep stage is a strong risk modulation signal, which the system uses to dynamically adjust the weights of specific edges in the graph. For example, when a patient is detected to be in deep sleep, the weight of the edge from "decreased blood sugar" to "high-risk event" is automatically reduced. The graph convolutional layer is responsible for performing the information transfer and aggregation calculations of these complex features and relationships.

[0065] Step S28: Calculate the attention coefficients between nodes through the graph attention layer to generate the nurse load-patient risk dynamic weight matrix with the dimensions of patient number and risk.

[0066] This sub-step involves the computation of generating the final decision matrix. An attention mechanism, specifically a graph attention layer, is introduced into the graph neural network. This layer calculates the "attention coefficient" between any two nodes in the graph, representing the influence of one node's risk state on the risk judgment of another node (e.g., whether the presence of a high-risk patient suggests the need for greater attention to patients in adjacent beds). After multiple layers of graph convolution and attention calculations, the model ultimately outputs a comprehensive weighted score for each patient, for each risk dimension (e.g., hypoglycemia risk, hyperglycemia risk). Arranging these scores for all patients forms the nurse workload-patient risk dynamic weighted matrix. This matrix serves as the direct input for subsequent calculations of the event risk value.

[0067] Step S29: Set the update trigger condition for the nurse workload-patient risk dynamic weight matrix to be a change in the patient's current sleep stage or a change in the nurse's current task count.

[0068] This sub-step specifies the timing of updates to the dynamic weight matrix to ensure its "dynamic" nature. The dynamic weight matrix is ​​not fixed but updates as key input parameters change. Two main triggering conditions are: 1) any patient's sleep stage data changes (e.g., transitioning from deep sleep to light sleep); 2) a significant change occurs in the nurse's current task count. Once these events are detected, the system immediately re-executes the matrix generation process that began in step S26. This event-driven update is more efficient than fixed-time polling, ensuring that the system state remains synchronized with the actual situation at all times.

[0069] Step S2A: Integrate the nurse workload-patient risk dynamic weight matrix with the workload-perceived abnormal probability and input it into the event risk value calculation process in step S30.

[0070] This sub-step converges the two paths of risk assessment. The nurse workload-patient risk dynamic weight matrix provides risk weights derived from the perspective of the relationship between "individual patient status and nurse workload" (an adjustment coefficient based on a macroscopic, static background). The workload-perceived anomaly probability provides the probability of anomalies derived from the perspective of "current blood glucose data patterns" (a direct signal of microscopic, dynamically changing events). The event risk value calculation in step S30 requires integrating these two core outputs. The integration method can be multiplication, weighted summation, or other functions. This step specifies the data flow: the two calculation results are used as inputs and passed to the next calculation unit.

[0071] Furthermore, the calculation of the event risk value in step S30 includes the following specific steps:

[0072] Step S31: Calculate the event risk value. This calculation integrates the nurse workload-patient risk dynamic weight matrix and the workload-perceived abnormality probability, wherein the integrated weight is dynamically set according to the patient's current sleep stage.

[0073] This sub-step defines the specific calculation method for the event risk value and introduces further adjustments based on the sleep stage. A typical integration approach is a weighted summation formula: Event Risk Value = α × Load-Perceived Abnormal Probability + β × Corresponding Weight in the Dynamic Weight Matrix. Where α and β are weighting coefficients. The innovation of this method lies in the fact that α and β are not fixed values, but are dynamically adjusted according to the patient's current sleep stage. For example, when the patient is in deep sleep, physiological blood glucose fluctuations are common, therefore the weight α of the blood glucose fluctuation itself (abnormal probability) should be reduced, while more consideration should be given to the patient's fixed risk background (dynamic weight). Conversely, during light sleep, the weight of α is increased. This makes the risk assessment logic more aligned with clinical realities under different physiological states.

[0074] Step S32: Determine the real-time load threshold according to the load threshold rules in the nighttime risk stratification rule base, wherein the load threshold rules store the mapping relationship between the nurse's current task count and the real-time load threshold;

[0075] This sub-step defines how to dynamically determine the alarm trigger threshold. The load threshold rule is a rule in the knowledge base specifically designed for managing alarm overload. It clearly specifies the real-time load threshold that the system should adopt under different current task count levels of the nurses. The principle is to simulate clinical decision-making: the busier the nurses are, the more saturated their ability to handle non-urgent matters becomes, and the higher the alarm threshold should be set by the system, allowing only more critical events to "squeeze in". This mapping relationship is usually derived from the analysis of clinical observation data on nurses' workload and response capabilities.

[0076] Step S33: Determine the event type by comparing the event risk value with the real-time load threshold. When the event risk value exceeds the real-time load threshold, output a true hypoglycemic event identifier; otherwise, output a physiological blood glucose fluctuation identifier.

[0077] This sub-step is the final binary decision-making step. The system compares the calculated event risk value with the real-time load threshold determined in step S32. This is a simple logical judgment: if the risk value is greater than the threshold, the risk level is considered to exceed the acceptable "delayed treatment" range under the current nurse load, requiring immediate alarm, and thus an "actual hypoglycemic event" flag is output. If the risk value is less than or equal to the threshold, the fluctuation is considered acceptable or can be delayed in the current context, and thus a "physiological blood glucose fluctuation" flag is output. This judgment is the sole basis for driving whether to issue an alarm.

[0078] Step S34: The event risk value calculation process receives data input from the load-aware anomaly probability and the nurse load-patient risk dynamic weight matrix, and outputs the results to drive the alarm decision in step S40.

[0079] This sub-step clarifies the data inflow and outflow relationship in step S30. It emphasizes the two core data sources of the event risk value calculation module: the load-aware anomaly probability from the recurrent neural network, and the nurse load-patient risk dynamic weight matrix from the graph neural network model. The output of this module, i.e., the judgment result (real event or physiological fluctuation), is the driving signal for the downstream alarm execution step S40. This outlines a clear data flow from data analysis to decision execution.

[0080] Step S35: The adjustment of the real-time load threshold is dynamically generated based on the linear relationship of the nurse's current task count.

[0081] This sub-step further explains a specific method for generating the real-time load threshold, namely, a linear relationship with the nurse's current task count. This can be expressed by the formula: Real-time load threshold = Base threshold + k × Nurse's current task count. In this formula, the base threshold is the alarm threshold when the nurse is completely idle, and k is a proportionality coefficient representing the increase in the alarm threshold for each level increase in the task count. This linear model is simple and effective, easy to calibrate the parameter (k value) based on clinical data, and clearly reflects the core logic of "higher load, higher threshold," ensuring the continuity and predictability of the adjustment process.

[0082] Furthermore, the step S20, which determines the patient's current sleep stage based on the sleep stage data, includes the following specific steps:

[0083] Step S2B: Preprocess the raw data of the EEG signal and the body movement signal to extract feature parameters;

[0084] This sub-step is the preliminary data processing stage for sleep stage analysis. The EEG signals and body movement signals obtained from sensors typically contain noise (such as power line interference and motion artifacts). Preprocessing includes filtering (such as using wavelet transform or bandpass filters to remove noise in specific frequency bands), segmentation, and normalization. Then, feature parameters for distinguishing sleep stages are extracted from the cleaned signals, such as the power spectral density ratio of EEG in different frequency bands (delta waves, theta waves, alpha waves), the amplitude and frequency of body movement signals, and possible heart rate variability indicators. These feature parameters are the inputs to the subsequent classifier.

[0085] Step S2C: Input the feature parameters into the classifier to identify the patient's current sleep stage and output the classification results of REM and non-REM sleep stages;

[0086] This sub-step utilizes a machine learning model to perform sleep staging. The classifier is a model pre-trained on a large amount of labeled sleep data, such as a support vector machine, random forest, or neural network. It takes the feature parameters extracted in step S2B as input, performs internal calculations, and outputs a classification label, i.e., the patient's current sleep stage. Typically, it is first distinguished into REM sleep and non-REM sleep, the latter of which can be further subdivided into light sleep and deep sleep. This result is a key assessment of the patient's physiological state.

[0087] Step S2D: When a deep sleep phase is detected, automatically extend the tolerance window for blood glucose fluctuations and adjust the risk stratification threshold.

[0088] This sub-step embodies the application of sleep stage knowledge to risk monitoring strategies. When the classifier determines that the patient is in deep sleep, the system automatically adjusts two key monitoring parameters: 1) Tolerance window: the length of time observed to determine whether a single drop in blood glucose constitutes a "sustained drop." Metabolism is slow during deep sleep, and blood glucose drops slowly, therefore a longer observation window (e.g., from 15 minutes to 30 minutes) is needed to confirm the trend. 2) Risk stratification threshold: the blood glucose concentration threshold for determining hypoglycemia. For safety redundancy, this threshold may be slightly increased from the usual 3.9 mmol / L to 4.2 mmol / L for patients in deep sleep to detect potential risks earlier. These adjustments directly affect the analysis logic in steps S20 and S30.

[0089] Step S2E: During the deep sleep stage, the recurrent neural network dynamically increases its tolerance to blood glucose drop patterns.

[0090] This sub-step achieves sleep stage adaptation from the perspective of the model's internal parameters. This supplements the "load perception" described in step S23 and can be considered as "sleep stage perception." Specifically, once the system context (the patient is in deep sleep) is clear, some parameters or decision logic within the recurrent neural network can be adjusted to reduce its output (i.e., the load-perceived abnormal probability) for blood glucose decline patterns consistent with the physiological characteristics of deep sleep (such as a slow, linear decline). This is equivalent to telling the neural network, "In the current stage, this pattern is not abnormal." This can be achieved by adding sleep stage labels as features to the model input or by scaling the probability values ​​according to the sleep stage during post-processing.

[0091] In step S2F, the update frequency of the sleep stage data is synchronized with the capture, and calibration is performed once every fixed period to ensure temporal alignment with the blood glucose sequence data.

[0092] This sub-step emphasizes the crucial issue of time synchronization in multi-source data fusion. The sleep stage data needs to be continuously updated at a certain frequency (e.g., every 30 seconds or every minute) to track the dynamic changes in sleep stages. More importantly, since the sleep monitor and blood glucose monitor are two independent devices, their system clocks may have slight deviations. Therefore, a timestamp calibration is required periodically (e.g., hourly or whenever a data packet arrives), typically aligned with the time of a central server. Ensuring a strict timeline correspondence between the sleep stage data and the blood glucose sequence data is a prerequisite for subsequent accurate correlation analysis (e.g., determining the blood glucose value at a specific sleep stage).

[0093] Furthermore, the step S40 of pushing the vibration alarm to the nurse's mobile terminal includes the following specific steps:

[0094] Step S41: When a hypoglycemic event that requires immediate response is determined, an alarm data packet containing the patient identifier, event risk value, and risk level label is generated;

[0095] This sub-step is the alarm information encapsulation process. Once step S30 determines that an alarm is needed, the system immediately constructs a structured alarm message. The patient identifier is used to uniquely identify the target patient (e.g., bed number, name). The event risk value is the specific numerical value used for the determination, allowing nurses to quickly assess the severity of the situation. The risk level label is a further simplified classification of the event risk value (e.g., high, medium, low), usually based on the range of the risk value, making it easier for nurses to intuitively understand the priority. This data packet contains the core information required for the response.

[0096] Step S42: The alarm data packet is encrypted and transmitted to the nurse's mobile terminal via a secure communication protocol, and a vibration alarm mode is triggered. The vibration intensity is dynamically set according to the event risk value.

[0097] This step is responsible for the secure delivery of alarms and tactile feedback. Encrypted communication methods, such as Transport Layer Security (TLS), are used to ensure that patient privacy data is not intercepted during transmission. Once the data packet arrives at the nurse's mobile terminal, the terminal parses it and triggers vibration. The innovation lies in linking the vibration intensity to the urgency of the event: the higher the risk value of the event, the stronger the triggered vibration and the longer its duration. This design allows nurses to make a preliminary assessment of the urgency of an event based solely on touch, without looking at the screen, making it particularly suitable for nighttime or busy periods.

[0098] Step S43: Perform data integrity verification during transmission. If an abnormal data packet is detected, initiate a retransmission mechanism.

[0099] This procedure ensures reliable delivery of alarm information. Interference in wireless network environments can lead to data packet corruption or loss. The system incorporates a verification mechanism at the communication protocol level, such as appending a Cyclic Redundancy Check (CRC) code to the end of the data packet. Upon receiving the data, the receiver (nurse's mobile terminal) recalculates the CRC value and compares it with the received CRC. If they do not match, it indicates an error occurred during transmission, and the receiver requests a retransmission of the data packet from the sender. This ensures accurate and complete delivery of alarm information, preventing missed alarms due to network issues.

[0100] Step S44: Record the alarm push time and nurse's response actions, and feed them back to the knowledge graph to optimize the nighttime risk stratification rule base;

[0101] This sub-step enables the system to learn and continuously optimize itself. The system not only pushes alarms but also records two key timestamps: the alarm push time and the time when the nurse confirms or handles the situation. This log data is anonymized (personal identification information removed) and then fed back into the knowledge graph management system. By analyzing this feedback data (e.g., events frequently marked as "false alarms" or with long nurse response delays), relevant rule parameters in the nighttime risk stratification rule base can be automatically or semi-automatically adjusted (e.g., adjusting thresholds, modifying weights), making future system decisions more accurate.

[0102] Step S45: The vibration alarm is activated only when the event risk value exceeds the real-time load threshold.

[0103] This step reiterates the fundamental conditions for alarm triggering and emphasizes the closed-loop logic of the entire method. It explicitly states that the necessary and sufficient condition for the activation of the final vibration alarm action is the determination result of step S33, namely, the event risk value must be greater than the real-time load threshold. This is the ultimate guarantee for the entire technical solution to address the "alarm overload" problem, ensuring that non-emergency events are effectively suppressed, thereby allowing nurses to focus their attention on high-risk events that truly require immediate attention.

[0104] Furthermore, it also includes a method for constructing the knowledge graph, the construction method comprising the following steps:

[0105] Step S50: Extract diabetes-related entities and relationships from medical literature databases and clinical guidelines, generate triples using natural language processing technology, and store them in a graph database;

[0106] This step forms the foundation for the automated construction of knowledge graphs. Natural Language Processing (NLP) techniques are used to scan and analyze structured and unstructured medical texts (such as treatment guidelines, textbooks, and research papers). The NLP model identifies medical entities mentioned in the text (such as diseases, symptoms, drugs, and test results) and the relationships between entities (such as "cause," "contraindicated," and "used for treatment"). These identified "entity-relationship-entity" pairs are then combined to form standardized triplet data. These triples are imported in batches into graph databases such as Neo4j, forming the raw skeleton of the knowledge graph. This transforms medical knowledge recorded in human language into structured data that can be processed by machines.

[0107] Step S51: Receive the nighttime risk stratification rules input from the expert knowledge base, and convert the nighttime risk stratification rules into graph node attributes through the rule engine;

[0108] This step involves digitizing domain expert experience and integrating it into a knowledge graph. Clinical experts, based on their experience, summarize specific rules for nighttime monitoring scenarios (e.g., "For diabetic patients with renal insufficiency, a nighttime blood glucose level below 5.0 mmol / L warrants attention"). These rules typically exist in a format closer to natural language or a specific rule-based language. A rule engine parses these expert rules and converts them into attributes that can be attached to graph nodes or edges. For example, a rule might be converted into adding the attribute "Nighttime hypoglycemia warning threshold = 5.0 mmol / L" to the entity node "Diabetic nephropathy" in the graph. This transforms the experts' tacit knowledge into queryable and computable structured information within the knowledge graph.

[0109] Step S52: Integrate the patient's historical data in the electronic medical record system, map the patient's historical data to knowledge graph nodes through an entity alignment algorithm, and update the risk weight values ​​of the nodes;

[0110] This step involves validating and quantifying the knowledge graph using real-world data. Anonymized patient history data is extracted from the hospital information system, including historical blood glucose levels, complication records, medication history, alarm events, and their handling results. The key challenge is "entity alignment," which requires matching and linking patients, diseases, and events mentioned in medical records with existing standard entities in the knowledge graph. After successful alignment, a large amount of historical data can be used for statistical analysis to update the weights of nodes or edges in the graph. For example, if historical data analysis reveals that "patients with diabetic nephropathy are twice as likely to experience nocturnal hypoglycemia as ordinary patients," then the weight of the relationship between "diabetic nephropathy" and "risk of nocturnal hypoglycemia" in the graph can be set or updated to 2.0. This evolves the graph from a qualitative knowledge base into an intelligent model with quantified probabilities.

[0111] Step S53: Periodically perform knowledge graph verification based on the matching degree between real-time monitoring data and historical labeled events. When the matching degree is lower than the preset standard, trigger the graph update process.

[0112] This step establishes a dynamic maintenance and quality assurance mechanism for the knowledge graph. The system periodically performs verification: it compares the risk predictions or judgments made by the current system based on the existing knowledge graph (real-time monitoring data) with manually verified, accurate historical event annotations (gold standard) to calculate the matching degree (e.g., accuracy, recall). If the matching degree is found to be consistently below a preset threshold (e.g., accuracy <90%), it indicates that the rules of the existing knowledge graph may be outdated or incomplete and cannot well fit current clinical practice. At this time, the system automatically or manually triggers an update process, re-executing or partially executing steps S50 to S52, introducing new literature, expert rules, or historical data to iteratively optimize the knowledge graph and maintain its advanced nature and accuracy.

[0113] Step S54: Use the completed knowledge graph as the source of the nighttime risk stratification rule base and interact with the central processing unit through the API interface.

[0114] This step completes the final link from knowledge construction to application implementation. The knowledge graph, constructed and optimized through the above steps, is deployed as a backend service. The nighttime risk stratification rule base is no longer a static database, but a real-time query view of this dynamic knowledge graph. The central processing unit (i.e., the server executing the main process of claim 1) sends query requests (e.g., "query the risk adjustment coefficient for a patient with diabetic nephropathy and in deep sleep") to the knowledge graph service through a well-defined application programming interface (API). The knowledge graph service calculates and returns the results instantly. This enables the monitoring system to always make decisions based on the latest and most comprehensive medical knowledge.

[0115] Furthermore, it also includes an automatic recording and analysis method for blood glucose, blood pressure, and blood lipids, wherein the automatic recording and analysis method includes the following steps:

[0116] Step S60: Synchronously capture blood glucose data, blood pressure data, and blood lipid data from multi-source monitoring devices. The physiological data are aligned with a unified timestamp and stored in a central database.

[0117] This step expands the monitoring scope from a single blood glucose level to key cardiovascular and metabolic indicators, achieving comprehensive health monitoring. The system simultaneously receives data from various medical IoT devices: continuous glucose monitors provide blood glucose data (high frequency, e.g., every 5 minutes), smart blood pressure monitors provide blood pressure data (low frequency, e.g., hourly or daily), and portable lipid analyzers provide lipid data (low frequency, e.g., daily or weekly). Because the devices are independent, the system uses the central server's time as a reference to realign all incoming physiological data with device timestamps, unifying them onto a single timeline before storing them in a time-series database. This enables subsequent analysis of synergistic changes among multiple indicators.

[0118] Step S61: Perform data cleaning on the physiological data to remove outliers, and integrate the aligned physiological data into a comprehensive health record according to the patient identifier;

[0119] This step involves data governance before multi-parameter analysis. First, data cleaning is performed using statistical methods (such as the 3σ rule) or clinically reasonable range rules to identify and remove obviously erroneous measurements (such as blood pressure 300 mmHg). Then, the cleaned and time-aligned blood glucose, blood pressure, and blood lipid data are aggregated according to the patient's unique identifier, creating a dynamically updated comprehensive health record for each patient. This record is a multi-dimensional time-series dataset that records the changes in various patient indicators over time, forming the basis for comprehensive health risk assessment.

[0120] Step S62: Apply a time series analysis model to analyze the time series dependencies of the blood glucose data, blood pressure data, and blood lipid data, and generate multi-dimensional anomaly probability values;

[0121] This step utilizes advanced models to uncover deep correlations between multiple parameters. The time-series analysis model (such as an extended recurrent neural network) is designed to simultaneously receive and process multiple parallel time series data, including blood glucose, blood pressure, and blood lipids. By learning from historical data, the model not only grasps the individual variation patterns of each indicator but, more importantly, learns the mutual influences and temporal linkages between them. For example, it learns the pattern that "when blood glucose drops rapidly, blood pressure and heart rate usually rise compensatorily." The multi-dimensional anomaly probability value output by the model is an overall score that integrates information from all input indicators regarding whether the current health status is abnormal; it is more comprehensive and reliable than anomaly judgments based on a single indicator.

[0122] Step S63: Input the multi-dimensional anomaly probability value into the nighttime risk stratification rule base, and dynamically adjust the risk assessment threshold according to the multi-parameter association rule to output a comprehensive risk score;

[0123] This step combines multi-parameter analysis results with traditional risk stratification knowledge. The nighttime risk stratification rule base, in addition to blood glucose-related rules, is expanded to include rules involving multi-parameter associations (e.g., "when the abnormal probability value > 0.7 and is accompanied by an increase in blood pressure, the risk level increases by one level"). The system uses the multi-dimensional abnormal probability value generated in step S62 as input, queries and applies these multi-parameter rules, dynamically adjusts the baseline risk value, and finally calculates a comprehensive risk score. This score quantifies the overall risk level under the combined effect of multiple physiological parameters.

[0124] Step S64: Embed the comprehensive risk score into the event risk value calculation process of step S30. When the comprehensive risk score exceeds the real-time load threshold, a high-priority alarm is triggered.

[0125] This step integrates the multi-parameter monitoring system with the core alarm logic. Previously, when calculating the event risk value in step S30, the calculation might have primarily relied on the probability of abnormal blood glucose levels. Now, the comprehensive risk score is used as a more comprehensive and accurate risk measure, replacing or partially replacing the original input. Subsequently, a comparison with the real-time load threshold is also performed. Because the comprehensive risk score includes additional risk information such as blood pressure and blood lipids, it can identify events that are actually at high risk (such as occult hypoglycemia) earlier and more accurately, even if blood glucose levels are not yet within the target range. This triggers the high-priority alarm, improving the sensitivity and early warning capability of the monitoring system.

[0126] Furthermore, it also includes a method for integrating height and weight information to calculate BMI and provide personalized recommendations, the method comprising the following steps:

[0127] Step S70: Obtain height and weight data from the patient's electronic medical record system. After verifying the patient's identity through the identity authentication interface, the height and weight data are stored in the health record.

[0128] This step involves acquiring the patient's basic anthropometric data. Height data is typically a one-time record submitted upon admission. Weight data may come from a bedside smart scale and can be automatically uploaded and updated periodically (e.g., daily). To prevent data confusion, the system authenticates the patient by scanning their RFID wristband or entering their employee ID number upon receiving weight data, ensuring the data is linked to the correct patient. This data, along with physiological data such as blood glucose levels, is stored in the patient's personal health record, laying the foundation for calculating body mass index and providing personalized recommendations.

[0129] Example: The system reads Zhang San's height as 1.75 meters from his electronic medical record. Every morning, Zhang San steps onto the smart scale. The scale automatically reads his wristband RFID, confirms his identity, uploads his weight of 82 kilograms to the system, and stores it in Zhang San's health record.

[0130] Step S71: Calculate the BMI value based on the height data and the weight data, and output the standardized BMI index;

[0131] This step performs a standardized health indicator calculation. The formula for calculating Body Mass Index (BMI) is: BMI = weight (kg) / [height (m)]². The system automatically retrieves the patient's latest height and weight data from their health record and substitutes them into the formula for calculation. The calculation results are categorized according to World Health Organization or Chinese standards, and the standardized BMI index is output, for example: <18.5 (underweight), 18.5-23.9 (normal), 24.0-27.9 (overweight), ≥28.0 (obese). This index is an important quantitative indicator for assessing a patient's nutritional status and metabolic risk.

[0132] Step S72: Generate health recommendations based on the personalized rule base of the knowledge graph, wherein the personalized rule base stores the association rules between BMI and blood glucose control;

[0133] This step utilizes medical knowledge to transform BMI data into actionable recommendations. The knowledge graph contains a subset specifically for health management, namely the personalized rule base. This base stores intervention rules based on features such as BMI, for example: "If BMI ≥ 24 and nighttime blood glucose fluctuates greatly, it is recommended to reduce carbohydrate intake at dinner by 20 grams," or "If BMI is normal but blood glucose is low in the early morning, it is recommended to have a snack before bed." The system automatically generates one or more health recommendations in text form by matching the patient's real-time or recent data (such as BMI index, blood glucose trend, and sleep patterns) with conditions in the rule base.

[0134] Step S73: Associate the health advice with the event risk value. When the event risk value is determined to be the delayed physiological blood glucose fluctuation, the system automatically pushes the advice to the patient's terminal.

[0135] This step creatively transforms the handling of non-emergency events into a health education opportunity. When step S30 determines that a blood glucose fluctuation is a "delayed physiological blood glucose fluctuation," it means that the event does not require immediate nurse intervention. The system does not trigger an alarm at this point, but instead executes this sub-step: based on the patient data and context that caused the fluctuation, it calls the logic of step S72 to generate a relevant health suggestion. Then, this suggestion is pushed to the patient via a tablet computer or a dedicated mobile application at the patient's bedside. This avoids unnecessary medical intervention and utilizes the "teaching moment" of the event to provide patients with immediate, personalized guidance, enhancing their self-management abilities.

[0136] Step S74: The BMI value is fed back to the knowledge graph in real time to optimize the risk stratification threshold.

[0137] This step enables a closed-loop application of BMI data in risk monitoring. The calculated BMI value is not only used to generate recommendations but is also fed back to the knowledge graph system as a basis for optimizing clinical decision-making rules. For example, the knowledge graph can analyze large amounts of data to discover that "obese patients with a BMI > 28 have a higher rate of asymptomatic hypoglycemia at night." Based on this finding, the system can automatically adjust the risk stratification threshold for obese patients.

[0138] Furthermore, it also includes a method for platform-supported mini-program integration, the method comprising the following steps:

[0139] Step S80: Construct the mini-program access interface layer. The interface layer interacts with the central monitoring system through a RESTful API. The RESTful API defines data request specifications and includes a security authentication mechanism.

[0140] This step provides a standardized and secure channel for external mobile applications to access the core monitoring system. The mini-program (such as a WeChat mini-program) runs on the doctor's or patient's mobile device and requires a bridge to communicate with the backend central monitoring system—the access interface layer. This layer adopts a RESTful API design, a universal interface style based on the HTTP protocol, explicitly defining how to request data (e.g., using GET / POST methods and which parameters to carry). A key component is a strict security authentication mechanism, typically employing protocols such as OAuth 2.0, ensuring that only authenticated and authorized users (such as attending physicians) can access the corresponding patient data through the mini-program, preventing information leakage.

[0141] Step S81: Encrypt and transmit the monitoring data captured in step S10 and the health advice generated in step S73 to the mini-program cache area.

[0142] This step is responsible for securely synchronizing data to the mobile device. The system periodically or upon request pushes two types of data generated by the central monitoring system: 1) real-time or historical monitoring data (blood glucose curves, alarm records), and 2) personalized health suggestions for patients, to the mini-program's local storage space, i.e., the cache area, via an encrypted channel (such as HTTPS). Encryption ensures the security of data transmission. The cache area design allows the mini-program to still display recently synchronized data even in weak network conditions or brief offline situations, ensuring a consistent user experience.

[0143] Step S82: Implement data visualization on the mini-program, parse the synchronized data to generate interactive charts, and transmit the user operation logs back to the central monitoring system in real time;

[0144] This step presents the data in an intuitive way on the mobile device and records user behavior. The mini-program includes a visualization engine that parses the monitoring data loaded from the cache and renders it into easy-to-understand charts, such as a trend chart of blood sugar changes over time, using different colors to distinguish between day and night. The charts are typically interactive, allowing doctors to click, zoom, and view specific values. The innovation lies in the fact that all actions a doctor performs on the mini-program (such as viewing a patient, clicking on alarm details, or modifying a setting) are recorded as operation logs and transmitted back to the central system in real time. These logs are valuable user behavior data.

[0145] Step S83: Respond to the user's remote operation command. When a risk assessment request is submitted through the mini-program, the event risk value is recalculated by calling the nighttime risk stratification rule base.

[0146] This step empowers doctors to remotely and proactively intervene in and review system decisions. Through the mini-program interface, doctors can not only passively view data but also actively initiate actions. For example, if a doctor has doubts about an event previously classified as a "physiological fluctuation" by the system, they can mark the event as "re-evaluation requested" on the mini-program. This instruction is sent to the central system via API. Upon receiving the instruction, the central system immediately retrieves the current real-time data (or historical snapshot data) and the latest nighttime risk stratification rule base, re-executing the risk assessment process (i.e., the core calculations in steps S20-S30) to obtain an updated event risk value and judgment result. This allows doctors' clinical experience to cover and validate the AI's decisions.

[0147] Step S84: The synchronized data of the mini-program comes from the real-time output of the central monitoring system, and the returned user operation log is used to optimize the calculation logic of the nurse's current task count.

[0148] This step reveals the two-way empowerment relationship between the mini-program and the core system. On the one hand, all data displayed by the mini-program originates from the main data stream of the central monitoring system, ensuring the uniqueness and authority of the data source. On the other hand, the user operation logs returned by the mini-program provide a new dimension for optimizing the core algorithm. In particular, doctors' viewing and processing behaviors can indirectly reflect the workload of nurses or the true urgency of events. For example, if a certain type of event is frequently marked or processed remotely by doctors, it may mean that this type of event requires higher priority attention. This can, in turn, optimize the model parameters for calculating the nurse's current task count in step S21, or adjust the mapping relationship between workload and threshold, making the system evaluation more closely aligned with actual clinical workflows.

[0149] Furthermore, it also includes a nurse emergency training simulation method based on virtual reality technology, the method comprising the following steps:

[0150] Step S90: Construct a virtual ward scene, wherein the data of the virtual ward scene comes from the real monitoring data captured in step S10;

[0151] This step aims to create a highly realistic, data-driven virtual training environment. Using virtual reality technology, a three-dimensional ward scene is generated in the computer, including beds, medical equipment, and patient models. The key innovation lies in the fact that this virtual scene is not static; its dynamic data (such as blood glucose curves, heart rate, and alarm information displayed on the virtual patient monitor) originates from historical or real-time anonymized data captured from the real ward environment in step S10. This makes the training scenario highly consistent with the real work environment, enhancing the relevance and realism of the training.

[0152] Step S91: Simulate a hypoglycemic event in the virtual ward scenario, wherein the hypoglycemic event is generated based on historical real hypoglycemic event data;

[0153] This step precisely recreates a critical situation in a virtual environment. The training system selects typical, confirmed real-life hypoglycemic event cases from a historical database. The system extracts all contextual data for each case: the time of the event, the specific trajectory of the blood glucose decline, the patient's vital signs at the time, sleep stage, etc. Then, in the virtual scenario, the system controls the virtual patient's physiological state to evolve precisely according to this data, thereby triggering a hypoglycemic emergency situation exactly the same as in the historical case at a specific moment, allowing nurses to practice handling the situation.

[0154] Example: The system selects a historical case: a patient's blood glucose level dropped linearly from 6.0 mmol / L to 2.8 mmol / L within 30 minutes, accompanied by an increased heart rate. In the virtual scenario, the system guides the virtual patient "Teacher Zhang's" blood glucose monitor to follow this curve, triggering an alarm on the virtual monitor at appropriate times.

[0155] Step S92: Receive emergency treatment operations performed by nurses in the virtual ward scene through VR devices, and record the emergency treatment operations in real time and synchronize them to the central system.

[0156] This step is the interactive and data collection phase of the training. Nursing trainees, wearing VR headsets and controllers, are immersed in a virtual ward. They can approach the bedside, view virtual monitor data, and operate virtual devices (such as simulating blood glucose testing, adjusting insulin pump parameters, and using the walkie-talkie to call for support), just as they would in real life. All their actions, their sequence, and the time taken are precisely captured and recorded by the system and synchronized in real time back to the central training management server for subsequent evaluation and analysis.

[0157] Example: Nurse trainee Xiao Wang sees "Teacher Zhang's" alarm in the VR system. She walks to the bedside, clicks on the monitor in the VR to view details, and then picks up the virtual blood glucose meter to perform a simulated finger-prick blood sampling operation. The system records each of her actions and its timestamp.

[0158] Step S93: Generate a training score based on the matching degree between the emergency response operation and the standard procedure, and feed the training score back to the knowledge graph to optimize the nurse workload-patient risk dynamic weight matrix;

[0159] This step quantifies the training effectiveness and uses the results to optimize the main system. The central system pre-sets standard operating procedures (SOPs) for various hypoglycemic events. The system compares the trainees' operation records with the SOPs to assess the accuracy, completeness, and timeliness of their operations, and calculates a comprehensive training score. The innovative application lies in the fact that this score is not only used to evaluate trainees, but its statistical results (e.g., a large number of trainees commonly experiencing delays or errors in a specific scenario) can be fed back into the knowledge graph. This may reveal deficiencies in existing risk warning rules or the nurse workload-patient risk dynamic weight matrix (e.g., alarms are too late or information is incomplete in this scenario), thereby triggering optimization of the knowledge graph and matrix model, forming a closed loop of two-way improvement between "training and practice."

[0160] Step S94: The training data is linked with the real monitoring data. When a nurse's score in handling a certain type of event in the virtual scenario improves, the system appropriately lowers the alarm threshold for the same type of event that the nurse is responsible for in the actual monitoring.

[0161] This step facilitates the transfer of personalized training outcomes to the actual work system, demonstrating personalized competency adaptation. The system establishes a training profile for each nurse. When a nurse repeatedly practices a certain type of hypoglycemic event (such as "asymptomatic nocturnal hypoglycemia") in VR and her training score continuously improves, it indicates that her ability to identify and handle such events has enhanced. In actual work, when she is on duty, the system can adopt a more "trust-based" strategy for similar events occurring to patients under her care, based on her personal competency profile. This could include appropriately lowering the alarm threshold (i.e., increasing alarm sensitivity), or, under heavy workloads, not significantly raising the threshold as it would for other nurses. This effectively "unburdens" more capable nurses, allowing the system's alarm strategy to more accurately match their actual handling capabilities.

[0162] Furthermore, it also includes a patient immersive health education method based on virtual reality technology, the method comprising the following steps:

[0163] Step S100: Generate a virtual body model based on the patient's individual data. The virtual body model reflects the blood glucose changes and sleep stage data in step S10 in real time.

[0164] This step creates a visual digital twin of the patient that is linked to their real-time status. The system generates a 3D virtual human model using the patient's actual anthropometric parameters (height, body type). The unique feature of this model is its dynamic "state," which can receive and visualize the patient's physiological data in real-time or near real-time by connecting to a central monitoring system. For example, the model can display current blood sugar levels and sleep stages (e.g., the model depicting a quiet sleep posture) through color changes (e.g., from blue to red), numerical labels, or animations, making abstract data intuitive and visible.

[0165] Example: Generate a virtual human model of patient Zhang San that is similar in size to him. When the central system monitors Zhang San's current blood glucose level at 5.5 mmol / L, the virtual model's heart, brain, and other organs are displayed with a comfortable light green halo; when he enters deep sleep, the virtual model closes its eyes and presents an animation of lying quietly.

[0166] Step S101: Simulate the effects of diet, exercise, and medication on blood sugar in a virtual environment, wherein the simulation is based on the medical rule base in the knowledge graph;

[0167] This step provides a safe, interactive "digital lab" that allows patients to explore the relationship between their behavior and health indicators. Using VR devices, patients can choose different foods (such as a bowl of rice or an apple), engage in different intensities of exercise (such as walking or running), or simulate taking medication in a virtual environment. After a choice is made, the system invokes medical rules and models stored in the knowledge graph (e.g., food glycemic index models, exercise glycemic effect models) to quickly calculate how this behavior will affect the blood glucose curve of their virtual body model, presenting the results instantly in the form of animations and charts. This provides an immersive and experiential learning experience that traditional verbal health education cannot match.

[0168] Step S102: When step S30 determines that the fluctuation is physiological, the system automatically triggers the VR education module to guide the patient to watch a virtual explanation of the cause of the current fluctuation.

[0169] This step seamlessly integrates the system's real-time monitoring with immediate patient education, creating a "teachable moment." When a patient's blood sugar fluctuates but is intelligently identified by the system as a "physiological fluctuation" (such as a normal drop during deep sleep), the system does not trigger an alarm or disturb the patient. Instead, it proactively triggers a dedicated educational module via VR devices at a time convenient for the patient (such as the following day). This module uses a virtual body model to replay the process of the nighttime blood sugar drop and, in the form of a virtual doctor or cartoon narrator, explains in simple language and animation, "Why did your blood sugar drop like this last night? This is related to your deep sleep stage and is a completely normal physiological phenomenon, so please don't worry." This eliminates the patient's doubts about normal fluctuations and enhances treatment adherence.

[0170] Step S103: Record the patient's interaction data in the VR education module to the health record. The interaction data is used to optimize the health suggestion generation logic in step S72.

[0171] This step collects behavioral data from patients during the education process for personalized optimization. The system records detailed logs of patients' use of the VR education module, including: which educational content they viewed, viewing duration, whether they completed interactive tests, test scores, and preference choices in simulation sessions (such as which foods they frequently choose for simulation). This data is stored in the patient's personal health record. When generating the health recommendations in step S72, the system can access this interactive data. For example, for a patient who consistently ignores the "exercise recommendations" module, the system may adjust the wording or try different incentive methods when generating recommendations later; for a patient who scores low on the "dietary choices" test, the system may push more basic and detailed dietary education content. This makes the logic for generating health recommendations more intelligent, varying from person to person and from behavior.

[0172] Step S104: Feedback the educational effect to the monitoring system. When a patient completes a specific educational module, the system appropriately increases the alarm suppression weight for subsequent similar physiological fluctuation events.

[0173] This step achieves positive feedback between patient education outcomes and clinical monitoring strategies, forming a reinforcing cycle of "education - improved self-management ability - increased system trust." The system marks the educational modules completed and skills mastered by each patient. When a patient systematically learns and masters knowledge about a certain type of physiological phenomenon (such as "dawn phenomenon" or "delayed post-exercise hypoglycemia"), the system considers the patient to have a correct understanding and self-management ability regarding such events. Therefore, in subsequent real-time monitoring, when the same type of physiological fluctuation occurs again, the system can more confidently suppress alarms, that is, appropriately increase the "alarm suppression weight" for this type of event for this patient. This means that the system will use a more lenient standard when judging whether it is a physiological fluctuation for this patient, thereby further reducing unnecessary disturbances to him, and also reflecting recognition and trust in the patient's learning outcomes.

[0174] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A comprehensive data monitoring method for diabetic patients based on deep learning, characterized in that, The method is executed by a processor and includes the following steps: Step S10: Real-time capture of operation frequency data from nurses' mobile terminals, blood glucose sequence data from continuous glucose monitors, sleep stage data from patients' sleep monitors, and the nighttime risk stratification rule base stored in the knowledge graph; Step S20: Calculate the nurse's current task count based on the operation frequency data and map the nurse's current task count to the task level; determine the patient's current sleep stage based on the sleep stage data; fuse the nighttime risk stratification rule base encoding to generate a nurse load-patient risk dynamic weight matrix to embed the nurse's current task count and the patient's current sleep stage; and simultaneously analyze the temporal fluctuation pattern of the blood glucose sequence data through a recurrent neural network to generate a load-aware anomaly probability, wherein the nurse's current task count is used as the input feature of the recurrent neural network. Step S30: Calculate the event risk value based on the nurse load-patient risk dynamic weight matrix, the load threshold rules in the nighttime risk stratification rule base, and the load-aware abnormal probability. The real-time load threshold is dynamically generated based on the nurse's current task count. When the event risk value exceeds the real-time load threshold, it is determined to be a real hypoglycemic event that requires immediate response; otherwise, it is determined to be a physiological blood glucose fluctuation that can be delayed. Step S40: When a genuine hypoglycemic event requiring immediate response is determined, a vibration alarm carrying patient identification information is pushed to the nurse's mobile terminal.

2. The method as described in claim 1, characterized in that, The real-time data capture in step S10 includes the following specific steps: Step S11: Extract the operation frequency data from the user interaction log of the nurse's mobile terminal in real time; Step S12: Receive the blood glucose sequence data from the continuous glucose monitor. The blood glucose sequence data is a data packet of blood glucose values ​​transmitted every 5 minutes. The blood glucose sequence data is stored in the buffer and timestamped with the operation frequency data. Step S13: Collect raw data of brain wave signals and body movement signals from the patient's sleep monitor, and preprocess the brain wave signals and body movement signals to output the sleep stage data; Step S14: Retrieve the nighttime risk stratification rule base from the knowledge graph database. The nighttime risk stratification rule base stores medical knowledge about the nighttime risk of diabetes in the form of triples. Step S15: Align the operation frequency data, the blood glucose sequence data, the sleep stage data, and the nighttime risk stratification rule base using timestamps and perform an integrity check.

3. The method as described in claim 1, characterized in that, The step S20, which calculates the nurse's current task count based on the operation frequency data, includes the following specific steps: Step S21: Monitor the operation frequency data in real time, set an initial value for the task count, increment the task count when the operation frequency data is continuously higher than the first threshold, and decrement the task count when the operation frequency data is continuously lower than the second threshold. Step S22: Map the nurse's current task count to the task level, and embed the task level into the encoding process of the nurse's workload-patient risk dynamic weight matrix; Step S23: Synchronously input the nurse's current task count into the recurrent neural network as the input feature of the load-aware anomaly probability; Step S24: Process the temporal dependency relationship through the gating mechanism of the recurrent neural network to generate the load-aware anomaly probability, wherein the gating mechanism integrates the nighttime risk stratification rule base to optimize network parameters; Step S25: Periodically update the nurse's current task count based on the filtered operation frequency data, and synchronously input the updated nurse's current task count into the nurse load-patient risk dynamic weight matrix and the recurrent neural network.

4. The method as described in claim 1, characterized in that, Step S20, which involves integrating the nighttime risk stratification rule base encoding to generate the nurse workload-patient risk dynamic weight matrix, includes the following specific steps: Step S26: Load the nighttime risk stratification rule base and construct a graph neural network model, where nodes represent patient risk factors and edges represent the strength of risk association; Step S27: Embed the nurse's current task count as a global feature into the node feature vector, and use the patient's current sleep stage as an edge weight adjustment factor to achieve feature fusion through a graph convolutional layer; Step S28: Calculate the attention coefficients between nodes through the graph attention layer to generate the nurse load-patient risk dynamic weight matrix with the dimensions of patient number and risk. Step S29: Set the update trigger condition for the nurse workload-patient risk dynamic weight matrix to be a change in the patient's current sleep stage or a change in the nurse's current task count. Step S2A: Integrate the nurse workload-patient risk dynamic weight matrix with the workload-perceived abnormal probability and input it into the event risk value calculation process in step S30.

5. The method as described in claim 1, characterized in that, The calculation of the event risk value in step S30 includes the following specific steps: Step S31: Calculate the event risk value. This calculation integrates the nurse workload-patient risk dynamic weight matrix and the workload-perceived abnormality probability, wherein the integrated weight is dynamically set according to the patient's current sleep stage. Step S32: Determine the real-time load threshold according to the load threshold rules in the nighttime risk stratification rule base, wherein the load threshold rules store the mapping relationship between the nurse's current task count and the real-time load threshold; Step S33: Determine the event type by comparing the event risk value with the real-time load threshold. When the event risk value exceeds the real-time load threshold, output a true hypoglycemic event identifier; otherwise, output a physiological blood glucose fluctuation identifier. Step S34: The event risk value calculation process receives data input from the load-aware anomaly probability and the nurse load-patient risk dynamic weight matrix, and outputs the results to drive the alarm decision in step S40. Step S35: The adjustment of the real-time load threshold is dynamically generated based on the linear relationship of the nurse's current task count.

6. The method as described in claim 1, characterized in that, The step S20, which determines the patient's current sleep stage based on the sleep stage data, includes the following specific steps: Step S2B: Preprocess the raw data of the EEG signal and the body movement signal to extract feature parameters; Step S2C: Input the feature parameters into the classifier to identify the patient's current sleep stage and output the classification results of REM and non-REM sleep stages; Step S2D: When a deep sleep stage is detected, the tolerance window for blood glucose fluctuations is automatically extended and the risk stratification threshold is adjusted. The adjustment data is fed back to the encoding process of the nurse workload-patient risk dynamic weight matrix. Step S2E: During the deep sleep stage, the recurrent neural network dynamically increases its tolerance to blood glucose drop patterns. In step S2F, the update frequency of the sleep stage data is synchronized with the capture, and calibration is performed once every fixed period to ensure temporal alignment with the blood glucose sequence data.

7. The method as described in claim 1, characterized in that, The step S40 of sending a vibration alarm to the nurse's mobile terminal includes the following specific steps: Step S41: When a hypoglycemic event that requires immediate response is determined, an alarm data packet containing the patient identifier, event risk value, and risk level label is generated; Step S42: The alarm data packet is encrypted and transmitted to the nurse's mobile terminal via a secure communication protocol, and a vibration alarm mode is triggered. The vibration intensity is dynamically set according to the event risk value. Step S43: Perform data integrity verification during transmission. If an abnormal data packet is detected, initiate a retransmission mechanism. Step S44: Record the alarm push time and nurse's response actions, and feed them back to the knowledge graph to optimize the nighttime risk stratification rule base; Step S45: The vibration alarm is activated only when the event risk value exceeds the real-time load threshold.

8. The method as described in claim 1, characterized in that, It also includes a method for constructing the knowledge graph, the construction method comprising the following steps: Step S50: Extract diabetes-related entities and relationships from medical literature databases and clinical guidelines, generate triples using natural language processing technology, and store them in a graph database; Step S51: Receive the nighttime risk stratification rules input from the expert knowledge base, and convert the nighttime risk stratification rules into graph node attributes through the rule engine and associate them with the triples; Step S52: Integrate the patient's historical data in the electronic medical record system, and map the patient's historical data to knowledge graph nodes through an entity alignment algorithm to update the risk weight values; Step S53: Periodically perform knowledge graph verification based on the matching degree between real-time monitoring data and historical labeled events. When the matching degree is lower than the preset standard, trigger the graph update process. Step S54: Use the completed knowledge graph as the source of the nighttime risk stratification rule base and interact with the central processing unit through the API interface.

9. The method as described in claim 1, characterized in that, It also includes methods for automatically recording and analyzing blood glucose, blood pressure, and blood lipids, wherein the automatic recording and analysis methods include the following steps: Step S60: Synchronously capture blood glucose data, blood pressure data, and blood lipid data from multi-source monitoring devices. The physiological data are aligned with a unified timestamp and stored in a central database. Step S61: Perform data cleaning on the physiological data to remove outliers, and integrate the aligned physiological data into a comprehensive health record according to the patient identifier; Step S62: Apply a time series analysis model to analyze the time series dependencies of the blood glucose data, blood pressure data, and blood lipid data, and generate multi-dimensional anomaly probability values; Step S63: Input the multi-dimensional anomaly probability value into the nighttime risk stratification rule base, and dynamically adjust the risk assessment threshold according to the multi-parameter association rule to output a comprehensive risk score; Step S64: Embed the comprehensive risk score into the event risk value calculation process of step S30. When the comprehensive risk score exceeds the real-time load threshold, a high-priority alarm is triggered.

10. The method as described in claim 1, characterized in that, It also includes a method for integrating height and weight information to calculate BMI and provide personalized recommendations, the method comprising the following steps: Step S70: Obtain height and weight data from the patient's electronic medical record system. After verifying the patient's identity through the identity authentication interface, the height and weight data are stored in the health record. Step S71: Calculate the BMI value based on the height data and the weight data, and output the standardized BMI index; Step S72: Generate health recommendations based on the personalized rule base of the knowledge graph, wherein the personalized rule base stores the association rules between BMI and blood glucose control; Step S73: Associate the health advice with the event risk value. When the event risk value is determined to be the delayed physiological blood glucose fluctuation, automatically push the health advice to the patient's terminal. Step S74: The BMI value is fed back to the knowledge graph in real time to optimize the risk stratification threshold. The feedback data is used to update the nurse workload-patient risk dynamic weight matrix after integrity verification. The method as described in claim 1, characterized in that, It also includes a method for platform-supported mini-program integration, the method comprising the following steps: Step S80: Construct the mini-program access interface layer. The interface layer interacts with the central monitoring system through a RESTful API. The RESTful API defines data request specifications and includes a security authentication mechanism. Step S81: Encrypt and transmit the monitoring data captured in step S10 and the health advice generated in step S73 to the mini-program cache area. Step S82: Implement data visualization on the mini-program, parse the synchronized data to generate interactive charts, and transmit the user operation logs back to the central monitoring system in real time; Step S83: Respond to the user's remote operation command. When a risk assessment request is submitted through the mini-program, the event risk value is recalculated by calling the nighttime risk stratification rule base. Step S84: The synchronized data of the mini-program comes from the real-time output of the central monitoring system, and the returned user operation log is used to optimize the calculation logic of the nurse's current task count. The method as described in claim 1, characterized in that, It also includes a nurse emergency training simulation method based on virtual reality technology, the method comprising the following steps: Step S90: Construct a virtual ward scene, wherein the data of the virtual ward scene comes from the real monitoring data captured in step S10; Step S91: Simulate a hypoglycemic event in the virtual ward scenario, wherein the hypoglycemic event is generated based on historical real hypoglycemic event data; Step S92: Receive emergency treatment operations performed by nurses in the virtual ward scene through VR devices, and record the emergency treatment operations in real time and synchronize them to the central system. Step S93: Generate a training score based on the matching degree between the emergency response operation and the standard procedure, and feed the training score back to the knowledge graph to optimize the nurse workload-patient risk dynamic weight matrix; Step S94: The training data is linked with the real monitoring data, and the alarm threshold for the corresponding nurse responsible for the same type of event is adjusted in the actual monitoring based on the training score. The method as described in claim 1, characterized in that, It also includes a patient immersive health education method based on virtual reality technology, the method comprising the following steps: Step S100: Generate a virtual body model based on the patient's individual data. The virtual body model reflects the blood glucose changes and sleep stage data in step S10 in real time. Step S101: Simulate the effects of diet, exercise, and medication on blood glucose in a virtual environment, wherein the simulation is based on the medical rule base in the knowledge graph; Step S102: When step S30 determines that the blood glucose fluctuation is a delayed physiological fluctuation, the VR education module is automatically triggered to guide the patient to watch a virtual explanation of the cause of the current fluctuation. Step S103: Record the patient's interaction data in the VR education module to the health record. The interaction data is used to optimize the health suggestion generation logic in step S72. Step S104: Feedback the educational effect to the monitoring system, and increase the alarm suppression weight of the patient for subsequent similar physiological blood glucose fluctuation events based on the specific educational modules completed by the patient.

Images