A novel centralized remote infusion management method and system for insulin

Abstract

This invention discloses a novel centralized remote insulin infusion management method and system, relating to the field of diabetes telemedicine technology. The invention employs a dual-platform architecture separating monitoring and intervention, with the cloud server and dedicated monitoring station as independent cloud subsystems. A persistent WebSocket connection is established between the cloud and the execution terminal to complete identity verification and communication key negotiation. Remote commands are sequentially checked for legality and concurrent conflicts, and command issuance is controlled by a distributed concurrent lock at specified time intervals to prevent deadlock. After completing local security verification, the execution terminal forwards the command to the insulin pump, synchronizing the execution status to the cloud and management terminal in real time, achieving closed-loop control throughout the entire process. This invention significantly improves the real-time performance and security of remote insulin infusion, overcoming the shortcomings of traditional SMS remote control solutions, such as cumbersome processes, unreliable communication, and inability to adapt to centralized management.

Description

Technical Field

[0001] This invention relates to a medical monitoring and management technology, and more particularly to a novel centralized remote insulin infusion management method and system. Background Technology

[0002] Diabetes mellitus is a prevalent chronic metabolic disease worldwide, and insulin infusion therapy is the core means of controlling patients' blood glucose levels and reducing the risk of complications. With the development of the Internet of Things and medical information technology, remote blood glucose monitoring platforms have been widely used in clinical and home blood glucose management, enabling the cloud-based aggregation, visualization, and abnormal alerts of blood glucose data and device operating status.

[0003] Open-source artificial pancreas systems (such as AndroidAPS, or AAPS) have driven the development of personalized blood glucose management as important tools for automated blood glucose management. Their built-in remote control function was initially designed primarily for collaborative scenarios between individual users, thus employing the then-common Short Message Service (SMS) as the communication mechanism. However, when this solution is placed in a professional medical environment with more stringent requirements for real-time performance, reliability, security, and operational efficiency, its three inherent flaws become significant bottlenecks to its widespread application. Traditional SMS solutions impose a heavy cognitive and operational burden on operators. Healthcare workers not only need to memorize and manually edit complex instruction templates for different functions, but also must rely on a separate, time-based one-time password (TOTP) tool to generate dynamic verification codes. Sending a single remote infusion command is a multi-step, asynchronous, and highly prone-to-failure "SMS handshake" process: First, medical staff send a command SMS to the patient's mobile phone number; then, they must passively wait for the patient's mobile phone to reply with a confirmation SMS stating "Command received, please enter verification code + PIN code"; finally, only after receiving this reply can the medical staff send a second dynamic verification code SMS to complete the final authorization. This process is not only cumbersome and has a high operational threshold, but its core problem lies in its asynchronous waiting mechanism. In a time-sensitive medical setting, any delay or loss of an SMS will interrupt the entire treatment intervention process, highlighting its extreme inefficiency.

[0004] Remote control inevitably relies on network transmission, but its core flaw lies not in the network itself, but in the unreliability of the chosen communication protocol. The problem with traditional solutions is their choice of SMS, a "store-and-forward" best-effort communication protocol. The protocol's design inherently cannot guarantee real-time, sequential, or guaranteed delivery, which is unacceptable in demanding clinical applications. This directly leads to frequent command delays or loss, severely impacting the timeliness of treatment.

[0005] A more serious safety hazard lies in the lack of a feedback mechanism. The transmission of command execution results (such as the actual infusion dose) also relies on SMS, often resulting in lost or incomplete feedback information, and even serious data inconsistencies where the feedback value does not match the actual execution value at the pump. This control mode prevents medical staff from accurately grasping the final treatment effect, posing a significant safety risk to the precision treatment of patients.

[0006] The traditional "phone-to-phone" point-to-point architecture is fundamentally incompatible with the "centralized and platform-based" management needs of modern clinical practice. When a nurse needs to manage multiple inpatients simultaneously, this model degenerates into a disaster requiring the tracking of countless independent and disorganized text message conversations. A significant amount of healthcare staff's energy is consumed by tedious communication and status confirmation, rather than professional medical decision-making. This fragmented operational silo makes the centralized, highly efficient work model that diabetes specialists and nursing teams hope to achieve—based on "one person managing multiple beds," and ultimately "one team managing the entire hospital"—unfeasible in practice. A fundamental contradiction exists between the technological architecture and clinical needs. Summary of the Invention

[0007] The technical problem solved by this invention is to provide a novel centralized remote insulin infusion management method and system, which solves the core technical problem in existing traditional remote insulin infusion management systems where remote control command communication is unreliable and cannot meet the requirements of safe, stable and efficient remote infusion operation in clinical practice.

[0008] The technical solution of this invention is: A novel centralized remote insulin infusion management method, employing a dual-platform architecture that separates monitoring and intervention, includes the following steps: S1: The end server establishes a persistent WebSocket connection with the execution terminal and completes identity verification and communication key negotiation; the cloud server automatically deploys a dedicated monitoring station for the patient. The dedicated monitoring station and the cloud server are two independent cloud subsystems. The execution terminal uploads data to the dedicated monitoring station in real time. S2: The management terminal initiates a remote infusion control request, and the cloud server performs a validity check on the request parameters. The checks include dose constraint check, frequency limit check, and concurrent command conflict check. S3: The cloud server enables a distributed concurrent lock with a deadlock prevention time of 20 seconds, sends an input command to the execution terminal through the WebSocket connection, and waits to receive confirmation feedback; S4: After the terminal receives the instruction, it sends a confirmation of receipt to the cloud server and performs local security verification on the instruction; the cloud server changes the instruction status to pending processing; the terminal performs local security verification on the received instruction. S5: After the local security verification is successful, the execution terminal forwards the instruction to the insulin pump to perform the infusion operation; the execution terminal reports the instruction execution status to the cloud server, and the cloud server changes the instruction status to in progress; S6: The execution terminal synchronizes the instruction execution status with the cloud server in real time, and provides feedback on the final execution result after the input is completed; S7: The cloud server synchronizes the instruction execution status and results to the management terminal to achieve closed-loop control of the entire process.

[0009] A novel centralized remote insulin infusion management system includes a cloud server with independent functions, a dedicated monitoring station, a mobile management terminal, an execution terminal, and an insulin pump. The execution terminal has a built-in and runs a customized AAPS application. The execution terminal establishes a persistent long connection with the business cloud server via WebSocket and communicates with the insulin pump via Bluetooth Low Energy. The business cloud server is used to automatically deploy dedicated monitoring sites for patients, complete the identity verification and communication key negotiation of the execution terminal, perform legality verification and concurrent conflict verification of remote commands initiated by the mobile management terminal, control the issuance of commands through distributed concurrent locks, and synchronize the command execution status and results to the mobile management terminal. The dedicated monitoring station is used to receive and store blood glucose data, device status data and treatment log data uploaded by the execution terminal, so as to realize monitoring and abnormal early warning; The mobile management terminal is used by medical staff to initiate remote insulin infusion commands or remote carbohydrate declaration commands, and to display the status and results of the entire command execution process. The execution terminal is used to receive and verify the instructions issued by the business cloud server, forward the instructions to the insulin pump, synchronize the execution status through WebSocket and HTTP dual channels, run the AAPS core algorithm and intelligent hypoglycemia trend pause function locally, cache data when the network is interrupted and synchronize it in time order after the network is restored; The insulin pump is used to execute infusion commands issued by the terminal and to provide feedback on the execution results.

[0010] As can be seen from the above description, the present invention does indeed have the following advantages: The platform deployment and usage threshold has been significantly reduced. This invention unifies and platforms traditional open-source monitoring platforms, enabling one-click deployment, automatic configuration, and cloud hosting. It eliminates the need for complex operations such as personal servers and manual deployment, making it more suitable for hospitals to quickly connect to and use a large number of patients in a long-term stable manner.

[0011] The reliability of remote command communication is greatly improved. This invention uses WebSocket long connection to replace unreliable communication methods such as traditional SMS and HTTP polling. Combined with command handshake, timeout retransmission, verification and error correction, and real-time execution status feedback mechanism, it fundamentally solves problems such as command loss, delay, missed execution, and repeated execution, and ensures the stability and security of remote infusion control.

[0012] To achieve closed-loop control throughout the entire process, this invention constructs a reliable four-layer architecture of "management terminal - cloud terminal - execution terminal - infusion device", forming a complete control closed loop of "issuance - confirmation - execution - feedback". Medical staff can grasp the execution results of instructions in real time and accurately, eliminating the clinical risks caused by information asymmetry.

[0013] Supporting centralized and hospital-wide efficient management, this invention enables unified monitoring, centralized display, hierarchical authorization, batch management, and unified alarm push for multiple patients, truly supporting the efficient clinical work model of "one person managing multiple beds and one team managing the entire hospital," significantly reducing the workload of medical staff and improving management efficiency.

