An intelligent decision-based adaptive infusion collaborative control method and system

Abstract

The present application relates to the technical field of medical Internet of Things, and in particular to a self-adaptive infusion collaborative control method and system based on intelligent decision-making. The method comprises: an end device analyzes multi-modal physiological time series data and infusion parameters through an end-to-end patient state evaluation model integrated in a sub-body infusion unit, and outputs a patient state index and infusion suggestions; combined with a pipeline pressure signal, an adaptive flow rate control algorithm based on LSTM is used to generate motor control instructions to realize closed-loop control. The edge device periodically aggregates local model parameter updates of multiple end devices through a mother base station. The cloud device fuses all updates uploaded by the edge devices based on a federated averaging algorithm, generates an optimized global model, and issues the global model. The present application realizes a paradigm shift from isolated execution to collaborative perception-decision-evolution of infusion, drives continuous evolution of group intelligence under the premise of protecting data privacy, and improves the accuracy, safety and overall intelligent level of infusion therapy in complex environments.

Description

Technical Field

[0001] This invention relates to the field of medical Internet of Things (IoT) technology, specifically to an adaptive infusion collaborative control method and system based on intelligent decision-making. Background Technology

[0002] In clinical medicine, especially in emergency and intensive care, intravenous infusion is a fundamental and crucial treatment method. Traditional infusion methods heavily rely on gravity, requiring the infusion bag to be suspended high up, with the flow of medication driven by the hydrostatic pressure generated by the fluid level difference. This method has significant limitations: firstly, its application is severely restricted by space, making it difficult to implement in environments lacking reliable suspension supports, such as earthquake rescue, battlefield front lines, and intra-hospital transport; secondly, the flow rate control precision is low and the stability is poor, mainly relying on medical staff to manually adjust the tubing clamps, and the flow rate is easily affected by changes in fluid level, patient position, and venous pressure, potentially leading to infusions that are too fast or too slow, posing safety hazards. To overcome the shortcomings of gravity-based infusion, various infusion pumps have emerged on the market, such as volumetric pumps and peristaltic pumps. These pumps actively propel the medication using mechanical power, achieving non-gravity-based infusion and more precise flow rate settings. However, most existing intelligent infusion pumps are still single-function, isolated devices. Their control logic is mostly based on preset fixed programs or simple feedback adjustments (such as PID control), failing to deeply integrate the patient's real-time physiological state (such as multimodal information like ECG, blood oxygen, and blood pressure) for personalized and proactive treatment decisions. Furthermore, these devices lack effective collaboration mechanisms; each device can only learn from its own limited experience, creating "data silos" and "experience silos." In large-scale rescue or group treatment scenarios, medical personnel cannot grasp the overall treatment situation of the group, and devices cannot share the valuable knowledge accumulated in handling complex cases, hindering a qualitative leap in overall treatment efficiency and intelligence. Moreover, the high sensitivity of medical data makes direct sharing of raw patient data for centralized model training between devices a serious privacy and compliance challenge. Therefore, there is an urgent need for a new intelligent infusion system and control method that can achieve precise individual control, group knowledge sharing, and ensure data privacy and security.

[0003] Therefore, existing technologies still need further development. Summary of the Invention

[0004] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide an adaptive infusion coordinated control method and system based on intelligent decision-making to solve the problems existing in the prior art.

[0005] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides an adaptive infusion coordinated control method based on intelligent decision-making, comprising: S1. By integrating the end-to-end patient status assessment model into the infusion unit, the acquired multimodal physiological time-series data and current infusion parameters are analyzed in real time, and the comprehensive index of patient volume status and infusion recommendations are output. The infusion recommendations and pipeline pressure signals are input into the LSTM-based adaptive flow rate control algorithm to generate motor control commands for driving the infusion power module, thereby realizing closed-loop control. S2. Periodically receive model parameter updates, which are obtained through local training, uploaded by multiple daughter infusion units through the parent base station; S3. Based on the federated averaging algorithm, aggregate the model parameter updates uploaded by all edge devices, generate an optimized global model, and distribute it to each edge device and end device.

[0006] Specifically, the end-to-end patient status assessment model is a lightweight CNN-Transformer hybrid network; the real-time parsed multimodal physiological time-series data and current infusion parameters include: Physiological signal sensors connected to the infusion unit continuously collect time-series data of the patient's electrocardiogram (ECG), blood oxygen saturation (SOS), and blood pressure. Simultaneously, real-time flow rate and cumulative infusion volume parameters are obtained from the infusion power module. The lightweight CNN-Transformer hybrid network performs convolutional feature extraction on the ECG, SOS, and blood pressure time-series data and fuses them with the flow rate and cumulative infusion volume parameters at the feature layer. Then, the Transformer encoder captures the fused cross-modal long-term temporal dependencies, and finally outputs a continuously changing comprehensive index that characterizes the dynamics of the patient's volume load. Based on the predefined risk range in which the comprehensive index is located, the infusion recommendation, which includes the target flow rate adjustment amount and adjustment duration, is generated.

[0007] Specifically, the LSTM-based adaptive flow rate control algorithm performs the following steps: The method takes the infusion recommendation, the real-time acquired tubing pressure signal, and the historical motor drive command sequence of the infusion power module as inputs; it learns the complex dynamic characteristics of the coupling system of the infusion power module, infusion tubing, and patient vascular dynamics through an LSTM network, and predicts the motor drive signal required to maintain the target flow rate in the next few control cycles; based on the prediction results and feedback from the current tubing pressure, it generates a smooth motor control command sequence using a model predictive control framework, and outputs the first command to the motor driver of the infusion power module; the method also includes an anomaly identification step: when the real-time tubing pressure signal exceeds the pressure range threshold predicted by the LSTM network, or when the patient volume status comprehensive index changes abruptly within a preset time, a safety protocol is triggered, which includes immediately reducing the flow rate to a safe baseline and sending an alarm containing an anomaly code to the upper-level side device.

[0008] Specifically, the generation of the infusion recommendation also incorporates risk prediction based on the short-term trends of the multimodal physiological time series data; when the adaptive flow rate control algorithm is executed, if the risk prediction indicates that the patient's condition is likely to deteriorate in a subsequent period, the generated motor control command sequence includes preparatory parameter adjustments, which include reducing the baseline flow rate gradually and in advance before deterioration occurs, or reserving some motor control margin to cope with possible rapid pressure adjustment needs.

[0009] Specifically, S1 also includes a local model training step: Locally within the sub-infusion unit, patient physiological data, control command data, and corresponding infusion result labels generated during the current infusion task cycle are used to incrementally train the end-to-end patient status assessment model and the sub-model in the adaptive flow rate control algorithm to obtain local model parameter updates. Before uploading, the model parameter updates undergo differential privacy noise reduction processing via the security module built into the sub-infusion unit.

[0010] Specifically, S2 includes: The parent base station, acting as the coordinating node for federated learning, verifies and aggregates the privacy-processed model parameter updates uploaded by all online child infusion units under its management when the preset aggregation period arrives. Based on the aggregated parameters, the parent base station generates a preliminarily optimized local model and uploads the parameter updates of the local model and its associated anonymized metadata to the cloud device. The anonymized metadata includes at least the number of child units participating in the aggregation and an overview of model performance improvement indicators.

[0011] Specifically, S3 also includes a global early warning step: The cloud device performs global situational analysis based on anonymized metadata received from all edge devices. The global situational analysis includes identifying the concentrated occurrence of specific physiological parameter patterns within the jurisdiction of multiple edge devices, or the trend of control efficiency decay in specific models of infusion power modules. When potential group risks or batch problems of equipment are identified, the cloud device generates and issues multi-level early warning instructions. The multi-level early warning instructions include enhanced monitoring instructions for edge devices in specific areas, and control parameter pre-adjustment instructions or model hot patching instructions for potentially affected end devices.

[0012] Specifically, the method also includes system startup and self-test steps: When any child infusion unit is removed from the receiving cavity of the parent base station and started, an adaptive startup process is executed. The adaptive startup process includes automatically detecting and accessing the current optimal communication network, pulling the latest global model parameters from the parent base station or directly from the cloud device to complete the local model update, and using the built-in simulated load to calibrate and test the infusion power module. After the parent base station detects that the child infusion unit in its receiving cavity has completed charging or software update, it triggers a cross-device consistency self-check to ensure that all child infusion units under its management run the same version of control logic and model.

[0013] Specifically, the patient's volume status comprehensive index, real-time flow rate, remaining power of the infusion power module, and warning information issued by the edge device or cloud device are visualized on the display screen on the sub-infusion unit. The visualization display adopts a combination of coded dynamic curves and graded color blocks, wherein the patient's volume status comprehensive index is displayed as a trend curve superimposed on a preset safety range background.

[0014] According to a second aspect of the present invention, an adaptive infusion coordination control system based on intelligent decision-making is provided, comprising: The terminal device, which is the infusion unit described in any of the above-mentioned embodiments, includes an infusion power module, a physiological signal acquisition module, a processing module, and a communication module; the processing module is used to load and run the end-to-end patient status assessment model and the LSTM-based adaptive flow rate control algorithm to execute S1; The edge device, which is the parent base station described in any of the above, includes an edge processing module and an edge communication module; the edge processing module is used to execute S2 as a coordinating node for federated learning. Cloud devices, including cloud server clusters, are used to execute the S3 described above to achieve federated aggregation, distribution, and system-level monitoring of the global model.

[0015] Beneficial effects: Compared with existing technologies, the adaptive infusion collaborative control system and method based on intelligent decision-making provided by this invention has the following significant advantages: First, at the individual device (edge-side) level, by integrating a lightweight deep learning model, a leap from "mechanical execution" to "intelligent perception-decision-control" has been achieved. The system can analyze multimodal physiological time-series data such as patient ECG, blood oxygen, and blood pressure in real time, and deeply integrate them with current infusion parameters. Through an end-to-end model, it dynamically assesses the patient's volume status and outputs structured infusion recommendations. Furthermore, combined with an adaptive flow rate control algorithm based on long short-term memory networks, the system can learn and predict the complex dynamics of the infusion tubing and patient vascular coupling system, achieving smooth, precise, and forward-looking closed-loop control. This significantly improves adaptability to individual patient differences, automatically maintaining the accuracy and safety of treatment under complex changes in the patient's condition, and reducing the burden on medical staff.