[0014] The medical-grade security and anomaly protection mechanisms are more comprehensive. This invention effectively avoids risks such as illegal operations, command conflicts, and duplicate infusions through multiple security mechanisms such as identity authentication, command signing, dosage constraints, distributed concurrent locks, and network interruption caching and resume transmission. It can still ensure local treatment safety when the network is abnormal, and automatically synchronize data after recovery, comprehensively improving system security, compliance and traceability. Attached Figure Description

[0015] Figure 1 This is a schematic flowchart of the method steps of a preferred embodiment of the present invention; Figure 2 This is a schematic diagram of the system architecture of a preferred embodiment of the present invention. Detailed Implementation

[0016] To provide a clearer understanding of the technical features, objectives, and effects of the present invention, specific embodiments of the present invention will now be described with reference to the accompanying drawings.

[0017] This invention relates to the field of telemedicine technology for diabetes, specifically a novel centralized remote insulin infusion management method and system based on WebSocket. Traditional open-source artificial pancreas systems, such as the remote control function built into Android APS, were initially designed only for peer-to-peer assistance scenarios, using Short Message Service (SMS) as the communication mechanism. In professional medical environments, these systems exhibit fatal flaws, including complex processes, unreliable communication, and an architecture incompatible with centralized management. Healthcare professionals not only need to memorize and manually edit complex instruction templates for different functions, but also must rely on a separate, time-based one-time password (TOTP) tool to generate dynamic verification codes. Healthcare professionals need to install a separate TOTP application on their mobile phones, manually enter the key provided by the patient to generate a 6-digit dynamic verification code, and the verification code automatically refreshes every 30 seconds, requiring regeneration upon expiration, further increasing the complexity and error probability of the operation. Issuing a single remote infusion command is a multi-step, asynchronous, and highly prone-to-failure "SMS handshake" process: First, medical staff send a command SMS to the patient's mobile phone number; then, they must passively wait for the patient's mobile phone to reply with a confirmation SMS stating "Command received, please enter verification code + PIN code"; finally, only after receiving this reply can the medical staff send a second dynamic verification code SMS to complete the final authorization. This process is not only cumbersome and has a high operational threshold, but its core problem lies in its asynchronous waiting mechanism. In the time-sensitive medical setting, any delay or loss of an SMS will lead to the interruption of the entire treatment intervention process.

[0018] More seriously, the crux of the problem with traditional solutions lies in their choice of SMS, a "store-and-forward" best-effort communication protocol. The protocol itself cannot guarantee real-time, sequential, and guaranteed delivery, which is unacceptable in demanding clinical applications and directly leads to frequent command delays or loss. The lack of a feedback mechanism further creates significant safety risks. The transmission of command execution results (such as actual infusion dose) also relies on SMS, often resulting in lost or incomplete feedback information, and even serious data inconsistencies where feedback values ​​do not match the actual values ​​executed at the pump. The traditional "phone-to-phone" point-to-point architecture is fundamentally unable to adapt to the "centralized and platform-based" management needs of modern clinical practice. When a nurse needs to manage multiple inpatients at the same time, this model degenerates into a disaster that requires tracking countless independent and disordered text message conversations. A large amount of the medical staff's energy will be consumed in tedious communication and status confirmation, rather than professional medical decision-making. As a result, the centralized and efficient working model that the diabetes specialist nurse team hopes to achieve, based on "one person managing multiple beds" and then "one team managing the whole hospital", cannot be implemented in practice.

[0019] To address the aforementioned technical bottlenecks, this invention innovatively proposes a dual-platform cloud architecture that separates monitoring and intervention, constructing a four-layer intervention system consisting of "management terminal - cloud server - execution terminal - CGM + insulin pump". Through one-click deployment and modification of the open-source Nightscout platform, automated cloud aggregation and real-time monitoring of patient data are achieved. WebSocket long connections are used to replace traditional SMS communication, resolving the issues of real-time and reliability in command transmission. A multi-layered security and privacy system is established throughout the entire data lifecycle, complying with mainstream international data protection regulations such as HIPAA, GDPR, and PIPL. The core AAPS algorithm and intelligent hypoglycemia trend pause function are fully preserved, ensuring mature and stable treatment decisions. This solution represents a leap from a limited personal tool to a professional clinical management platform, providing solid technical support for a 1-vs-N centralized remote management model, and significantly improving the safety, efficiency, and scalability of remote insulin therapy.

[0020] This invention proposes a novel centralized remote insulin infusion management method. Please refer to [link to relevant documentation]. Figure 1 and Figure 2 In a preferred embodiment, a dual-platform architecture separating monitoring and intervention is adopted, including the following steps: S1: The cloud server establishes a persistent WebSocket connection with the execution terminal and completes identity verification and communication key negotiation; the cloud server automatically deploys a dedicated monitoring station for the patient. The dedicated monitoring station and the cloud server are two independent cloud subsystems. The execution terminal uploads data to the dedicated monitoring station in real time. S2: The management terminal initiates a remote infusion control request, and the cloud server performs a validity check on the request parameters. The checks include dose constraint check, frequency limit check, and concurrent command conflict check. S3: The cloud server opens a distributed concurrent lock to prevent deadlock at a specified time interval (20 seconds is preferred), sends an input command to the execution terminal through the WebSocket connection, and waits to receive confirmation feedback; S4: After the terminal receives the instruction, it sends a confirmation of receipt to the cloud server and performs local security verification on the instruction; the cloud server changes the instruction status to pending processing; the terminal performs local security verification on the received instruction. S5: After the local security verification is successful, the execution terminal forwards the instruction to the insulin pump to perform the infusion operation; the execution terminal reports the instruction execution status to the cloud server, and the cloud server changes the instruction status to in progress; S6: The execution terminal synchronizes the instruction execution status with the cloud server in real time, and provides feedback on the final execution result after the input is completed; S7: The cloud server synchronizes the instruction execution status and results to the management terminal to achieve closed-loop control of the entire process.

[0021] In this embodiment, the execution terminal can be a mobile device such as a smartwatch or smartphone, with a smartwatch being the preferred implementation due to its advantages of small size, ease of wear, and long battery life, making it very suitable as a wearable medical execution terminal. Step S1 uses WebSocket long-lived connections as the core communication protocol, completely abandoning the traditional SMS "store-and-forward" best-effort transmission mode. WebSocket is a full-duplex communication protocol that can establish a persistent connection between the client and the server, allowing both parties to send data to each other at any time without establishing a new connection for each communication like HTTP. This feature reduces the transmission latency of instructions to the millisecond level, fully meeting the real-time requirements of clinical emergency scenarios. In contrast, the transmission latency of the traditional SMS protocol is usually between several seconds and several minutes, with a packet loss rate of about 5%-10%. In areas with network congestion or poor base station signals, the packet loss rate can be even higher, which is unacceptable for insulin therapy that requires precise control of infusion time.

[0022] Identity verification and communication key negotiation form the first line of defense for system security. When establishing a WebSocket connection, the executing terminal sends an authentication request containing the device's unique identifier and the patient's account information to the cloud server. The cloud server performs multiple verifications on this information to ensure that only authorized devices can access the system. After successful verification, the cloud server generates a unique communication key and returns it to the executing terminal. All subsequent command interactions will use this key for encryption and signing to prevent commands from being eavesdropped on or tampered with during transmission.

[0023] This invention innovatively proposes a dual-platform architecture that separates monitoring and intervention. Specifically, a dedicated monitoring station and a cloud server are two independent, clearly defined cloud subsystems. The dedicated monitoring station is only responsible for receiving, storing, visualizing, and issuing anomaly alerts, without participating in any command issuance or control. The cloud server, on the other hand, is dedicated to command processing, routing, and closed-loop control, without handling data display. This separation architecture offers several advantages: First, the two systems can be deployed and expanded independently. When the amount of monitoring data increases, the server resources of the dedicated monitoring station can be expanded independently without affecting command processing performance. Second, it achieves minimal access control; medical staff do not need command issuance permissions to view monitoring data, reducing the risk of misoperation. Finally, even if one system fails, the other system can still operate normally. For example, if the cloud server experiences a brief failure, the dedicated monitoring station can continue to receive and display the patient's blood glucose data, ensuring that basic monitoring functions are not affected.

[0024] The legality verification in step S2 is a crucial step in ensuring treatment safety. After receiving a remote infusion control request from the management terminal, the cloud server does not immediately issue instructions but instead performs rigorous multi-dimensional verification of the request parameters. Dosage constraint verification prevents excessive insulin infusion in a single instance or within a short period, avoiding severe hypoglycemic events. Frequency restriction verification prevents overly frequent infusion operations, preventing excessive blood glucose fluctuations due to dose accumulation. Concurrent instruction conflict verification prevents multiple healthcare professionals from simultaneously issuing instructions to the same patient, leading to incorrect infusion dosages. These verification rules are based on extensive clinical data and expert experience, enabling the interception of the vast majority of unsafe instructions in the cloud, thus safeguarding patient safety from the outset.

[0025] The distributed concurrent lock mechanism in step S3 is designed to address the issue of concurrent operations across multiple endpoints. In real-world hospital applications, multiple medical staff may simultaneously log into the same patient's management interface and attempt to issue commands. Without a concurrency control mechanism, multiple commands could be executed concurrently, leading to excessive infusion dosage. This invention employs a distributed concurrent lock, implemented using Redis. Leveraging Redis's single-threaded nature and atomic operations, it ensures that only one client can acquire the lock at any given time in a distributed environment, effectively preventing command conflicts caused by concurrent operations across multiple endpoints. When the cloud server receives a command request, it immediately acquires the lock corresponding to that patient. Before the lock is released, all other command requests for that patient are rejected. The lock's deadlock prevention timeout is set to 20 seconds. This is because the command processing flow of the system platform on which this invention is based typically completes within 10 seconds. The 20-second timeout ensures that the lock is not held for an extended period and also prevents premature lock release due to network latency or other reasons. Meanwhile, the cloud server will initiate a 30-second instruction arrival timeout. If no confirmation of receipt is received from the execution terminal within 30 seconds, the instruction transmission will be considered to have failed, the instruction will be marked as expired, and the lock resources will be released to allow subsequent instructions to be issued normally.

[0026] The system defines a complete enumeration of instruction status values, including six states: Pending, In Progress, Completed, Cancelled, Expired, and Failed. After an instruction is issued, its initial state is Pending. Once the execution terminal begins execution, it changes to In Progress. Successful execution changes it to Completed. User-initiated cancellation changes it to Cancelled. Failure to execute within timeout changes it to Expired. An error during execution changes it to Failed. All state transitions have clear triggering conditions and are logged, ensuring full traceability of the instruction process.

[0027] Step S4, the local security verification of the execution terminal, is an important supplement to the cloud verification, forming a dual security defense of "cloud + local". Even if the cloud server is compromised and an attacker issues malicious commands, the local verification of the execution terminal can intercept these commands and prevent their execution. After receiving a command, the execution terminal first verifies the digital signature and timestamp of the command to ensure that the command was sent by a legitimate cloud server and has not been tampered with; then it checks the low-power Bluetooth connection status between itself and the insulin pump to ensure normal communication; next, it checks the remaining insulin dosage of the pump to prevent infusion interruption due to insufficient dosage; finally, it checks whether there is any ongoing manual infusion operation to avoid conflicts between automatic commands and manual operations. If any verification fails, the execution terminal will refuse to execute the command and report the specific error code to the cloud server so that medical staff can handle it in a timely manner.

[0028] In step S5, the execution terminal forwards the command to the insulin pump via Bluetooth Low Energy (BLE). Bluetooth Low Energy is characterized by low power consumption, stable connection, and moderate transmission distance, making it ideal for communication between wearable devices and medical devices. After successfully sending the command to the insulin pump, the execution terminal immediately reports the command execution status to the cloud server. The cloud server then updates the command status to "in progress" and synchronizes it to the management terminal, allowing medical staff to monitor the command execution progress in real time.

[0029] In step S6, the execution terminal synchronizes the execution status of the instruction with the cloud server in real time, including information such as the infusion progress and remaining dose. Once the infusion is complete, the execution terminal sends the final dose back to the cloud server, ensuring that the dose recorded in the cloud is completely consistent with the dose actually infused by the insulin pump. This real-time synchronization mechanism solves the problems of lost feedback information and inconsistent data in traditional SMS protocols, allowing medical staff to accurately grasp the final treatment effect.

[0030] In step S7, the cloud server synchronizes the entire process status and final execution result of the instruction to the management terminal. Medical staff can clearly see the entire process of the instruction from initiation, issuance, execution to completion on the management terminal, realizing closed-loop control of the entire remote operation process. Compared with the drawbacks of asynchronous waiting and inability to track execution status in traditional SMS solutions, the closed-loop control mechanism of this invention greatly improves the controllability and security of remote operation, allowing medical staff to precisely control insulin infusion as if they were at the patient's bedside.

[0031] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention described above, in step S1, the dedicated monitoring station is automatically deployed and configured with an independent access password through patient mobile phone number verification; medical staff access the station after authorization by the patient; patient-side data uploaded by the execution terminal through a customized AAPS application includes blood glucose level, insulin pump power consumption, remaining insulin dosage, AAPS closed-loop operation status, algorithm decision data, device connection log, application operation log, and treatment instruction records; the dedicated monitoring station triggers an alarm when blood glucose exceeds the limit, pump power consumption is below the threshold, or no data is received within a specified time interval.

[0032] In this embodiment, the dedicated monitoring site can be a new, customized platform with an architecture similar to the open-source Nightscout platform. While the traditional Nightscout platform is powerful, its deployment process is extremely complex, requiring users to possess certain technical skills to download code from GitHub, purchase and configure cloud servers independently, and manually complete the deployment. The original Nightscout adopted a "single-user, self-deployment" model, essentially a personal self-built service with one server, one account, and one site per person. Users not only need to purchase cloud servers, configure Linux operating systems, install databases and web servers, but also manually modify configuration files and compile and run code. The entire process involves dozens of technical steps, making it almost impossible for ordinary patients and medical staff without programming experience to complete. This model also suffers from serious resource waste; one cloud server can only provide services to one patient, failing to support the centralized management needs of hospitals where "one person manages multiple beds, and one team manages the entire hospital."

[0033] To address this issue, this invention proposes a one-click deployment method for a dedicated monitoring platform site. The invention features a minimalist interface and data interaction format, providing a centralized, hospital-wide cluster similar to the Nightscout platform. This cluster is physically isolated from existing overseas NS systems, operates independently, and is autonomously controllable. All patient data is stored on compliant domestic cloud servers, fully complying with domestic data security regulations such as the "Personal Information Protection Law of the People's Republic of China." In practical use, users (patients) only need to verify their mobile phone number on the medical system providing this one-click deployment function. The system then automatically creates and deploys a dedicated, password-protected monitoring site for them in the cloud. Employing a multi-tenant cluster architecture, all patients share the same cloud server cluster. Tenant isolation technology and independent database instances ensure strict isolation of different patient data, guaranteeing data non-interference and absolute confidentiality. A standard cloud server cluster can simultaneously support the monitoring needs of hundreds or even thousands of patients, increasing resource utilization by hundreds of times and completely solving the resource waste problem of the traditional single-user model. The entire process requires no technical operation from the user and takes less than one minute. This one-click deployment method greatly reduces the barrier to entry for the system and solves the problem that the Nightscout platform cannot be applied to large-scale clinical scenarios.

[0034] Each dedicated monitoring station is configured with an independent access password and uses the HTTPS encrypted transmission protocol to ensure data security during transmission. After authorization from the patient, the medical team can access the patient's dedicated monitoring page from any network terminal for real-time data monitoring. The authorization process employs a strict identity verification mechanism; medical staff need to enter their employee ID, password, and a temporary authorization code provided by the patient to gain access. The temporary authorization code generated by the patient is valid for 24 hours and automatically expires afterward. Medical staff need to obtain new authorization to continue accessing the site, further ensuring the privacy and security of patient data. This authorization mechanism fully protects the patient's right to privacy and complies with relevant regulations on medical data protection.

[0035] In the customized AAPS App, users only need to enter the URL and key of the platform-generated dedicated monitoring station to achieve automated, continuous, and real-time uploading of data such as blood glucose, insulin pump status (e.g., battery level, dosage), closed-loop status, and algorithm decisions. This data covers all aspects of patient blood glucose management, providing healthcare professionals with comprehensive and accurate patient status information. Blood glucose levels are the most crucial monitoring data. The customized AAPS application retrieves blood glucose values ​​from the CGM (Continuous Glucose Monitoring) device every 5 minutes and immediately uploads them to the dedicated monitoring station. Healthcare professionals can view real-time blood glucose curves on the station to understand the patient's blood glucose trends. Insulin pump battery level and remaining insulin dosage data help healthcare professionals remind patients in advance to replace batteries or replenish insulin, avoiding treatment interruptions due to device power outages or insufficient dosage. AAPS closed-loop operation status data allows healthcare professionals to understand whether the closed-loop system is working properly and whether any abnormalities have occurred. Algorithm decision data records the reasons and basis for each adjustment of the basal rate or infusion of a large dose by the AAPS system, helping healthcare professionals analyze treatment effects and optimize treatment plans. The device connection log records the connection and disconnection status between the execution terminal and the insulin pump, CGM device, and cloud server, facilitating medical staff in troubleshooting device malfunctions. The application operation log records the running status of the AAPS application, including information such as application startup, shutdown, and crashes, providing a basis for system maintenance and optimization. The treatment instruction log completely saves all locally and remotely issued treatment instructions and their execution results, serving as an important basis for handling medical disputes and evaluating treatment effectiveness.