[0016] Secondly, at the system architecture level, an innovative distributed intelligent network with "cloud-edge-device" three-level collaboration is constructed. Edge devices (the parent base station), acting as local coordination nodes, can aggregate anonymized knowledge (model parameter updates) from multiple terminal devices under their jurisdiction to generate locally optimized models. Cloud devices further integrate aggregated information from edge devices globally, generating and distributing a more powerful global model through a federated learning framework. This mechanism, while strictly protecting the privacy of patients' original data, breaks down "experience silos" between devices, enabling each newly connected device to immediately obtain intelligence optimized by the experience of all devices. This achieves continuous emergence and evolution of collective intelligence, making it particularly suitable for large-scale emergency rescue scenarios requiring rapid deployment and adaptive optimization.

[0017] Finally, the cloud also has global situational analysis capabilities, which can identify potential regional health risks or equipment performance degradation trends based on anonymized metadata, and generate multi-level early warning instructions, realizing a closed loop from micro-treatment to macro-management, greatly improving the intelligence level and overall efficiency of the entire medical system in responding to public health emergencies and carrying out lean equipment management. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the non-gravity mother-daughter infusion system in an embodiment of the present invention; Figure 2 This is a schematic diagram of the infusion unit of the female body in an embodiment of the present invention; Figure 3 This is a schematic diagram of the infusion unit of the female body in an embodiment of the present invention from another perspective; Figure 4 This is an exploded schematic diagram of the infusion unit of the daughter body in an embodiment of the present invention; Figure 5 This is an assembly view of the infusion unit, infusion bag, and infusion tube in an embodiment of the present invention; Figure 6 This is a schematic diagram of the parent base station (excluding the backband) in an embodiment of the present invention; Figure 7 This is a schematic diagram of another perspective (excluding the back strap) of the parent base station in an embodiment of the present invention; Figure 8 This is an exploded schematic diagram of the parent base station in an embodiment of the present invention; Figure 9 This is a schematic diagram of the parent base station with the storage compartment in an open state in an embodiment of the present invention; Figure 10 This is a flowchart illustrating the adaptive infusion coordinated control method based on intelligent decision-making in an embodiment of the present invention.

[0019] In the attached image: 100. Sub-unit infusion unit; 101. Sub-unit shell; 102. Cover; 103. Fixing component; 1031. Telescopic bandage; 1032. Bandage fixing piece; 104. Cover plate; 105. Power receiving interface; 106. Portable auxiliary component; 107. Placement cavity; 108. Placement slot; 109. Infusion power module; 110. Sub-unit power module; 200. Main unit base station; 201. Receiving cavity; 202. Main unit shell; 203. Grip groove; 204. Connector; 205. Charging interface; 206. Storage compartment; 207. External power socket; 208. Indicator light; 209. Front cover; 300. Carrying strap; 400. Infusion bag; 500. Infusion tubing. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Based on the embodiments in this application, other similar embodiments obtained by those skilled in the art without creative effort should all fall within the scope of protection of this application. Furthermore, directional terms mentioned in the following embodiments, such as "up," "down," "left," and "right," are only for reference to the directions in the accompanying drawings; therefore, the directional terms used are for illustrative purposes and not for limiting the invention.

[0021] The present invention will be further described below with reference to the accompanying drawings and preferred embodiments.

[0022] Please see Figures 1-10 This invention provides an adaptive infusion coordination control method based on intelligent decision-making, comprising: S1. By integrating the end-to-end patient status assessment model into the infusion unit, the acquired multimodal physiological time-series data and current infusion parameters are analyzed in real time, and the comprehensive index of patient volume status and infusion recommendations are output. The infusion recommendations and pipeline pressure signals are input into an LSTM-based adaptive flow rate control algorithm to generate motor control commands for driving the infusion power module, thereby achieving closed-loop control.

[0023] It should be further explained that this method constructs a complete "cloud-edge-device" three-level collaborative control architecture. The device at the edge is each independent sub-infusion unit 100, a portable intelligent device integrating an infusion power module 109, multiple sensors, a processor, and a wireless communication module. The sub-unit housing 101 and cover 102 constitute its main structure, internally integrating the infusion power module 109 (preferably a precision peristaltic pump) and the sub-unit power module 110. It can be securely fixed to the patient's limb via fasteners 103, such as an assembly including a telescopic bandage 1031 and a bandage fixing piece 1032. The placement cavity 107 is used to accommodate the infusion bag 400, and the infusion tube 500 extends from the cover 104 and is driven by the infusion power module 109. The power receiving interface 105 is used to connect to the charging interface 205 of the parent base station 200 for charging. The portable accessory 106 and the placement slot 108 facilitate carrying and temporary placement.

[0024] Furthermore, the edge device, namely the parent base station 200, has multiple receiving cavities 201 within its housing 202 for simultaneously accommodating and charging multiple daughter infusion units 100. Grip grooves 203 and connectors 204 facilitate carrying and hanging, while a carrying strap 300 allows for transport by carrying. An external power socket 207 connects to an external power source, indicator lights 208 display status, a front cover 209 protects internal components, and a storage compartment 206 stores spare consumables. The parent base station 200 possesses strong edge computing and network connectivity capabilities, serving as a local coordination and data aggregation node.

[0025] Furthermore, cloud devices are server clusters located in remote data centers, possessing the strongest computing and storage resources, and are responsible for global model optimization and system-level monitoring.

[0026] Furthermore, at the end-user side, each infusion unit 100 independently executes an intelligent sensing, decision-making, and control cycle. It continuously collects the patient's physiological time-series data via connected finger-clip pulse oximeters, ECG electrode patches, and non-invasive blood pressure cuffs (connectable via dedicated interfaces on the sub-unit housing 101), while simultaneously reading real-time flow rate from the encoder of the infusion power module 109 and cumulative infusion volume from memory. This data is input into an end-to-end patient status assessment model to obtain real-time patient status assessment results and adjustment suggestions. These suggestions, along with tubing pressure measured by a high-precision pressure sensor (installed on the infusion tubing 500 path), are fed into an LSTM-based adaptive flow rate control algorithm. This algorithm ultimately calculates precise commands to control the peristaltic pump motor speed and direction, achieving personalized, adaptive closed-loop infusion.

[0027] S2. The parent base station periodically receives model parameter updates, which are obtained through local training, uploaded by multiple daughter infusion units.

[0028] It should be further explained that, on the side, a parent base station 200 manages all its daughter infusion units 100. It periodically (e.g., every 24 hours or after a daughter unit completes an infusion task) wakes up these daughter units, collects the model parameter updates generated during their local training (which are incremental changes in model weights, rather than the original patient physiological data), and performs preliminary aggregation and coordination.

[0029] S3. Based on the federated averaging algorithm, aggregate the model parameter updates uploaded by all edge devices, generate an optimized global model, and distribute it to each edge device and end device.

[0030] It should be further explained that, on the cloud side, numerous parent base stations 200 from different regions and rescue sites around the world update and upload the initially aggregated model parameters. The cloud server uses algorithms such as federated averaging to integrate this dispersed knowledge and generate a more powerful and universal next-generation global intelligent model. This new model is distributed to all parent base stations 200 and their managed daughter infusion units 100, enabling each device to immediately access the collective experience accumulated by the entire system and achieve continuous performance evolution.

[0031] Understandably, this method fundamentally changes the traditional isolated and static working mode of infusion pumps. Through edge-side deep learning and closed-loop control, it achieves dynamic and precise responses to individual patient conditions, improving the safety and effectiveness of infusions. Through an edge-cloud collaborative federated learning framework, while strictly protecting patient data privacy (raw data not leaving the device), it achieves the sharing and evolution of collective intelligence. This enables the system to cope with more complex clinical situations and emerging case patterns, making it particularly suitable for rapid deployment and adaptive optimization in large-scale emergency care and field rescue scenarios. Overall, it significantly improves the intelligence level and collaborative efficiency of critical care infusion therapy under conditions of limited medical resources.

[0032] Specifically, the end-to-end patient status assessment model is a lightweight CNN-Transformer hybrid network; the real-time parsing and acquisition of multimodal physiological time-series data and current infusion parameters includes: continuously collecting the patient's ECG, blood oxygen, and blood pressure time-series data through physiological signal sensors connected to the sub-infusion unit 100; simultaneously, acquiring real-time flow rate and cumulative infusion volume parameters from the infusion power module 109; the lightweight CNN-Transformer hybrid network performs convolutional feature extraction on the ECG, blood oxygen, and blood pressure time-series data, and fuses it with the flow rate and cumulative infusion volume parameters at the feature layer, then captures the fused cross-modal long-term temporal dependencies through a Transformer encoder, and finally outputs a continuously changing comprehensive index characterizing the patient's volume load dynamics, and generates the infusion recommendation containing the target flow rate adjustment amount and adjustment duration based on the predefined risk interval of the comprehensive index.

[0033] It should be further noted that the end-to-end patient status assessment model in this embodiment is a lightweight model specifically designed for embedded medical devices, and its preferred structure is as follows: 1) Input Layer: Receives multi-channel time-series data. The preferred sampling frequency for ECG signals is 250Hz, using a single-lead (lead II) signal to balance information content and computational load. The preferred sampling frequency for SpO2 and blood pressure (BP) waveform signals is 125Hz. Simultaneously, infusion flow rate (unit: ml / h) and cumulative infusion volume (unit: ml) are input as scalar parameters. All physiological signals undergo a sliding time window before model inference, with a preferred window length of 30 seconds and a preferred sliding step size of 1 second. This provides the model with sufficient contextual information to capture physiological trends while ensuring near real-time response speed (a 1-second delay is clinically acceptable).

[0034] 2) Feature Extraction and Fusion Module: For the three waveform data (ECG, blood oxygen, and blood pressure), a one-dimensional convolutional neural network (1D-CNN) is used for local feature extraction. Each 1D-CNN can contain two convolutional layers. The first layer preferably has a kernel size of 5 and 16 filters; the second layer preferably has a kernel size of 3 and 32 filters. Each layer is followed by a ReLU activation function and max pooling (preferably with a pooling size of 2). After CNN processing, each physiological signal is converted into a fixed-length feature vector. At the same time, the two scalar parameters, flow rate and cumulative infusion volume, are mapped to the same feature space as the physiological feature vector through a fully connected layer (e.g., output dimension 8). Subsequently, all five feature vectors are concatenated along the feature dimension to form a fused multimodal feature representation.