[0036] The NS platform itself has a powerful early warning function. Once a patient experiences abnormal blood sugar, low insulin pump battery, or an extended period without new data uploads from the AAPS (Advanced Analytic Perceptual System), the dedicated monitoring station can proactively issue alarms to notify the healthcare team for timely intervention. When a patient's blood sugar level is higher or lower than the preset normal range, the station will immediately issue a blood sugar over-limit warning, reminding healthcare personnel to intervene promptly. When the insulin pump's battery level falls below a preset threshold (usually 20%), the station will issue a low battery warning, reminding the patient to replace the batteries. If no data is received from the execution terminal for 30 consecutive minutes, the station will issue a data interruption warning, which may indicate a network disconnection, device shutdown, or other malfunction, requiring healthcare personnel to contact the patient immediately to troubleshoot the problem. These warning messages are sent to healthcare personnel via SMS, push notifications, and other methods to ensure that abnormal situations are detected and addressed promptly.

[0037] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention as described above, step S1 includes identity verification including account existence verification, account availability verification, device number verification, and device binding relationship verification; the cloud server stores the mapping relationship between WebSocket connections and accounts; all interactive instructions between the cloud server and the execution terminal are integrated with digital signatures and timestamps based on communication keys.

[0038] In this embodiment, identity verification is the first line of defense for system security. Only execution terminals that pass identity verification can establish a WebSocket connection with the cloud server and interact with data. Identity verification includes four levels of verification, progressively strengthening each other to ensure that devices and users accessing the system are legitimately authorized. First is account existence verification: the cloud server checks whether the patient account submitted by the execution terminal exists in the system database. If the account does not exist, the cloud server will directly reject the connection request, preventing unauthorized accounts from attempting to access the system. This verification can block the vast majority of malicious connection attempts and is the basic line of defense for system security. Second is account availability verification: even if the account exists, the cloud server will check whether the account is in an available state. If the account is frozen or canceled due to unpaid fees, violations, etc., the cloud server will also reject the connection request. This mechanism ensures that only users who pay normally and comply with the usage rules can use the system, guaranteeing the normal operation of the system. Third is device number verification: each execution terminal has a globally unique device number. When a patient uses the system for the first time, they need to bind the execution terminal's device number to their account. When performing identity verification, the cloud server checks whether the device number submitted by the execution terminal matches the device number bound to the account in the database. If there is a discrepancy, it indicates that the device may have been stolen or misused. The cloud server will reject the connection request and send an abnormal login alert to the patient. This verification effectively prevents others from using unauthorized devices to access the patient's medical data or control the insulin pump. Finally, there is a device binding verification. The cloud server checks whether the device ID is already bound to other accounts. If a device ID is already bound to another account, it means that the device may be shared by multiple people, which is extremely dangerous in a medical setting because different patients have completely different treatment plans and dosage requirements. Sharing devices could lead to serious medical accidents. Therefore, the cloud server will reject such connection requests and prompt the user to unbind the device from other accounts.

[0039] After successful identity verification, the cloud server generates a unique communication key and returns it to the execution terminal. Simultaneously, it stores the mapping between WebSocket connections and patient accounts in the database. This mapping ensures that when the cloud server receives a command request, it can accurately send the command to the corresponding patient's execution terminal, preventing mis-sending of commands. When the WebSocket connection is closed, the cloud server automatically deletes the corresponding mapping and releases resources.

[0040] To ensure the integrity and authenticity of instructions during transmission, all interactive instructions between the cloud server and the execution terminal are integrated with digital signatures. This ensures that the instructions have not been tampered with during transmission and verifies the legitimacy of their origin. Simultaneously, by introducing timeliness verification (timestamps), replay attacks are effectively prevented. The digital signatures are generated using an asymmetric encryption algorithm; this system employs the Elliptic Curve Digital Signature Algorithm (ECDSA), which, compared to the traditional RSA algorithm, offers shorter key lengths and faster computation speeds at the same security strength, making it ideal for resource-constrained devices such as execution terminals. The cloud server signs the instruction content using its private key, and the execution terminal verifies the signature using the cloud server's public key. If the verification passes, it indicates that the instruction has not been tampered with during transmission and was indeed sent by a legitimate cloud server. The timestamp is used to prevent replay attacks. Even if an attacker intercepts a legitimate instruction, they cannot resend it later because the execution terminal checks the timestamp in the instruction. If the difference between the timestamp and the current time exceeds a preset threshold (usually 5 minutes), the instruction is considered invalid.

[0041] This solution strictly adheres to the data processing principles of "legality, fairness, and transparency." All collection, uploading, and sharing of patient data are contingent upon the patient or their guardian signing a detailed Informed Consent Form and Privacy Policy. The software clearly and understandably informs users of the purpose of data processing, the scope of use, the storage method, and the rights and obligations of both parties, fully protecting users' right to know. Furthermore, the entire system is designed closely around the specific medical purpose of "diabetes AID treatment and management," collecting no unnecessary data unrelated to this purpose, naturally adhering to the principles of "purpose limitation" and "data minimization." This multi-layered identity verification mechanism and encrypted communication scheme construct a robust security defense, effectively resisting various common cyberattacks and ensuring the safety of patients' medical data and treatment.

[0042] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention as described above, in step S2, the dose constraint verification of the remote insulin infusion command is as follows: the cumulative infusion dose within 2 hours is ≤15U, and the cumulative infusion dose within 24 hours is ≤60U; the frequency limit verification is as follows: the number of commands within 24 hours is ≤20, and the interval with the previous command is ≥15 minutes; the dose constraint verification of the remote carbohydrate declaration command is as follows: the cumulative dose within 24 hours is ≤500g, and the frequency limit verification is as follows: the number of commands within 24 hours is ≤20.

[0043] In this embodiment, the dose constraint verification and frequency limit verification were developed based on extensive clinical data and diabetes treatment guidelines, aiming to prevent hypoglycemia or drastic blood glucose fluctuations caused by excessive or frequent infusions. These thresholds have been repeatedly demonstrated and clinically validated by endocrinologists, covering the treatment needs of the vast majority of diabetic patients while maximizing treatment safety.

[0044] The restriction of no more than 15 U of cumulative infusion dose within 2 hours for remote insulin infusion instructions is to prevent a rapid drop in blood glucose caused by a large infusion of insulin in a short period. Insulin's duration of action is typically 2-4 hours. Infusing more than 15 U of insulin within 2 hours can cause a rapid increase in insulin concentration in the patient's body, potentially leading to severe hypoglycemic coma or even death. The restriction of no more than 60 U of cumulative infusion dose within 24 hours is based on statistical data on the total daily insulin requirements of most diabetic patients. Generally, the total daily insulin requirement for adult diabetic patients is between 0.5-1.0 U / kg body weight. For a patient weighing 60 kg, the total daily requirement is approximately 30-60 U. Therefore, limiting the cumulative dose of remote infusion to 60 U within 24 hours effectively prevents hypoglycemic events caused by excessive remote infusion.

[0045] The frequency limit check, restricting the number of instructions to no more than 20 within 24 hours, is to prevent healthcare professionals from adjusting insulin dosage too frequently, leading to excessive blood sugar fluctuations. Blood sugar regulation in diabetic patients is a slow process; insulin takes time to take effect and be metabolized. Too frequent dosage adjustments can cause blood sugar to become uncontrolled, resulting in erratic fluctuations. The restriction of at least 15 minutes between instructions is to allow sufficient time for the previously infused insulin to take effect, preventing repeated infusions before the insulin has taken effect, thus avoiding dose accumulation. For example, if a healthcare professional issues an infusion instruction when a patient's blood sugar is high, but insulin takes 15-30 minutes to take effect, the patient's blood sugar may continue to rise during those 15 minutes. If the healthcare professional is impatient and issues another infusion instruction, the doses from the two infusions will accumulate, ultimately causing the patient's blood sugar to drop too low.

[0046] The limit of no more than 500g of cumulative carbohydrate dose declared remotely within 24 hours is based on statistical data on the daily carbohydrate intake of normal adults. Generally, the daily carbohydrate intake of normal adults is between 200-400g, and even for patients with high levels of physical activity, the daily intake rarely exceeds 500g. Therefore, limiting the cumulative carbohydrate dose declared remotely within 24 hours to 500g can effectively prevent excessive or insufficient insulin infusion due to incorrect carbohydrate input. The limit of no more than 20 commands within 24 hours is also to avoid excessively frequent declarations, which could lead to excessive fluctuations in blood glucose levels.

[0047] It's important to note that these thresholds are not fixed and can be adjusted individually by system administrators based on each patient's specific situation. For example, for patients with severe insulin resistance, the total daily insulin requirement may exceed 60U, and doctors can set a higher 24-hour cumulative dose limit for that patient within the system. This flexible threshold setting mechanism ensures treatment safety for most patients while also meeting the personalized treatment needs of special patients.

[0048] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention as described above, step S2 includes the concurrent instruction conflict verification as follows: querying the database for pending instructions that have not exceeded 20 minutes, obtaining the last infusion time and manual infusion status of the execution terminal; if there are pending instructions, the interval is less than 15 minutes, or manual infusion is in progress, the cloud server rejects the current instruction.

[0049] In this embodiment, concurrent instruction conflict verification is used to solve the problems of concurrent operation on multiple terminals and instruction timing conflicts, ensuring that at any given time, only one treatment instruction is being processed for the same patient, thus guaranteeing the uniqueness and accuracy of the treatment.

[0050] First, the cloud server checks the database for pending instructions that have been pending for less than 20 minutes. Pending instructions are those sent to the execution terminal but not yet executed or for which the execution result has not yet been returned. If such instructions exist, it means the previous remote operation has not yet completed. Sending a new instruction at this time could result in two instructions being executed simultaneously, leading to an overdose. The validity period for pending instructions is set to 20 minutes because normal instruction execution typically takes less than 10 seconds. The 20-minute time window covers most normal situations without affecting subsequent operations due to instructions remaining in a pending state for an extended period.

[0051] Secondly, the cloud server requests the time of the last insulin injection instruction from the execution terminal and whether there is an ongoing manual insulin injection. This step is crucial because the instruction information recorded in the database may be delayed or inaccurate, while the execution terminal, as the device that communicates directly with the insulin pump, records the most accurate information. By querying the execution terminal directly, the cloud server ensures that it receives the latest instruction status information.

[0052] If the query results show that the time interval between the last insulin injection command from the execution terminal is less than 15 minutes, the cloud server will reject the current command request. This restriction echoes the aforementioned frequency limit check, further strengthening the control over infusion frequency and preventing dose accumulation due to frequent infusions. Even if there is no pending command recorded in the database, if the execution terminal has just performed an infusion operation within 15 minutes, a new command is not allowed to be issued immediately.

[0053] If a manual insulin injection is already in progress on the terminal, the cloud server will also reject the current instruction request. Manual infusion is typically performed by the patient or healthcare professional directly at the bedside using the insulin pump, and has higher priority than remote infusion instructions. Issuing a remote instruction during a manual infusion could result in the dosage of both manual and remote infusions overlapping, potentially causing serious medical accidents. Therefore, the system prioritizes the execution of manual infusions and rejects all remote infusion instructions until the manual infusion is completed.

[0054] When the cloud server rejects a current command request, it returns a clear reason for rejection to the management system, such as "Less than 15 minutes have passed since the last infusion, please try again later" or "The patient is currently receiving a manual infusion, and remote operation cannot be performed." Healthcare professionals can take appropriate measures based on the reason for rejection, such as waiting a period of time before attempting to issue the command again, or contacting the patient to confirm the manual infusion status.

[0055] This dual concurrent instruction conflict verification mechanism, which combines database queries and real-time queries from the execution terminal, can minimize instruction conflicts and ensure the accuracy and safety of treatment.

[0056] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention as described above, in step S3, if the cloud server does not receive a confirmation of receipt within 30 seconds, it marks the instruction as expired and releases the distributed concurrent lock; if the terminal does not execute the instruction after receiving it within 30 minutes, it automatically marks the instruction as expired and synchronizes it to the cloud server.

[0057] In this embodiment, the instruction timeout handling mechanism is designed to address situations such as network transmission anomalies and execution terminal failures, ensuring that the system does not fall into a deadlock state due to the failure of a single instruction, and preventing expired instructions from being executed unexpectedly after the network is restored, which could lead to the patient receiving insulin infusions when not needed.

[0058] After issuing a command, the cloud server starts a 30-second command arrival timeout timer. If a receipt confirmation is received from the execution terminal within 30 seconds, it means the command has successfully reached the execution terminal, and the cloud server will continue to wait for the execution result feedback. If no receipt confirmation is received within 30 seconds, it means the command was lost during transmission or the execution terminal malfunctioned and cannot receive the command. In this case, the cloud server will immediately mark the command as expired and release the previously acquired distributed concurrency lock, allowing subsequent command requests to be processed normally. The 30-second timeout period was determined through repeated testing and optimization. The transmission latency of the WebSocket protocol is usually within 100 milliseconds, and even under poor network conditions, 30 seconds is sufficient for the command to complete transmission. If no confirmation is received after 30 seconds, it can be basically determined that the command transmission failed, and continuing to wait is meaningless.

[0059] Upon receiving a command, the execution terminal also starts a 30-minute command execution timeout timer. Normally, the execution terminal completes local security verification within seconds of receiving the command and forwards it to the insulin pump for execution. However, in certain special circumstances, such as a sudden Bluetooth connection loss between the execution terminal and the insulin pump, or a malfunction in the insulin pump preventing command execution, the execution terminal may not be able to complete the command execution within a short time. If the command is not executed within 30 minutes, it indicates that the command has become expired, and the patient's blood glucose level may have changed. Executing the command at this point could lead to inadequate blood glucose control. Therefore, the execution terminal automatically marks the command as expired and synchronizes the expiration status to the cloud server via both WebSocket and HTTP channels. Upon receiving the expired status, the cloud server updates the command status in its database and synchronizes it to the management end, allowing healthcare personnel to understand the command execution status.

[0060] Once a command expires, the system will not automatically reissue it. Healthcare professionals must reassess the patient's current blood glucose level to determine if a new command is necessary. This design avoids the risk of dosage accumulation caused by automatic reissue of commands, keeping the initiative in treatment decisions firmly in the hands of healthcare professionals.

[0061] This two-way instruction timeout handling mechanism can promptly handle transmission failures from the cloud to the execution terminal, as well as execution failures on the local execution terminal, ensuring stable operation of the system under various abnormal conditions and safeguarding patient treatment safety.

[0062] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention described above, step S4 includes local security verification of instruction digital signature, timestamp validity, Bluetooth connection status between execution terminal and pump, remaining insulin pump dosage, and manual infusion status; if any verification fails, the execution terminal refuses to execute and returns an error code.

[0063] In this embodiment, the local security verification of the execution terminal is the last line of defense to ensure treatment safety. Even if the verification mechanism of the cloud server is breached, local verification can still intercept malicious commands and prevent them from being executed. Local security verification includes five aspects, comprehensively covering all aspects such as command legitimacy, device status, and operational conflicts.

[0064] The first step is instruction digital signature verification. The executing terminal uses a pre-negotiated communication key to verify the digital signature of the instruction. If the verification passes, it means the instruction was sent from a legitimate cloud server and has not been tampered with during transmission. If the verification fails, it means the instruction may have been tampered with or forged by an attacker. The executing terminal will immediately refuse to execute the instruction and send an error code "Digital signature verification failed" to the cloud server. This verification effectively prevents man-in-the-middle attacks and instruction tampering attacks, ensuring the authenticity and integrity of the instruction.

[0065] Secondly, there's the timestamp validity check. The executing terminal checks the difference between the timestamp in the instruction and the current system time. If the difference exceeds a preset threshold (usually 5 minutes), it indicates that the instruction is expired, possibly because an attacker intercepted a previously legitimate instruction and performed a replay attack. In this case, the executing terminal will refuse to execute the instruction and return an "invalid timestamp" error code. Timestamp verification effectively prevents replay attacks, ensuring that instructions can only be executed within a valid time window.

[0066] Thirdly, the execution terminal verifies the Bluetooth connection status between itself and the insulin pump. The execution terminal checks if the low-power Bluetooth connection between itself and the insulin pump is normal. If the Bluetooth connection is lost, the execution terminal cannot forward instructions to the insulin pump, making instruction execution meaningless. Therefore, the execution terminal will refuse to execute the instruction and return a "Bluetooth connection interrupted" error code. Upon receiving this error code, healthcare professionals can remind the patient to check the Bluetooth connection status of the insulin pump to ensure normal device communication.

[0067] Fourthly, there's the insulin pump's remaining insulin level check. The execution terminal queries the insulin pump for the current remaining insulin level. If the remaining level is insufficient to execute the infusion command, the execution terminal will refuse to execute the command and return an error code: "Insufficient insulin level." This check prevents infusion interruptions due to insufficient insulin level, ensuring the patient receives the full therapeutic dose. Upon receiving this error code, healthcare professionals can remind the patient to replenish insulin promptly.

[0068] Finally, there's a manual infusion status check. The execution terminal checks if the insulin pump is currently performing a manual infusion. If an ongoing manual infusion is detected, the execution terminal will refuse to execute the remote command and return an error code indicating "manual infusion in progress." This check prevents conflicts between remote commands and manual operations, thus preventing dose stacking that could lead to hypoglycemia.