[0035] 3) Temporal Dependency Modeling Module: The fused feature vector sequence (one feature vector per second, forming a 30-step sequence) is input into a lightweight Transformer encoder. This encoder preferably contains two encoding layers, each layer including a multi-head self-attention mechanism (preferably 4 heads) and a feedforward neural network (FFN, with a hidden layer dimension of 128). The self-attention mechanism can capture the dependency between features at any two time points in the sequence, regardless of their distance, thus effectively modeling trans-temporal physiological patterns such as "blood pressure decrease lags behind heart rate increase." The final output of the encoder (corresponding to the representation of the last time step of the sequence) is passed through a fully connected output layer.

[0036] 4) Output and Decision Module: The fully connected output layer produces two outputs. The first output is a scalar value, namely the patient volume status comprehensive index. ,in The range of values ​​for can be normalized to [0,1] or [-1,1]. A lower value generally indicates a higher risk of insufficient capacity. A higher value indicates a higher risk of capacity overload. The second output is the flow rate adjustment decision. The system predefines several risk ranges, such as: high-risk range ( Low-risk area ( ), normal range ( ), attention range ( High-risk areas ( The model will be based on the current... The interval in which the value falls, and The recent trend (e.g., derivative) is used to map specific infusion recommendations from a set of predefined strategies. This recommendation is not a simple "accelerate / decelerate" instruction, but rather a recommendation that includes a target flow rate adjustment. (Unit: ml / h, can be positive, negative or zero) and adjust duration A tuple (unit: minutes). For example, when When the risk level is in the low-risk range and there is a downward trend, the model may output suggestions ( This means "to increase the target flow rate by 10 ml / h within the next 15 minutes."

[0037] Understandably, employing a lightweight CNN-Transformer hybrid network enables complex multimodal physiological signal analysis to be performed in real-time on the embedded processor of the infusion unit 100. CNN excels at extracting local spatiotemporal features of signals (such as the QRS complex in ECG), while Transformer excels at capturing long-range temporal dependencies (such as the impact of the respiratory cycle on blood oxygen waveform). Combining the two allows for a more accurate assessment of the patient's dynamically changing volume status. Integrating treatment parameters such as flow rate and cumulative infusion volume with physiological signals at the feature layer allows the model to understand the relationship between "treatment intervention" and "physiological response," thereby making more rational decisions. The final output is a structured recommendation (adjustment amount + duration), rather than a single classification label, providing more nuanced and clinically logical guidance for subsequent flow rate control algorithms, avoiding frequent and drastic fluctuations in control.

[0038] Specifically, the LSTM-based adaptive flow rate control algorithm performs the following steps: taking the infusion recommendation, the real-time acquired tubing pressure signal, and the historical motor drive command sequence of the infusion power module 109 as input; learning the complex dynamic characteristics of the coupling system of the infusion power module 109, the infusion tubing, and the patient's vascular dynamics through the LSTM network, predicting the motor drive signal required to maintain the target flow rate in the next few control cycles; based on the prediction results and feedback from the current tubing pressure, generating a smooth motor control command sequence using a model predictive control framework, and outputting the first command to the motor driver of the infusion power module 109; the method also includes an anomaly identification step: when the real-time tubing pressure signal exceeds the pressure range threshold predicted by the LSTM network, or when the patient's volume status comprehensive index changes abruptly within a preset time, a safety protocol is triggered, the safety protocol including immediately reducing the flow rate to a safe baseline and sending an alarm containing an anomaly code to the upper-level side device.

[0039] It should be further explained that the adaptive flow rate control algorithm in this embodiment is a two-layer intelligent controller based on data and models. Its core is a combination of an LSTM network and a model predictive control (MPC) framework, and the specific design is as follows: (1) LSTM prediction model: The input of this LSTM network is a time series window, which contains historical data of a past period (e.g., the past 20 seconds, with a sampling interval of 1 second), i.e., historical motor drive commands. (Duty cycle or frequency value), historical pipeline pressure and infusion suggestion vectors received from the patient status assessment model. (Include and The network output is a predicted pipeline pressure sequence for a future time period (e.g., the next 10 seconds). The LSTM network preferably has 50 hidden layer units and 2 layers. The network is trained with a large amount of historical data to learn the dynamic mapping relationship from "control commands" to "system response (pressure)". This system is a complex nonlinear system consisting of a series of physical components such as motors, peristaltic pump heads, infusion tubing, needles, and patient vascular resistance.

[0040] (2) Model Predictive Control (MPC) Optimization: At each control time t, the algorithm performs the following steps: a) Status Acquisition: Obtain the current infusion recommendation. Current and historical pipeline pressure Historical control commands .

[0041] b) Rolling optimization: Minimizing the objective function within a finite time domain (e.g., the next 10 seconds). To achieve the objective, find the optimal sequence of future control commands. Objective function One example is: in, It is the pressure predicted by the LSTM model at the k-th future step. It is the reference pressure (estimated from the target flow velocity using fluid dynamics formulas, combined with...). Target flow rate adjustment amount ), This term is used to penalize drastic changes in the control quantity to achieve smooth control. This is the weighting coefficient, preferably 0.1. It is solved using an optimization algorithm (such as gradient descent) to achieve... Minimize the control sequence.

[0042] c) Instruction Execution: Execute the first control instruction from the optimal control sequence obtained from the solution. The output is sent to the motor driver of the infusion power module 109 to drive the motor to run.

[0043] d) Rolling update: In the next control cycle, the above process is repeated, and the system is re-optimized based on the new measurement values ​​to achieve closed-loop feedback control.

[0044] (3) Anomaly Detection and Security Protocol: To ensure security, the algorithm employs a dual anomaly detection mechanism. The first layer is based on model prediction: the LSTM network outputs a predicted stress value. At the same time, it will also output a prediction confidence interval. If the pipeline pressure is measured in real time If the sampling points consistently fall outside this range (e.g., three consecutive sampling points), it may indicate tubing blockage, detachment, or pump head malfunction. The second factor is based on patient condition: if the patient's volume status index... If a change exceeds a preset threshold within a short period (e.g., within 10 seconds) (e.g., the absolute value of the change is greater than 0.3), it may indicate an acute physiological deterioration in the patient. Once any anomaly is triggered, the algorithm immediately executes a safety protocol: overriding the MPC optimization instructions, it forces the motor control instructions to be set to an extremely low safety baseline flow rate (e.g., 5 ml / h, just to keep the tubing open), and immediately sends a structured alarm message to the parent base station 200 that manages it via the wireless communication module. The message contains anomaly codes (e.g., "01" for pressure anomaly, "02" for CI mutation), the time of occurrence, device ID, and other information.

[0045] Understandably, this algorithm upgrades traditional fixed-model-based control (such as PID) to adaptive predictive control based on a learned dynamic model. LSTM networks can learn and memorize the complex dynamic characteristics of the system, including nonlinearity and hysteresis, resulting in more accurate predictions. The MPC framework, through rolling optimization, can proactively and forward-lookingly control, rather than simply reacting to errors that have already occurred, thus achieving smoother and more precise flow rate tracking. The anomaly identification mechanism integrates physical system (tubing pressure) anomalies and physiological system (patient status) anomalies into unified monitoring and establishes clear and automated safety response procedures, greatly improving the safety of the infusion process and providing clinicians with crucial early warning information.

[0046] Specifically, the generation of the infusion recommendation also incorporates risk prediction based on the short-term trends of the multimodal physiological time series data; when the adaptive flow rate control algorithm is executed, if the risk prediction indicates that the patient's condition is likely to deteriorate in a subsequent period, the generated motor control command sequence includes preparatory parameter adjustments, which include reducing the baseline flow rate gradually and in advance before deterioration occurs, or reserving some motor control margin to cope with possible rapid pressure adjustment needs.

[0047] It should be further noted that this implementation method incorporates a forward-looking risk prediction mechanism when generating infusion recommendations and implementing control measures to further improve safety and control quality. The specific design includes: (1) Risk prediction: In the end-to-end patient status assessment model, in addition to outputting the current volume status comprehensive index, It will also output a risk prediction score. This indicates a prediction of the future. After a time (e.g.) The patient's condition deteriorates (e.g., seconds) The probability of a value entering the danger zone. This prediction is based on temporal features extracted by a lightweight CNN-Transformer hybrid network and is achieved through an additional fully connected layer (sigmoid activation). It is a value between 0 and 1, with higher values ​​indicating greater risk. The threshold can be set to 0.7, meaning when... At that time, it was believed that there was a clear risk of short-term deterioration.

[0048] (2) Preliminary parameter adjustment: When the adaptive flow rate control algorithm receives infusion suggestions Furthermore, the risk prediction score was obtained from the state assessment model. When the threshold is exceeded, the objective function in the MPC optimizer It will be dynamically adjusted. There are two adjustment methods: a) Adjust the reference trajectory: If the current recommendation is to increase the flow rate ( However, anticipating the risks, the reference pressure of MPC The growth rate will be proactively reduced, which is equivalent to reducing the growth rate of the target flow rate in advance and gradually, leaving room for possible emergency deceleration.

[0049] b) Add control penalties: In the objective function In the context of penalizing changes in control quantities, the weighting coefficients are used. This will be temporarily increased. This means that the optimizer will be more inclined to generate "mild" control commands to avoid the motor making overly aggressive adjustments at the current moment, thereby reserving sufficient control margin (adjustable range of motor torque and speed) for potentially large and rapid adjustments later (such as emergency deceleration).

[0050] (3) Specific process example: The model analyzes the trend of physiological signals and predicts the risk that the patient may experience relative hypovolemia after 1 minute. ), and at this time according to the current The generated infusion recommendation is "a slight increase of 5 ml / h over 10 minutes." Upon receiving this recommendation and a high-risk prediction, the control algorithm will make preliminary adjustments. It will not immediately execute the 5 ml / h increase, but may instead generate a control sequence: an increase of only 2 ml / h for the first 30 seconds, with close monitoring. The actual change. If after 30 seconds... If the decline does indeed begin and the risk is eliminated, then the original acceleration plan will be resumed; if If the descent accelerates and the risk increases, the pre-set emergency deceleration plan will be activated immediately. This "prediction-preparation" mechanism makes the control behavior more intelligent and forward-looking.

[0051] Understandably, this optimization upgrades the system from "responsive control" to "predictive intervention." It no longer passively waits for the patient's physiological indicators to reach dangerous thresholds before taking action; instead, it can make gentle, defensive adjustments based on subtle early signals before danger occurs. This is similar to an experienced clinician's ability to anticipate changes in the patient's condition and intervene in advance. These preparatory adjustments are typically mild and proactive, potentially preventing crises without excessively interfering with current treatment. This significantly enhances the safety margin and intelligence level of intravenous therapy, representing a key manifestation of artificial intelligence surpassing simple rule-based control in closed-loop clinical applications.

[0052] Specifically, S1 further includes a local model training step: locally in the sub-infusion unit 100, using the patient physiological data, control command data and corresponding infusion result labels generated during the current infusion task cycle, incremental training is performed on the end-to-end patient status assessment model and the sub-model in the adaptive flow rate control algorithm to obtain local model parameter updates; before uploading, the model parameter updates are processed by differential privacy noise reduction through the security module built into the sub-infusion unit 100.

[0053] It should be further explained that, in order to achieve continuous evolution under federated learning, each sub-infusion unit 100 has the ability to incrementally train the model locally. The specific design includes: (1) Local training data generation: After a complete infusion task is completed, the storage module of the daughter infusion unit 100 will save the full-cycle data of this task, including: 1) Time-series physiological data (ECG, blood oxygen, blood pressure); 2) Timing control data (motor commands, actual flow rate, pipeline pressure); 3) Infusion result labels. Result labels can be entered by medical staff through a simple interface on the device after the task is completed (such as pressing the "Success", "Complication - Minor", "Complication - Serious", etc. buttons), or automatically generated by the system according to preset rules (such as: "Success" if the patient's condition is stable and there are no alarms, and "Tubing Problem" if an abnormal pressure alarm is triggered).

[0054] (2) Incremental Training Process: The device initiates a local training process when idle (e.g., during charging). For the end-to-end patient status assessment model, the collected physiological and control data are used as inputs, and the corresponding infusion result labels (converted into supervisory signals that the model can learn, such as "success" corresponding to the expected result) are used. The stable interval is used as the training target, and fine-tuning is performed with a small learning rate (e.g., 0.0001) and a small number of iterations (e.g., 100 epochs). For the LSTM prediction model in the adaptive flow rate control algorithm, historical (motor commands, pipeline pressure) data pairs are used, and fine-tuning is performed with the goal of minimizing the prediction error. After training, the changes in model parameters (weights and biases) relative to before training are calculated, i.e., the "model parameter update" (usually a tensor of the same dimension as the model parameters, recording the change value of each parameter). ).

[0055] (3) Differential Privacy Noise Addition: To protect patient privacy and prevent the original data from being inferred from the model parameter updates, noise must be added before uploading the update. Specifically, Differential Privacy (DP) technology is used. This applies to the calculated model parameter updates. Add noise that follows a certain distribution. A common and effective method is the Gaussian mechanism. For updating the vector... Its noisy version for: in, This indicates that the mean is 0 and the covariance matrix is... The noise vector sampled from the multidimensional Gaussian distribution, where It is an identity matrix. It refers to the sensitivity of model parameter updates, which is typically defined as the parameter updates obtained by training on any two adjacent datasets (i.e., datasets that differ by only one patient's infusion data). The maximum L2 norm difference needs to be determined by setting an upper bound through theoretical analysis or experience, for example, 1.0. It is a noise scale parameter, the value of which is related to the privacy budget. and Relevant. In medical settings, where privacy requirements are extremely high, a smaller privacy budget can be set, for example... Corresponding The value can be calculated using the privacy calculation formula of the Gaussian mechanism, for example, approximately 1.5. After adding noise, even if an attacker obtains the noisy update... Furthermore, it is impossible to reliably infer the original data of any particular patient, thus achieving strict privacy protection.

[0056] Understandably, local incremental training allows each infusion unit 100 to learn from its own usage experience, individually optimizing its model to better adapt to local conditions (such as specific rescue environments or patient populations). This is a prerequisite for federated learning to aggregate effective knowledge. Differential privacy-enhancing noise processing is a key privacy protection barrier in this solution. It ensures that sensitive physiological data of individual patients never leaves the device; only encrypted and noise-protected "knowledge" (model updates) that does not contain identifiable individual information is shared. This solves the most critical privacy and compliance challenges in medical data sharing, making collaborative model evolution across large scale and multiple institutions possible, while fully complying with stringent data protection regulations such as HIPAA and GDPR.

[0057] Specifically, S2 includes: the parent base station 200, acting as the coordinating node of federated learning, verifies and aggregates the privacy-processed model parameter updates uploaded by all online child infusion units 100 under its management when the preset aggregation period arrives; the parent base station 200 generates a preliminary optimized local model based on the aggregated parameters, and uploads the parameter updates of the local model and its associated anonymized metadata to the cloud device; the anonymized metadata includes at least the number of child units participating in the aggregation and an overview of model performance improvement indicators.

[0058] It should be further explained that the parent base station 200 plays a crucial "coordinator" and "middle layer" role in the federated learning framework, and its specific design includes: (1) Aggregation cycle and trigger: The aggregation cycle can be set according to the actual application scenario. In scenarios with clear tasks, such as field rescue, it can be set to the end of a task cycle (e.g., every evening). In normalized medical units, it can be set to a fixed time interval (e.g., every 24 hours). The parent base station 200 is equipped with a timer. When the aggregation cycle arrives, it will send an aggregation request signal to all the daughter infusion units 100 that are paired with it and are currently in a charging or idle state (i.e. placed in the receiving cavity 201) through a wireless network (such as Wi-Fi or a dedicated medical frequency band).

[0059] (2) Validation and aggregation: Upon receiving the request, the daughter infusion unit 100 updates its noisy model parameters. (Where i represents the i-th child entity) Upload. The parent base station 200 first performs simple verification, such as checking whether the format of the updated data is correct and whether the size is abnormal, to filter out potentially corrupted data. After successful verification, the parent base station 200 executes the aggregation algorithm. The most commonly used algorithm is Federated Avg. Specifically, assuming that K children entities participate in aggregation in the current period, the model parameters of each child entity's local model after local training are denoted as... The global model parameters before aggregation are denoted as Then the parameters of each child body are updated as follows: After adding noise, the result is... The parent base station calculates a weighted average aggregation update based on 200 data points: in, This represents the number of local data samples used by the i-th child in this training cycle. This is the total number of samples from all participating sub-units. Using sample size weighting is to give higher weight to devices with larger datasets in the aggregation, which is generally more reasonable. Then, the parent base station 200 uses this aggregation update to update its stored local model parameters: .this This is the local model after preliminary optimization.

[0060] (3) Anonymized Metadata Packaging and Upload: The parent base station 200 does not upload any raw data or detailed information traceable to a single device / patient. It only uploads two things: First, the parameter difference between the local model obtained in this aggregation and the global model in the previous round, i.e. Second, there is a small packet of anonymized metadata, which can be a fixed data structure containing: an aggregation timestamp, the number K of valid child devices participating in this aggregation, the total number N of local data samples from these child devices, and an overview metric for model performance improvement (e.g., on a small standard validation set maintained locally by the parent base station 200, using the new model). and the old model Each inference is performed separately to calculate the relative percentage improvement in accuracy or error, such as "mean absolute error reduced by 2.3%". This metadata contains no individual information and is used solely for global analysis and evaluation of cloud devices.

[0061] Understandably, the introduction of the parent base station 200 forms an "edge" layer, bringing multiple benefits. First, as a local coordination node, it reduces the need for direct communication between individual sub-infusion units 100 and remote cloud servers, saving communication power consumption of sub-devices and reducing the risk of communication failure in weak network environments. Second, by performing the first round of aggregation locally, it can quickly absorb and utilize the experience of local device groups, generating a "local optimization model" more suitable for the local area (such as a rescue team or a ward), and can immediately distribute it to its subordinate sub-devices for faster local response. Finally, it uploads aggregated and de-identified information to cloud devices, greatly reducing the amount of uplink data, protecting privacy, and reducing the computing and storage pressure on the cloud, making the entire system architecture more efficient and scalable.

[0062] Specifically, S3 further includes a global early warning step: the cloud device performs a global situational analysis based on anonymized metadata received from all side devices; the global situational analysis includes identifying the concentrated occurrence of specific physiological parameter patterns within the jurisdiction of multiple side devices, or the trend of control efficiency decay in a specific model of infusion power module 109; when potential group risks or equipment batch problems are identified, the cloud device generates and issues multi-level early warning instructions, including enhanced monitoring instructions for side devices in specific areas, and control parameter pre-adjustment instructions or model hot patches for potentially affected end devices.

[0063] It should be further explained that the cloud server cluster not only handles global model aggregation but also acts as the "intelligent brain" for system-level monitoring and early warning. Specific design features include: (1) Global Situation Analysis: The cloud server continuously receives anonymized metadata uploaded from 200 parent base stations around the world. It maintains a large database to store this time-series metadata. The analysis engine runs periodically, performing the following analyses: a) Group Physiological Pattern Mining: The cloud server can analyze anonymized metadata reported by 200 different parent base stations to see if patterns related to specific clinical events frequently appear. For example, it might use machine learning clustering algorithms to discover that in data uploaded by multiple base stations in a certain geographical area (such as a city), the weights of model features related to "low blood volume" have increased significantly in the past 24 hours. Although the specific patients are unknown, this change in group feature weights suggests that the area may be experiencing a public health event (such as an increase in heatstroke and dehydration cases due to high temperatures).

[0064] b) Equipment performance degradation monitoring: The cloud server tracks the control model (LSTM) parameter updates for different batches and models of infusion power modules 109. If it is found that for a specific hardware batch (identified by the device ID prefix), the calibration parameters used to compensate for motor efficiency decline or pump tube wear in the reported model updates continuously drift in a certain direction, and the drift exceeds the historical normal range, it can be inferred that the equipment in this batch may have potential hardware performance degradation or aging trends.