[0069] If any check fails, the executing terminal immediately refuses to execute the instruction and sends a specific error code to the cloud server. Upon receiving the error code, the cloud server synchronizes it to the management terminal, allowing medical staff to quickly locate the problem and take appropriate corrective measures. This explicit error feedback mechanism greatly improves the system's maintainability and fault handling efficiency.

[0070] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention described above, step S4, the local security verification step of the execution terminal, further includes an intelligent hypoglycemia trend pause function. This function is run locally by the execution terminal, calculating a dynamic warning threshold according to the formula threshold = min_bg - 0.5 × (min_bg - 40), where min_bg is configurable within the range of 65–120 mg / dL. When real-time or predicted blood glucose falls below this threshold, a pause duration of 30–120 minutes is automatically calculated, and a zero temporary basal rate command is issued to the insulin pump. The execution terminal uploads the device status, operation log, and treatment records to a dedicated monitoring site in real time, and the command execution status is synchronized to the cloud server via both WebSocket and HTTP channels. min_bg, short for minimum blood glucose, represents the user / doctor's preset target minimum blood glucose value (unit: mg / dL). It is the lower limit target blood glucose value set by the doctor for the patient, with a configurable range of 65–120 mg / dL. The system uses it to dynamically calculate the hypoglycemia warning threshold, rather than using a fixed threshold. Using this preset minimum target blood glucose level, a formula can be used to calculate an actual warning trigger value that better suits the individual patient's situation.

[0071] In this embodiment, while developing its own monitoring and intervention platform, the present invention fully retains and relies on the core algorithm of the original open-source AAPS to ensure the stability and maturity of treatment decisions. The system mainly employs four key prediction models: active insulin level (IOB), active carbohydrate level (COB), unannounced meal (UAM), and a zero temporary basal rate prediction model simulating insulin pause. Among them, the active insulin level (IOB) model is used to calculate the total amount of insulin in the patient's body that has not been fully metabolized, based on the pharmacokinetic curve of insulin, considering the onset time, peak time, and duration of action of different types of insulin; the active carbohydrate level (COB) model is used to calculate the total amount of carbohydrates ingested by the patient that have not been converted into blood glucose, and dynamically adjusts it in combination with the carbohydrate absorption rate and the patient's insulin sensitivity; the unannounced meal (UAM) model is used to detect the patient's unannounced meal intake, automatically identify meal events by analyzing the blood glucose rise trend and adjust the insulin infusion dose to avoid hyperglycemia caused by missed meal reporting.

[0072] The Predictive Hypoglycemia Suspension function is one of the core safety features of the AAPS system. This invention fully integrates it into the execution terminal to ensure that the function can operate normally even in the event of a network interruption, thus protecting the patient's safety.

[0073] Traditional hypoglycemic pause functions typically use a fixed threshold, such as pausing insulin infusion when blood glucose falls below 70 mg / dL. However, this fixed threshold method does not consider individual patient differences. For some patients with normally high blood glucose levels, a drop to 70 mg / dL may already indicate hypoglycemia; while for some patients with normally low blood glucose levels, 70 mg / dL may be a normal blood glucose level. To address this issue, this invention employs a dynamic warning threshold calculation method, calculated using the formula threshold = min_bg - 0.5 * (min_bg - 40), where min_bg can be configured between 65-120 mg / dL. For example, if a doctor sets the patient's min_bg to 80 mg / dL, the dynamic warning threshold is 80 - 0.5 × (80 - 40) = 60 mg / dL; if min_bg is set to 100 mg / dL, the dynamic warning threshold is 100 - 0.5 × (100 - 40) = 70 mg / dL. This dynamic threshold calculation method can automatically adjust the warning threshold according to the patient's individual blood glucose target value, making the hypoglycemia warning more accurate. It can not only detect the risk of hypoglycemia in time, but also avoid unnecessary treatment interruption.

[0074] When the current or predicted blood glucose level falls below the dynamic threshold, the system initiates predictive intervention. It intelligently calculates an appropriate pause duration (30-120 minutes) and automatically sets a zero temporary basal rate. The pause duration calculation considers factors such as the patient's current active insulin level (IOB) and the trend of blood glucose decline. If the patient's active insulin level is high and the blood glucose decline trend is rapid, the system will set a longer pause duration; conversely, a shorter pause duration will be set. After determining the pause duration, the system sends a zero temporary basal rate command to the insulin pump, pausing insulin infusion until the pause duration ends or blood glucose returns to a safe level. This predictive hypoglycemic pause function allows for intervention before hypoglycemic symptoms appear, effectively reducing the risk of severe hypoglycemia.

[0075] Meanwhile, this embodiment also employs a dual-path parallel anomaly handling and feedback mechanism to ensure that medical staff can understand the patient's status and the execution of instructions in a timely and comprehensive manner. The first path is a comprehensive log and monitoring pathway based on Nightscout, which serves as the system's "black box" and "panoramic monitor." The AAPS running on the execution terminal is responsible for continuously recording all statuses and events of itself and the insulin pump, including but not limited to: device connection status (such as Bluetooth connection and disconnection between the execution terminal and the insulin pump), hardware status (such as the battery level of the execution terminal or insulin pump, remaining insulin levels, etc.), application software status (such as the normal operation logs or accidental crash records of the AAPS application), and treatment instruction records (whether locally closed-loop automatically executed instructions or remotely issued instructions and their execution results). All this information is continuously and in real time uploaded by the AAPS to the patient's dedicated monitoring station. Medical staff can access this dedicated monitoring station at any time to view detailed historical logs and gain a comprehensive understanding of the long-term operation of the patient's devices. The dedicated monitoring station's early warning system will also proactively issue alerts based on this data (such as low pump battery or prolonged lack of data).

[0076] The second path is a real-time intervention feedback channel based on WebSocket, serving as a "dashboard" and "real-time alarm" for medical staff during proactive remote intervention. When medical staff issue a specific instruction through the management terminal, the system activates an immediate, point-to-point feedback link: the instruction is sent to the execution terminal via WebSocket, the execution terminal attempts to execute the instruction, and if any anomaly occurs during the instruction's execution lifecycle (such as Bluetooth connection failure, pump refusal, etc.), the execution terminal immediately returns the specific failure status and error reason to the medical staff's management terminal via WebSocket in real time. The medical staff's management interface will immediately display the failure result of this operation in a prominent manner. The purpose of using dual-channel synchronization is to improve the reliability of feedback; even if one communication method fails, the other can still guarantee the transmission of feedback information. This dual-path parallel feedback mechanism achieves a unity of comprehensiveness and immediacy of information, transforming previously imperceptible remote problems into traceable and real-time decision-making information, greatly improving the security of remote management.

[0077] In a preferred embodiment of the novel centralized remote insulin infusion management method of the present invention described above, when the network between the execution terminal and the cloud server is interrupted, the data to be uploaded is cached locally and continuously reconnected; after the network is restored, the cached data is synchronized in chronological order; during the interruption, the local AAPS closed-loop algorithm of the execution terminal independently runs insulin infusion regulation based on CGM data.

[0078] In this embodiment, the network outage contingency plan is a key design feature to ensure the system's stable operation even in harsh network environments. In real-world hospital applications, unstable network connections are a frequent problem, such as weak WiFi signals in certain areas or patients moving to areas without network coverage. If the system malfunctions during a network outage, it poses a serious safety hazard to the patient's treatment. Therefore, this invention fully considers network connection instability from the outset and has developed a comprehensive network outage contingency plan. The core principle is patient-side local autonomy, meaning that network outages do not affect the patient's basic treatment.

[0079] When the execution terminal detects a network connection interruption with the cloud server, it automatically enters data caching mode, securely storing all blood glucose records, operation logs, and other information to be uploaded locally. Simultaneously, it continuously attempts to re-establish a connection with the cloud server. All blood glucose records, operation logs, treatment instruction records, and other information to be uploaded are securely stored in the execution terminal's local storage. Local storage is encrypted to prevent data leakage. At the same time, the execution terminal starts a background thread to continuously attempt to re-establish a WebSocket connection with the cloud server, employing an exponential backoff algorithm. The initial reconnection interval is 1 second, and the interval doubles after each subsequent failed reconnection attempt: 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds… up to a maximum interval of 5 minutes, avoiding excessive power consumption and network bandwidth due to frequent connection attempts.

[0080] During network outages, the AAPS closed-loop algorithm on the patient's end can operate independently and completely without relying on the network. This means that even if the network between the execution terminal and the cloud server is completely interrupted, the patient's automated blood glucose management (automatically adjusting insulin infusion based on CGM data) remains effective, and the patient's basic treatment and safety are unaffected. The AAPS closed-loop algorithm automatically calculates and adjusts the basal insulin infusion rate based on real-time blood glucose data collected by the CGM device, combined with information such as the patient's active insulin and active carbohydrate levels, to achieve automated blood glucose management. This design is one of the key advantages of this invention compared to traditional remote control solutions. Traditional solutions not only cannot perform remote control during network outages, but even the local closed-loop function may fail to operate normally, posing a significant safety risk to the patient.

[0081] Once the network connection is restored, the execution terminal will immediately re-establish a WebSocket connection with the cloud server. After a successful connection, it will populate the server with all locally cached historical data in chronological order. Upon receiving this data, the server will synchronously update the management terminal for healthcare workers. This mechanism ensures that even after a prolonged network outage, the patient's historical data records remain complete and without omissions, guaranteeing data consistency and traceability. This chronological data population mechanism ensures data consistency and traceability, allowing healthcare workers to view all patient blood glucose data and treatment records from the period of network interruption after network restoration, providing a comprehensive understanding of changes in the patient's condition.

[0082] In addition, the independent NS monitoring platform will trigger a "data interruption" alarm after a preset time (e.g., 30 minutes) without receiving new data, proactively notifying the healthcare team. Upon receiving the alarm, healthcare personnel can promptly contact the patient to investigate the cause of the network interruption and ensure the patient's devices function normally. This reverse early warning mechanism further enhances system security, preventing patients from being left unattended due to network interruptions.

[0083] The present invention also proposes a novel centralized remote insulin infusion management system, in a preferred embodiment of which includes a cloud server, a dedicated monitoring site, a management terminal, an execution terminal, and an insulin pump, each with independent functions. The execution terminal has a built-in and runs a customized AAPS application. The execution terminal establishes a persistent long connection with the cloud server via WebSocket and communicates with the insulin pump via Bluetooth Low Energy. The cloud server is used to automatically deploy dedicated monitoring stations for patients, complete the identity verification and communication key negotiation of the execution terminal, perform legality verification and concurrent conflict verification of remote commands initiated by the management terminal, control the issuance of commands through distributed concurrent locks, and synchronize the command execution status and results to the management terminal. The dedicated monitoring station is used to receive and store blood glucose data, device status data and treatment log data uploaded by the execution terminal, so as to realize monitoring and abnormal early warning; The management terminal is used by medical staff to initiate remote insulin infusion commands or remote carbohydrate declaration commands, and to display the status and results of the entire command execution process. The execution terminal is used to receive and verify the instructions sent by the cloud server, forward the instructions to the insulin pump, synchronize the execution status through WebSocket and HTTP dual channels, run the AAPS core algorithm and intelligent hypoglycemia trend pause function locally, cache data when the network is interrupted and synchronize it in time order after the network is restored; The insulin pump is used to execute infusion commands issued by the terminal and to provide feedback on the execution results.

[0084] In this embodiment, the entire system adopts a modular design, with clear division of labor and collaborative work among its components to achieve centralized remote insulin infusion management. The cloud server serves as the control center of the entire system, responsible for handling all business logic and instruction scheduling. Its main functions include: automatically deploying dedicated monitoring stations for patients, simplifying the user deployment process; completing identity verification and communication key negotiation for the execution terminals, ensuring system access security; performing multi-dimensional legality and concurrency conflict checks on remote instructions initiated by the management terminal, intercepting insecure instructions; controlling the issuance of instructions through distributed concurrency locks to avoid conflicts caused by concurrent operations from multiple terminals; and receiving instruction execution status and results from the execution terminals and synchronizing them to the management terminal to achieve closed-loop control throughout the entire process. The cloud server employs a highly available and scalable architecture, capable of supporting thousands or even tens of thousands of patients simultaneously online, meeting the needs of large-scale clinical applications in hospitals.

[0085] The dedicated monitoring station serves as the system's monitoring platform, custom-developed based on the open-source Nightscout platform. Its main function is to receive and store various data uploaded from the execution terminals and display them to healthcare professionals in intuitive charts. Healthcare professionals can view patients' real-time blood glucose curves, historical blood glucose data, insulin infusion records, and device status information on the dedicated monitoring station. Simultaneously, the dedicated monitoring station also features intelligent early warning capabilities, automatically detecting abnormal blood glucose levels, low device battery, data interruptions, and other situations, and issuing timely alerts. The dedicated monitoring station operates independently from the cloud server; even if the cloud server malfunctions, the dedicated monitoring station can still receive and display data normally, ensuring basic monitoring functions.

[0086] The management interface serves as the entry point for healthcare professionals to perform remote operations, employing a simple and intuitive graphical user interface design. Healthcare professionals can view a list of all patients under their care through the management interface. After clicking into a patient's details page, they can view the patient's real-time blood glucose data, device status, and historical treatment records. When remote intervention is required, healthcare professionals simply enter the treatment dosage on the interface and click the confirmation button to issue the command. The entire process of issuing, receiving, executing, and completing the command is synchronized in real time on the interface, allowing healthcare professionals to clearly see the execution status of each step. The management interface also supports push notification functionality; when a patient experiences abnormal blood glucose levels or a command execution failure, a push notification will be immediately sent to healthcare professionals to ensure timely handling.

[0087] The execution terminal has a built-in and runs a customized AAPS application, and the AAPS customized for hospitals also runs on the execution terminal. The execution terminal can be a mobile device such as a smartwatch or smartphone, with a smartwatch being the preferred implementation form, which is a key innovation of this invention. Traditional remote control solutions typically use the patient's mobile phone as the execution terminal, but mobile phones are bulky, inconvenient to carry, and prone to running out of power or shutting down. Smartwatches, on the other hand, have advantages such as small size, ease of wear, and long battery life, making them very suitable as wearable medical execution terminals. The execution terminal has a built-in and runs a customized AAPS application, establishing a persistent connection with the cloud server via WebSocket to receive instructions from the cloud; it also communicates with the insulin pump via Bluetooth Low Energy, forwarding instructions to the insulin pump for execution. Simultaneously, the execution terminal is also responsible for running the core AAPS algorithm and the intelligent hypoglycemia trend pause function locally, achieving automated blood glucose management. In the event of a network interruption, the execution terminal caches data to be uploaded and automatically synchronizes it after the network is restored, ensuring data integrity.

[0088] The insulin pump is the final command execution unit, responsible for accurately infusing insulin according to instructions issued by the execution terminal. Driven by a high-precision stepper motor, the insulin pump achieves a minimum infusion accuracy of 0.01U, meeting the fine-tuning needs of different patients and ensuring accurate insulin delivery. The insulin pump continuously reports its status information to the execution terminal in real time, including battery level, remaining medication volume, and infusion status. The execution terminal then uploads this information to a dedicated monitoring station for healthcare personnel to view.

[0089] In summary, the novel centralized remote insulin infusion management method and system based on WebSocket proposed in this invention, through its pioneering dual-platform architecture design and four-layer intervention system, completely solves the core pain points of traditional SMS remote control solutions in clinical applications, such as complex processes, unreliable communication, and inability to adapt to centralized management. It achieves a leap from personal tools to a professional clinical management platform, and has the following significant advantages and effects: First, operational efficiency has been significantly improved. Engineers have completely encapsulated all complex command generation, verification, and communication processes in the backend. For medical staff, remote operation has been greatly simplified. After securely logging into the designated patient's management interface via dynamic verification code, they only need to enter the treatment dosage on a simple graphical interface and click confirm. The entire process, from command issuance to pump reception, execution start, and completion, is clearly and intuitively synchronized in real time on the interface. This shift from "command line" to "graphical interface," and from "asynchronous waiting" to "real-time tracking," greatly reduces operational difficulty and potential error rates. The time for a single remote operation has been reduced from several minutes in traditional solutions to less than 10 seconds, improving operational efficiency by tens of times.

[0090] Secondly, real-time performance and reliability are absolutely guaranteed. The strong closed-loop feedback mechanism based on WebSocket ensures that every instruction issued by medical staff receives a precise response. Whether it's a successfully executed dose value or an error code indicating failure, it will be accurately returned to the management end. This high level of data consistency and reliability provides a solid and reliable technical guarantee for routine clinical adjustments and even emergency treatments. Furthermore, the system design fully considers network dependency boundaries; the AAPS closed-loop algorithm on the patient's end can run independently without relying on the network, and network connection interruptions only affect the uploading of remote monitoring data. This means that even in extreme situations without a network, the patient's automated blood glucose management remains effective. Simultaneously, the dedicated monitoring station's "no data received for an extended period" alarm function can proactively alert the medical team to check whether the patient's device is offline or malfunctioning, forming another layer of security.