[0065] (2) Generation and issuance of multi-level early warning instructions: When the above-mentioned potential risks are identified, the cloud server will generate early warning instructions at different levels and issue them precisely, including: a) Enhanced monitoring instructions for edge devices (parent base stations): For example, send instructions to all parent base stations 200 in areas where abnormal physiological conditions of the population are identified, requiring them to temporarily increase the frequency of patient status assessment of their subordinate infusion units 100 from the default 1 time / second to 2 times / second in the next period of time (e.g., 12 hours), and temporarily raise the threshold of abnormal alarms by one sensitivity level in order to detect cases earlier.

[0066] b) Control parameter pre-adjustment instructions or model hot patches for potentially affected end devices (sub-unit infusion units): For example, for a batch of sub-unit infusion units 100 suspected of having hardware performance degradation, the cloud server can generate a "control parameter compensation package." This compensation package is not a complete model, but a set of small parameter offsets. When these sub-units download the global model update from their parent base station 200, they will receive this compensation package simultaneously and automatically load it into the control algorithm to fine-tune the control output to offset the impact of hardware degradation. In more severe cases, the cloud server can directly generate a "model hot patch" (a small model parameter difference file) that fixes a specific problem and distribute it to the specific device via the side device to achieve remote and rapid software repair.

[0067] Understandably, the cloud-based global early warning function elevates the system's value from "individual intelligence" and "local collaboration" to the level of "global insight" and "proactive risk management." It transforms medical devices scattered across different locations from isolated information silos; their aggregated, anonymized metadata reveals macro-trends and potential risks that cannot be detected by single-point data alone. This enables public health departments, equipment manufacturers, and emergency command centers to gain unprecedented real-time situational awareness, allowing for early warning and proactive intervention against regional health threats and batch-specific equipment issues. This closed loop—where "micro-operational data converges into macro-level decision-making knowledge, which then guides micro-operations"—significantly enhances the resilience and social value of the entire medical IoT system.

[0068] Specifically, the method also includes system startup and self-test steps: When any child infusion unit 100 is removed from the receiving cavity 201 of the parent base station 200 and started, an adaptive startup process is executed. The adaptive startup process includes automatically detecting and accessing the current optimal communication network, pulling the latest global model parameters from the parent base station 200 or directly from the cloud device to complete the local model update, and using the built-in simulated load to calibrate and test the infusion power module 109. After the parent base station 200 detects that the child infusion unit 100 in its receiving cavity 201 has completed charging or software update, it triggers a cross-device consistency self-check to ensure that all child infusion units 100 under its management run the same version of control logic and model.

[0069] It should be further explained that, to ensure reliable and consistent system operation, a comprehensive startup and self-check mechanism has been designed, specifically including: (1) Adaptive startup process of daughter body infusion unit 100: a) Network Access: When the daughter infusion unit 100 is removed from the receiving cavity 201 of the mother base station 200, its motion sensor or proximity sensor detects the "removed" event and automatically powers on. After startup, its communication module scans for available wireless networks. The priority order can be preset as follows: firstly, the dedicated local area network (such as Bluetooth Mesh or Zigbee network) created by the paired mother base station 200 is preferred; if unavailable, it attempts to connect to the preset institutional Wi-Fi; if still unavailable, the cellular mobile network (4G / 5G) is activated as a backup. This process is completed automatically without user intervention.

[0070] b) Model Synchronization: After successfully connecting to the network, the child infusion unit 100 first sends a handshake signal and version query to its parent base station 200. The parent base station 200 checks its stored global model version number against the child's local version number. If the versions are inconsistent, the parent base station 200 sends the latest stored model parameter differential file to the child, enabling the child to quickly update. If the parent base station 200 itself has not updated, the child will query and pull the update from the cloud server via the parent relay or directly through the cellular network. This ensures that every device in use possesses the latest "collective intelligence."

[0071] c) Hardware Self-Calibration: Before clinical use, the infusion unit 100 automatically performs a brief hardware self-test. Its infusion power module 109 drives the peristaltic pump head, pushing a short section of tubing through a built-in, precision simulated resistance device (simulating patient vascular resistance), while simultaneously measuring the pressure-flow curve using a high-precision pressure sensor. The measurement results are compared with the factory calibration value or the last calibration value. If the deviation is within the allowable range (e.g., ±5%), the calibration is successful; if the deviation exceeds the limit, a calibration compensation coefficient is automatically calculated and applied to correct the motor commands in subsequent control algorithms, while logging is also recorded. If the deviation is too large to calibrate, a hardware fault alarm is issued and the system is locked, prohibiting infusion.

[0072] (2) Cross-device consistency self-check of the parent base station 200: When the parent base station 200 detects that the charging of a child infusion unit 100 in one of its receiving cavities 201 is complete (judged by communication between the charging interface 205 and the power receiving interface 105), or receives a new software / model update package through background push, it will trigger a self-check process. It will poll all child infusion units 100 currently located in its receiving cavity 201 and with sufficient power (>20%) to obtain their software version number, model version number, control parameter hash value, and other information. Then it will compare them. If an inconsistency is found, it will automatically read the difference information from the child infusion unit 100 with the latest version, or pull a unified update package from the cloud, and then coordinate to silently update all child infusion units 100 with outdated versions (completed in the charging state) to ensure that all devices in the "equipment library" it manages are at a completely consistent software and intelligence level.

[0073] Understandably, the adaptive startup and cross-device consistency self-check mechanism ensure the system's "ready-to-use" capability and high reliability. In emergencies, medical staff simply need to remove the daughter infusion unit 100 from the parent base station 200, power it on, and the device automatically completes network connection, intelligent model updates, and hardware self-checks, ensuring it's in optimal, up-to-date condition and reducing cumbersome preparation and technical barriers. The parent base station 200, acting as an "equipment manager," ensures software and algorithm consistency across all its devices, avoiding treatment discrepancies or coordination issues caused by different device versions—crucial for teamwork and standardized treatment. Simultaneously, automated hardware calibration promptly detects performance drift caused by pump tube wear, motor aging, etc., and compensates for it through software, extending the reliable lifespan of the equipment and ensuring infusion accuracy and safety.

[0074] Specifically, the patient volume status comprehensive index, real-time flow rate, remaining power of the infusion power module 109, and warning information issued by the edge device or cloud device are visualized on the display screen on the sub-infusion unit 100. The visualization display adopts a combination of coded dynamic curves and graded color blocks, wherein the patient volume status comprehensive index is displayed as a trend curve superimposed on a preset safety range background.

[0075] It should be further noted that the intuitiveness of the human-computer interface is crucial for clinical use. A small color display or e-ink screen is integrated on the cover 104 of the infusion unit 100 for visualizing key information. Specific design includes: (1) Display content layout: The main area of ​​the screen is divided into several parts: a) Core Indicator Area: Occupying the most prominent position in the center of the screen is the Comprehensive Index of Patient Capacity Status. The dynamic trend curve. This curve is plotted with time on the horizontal axis (e.g., the most recent 10 minutes), and... Values ​​(range 0-1) are plotted in real-time on the vertical axis. The background is divided into distinct color bands: green areas (e.g., A value between 0.4 and 0.6 indicates "safe," a yellow area (0.2-0.4, 0.6-0.8) indicates "concern," and a red area (<0.2, >0.8) indicates "high risk." The curve moves across the colored background, allowing medical staff to easily see the current status and historical trends.

[0076] b) Key Parameter Digital Display Area: Below or to the side of the trend graph, the current real-time flow rate (unit: ml / h) and the remaining battery percentage of the infusion power module 109 are displayed in clear, large font. The flow rate value can be displayed in different colors according to its proximity to the target flow rate (e.g., green indicates matching, yellow indicates deviation >10%). The battery level is displayed using both icons and numbers; when the battery level is below 20%, the icon turns red and flashes.

[0077] c) Alarm and Information Area: A bar-shaped area at the top or bottom of the screen displays scrolling alerts from edge devices (main base station) or cloud devices. For example, when a "Regional Enhanced Monitoring" command is received from the cloud, this area will display a message such as "System monitoring in progress...". When the device itself triggers an abnormal alarm, this area will highlight the alarm content, such as "Abnormal pressure! Traffic throttling implemented."

[0078] (2) Encoding and Interaction: In order to convey more information within a limited screen space, encoding methods are used. For example, the thickness of the trend curve lines can be encoded. The short-term rate of change (derivative) of the value is displayed; a thicker curve indicates an accelerated change. Next to the curve may be a small icon whose shape encodes the type of the most recent infusion recommendation (e.g., an upward arrow indicating an accelerated recommendation). Healthcare professionals can switch between different display views (such as trend graphs, detailed parameter lists, and historical event logs) by pressing a physical button on the edge of the screen or by touching a specific area of ​​the touchscreen.

[0079] Understandably, this highly integrated, intelligently coded visualization solution presents complex, multi-dimensional information (time-series trends, safety status, real-time values, system status, external warnings) to medical staff in an intuitive and easy-to-interpret manner. Especially in high-pressure environments such as emergency care, medical staff no longer need to navigate through multiple menus or interpret complex numbers; they can instantly grasp the patient's volume status and treatment safety through colors, graphics, and trends, greatly improving human-computer interaction efficiency and decision support effectiveness. The combination of tiered color blocks and trend curves makes judging whether a patient's condition is "normal" immediately clear, reducing the possibility of misinterpretation. The unified display logic also reduces the training costs for different personnel.

[0080] This invention provides another embodiment, which offers an adaptive infusion coordination control system based on intelligent decision-making. The adaptive infusion coordination control system based on intelligent decision-making includes: (1) End device, which is the infusion unit of any of the above, including infusion power module, physiological signal acquisition module, processing module and communication module; the processing module is used to load and run the end-to-end patient status assessment model and the LSTM-based adaptive flow rate control algorithm to execute S1.

[0081] It should be further explained that this system is the physical entity corresponding to the aforementioned method, and is composed of three types of devices—end, edge, and cloud—collaborating through a communication network. The end device—the infusion unit 100—is the system's execution and sensing endpoint. All necessary hardware is integrated within its casing 101 and cover 102. The infusion power module 109 is the core actuator, preferably a peristaltic pump driven by a high-precision stepper motor, responsible for precisely propelling the medication in the infusion tubing 500. The physiological signal acquisition module includes interface circuits and signal conditioning circuits for connecting to external sensors (such as finger-clip pulse oximeters, ECG leads, and blood pressure cuffs), used to acquire analog signals such as ECG, pulse oximetry, and blood pressure, and convert them into digital signals. The processing module is the "brain" of the device, typically an embedded microprocessor (such as an ARM Cortex-M series) or application processor, responsible for running lightweight CNN-Transformer hybrid networks, LSTM-MPC control algorithms, local training, differential privacy noise addition, and all computationally intensive tasks. The communication module (such as a Wi-Fi / Bluetooth / 4G chip) is responsible for connecting to the edge device (main base station 200) and the cloud. The daughter power module 110 (such as a lithium polymer battery) powers all modules. Mechanical structures such as the fixing component 103 and the portable auxiliary component 106 ensure its portability and stability for clinical use.

[0082] (2) Edge device, which is the parent base station described in any of the above, including edge processing module and edge communication module; the edge processing module is used to execute S2 as a coordinating node for federated learning.

[0083] It should be further explained that the side device—the parent base station 200—is the local hub of the system. Its parent housing 202 and internal receiving cavity 201 constitute the charging and storage compartments for the daughter infusion units 100. The side processing module typically uses a more powerful processor (such as a high-performance ARM processor or a low-power x86 processor) to run the federated average aggregation algorithm, manage the communication of all subordinate daughter infusion units 100, monitor their status, and perform preliminary local model aggregation and distribution. The side communication module needs to have stronger connectivity capabilities, typically including short-range wireless modules (such as Bluetooth gateways or Zigbee coordinators) for communication with the daughter infusion units 100, Wi-Fi or Ethernet modules for internet access, and possibly cellular modules for wide-area backup. The charging interface 205 charges the daughter unit through the power receiving interface 105. Indicator lights 208, displays, etc., provide status indications. Grip grooves 203, connectors 204, and carrying straps 300 facilitate movement in the field.

[0084] (3) Cloud devices, including cloud server clusters, are used to execute the S3 described above to realize the federated aggregation, distribution and system-level monitoring of the global model.

[0085] It should be further explained that the cloud device is the brain and knowledge center of the system. It consists of several servers located in the data center, running database services, federated learning global aggregation services, a global situational analysis engine, a device management platform, and model distribution services. It communicates with the parent base stations 200 located around the world via the Internet, receives anonymized model updates and metadata, performs complex global model training and optimization, generates early warning instructions, and distributes the latest intelligent models and security policies to the edge.

[0086] Regarding the system workflow, the solution designed in this invention includes: At the rescue site, medical personnel retrieved the required number of child infusion units 100 from the main base station 200, secured them to the patient, and connected them to the infusion bag 400 and physiological sensors. The child units automatically started, performed self-checks, connected to the network, and synchronized with the latest model. After treatment began, each child unit independently controlled the intelligent infusion and periodically reported encrypted model updates to the main base station 200. The main base station 200 aggregated local updates while charging and uploaded them to the cloud. The cloud server integrated global data, generated a better model for deployment, and monitored overall risks. The main base station 200 notified the on-site commander of the system status via indicator lights 208 and the network.

[0087] Understandably, this control system tightly integrates advanced algorithms with specific hardware devices (the daughter infusion unit 100 and the parent base station 200) to form a complete and feasible product solution. The daughter unit is responsible for precise execution and individual intelligence, the parent base station for local coordination and energy replenishment, and the cloud for global optimization and macro-level monitoring. This clearly defined "cloud-edge-device" architecture fully utilizes the powerful computing and data integration capabilities of the cloud, reduces latency, protects privacy, and enhances network robustness through edge computing, and achieves offline autonomous operation through edge intelligence. It is highly suitable for complex medical scenarios such as field rescue, emergency care, and intra-hospital transport where network conditions are unstable, mobility is high, and privacy and security requirements are extremely stringent. The entire system, through software and hardware collaboration, achieves a complete closed loop from individual precision treatment to group collaborative optimization and then to global intelligent insight.

[0088] It should be further explained that the above system and method can be more clearly demonstrated through a specific operational case spanning the "cloud-edge-device" architecture. The following example, a rescue scenario, illustrates the entire process of data operation, collaborative computing, and result analysis: A disaster occurs in a certain area, and a rescue team rushes to the scene with this system. The system includes a parent base station 200 and three sub-infusion units 100 (including the first sub-infusion unit Q1, the second sub-infusion unit Q2, and the third sub-infusion unit Q3). A basic global model has been pre-trained in the cloud. The rescue team provides emergency intravenous infusion treatment to three patients, A, B, and C, suspected of dehydration and shock. The specific process is as follows: 1. End-side device initialization and intelligent control: a) Medical staff remove the first sub-infusion unit Q1, the second sub-infusion unit Q2, and the third sub-infusion unit Q3 from the receiving cavity 201 of the parent base station 200. Each sub-unit automatically starts up, connects to the temporary local area network created by the parent base station 200 through the communication module, and synchronizes to the latest global model parameter version V1.2.

[0089] b) Fix Q1, Q2, and Q3 to the limbs of patients A, B, and C respectively, and connect the physiological sensors to infusion bags 400 pre-filled with compound sodium chloride injection solution. Medical staff set the initial flow rate to 100 ml / h for all patients.

[0090] c) Taking Q1's treatment of patient A as an example, its end-side intelligent module starts working: (1) Data Acquisition and Status Assessment: Q1 continuously acquired physiological signals of patient A (assuming a heart rate of 125 bpm, decreased blood oxygen saturation waveform amplitude, and blood pressure of 85 / 50 mmHg at a certain moment), and input them along with the current flow rate (100 ml / h) and cumulative infusion volume (150 ml) into a lightweight CNN-Transformer hybrid network. After the network extracted the temporal features, it calculated and output the comprehensive index of patient volume status. The value is 0.15 (falling into the high-risk range). ), and generate infusion recommendations: target flow rate adjustment amount ml / h, adjust duration Minutes. Simultaneously, the risk prediction module outputs the probability of deterioration in the next 2 minutes. (Exceeds the threshold of 0.7).

[0091] (2) Adaptive flow rate control: The adaptive flow rate control algorithm receives the above suggestions ( ) and high-risk signals ( The LSTM-MPC controller performs rolling optimization by combining real-time pipeline pressure signals (e.g., 45 mmHg) and historical control commands. Due to the presence of high-risk predictions, the optimizer increases the weight of control smoothness in the objective function. It adopted a conservative reference trajectory. Ultimately, it generated and executed a set of gradually increasing control commands, progressively increasing the motor speed from the current 100 ml / h to 125 ml / h over the next two minutes (this is a preliminary adjustment, lower than the aggressive approach of directly increasing to 140 ml / h), while closely monitoring... change.

[0092] (3) Control effect and abnormal management: After increasing the flow rate, patient A's The value slowly recovered from 0.15 to 0.28 within 5 minutes. The tubing pressure stabilized within the range of 50-55 mmHg, consistent with the prediction confidence interval of the LSTM model, with no abnormal triggers. Treatment continued, and the model continuously fine-tuned its control based on real-time data.

[0093] 2. Edge-side collaboration and local aggregation: a) Approximately 6 hours later, the infusions for all three patients were completed. During the task cycle, Q1, Q2, and Q3 were performed based on the unique physiological responses of each patient (e.g., patient B was more sensitive to flow rate, patient C required a longer infusion time). (After a brief recovery), incremental model training was performed locally, generating updated model parameters with added noise. .

[0094] b) After the task is completed, the device is returned to the receiving cavity 201 of the parent base station 200 for charging. The parent base station 200, acting as a side device, verifies and aggregates these three updates during a preset aggregation cycle. Assume the local data sample numbers for the three are respectively... Then the total number of samples The parent base station 200 calculates local aggregate updates using the federated average formula: Use this update to generate the local optimization model V1.2.1 (local version).

[0095] c) The parent base station 200 will aggregate the differential parameters for this time. Packaged with anonymized metadata (e.g., number of participating devices = 3, total number of samples = 3450, local validation set error reduced by approximately 1.8%), it is sent to the cloud via satellite link.

[0096] 3. Cloud-based global optimization and early warning: a) The cloud server simultaneously received aggregated updates from the parent base station 200 of this rescue team and multiple other parent base stations in various regions. The cloud server executed a federated averaging algorithm, merging all updates to generate a new generation global model V1.3. Because this model incorporates experience from this rescue operation regarding the specific pattern of "post-disaster dehydration shock," its predictive accuracy in handling similar physiological characteristics has been improved.

[0097] b) When analyzing the metadata uploaded by various devices, the global situational analysis engine found that, including the rescue team, the weights related to "rapid correction of hypovolemia" in the reported model features of base stations from three different geographical regions were significantly active in the past 24 hours. Although there was no individual data, the cloud server determined that there might be a regional risk of heat stress disease and thus generated a group warning.

[0098] c) The cloud server will send the new global model V1.3 and the group early warning instruction "Be alert for cases of high-temperature-related dehydration, and it is recommended to increase the monitoring frequency" to all online parent base stations 200.

[0099] 4. Results Analysis and System Evolution: a) End-to-end outcome: Patient A received timely and adaptive fluid resuscitation, and The value improved steadily, avoiding the risk of fluid overload that might be caused by rapid and large-volume fluid replenishment. Q1's intelligent control enabled the transformation from "fixed flow rate" to "on-demand titration".

[0100] b) Side results: The parent base station 200 efficiently completed the fusion of local knowledge and generated a model V1.2.1 that is more adapted to the local rescue environment, which can be used immediately for subsequent tasks.

[0101] c) Global Results: A more powerful V1.3 model was generated in the cloud. When another rescue team activated a brand-new, never-before-used infusion unit 100 at another location several hours later, the initial model synchronized from the cloud or edge device was V1.3. Therefore, upon startup, it possessed the "experience" accumulated by all previous rescue teams (including the first) in handling similar shock patients, enabling faster and more accurate assessment of patient status and implementation of control measures, achieving the effect of "ready to use and expert immediately." Simultaneously, the received early warning information alerted medical staff to pay attention to environmental risks, demonstrating the system's macro-level decision-making support capabilities.

[0102] Understandably, this case study fully demonstrates the complete process from the perception-decision-control closed loop of a single device, to the collaborative knowledge aggregation of a local device group, and then to the fusion and distribution of global knowledge, ultimately enabling the new device to acquire "collective intelligence." The data flow, control decisions, model updates, and results in this case study are completely consistent with the technical details described in the aforementioned specific implementation methods (such as model structure, federated averaging formula, and early warning mechanism), verifying the feasibility of the system in achieving personalized precision treatment and continuous evolution of collective intelligence in real-world scenarios.