[0091] Third, it revolutionizes clinical management. The core value of this solution lies in its platform-based architecture, which truly empowers the innovation of clinical treatment models. It provides a unified and standardized management portal, freeing medical staff from the burden of tracking countless complex text messages. This "platform-based, account-based" management model represents a qualitative leap compared to fragmented SMS communication. Once logged in, medical staff can access a powerful and unified control center for real-time monitoring and precise operation. More significantly, it provides technical support for the implementation of a 1-vs-NCare Centralized Remote Management model. Now, endocrinology teams can leverage this platform to professionally manage any patient requiring intervention throughout the hospital through standardized authorization and login processes, providing homogeneous and standardized professional treatment. Medical staff no longer need to deal with a bunch of scattered, individual monitoring stations; they can complete the monitoring and intervention of all patients through a unified management portal, achieving unified access, unified authorization, unified monitoring, and unified remote intervention, truly supporting the implementation of a hospital-wide closed-loop diabetes management model. This shift from "managing communication channels" to "managing secure sessions" makes it possible to achieve refined management of all patients in the hospital with minimal manpower, resulting in an order-of-magnitude increase in clinical work efficiency.

[0092] Fourth, a comprehensive security and privacy protection system has been established. From its inception, this solution has been guided by the core principles of mainstream international data protection regulations such as HIPAA, GDPR, and PIPL, constructing a security and privacy compliance system that spans the entire data lifecycle. The user rights protection mechanism, centered on "clear division of rights and responsibilities," explicitly stipulates that authorized medical personnel at the hospital level only have viewing rights for patient data and cannot modify or delete historical data, ensuring the originality and integrity of the data; patients have absolute control over their data, and can choose to download a complete copy of their data at any time through the platform, or clear all their personal data locally with a single click. Through multi-layered identity verification, command encryption and signature, and distributed concurrent locks, the system's access security and command transmission security are guaranteed. This comprehensive security and privacy protection mechanism ensures the system's compliance in clinical applications, eliminating concerns for both patients and hospitals.

[0093] Future work will focus on in-depth data mining, such as combining historical blood glucose data with treatment records and using machine learning models to provide auxiliary decision-making suggestions for medical staff, further improving the intelligence level of treatment. This invention not only significantly improves the safety and efficiency of remote insulin therapy, but more importantly, it verifies the feasibility of building a new, centralized, hospital-wide blood glucose management model, demonstrating its enormous potential and value in professional medical environments.

[0094] The above description is merely an illustrative embodiment of the present invention and is not intended to limit the scope of the invention. Any equivalent changes and modifications made by those skilled in the art without departing from the concept and principles of the present invention should fall within the scope of protection of the present invention.

Claims

1. A novel centralized remote infusion management method for insulin, characterized by, The dual-platform architecture, which separates monitoring and intervention, includes the following steps: S1: The cloud server establishes a persistent WebSocket connection with the execution terminal and completes identity verification and communication key negotiation; the cloud server automatically deploys a dedicated monitoring station for the patient. The dedicated monitoring station and the cloud server are two independent cloud subsystems. The execution terminal uploads data to the dedicated monitoring station in real time. S2: The management terminal initiates a remote infusion control request, and the cloud server performs a validity check on the request parameters. The checks include dose constraint check, frequency limit check, and concurrent command conflict check. S3: The cloud server opens a distributed concurrent lock to prevent deadlock for a specified time interval, sends an input command to the execution terminal through the WebSocket connection, and waits to receive confirmation feedback; S4: After the terminal receives the instruction, it sends a confirmation of receipt to the cloud server and performs local security verification on the instruction; the cloud server changes the instruction status to pending processing; the terminal performs local security verification on the received instruction. S5: After the local security verification is successful, the execution terminal forwards the instruction to the insulin pump to perform the infusion operation; the execution terminal reports the instruction execution status to the cloud server, and the cloud server changes the instruction status to in progress; S6: The execution terminal synchronizes the instruction execution status with the cloud server in real time, and provides feedback on the final execution result after the input is completed; S7: The cloud server synchronizes the instruction execution status and results to the management terminal to achieve closed-loop control of the entire process.

2. The insulin novel centralized remote infusion management method of claim 1, wherein, In step S1, the dedicated monitoring station is automatically deployed and configured with an independent access password through patient mobile phone number verification; medical staff access the station after authorization by the patient; patient-side data uploaded by the execution terminal through the customized AAPS application includes blood glucose level, insulin pump power consumption, remaining insulin dosage, AAPS closed-loop operation status, algorithm decision data, device connection log, application operation log, and treatment instruction records; the dedicated monitoring station triggers an alarm when blood glucose exceeds the standard, pump power consumption is below the threshold, or no data is received within a specified time interval.

3. The insulin novel centralized remote infusion management method of claim 1, wherein, In step S1, the identity verification includes account existence verification, account availability verification, device number verification, and device binding relationship verification. The cloud server stores the mapping relationship between WebSocket connections and accounts; All interactive instructions between the cloud server and the execution terminal are integrated with digital signatures and timestamps based on communication keys.

4. The novel centralized remote insulin infusion management method according to claim 1, characterized in that, In step S2, the dose constraint verification for remote insulin infusion instructions is as follows: cumulative infusion dose ≤ 15U within 2 hours and cumulative infusion dose ≤ 60U within 24 hours; the frequency limit verification is as follows: number of instructions ≤ 20 within 24 hours and interval ≥ 15 minutes from the previous instruction; the dose constraint verification for remote carbohydrate declaration instructions is as follows: cumulative dose ≤ 500g within 24 hours and frequency limit verification is as follows: number of instructions ≤ 20 within 24 hours.

5. The novel centralized remote insulin infusion management method according to claim 1, characterized in that, In step S2, the concurrent instruction conflict verification includes: querying the database for pending instructions that have not exceeded 20 minutes, obtaining the last input time and manual input status of the execution terminal; if there are pending instructions, the interval is less than 15 minutes, or manual input is in progress, the cloud server rejects the current instruction.

6. The novel centralized remote insulin infusion management method according to claim 1, characterized in that, In step S3, if the cloud server does not receive a confirmation of receipt within 30 seconds, it marks the instruction as expired and releases the distributed concurrent lock; if the terminal does not execute the instruction within 30 minutes of receiving it, the instruction is automatically marked as expired and synchronized to the cloud server.

7. The novel centralized remote insulin infusion management method according to claim 1, characterized in that, In step S4, the local security verification includes instruction digital signature verification, timestamp validity verification, watch and pump Bluetooth connection status verification, insulin pump remaining dosage verification, and manual infusion status verification; if any verification fails, the execution terminal refuses to execute and returns an error code.

8. The novel centralized remote insulin infusion management method according to claim 1, characterized in that, The local security verification step of the execution terminal in step S4 also includes an intelligent hypoglycemia trend pause function. This function is run locally on the execution terminal. The dynamic warning threshold is calculated according to the formula threshold=min_bg-0.5×(min_bg-40), and the min_bg can be configured in the range of 65–120 mg / dL. When the real-time blood glucose or predicted blood glucose is lower than this threshold, the pause duration of 30–120 minutes is automatically calculated and a zero temporary basal rate command is issued to the insulin pump. The execution terminal uploads the device status, operation log, and treatment record to the dedicated monitoring station in real time. The command execution status is synchronized to the cloud server through both WebSocket and HTTP channels.

9. The novel centralized remote insulin infusion management method according to claim 1, characterized in that, When the network between the execution terminal and the cloud server is interrupted, the data to be uploaded is cached locally and reconnection is continuously performed; after the network is restored, the cached data is synchronized in chronological order; during the interruption, the local AAPS closed-loop algorithm of the execution terminal independently runs insulin infusion regulation based on CGM data.

10. A novel centralized remote insulin infusion management system, characterized in that, This includes independently functioning cloud servers, dedicated monitoring sites, mobile management terminals, execution terminals, and insulin pumps; The execution terminal has a built-in and runs a customized AAPS application. The execution terminal establishes a persistent long connection with the business cloud server via WebSocket and communicates with the insulin pump via Bluetooth Low Energy. The business cloud server is used to automatically deploy dedicated monitoring sites for patients, complete the identity verification and communication key negotiation of the execution terminal, perform legality verification and concurrent conflict verification of remote commands initiated by the mobile management terminal, control the issuance of commands through distributed concurrent locks, and synchronize the command execution status and results to the mobile management terminal. The dedicated monitoring station is used to receive and store blood glucose data, device status data and treatment log data uploaded by the execution terminal, so as to realize monitoring and abnormal early warning; The mobile management terminal is used by medical staff to initiate remote insulin infusion commands or remote carbohydrate declaration commands, and to display the status and results of the entire command execution process. The execution terminal is used to receive and verify the instructions issued by the business cloud server, forward the instructions to the insulin pump, synchronize the execution status through WebSocket and HTTP dual channels, run the AAPS core algorithm and intelligent hypoglycemia trend pause function locally, cache data when the network is interrupted and synchronize it in time order after the network is restored; The insulin pump is used to execute infusion commands issued by the terminal and to provide feedback on the execution results.

Images