[0103] In a preferred embodiment, this application also provides a non-gravity mother-daughter infusion system; please refer to [link to relevant documentation]. Figure 1 The system includes: a daughter infusion unit 100, which includes an infusion power module 109 for non-gravity delivery of medication and a placement cavity 107 for holding an infusion bag 400; and a mother base station 200, which includes at least one receiving cavity 201 for housing the daughter infusion unit 100, wherein the daughter infusion unit 100 is detachably disposed within the receiving cavity 201. It is understood that the daughter infusion unit 100 integrates the infusion power module 109 for actively pumping medication and has a placement cavity 107 for accommodating the infusion bag 400. The housing of the mother base station 200 has at least one receiving cavity 201, into which the daughter infusion unit 100 is detachably placed for storage, charging, and overall transportation.

[0104] Specifically, the number of accommodating cavities 201 can be one, two, four, eight or more, to adapt to the scale of equipment management in different scenarios.

[0105] Specifically, the separable connection between the infusion unit 100 and the receiving cavity 201 can be achieved by means of plug-in, magnetic attraction, snap-fit ​​or sliding rail.

[0106] By adopting the above technical solution, the sub-infusion unit 100, as a complete and independent infusion terminal, can completely detach from the parent base station 200 and perform infusion tasks at any location. This independence is key to dealing with emergency rescue, transportation, and other environmental scenarios. The receiving cavity 201 provides a physical storage location for the sub-infusion unit 100.

[0107] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 5 The infusion unit 100 includes a housing 101 and a fixing member 103 disposed on the housing 101. The fixing member 103 is configured as an adjustable structure, so that the infusion unit 100 can be flexibly and firmly fixed to various load-bearing objects, such as a patient's limbs, bed rails, or stretcher poles.

[0108] Specifically, the fastener 103 can be a combination of a retractable bandage 1031 and a bandage fixing piece 1032. The bandage fixing piece 1032 is connected to the end of the retractable bandage 1031. The retractable bandage 1031 is connected to a groove on one side of the sub-body housing 101 via a roller. The other side of the sub-body housing 101 is provided with a fixing buckle that engages with the bandage fixing piece 1032. Alternatively, the fastener 103 can also be a Velcro strap, etc.

[0109] Specifically, the material of the fastener 103 can be medical silicone or fabric with antibacterial and hypoallergenic properties to improve wearing comfort.

[0110] By adopting the above technical solution, the design of the fixing component 103 directly determines the portability and attachment reliability of the infusion unit 100. The adjustable design enables it to adapt to different patient limb circumferences, different fixing positions, or different diameter carriers (such as bed rails), which saves space and avoids infusion interruption or equipment damage due to detachment.

[0111] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 5 The sub-body shell 101 is provided with a portable auxiliary component 106. The portable auxiliary component 106 may be a ring handle, a strip-shaped ridge, an anti-slip textured area, a hanging hole, or a recessed finger groove.

[0112] Specifically, different types of portable auxiliary parts 106 are provided on multiple surfaces of the sub-body shell 101 to adapt to the holding needs in different scenarios.

[0113] By adopting the above technical solution, the portable accessory 106 can be held and stably lifted with one hand, preventing the device from slipping out of the hand due to its smooth surface. It can also serve as a temporary suspension point, for example, when changing infusion bags, the device can be temporarily hung on a wall or infusion stand hook.

[0114] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 5 The upper surface of the sub-body shell 101 is recessed towards its lower surface to form the placement cavity 107, and a cover 102 is rotatably connected to the placement cavity 107. An anti-slip pad is provided on the lower surface of the sub-body shell 101.

[0115] Specifically, a cover 102 is hinged above the placement cavity 107 via a pivot. The cover 102 can be opened to allow insertion or removal of the infusion bag 400, and when closed, it provides restraint and protection for the infusion bag 400. The connection method of the cover 102 is not limited to hinged; it can also be a sliding cover.

[0116] Specifically, one side of the cover 102 is hinged to the cover frame, the other side of the cover 102 is engaged with the cover frame, and the cover frame is connected to the sub-body shell 101.

[0117] Specifically, the cover 102 can be transparent, allowing for easy observation of the remaining fluid volume in the infusion bag without opening it.

[0118] By adopting the above technical solution, the combined design of the recessed placement cavity 107 and the cover 102 achieves embedded fixation and protection of the infusion bag 400. The rotating connection of the cover 102 is simple and quick to operate, and when closed, it effectively prevents the infusion bag 400 from falling out of the cavity during movement or bumps, ensuring the continuity of the infusion process. At the same time, the cover 102 applies a slight constraint to the infusion bag 400, which can reduce the swaying of the infusion bag caused by the internal liquid sloshing, indirectly helping to improve the accuracy of infusion.

[0119] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 5 The infusion unit 100 further includes a placement groove 108 through which the infusion tube 500 passes. The infusion power module 109 is disposed on the infusion tube 500 and is detachably disposed in the placement groove 108.

[0120] Specifically, a placement groove 108 is provided on the sub-body housing 101 for laying and fixing the infusion tube 500 extending from the infusion bag 400. The infusion power module 109 is designed to be clamped onto a specific section of the infusion tube 500, and the assembly can be securely snapped into or embedded in the placement groove 108.

[0121] Specifically, the infusion power module 109 can be fixed to the placement tank 108 by means of clips or magnetic attraction. The placement tank 108 is equipped with a detachable cover plate 104 to further protect the pump tubing assembly.

[0122] Specifically, the infusion power module 109 employs a peristaltic pump. This peristaltic pump propels the medication flow by periodically squeezing the flexible infusion tubing 500. The peristaltic pump features a modular design, with its body section housed in the placement slot 108. The pump head section can be quickly disassembled from the body section for easy cleaning, disinfection, or replacement. By controlling the motor speed of the body section, the frequency of squeezing the infusion tubing 500 can be precisely controlled, thereby achieving precise flow rate regulation. Furthermore, the flow rate is virtually unaffected by changes in the fluid level within the infusion bag or the patient's venous pressure.

[0123] By adopting the above technical solution, the infusion power module 109 is designed to be pre-assembled with the infusion tubing 500 and then snapped into the placement slot 108, achieving plug-and-play functionality, greatly simplifying the operation process, and making it suitable for emergency situations. This detachable design facilitates replacement and maintenance without affecting the main unit, making it convenient to replace consumables (infusion tubing). At the same time, the placement slot 108 provides physical protection for the pump tubing assembly, preventing direct impact.

[0124] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 7 The daughter infusion unit 100 further includes a daughter power module 110, which is electrically connected to the infusion power module 109; the mother base station 200 further includes a mother power module, and a charging interface 205 electrically connected to the mother power module is provided in the receiving cavity 201. The daughter infusion unit 100 is correspondingly provided with a power receiving interface 105. When the daughter infusion unit 100 is placed in the receiving cavity 201, the charging interface 205 is connected to the power receiving interface 105 to charge the daughter power module 110.

[0125] Understandably, the daughter infusion unit 100 integrates a daughter power module 110 (such as a rechargeable lithium battery), which powers the infusion power module 109 and other electronic components (such as a display screen located on top of the daughter housing 101, showing the real-time infusion rate, remaining medication volume, and remaining power of the daughter power module 110). Correspondingly, the parent base station 200 contains a larger capacity parent power module (not shown separately in the figure). Each receiving cavity 201 of the parent base station 200 is equipped with a charging interface 205. A corresponding power receiving interface 105 is provided in the daughter infusion unit 100. When the daughter infusion unit 100 is correctly placed into the receiving cavity 201, the charging interface 205 connects to the power receiving interface 105, allowing the parent power module to charge the daughter power module 110.

[0126] Specifically, a spherical soft pad is provided in the receiving cavity 201 to reduce wear on the cavity wall during insertion and removal of the infusion unit 100.

[0127] Specifically, the charging interface 205 and the power receiving interface 105 can adopt a foolproof design and a magnetic alignment design to ensure a correct and secure connection.

[0128] Specifically, the main power module can be a replaceable battery pack to support longer periods of fieldwork without mains power.

[0129] Specifically, the main base station 200 is equipped with an external power socket 207, which is electrically connected to the main power module. In locations with fixed power supplies, such as hospitals and emergency stations, the main power can be connected via the external power socket 207 to store power for the main power module, ensuring it is always fully charged and ready for use. In environments without mains power, such as outdoors, disaster sites, or during transport, a fully charged main base station 200 can use its internal stored energy to charge multiple daughter infusion units 100 in multiple cycles. Furthermore, this external power socket 207 can also output power to temporarily supply power to other urgently needed medical equipment (such as monitors and small suction devices) or communication equipment.

[0130] Specifically, the parent base station 200 is equipped with an indicator light 208, which is set one-to-one with the receiving cavity 201 to display the charging status of the daughter infusion unit 100 in the corresponding receiving cavity 201.

[0131] By adopting the above technical solution, the sub-power module 110 ensures the continuous operation of the sub-infusion unit 100 when it is disconnected from the parent base station 200, and its capacity must meet the requirements of a typical single infusion duration (e.g., several hours). The parent power module has a larger capacity, capable of cyclically charging multiple sub-power modules 110, and can be replenished with energy from the mains power via the external power socket 207. This design allows the sub-infusion unit 100 to be used immediately upon request, without the constraints of a power cord; after use, it can be automatically replenished by returning it to the parent base station 200, eliminating the need for manual searching and unplugging of the charger. The automatic docking design between the charging interface 205 and the power receiving interface 105 simplifies operation and improves reliability.

[0132] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 9 The parent base station 200 also includes a storage compartment 206 that is physically separated from the receiving cavity 201, for storing infusion auxiliary devices (such as spare infusion tubing, syringes of different specifications, infusion dressings, disinfectant swabs, tourniquets, sharps boxes, etc.).

[0133] Specifically, the storage compartment 206 can be designed as multiple independent compartments to achieve classified storage of infusion auxiliary devices.

[0134] Specifically, the parent base station 200 includes a parent housing 202 and a front cover 209 located in front of the parent housing 202. The parent housing 202 and the front cover 209 are fastened together, and the front cover 209 has a through hole corresponding to the receiving cavity 201. An anti-slip pad is provided on the bottom of the parent housing 202. The bottom of the storage compartment 206 is hinged to the parent housing 202, and the top of the storage compartment 206 is engaged with the parent housing 202. The storage compartment 206 can be made of transparent material for easy and quick viewing of the internal infusion auxiliary devices.

[0135] By adopting the above technical solution, the storage compartment 206 can store different infusion auxiliary devices in separate areas, saving search time, improving work efficiency, and ensuring that all necessary items are readily available in emergencies. Furthermore, the separate design prevents interference between the infusion auxiliary devices and the infusion unit 100.

[0136] In this embodiment of a non-gravity mother-daughter infusion system, please refer to... Figures 1 to 9 The mother base station 200 is provided with a connector 204 for mounting a carrying strap 300.

[0137] Specifically, connectors 204 (such as D-rings or webbing buckles) are provided on both sides and the top of the mother housing 202, and the carrying strap 300 can be installed on the mother base station 200 through the connectors 204. At the same time, gripping grooves 203 are formed by partial indentation on both sides of the mother housing 202 to facilitate handling.

[0138] By adopting the above technical solution, the connection 204 and the carrying strap 300 work together to transform the parent base station 200 from a desktop device into a portable mobile workstation.

[0139] The working principle of the non-gravity mother-daughter infusion system described in this invention is as follows: 1. Preparation and Charging Phase: In the non-use state, one or more daughter infusion units 100 are placed in the receiving cavity 201 of the parent base station 200. At this time, the power receiving interface 105 and the charging interface 205 are automatically connected, and the parent base station 200 begins charging the daughter power module 110. The parent base station 200 itself can be charged by connecting to mains power through the external power socket 207. Infusion auxiliary devices (such as spare infusion tubing) can be stored in a separate storage compartment 206.

[0140] 2. Retrieval and Deployment Phase: When intravenous infusion is required, medical staff retrieve a fully charged infusion unit 100 from the receiving cavity 201. The pre-filled infusion bag 400 is placed into the placement cavity 107 and the cover 102 is closed. One end of the infusion tubing 500 is connected to the infusion bag 400, and the other end is connected to an indwelling intravenous catheter, and the tubing is laid in the placement slot 108. The infusion power module 109 (the pump head section of the peristaltic pump) is clamped in a suitable position on the infusion tubing 500, and then the pump tubing assembly is snapped into the placement slot 108 for fixation. At this point, the pump head section of the peristaltic pump is connected to its body section. The entire infusion unit 100 is securely fixed to the patient's limb or a suitable position beside the bed using the fixing piece 103.

[0141] 3. Infusion Operation Phase: The infusion power module 109 starts working, and its pump head section periodically squeezes the infusion tubing 500, actively pumping the medication from the infusion bag 400 into the patient's vein. The entire infusion process does not rely on gravity suspension at all.

[0142] 4. End and Return Phase: After the infusion is completed, turn off the device. Remove the fixation piece 103 from the patient and remove the infusion unit 100. Remove the used infusion tubing 500 along with the infusion power module 109 (the pump head section of the peristaltic pump) from the placement slot 108 and dispose of it as medical waste. Place the infusion unit 100 back into the receiving cavity 201, and the system will enter charging and standby mode again, completing one usage cycle.

[0143] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0144] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0145] In a preferred embodiment, this application also provides an electronic device, the electronic device comprising: The computer device includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, implement the adaptive infusion coordination control method based on intelligent decision-making. The computer device can be broadly categorized as a server, terminal, or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs the steps of the method of the present invention.

[0146] This invention can be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the methods of embodiments of the invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0147] Those skilled in the art will understand that the method steps of this invention can be performed by a computer program instructing related hardware, such as a computer device or processor, to perform the steps of this invention when executed. Depending on the context, any references herein to memory, storage, databases, or other media may include non-volatile and / or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc.

[0148] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0149] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. An adaptive infusion coordinated control method based on intelligent decision-making, characterized in that, The method includes: S1. By integrating the end-to-end patient status assessment model into the infusion unit (100), the acquired multimodal physiological time-series data and current infusion parameters are analyzed in real time, and the comprehensive index of patient volume status and infusion suggestions are output. The infusion suggestions and pipeline pressure signals are input into the LSTM-based adaptive flow rate control algorithm to generate motor control commands for driving the infusion power module (109) to achieve closed-loop control. S2. The parent base station (200) periodically receives updates of model parameters obtained through local training uploaded by multiple daughter infusion units (100); S3. Based on the federated averaging algorithm, aggregate the model parameter updates uploaded by all edge devices, generate an optimized global model, and distribute it to each edge device and end device.

2. The method according to claim 1, characterized in that, The end-to-end patient status assessment model is a lightweight CNN-Transformer hybrid network; the real-time parsed multimodal physiological time-series data and current infusion parameters include: Physiological signal sensors connected to the infusion unit (100) continuously collect time-series data of the patient's electrocardiogram, blood oxygen, and blood pressure. Simultaneously, real-time flow rate and cumulative infusion volume parameters are obtained from the infusion power module (109). The lightweight CNN-Transformer hybrid network performs convolutional feature extraction on the time-series data of electrocardiogram, blood oxygen, and blood pressure, and fuses it with the flow rate and cumulative infusion volume parameters at the feature layer. Then, the Transformer encoder captures the fused cross-modal long-term temporal dependency relationship, and finally outputs a continuously changing comprehensive index that characterizes the dynamics of the patient's volume load. Based on the predefined risk range in which the comprehensive index is located, the infusion recommendation containing the target flow rate adjustment amount and adjustment duration is generated.

3. The method according to claim 2, characterized in that, The LSTM-based adaptive flow velocity control algorithm performs the following steps: The method takes the infusion recommendation, the real-time collected tubing pressure signal, and the historical motor drive command sequence of the infusion power module (109) as inputs; it learns the complex dynamic characteristics of the coupling system of the infusion power module (109), the infusion tubing, and the patient's vascular dynamics through an LSTM network, and predicts the motor drive signal required to maintain the target flow rate in the next few control cycles; based on the prediction results and the feedback of the current tubing pressure, it generates a smooth motor control command sequence using a model predictive control framework, and outputs the first command to the motor driver of the infusion power module (109); the method also includes an anomaly identification step: when the real-time tubing pressure signal exceeds the pressure range threshold predicted by the LSTM network, or when the patient's volume status comprehensive index changes abruptly within a preset time, a safety protocol is triggered, the safety protocol including immediately reducing the flow rate to a safe baseline and sending an alarm containing an anomaly code to the upper-level side device.

4. The method according to claim 3, characterized in that, The generation of the infusion recommendation also incorporates risk prediction based on the short-term trends of the multimodal physiological time-series data; when the adaptive flow rate control algorithm is executed, if the risk prediction indicates that the patient's condition is likely to deteriorate in a subsequent period, the generated motor control command sequence includes preparatory parameter adjustments, which include reducing the baseline flow rate gradually and in advance before deterioration occurs, or reserving some motor control margin to cope with possible rapid pressure adjustment needs.

5. The method according to claim 1, characterized in that, S1 also includes a local model training step: Locally within the sub-infusion unit (100), patient physiological data, control command data, and corresponding infusion result labels generated during the current infusion task cycle are used to incrementally train the end-to-end patient status assessment model and the sub-model in the adaptive flow rate control algorithm to obtain local model parameter updates. Before uploading, the model parameter updates undergo differential privacy noise reduction processing via the built-in security module of the sub-infusion unit (100).

6. The method according to claim 5, characterized in that, S2 specifically includes: The parent base station (200) acts as the coordinating node for federated learning. When the preset aggregation period arrives, it verifies and aggregates the privacy-processed model parameter updates uploaded by all online child infusion units (100) under its management. Based on the aggregated parameters, the parent base station (200) generates a preliminary optimized local model and uploads the parameter updates of the local model and its associated anonymized metadata to the cloud device. The anonymized metadata includes at least the number of child units participating in the aggregation and an overview of model performance improvement indicators.

7. The method according to claim 6, characterized in that, S3 also includes a global early warning step: The cloud device performs global situational analysis based on anonymized metadata received from all edge devices. The global situational analysis includes identifying the concentrated occurrence of specific physiological parameter patterns within the jurisdiction of multiple edge devices, or the trend of control efficiency decay in a specific model of infusion power module (109). When potential group risks or batch problems of equipment are identified, the cloud device generates and issues multi-level early warning instructions. The multi-level early warning instructions include enhanced monitoring instructions for edge devices in specific areas, and control parameter pre-adjustment instructions or model hot patching instructions for potentially affected end devices.

8. The method according to claim 1, characterized in that, The method also includes system startup and self-test steps: When any child infusion unit (100) is taken out from the receiving cavity (201) of the parent base station (200) and started, an adaptive startup process is executed. The adaptive startup process includes automatically detecting and accessing the current optimal communication network, pulling the latest global model parameters from the parent base station (200) or directly from the cloud device to complete the local model update, and using the built-in simulated load to calibrate and test the infusion power module (109). After the parent base station (200) detects that the child infusion unit (100) in its receiving cavity (201) has completed charging or software update, it triggers a cross-device consistency self-check to ensure that all child infusion units (100) under its management run the same version of control logic and model.

9. The method according to any one of claims 1 to 8, characterized in that, The patient's volume status comprehensive index, real-time flow rate, remaining power of the infusion power module (109), and warning information issued by the edge device or cloud device are visualized on the display screen on the sub-infusion unit (100). The visualization display adopts a combination of coded dynamic curves and graded color blocks, wherein the patient's volume status comprehensive index is displayed as a trend curve superimposed on a preset safe range background.

10. An adaptive infusion coordination control system based on intelligent decision-making, characterized in that, include: The end device, which is the infusion unit (100) in the method of any one of claims 1-9, includes an infusion power module (109), a physiological signal acquisition module, a processing module and a communication module; the processing module is used to load and run the end-to-end patient status assessment model and the LSTM-based adaptive flow rate control algorithm to execute S1 in the method of claim 1; The edge device, which is the parent base station (200) in the method of any one of claims 1-9, includes an edge processing module and an edge communication module; the edge processing module is used to execute S2 in the method of claim 1, as a coordinating node for federated learning; Cloud devices, including cloud server clusters, are used to execute S3 in the method of claim 1 to realize the federated aggregation, distribution and system-level monitoring of the global model.

Images