Multi-pump closed-loop management system

Abstract

An infusion device control system intercepts a first command provided by a closed-loop control algorithm to a first infusion pump, the first command configured to regulate delivery of a first fluid by the first infusion pump in accordance with sensor measurements provided to the closed-loop control algorithm. The control system receives treatment target control parameters for modifying delivery of the first fluid based on real-time parameters for delivery of the second fluid by the second infusion pump, receives real-time operating parameters and infusion status information associated with the first and second infusion pumps, and modify the intercepted first command to control the effect of delivery of the first fluid and the second fluid based on real-time operational parameters and infusion status information and treatment target control parameters without providing input to the closed loop control algorithm for modifying the intercepted first command.

Description

Technical Field

[0001] The present disclosure generally relates to managing infusions using closed-loop algorithms. Background Art

[0002] Closed-loop control of intravenous (IV) infusions requires specific setup conditions and operates according to a predetermined algorithm with a specific task of controlling a single parameter. In addition, the control loop algorithm is optimized for specific IV infusion sets and devices. Modifying the closed-loop algorithm to accommodate different therapies, different sensors, or to control different types of infusion devices is expensive and time consuming. Summary of the invention

[0003] According to various aspects, the subject technology provides a closed-loop management system and method for controlling multiple infusion pumps. According to various aspects, a method includes intercepting a first command provided by a closed-loop control algorithm to a first infusion pump, the first command being configured to adjust the delivery of a first fluid by the first infusion pump according to a sensor measurement provided to the closed-loop control algorithm; receiving a therapeutic target control parameter for modifying the delivery of the first fluid based on a real-time parameter of the second fluid delivered by a second infusion pump; receiving real-time operating parameters and infusion status information associated with the first infusion pump and the second infusion pump; and modifying the intercepted first command based on the real-time operating parameters and infusion status information and the therapeutic target control parameter to control the effect of the delivery of the first fluid and the second fluid, without providing the closed-loop control algorithm with input for modifying the intercepted first command. Other aspects include corresponding systems, devices, and computer program products for implementing corresponding methods and features thereof.

[0004] It will be appreciated that other configurations of the subject technology will be readily apparent to those skilled in the art from the following detailed description, wherein the various configurations of the subject technology are illustrated and described by way of illustration. As will be appreciated, the subject technology can have other and different configurations and several of its details can be modified in various other aspects, all without departing from the scope of the subject technology. Therefore, the accompanying drawings and detailed description should be considered illustrative in nature and not to be considered restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] For a better understanding of the various described embodiments, reference should be made to the following description of the embodiments in conjunction with the following drawings. Throughout the drawings and description, like reference numerals refer to corresponding parts.

[0006] Figure 1 An example of an institutional patient care system for a healthcare organization in accordance with aspects of the subject technology is depicted.

[0007] Figure 2AA conceptual diagram illustrating an example system architecture including an example resource management unit in accordance with aspects of the subject technology.

[0008] Figure 2B The present invention shows aspects of the subject technology. Figure 2A An exemplary system architecture in which multiple infusion sets provide medication to a single expansion kit.

[0009] Figures 3A to 3C are first, second, and third example conceptual diagrams of managing multiple infusion pumps using an intelligent control module in a closed-loop or semi-closed-loop environment in accordance with various aspects of the subject technology.

[0010] Figure 4 Depicted is an example process for managing multiple infusion pumps using an intelligent control system in a closed-loop or semi-closed-loop environment in accordance with various aspects of the subject technology.

[0011] Figure 5 is a conceptual diagram illustrating an example electronic system for managing multiple infusion pumps using an intelligent control system in a closed-loop or semi-closed-loop environment in accordance with aspects of the subject technology. DETAILED DESCRIPTION

[0012] Reference will now be made to embodiments, examples of which are shown in the accompanying drawings. In the following description, many specific details are set forth in order to provide an understanding of the various described embodiments. However, it will be apparent to one of ordinary skill in the art that the various described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks are not described in detail in order to avoid unnecessarily obscuring aspects of the embodiments.

[0013] This article describes a portable infusion device control system that can be connected to multiple infusion devices and control the infusion device by re-purposing the existing closed-loop control algorithm. For example, the closed-loop algorithm can receive feedback information from the infusion device in the form of infusion information, and receive feedback information from the patient in the form of biometric and physiological sensor information. Based on this information, the algorithm can continuously control physiological parameters based on manipulating the control of the infusion device to dynamically adjust the delivery of the drug to the patient according to the target parameters. The control system of the subject technology is configured to be positioned between the control loop algorithm and the pump, and intercepts and modifies the pump command sent by the control loop algorithm based on the same input (and potential additional inputs) to control the pump according to the real-time program requirements in the field.

[0014] The subject technology provides a way to dynamically adjust a closed-loop control algorithm for an infusion device without recoding or retraining the algorithm. The infusion device control system intercepts commands provided by the closed-loop control algorithm to a first infusion pump and receives a treatment target control parameter for modifying the delivery of the fluid. The system modifies the intercepted commands to control the treatment provided by the infusion device based on real-time operating parameters and infusion state information and the treatment target control parameter without providing input to the closed-loop control algorithm for modifying the intercepted commands. In this way, the closed-loop algorithm remains independent of the treatment and the pump.

[0015] The infusion device control system is also configured to reuse and / or adjust an existing control loop algorithm configured for one infusion device to control multiple infusion devices based on feedback information provided by the pumps and associated sensors. In this regard, patient sensor information is also provided to the control system along with the infusion information from the controlled pumps. The clinician selects a treatment and the number of pumps to be used in the treatment (which may be based on the selection), and the control system converts the control parameters of the single treatment into the control parameters of the multiple treatments.

[0016] Figure 1 An example of an institutional patient care system 100 for a healthcare organization in accordance with various aspects of the subject technology is depicted. Figure 1 In the embodiment of the present invention, patient care devices (or generally "medical devices") 12 are connected to the hospital network 10. The term patient care device (or "PCD") can be used interchangeably with the term patient care unit (or "PCU"), which can include various auxiliary medical devices, such as infusion pumps, vital signs monitors, drug dispensing equipment (e.g., cabinets, suitcases), drug preparation equipment, automatic dispensing equipment, modules connected to one of the foregoing (e.g., syringe pump modules configured to be attached to infusion pumps), or other similar devices. Each element 12 is connected to the internal healthcare network 10 via a transmission channel 31. The transmission channel 31 can be a wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some embodiments, the network 10 also includes computer systems located in various departments throughout the hospital. For example, the network 10 optionally includes computer systems associated with the admission department, the billing department, the biomedical engineering department, the clinical laboratory, the central supply department, one or more unit station computers, and / or a medical decision support system. As further described below, the network 10 can include discrete subnets. In the depicted example, the network 10 includes a device network 40 through which the patient-care devices 12 (and other devices) communicate in accordance with normal operations.

[0017] In addition, the institutional patient care system 100 may include a separate information system server 30, the functionality of which will be described in more detail below. In addition, although the information system server 30 is shown as a separate server, the functionality and programming of the information system server 30 can be incorporated into another computer if desired by the engineers designing the institutional information system. The institutional patient care system 100 may also include one or more device terminals 32 for connecting and communicating with the information system server 30. The device terminal 32 may include a personal computer, a personal data assistant, a mobile device such as a laptop, a tablet, an augmented reality device, or a smart phone configured with software for communicating with the information system server 30 via the network 10.

[0018] The patient care device 12 includes a system for providing patient care, such as the system described in U.S. Patient Care Device 12, U.S. Patient Care Device ...

[0019] In various embodiments, the user interface device 54 is a touch screen for displaying information to a user and allowing the user to input information by touching a defined area of ​​the screen. Additionally or alternatively, the user interface device 54 may include means for displaying and inputting information (specifically configured with one or more of the features described), such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. The data input device 60 may be a bar code reader capable of scanning and interpreting data printed in a bar code format. Additionally or alternatively, the data input device 60 may be a device specially configured for inputting encoded data into a computer, such as a device for reading a magnetic strip, a radio frequency identification (RFID) device, wherein the digital data encoded in an RFID tag or smart tag (defined below) is captured by the reader 60 via radio waves, a PCMCIA smart card, a radio frequency card, a memory stick, a CD, a DVD, or other analog or digital storage medium. Other examples of the data input device 60 include a voice activation or recognition device or a portable personal data assistant (PDA). Depending on the type of interface device used, the user interface device 54 and the data input device 60 may be the same device. Although as Figure 1 As shown, the data input device 60 is disposed within the interface unit 14, but it will be appreciated that the data input device 60 can be integrated within the pharmacy system 34, or located externally and communicate with the pharmacy system 34 via an RS-232 serial interface or other appropriate communication means. The auxiliary interface 62 can be an RS-232 communication interface, however, other means for communicating with peripheral devices in the environment (such as printers, patient monitors, infusion pumps or other medical devices) can be used without departing from the subject technology. In addition, the data input device 60 can be a separate functional module, such as modules 16, 18, 20 and 22, and is configured to communicate with the controller 14 or other systems on the network, using appropriate programming and communication protocols.

[0020] The network connection 52 may be a wired or wireless connection, such as via Ethernet, WiFi, Bluetooth, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem, or a cable modem. A direct or indirect network connection may be used, including but not limited to a telephone modem, a MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link, a personal area network connection, a local area network connection, a cellular link, or a WLANS connection or other wireless connection.

[0021] Functional modules 16, 18, 20, 22 are specially configured devices for providing care to patients or for monitoring the condition of patients. Figure 1As shown, at least one of the functional modules 16, 18, 20, 22 can be an infusion pump module, such as an intravenous infusion pump for delivering drugs or other fluids to a patient. For the purpose of this discussion, the functional module 16 is an infusion pump module. Each functional module 18, 20, 22 can be a patient treatment or monitoring device, including but not limited to an infusion pump, a syringe pump, a patient-controlled analgesia (PCA) pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, or an intracranial pressure monitor, etc. The functional modules 18, 20 and / or 22 can be printers, scanners, barcode readers, or other peripheral input, output, or input / output devices.

[0022] Each functional module 16, 18, 20, 22 communicates directly or indirectly with the interface unit 14, wherein the interface unit 14 provides overall monitoring and control of the device 12. The functional modules 16, 18, 20, 22 can be physically and electronically connected to one or both ends of the interface unit 14 in a serial manner, such as Figure 1 , or as detailed by Eggers et al. However, it will be appreciated that other means for connecting the functional modules to the interface unit may be used without departing from the subject technology. It will also be appreciated that a device such as a pump or patient monitoring device that provides sufficient programmability and connectivity may be able to operate as a standalone device and may communicate directly with the network without being connected through a separate interface unit or control unit 14. As described above, additional medical devices or peripheral devices may be connected to the patient care device 12 via one or more auxiliary interfaces 62.

[0023] Each functional module 16, 18, 20, 22 may include module-specific components 76, a microprocessor 70, volatile memory 72, and non-volatile memory 74 for storing information. Figure 1 Four functional modules are shown in FIG, but any number of devices may be connected directly or indirectly to the central controller 14. The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. Module-specific components 76 include components of a specific configuration required to operate a specific module, such as a pumping mechanism 16 for an infusion pump module.

[0024] Although each functional module may be capable of at least some degree of independent operation, interface unit 14 monitors and controls the overall operation of device 12. For example, as will be described in more detail below, interface unit 14 provides programming instructions 16, 18, 20, 22 to the functional modules and monitors the status of each module.

[0025] The patient care device 12 can operate in several different modes or personalities, each of which is defined by a configuration database. The configuration database can be a database 56 internal to the patient care device or an external database 37. A specific configuration database is selected based at least in part on patient-specific information such as patient location, age, physical characteristics, or medical characteristics. Medical characteristics include, but are not limited to, patient diagnosis, treatment prescriptions, medical history, medical records, patient care provider identification, physiological characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identification) or the location of the patient care device 10 in a hospital or hospital computer network. Patient care information can be input through interface devices 52, 54, 60, or 62 and may originate from any location in the network 10, for example, from a pharmacy server, an admission server, a laboratory server, etc.

[0026] Medical devices incorporating aspects of the subject technology may be equipped with a network interface module (NIM) that allows the medical device to participate in a network as a node. Although for clarity, the subject technology will be described as operating in an Ethernet network environment using the Internet Protocol (IP), it should be understood that the concepts of the subject technology are equally applicable to other network environments, and such environments are intended to be within the scope of the subject technology.

[0027] Existing techniques may be used to convert data to and from various data sources into network compatible data, and movement of information between medical devices and the network may be accomplished in a variety of ways. For example, patient care devices 12 and network 10 may communicate via automatic interaction, manual interaction, or a combination of both automatic and manual interaction. Automatic interaction may be continuous or intermittent, and may occur via a direct network connection 54 (e.g., Figure 1 As shown), or through an RS232 link, a MIB system, an RF link such as Bluetooth, an IR link, a PAN, a LAN, a WLAN, a digital cable system, a telephone modem, or other wired or wireless communication methods. Manual interaction between the patient care devices 12 and the network 10 involves the intermittent or periodic physical transfer of data between systems using, for example, a user interface device 54, a data encoding data input device 60, a bar code, a computer disk, a portable data assistant, a memory card, or other media for storing data. The communication methods in all aspects are bidirectional, and data can be accessed from as many distributed data sources as possible. Decisions can occur at multiple locations within the network 10. For example, but not limited to, decisions can be made at the HIS server 30, the decision support 48, the remote data server 49, the hospital department or unit station 46, or in the patient care device 12 itself.

[0028] All direct communications with medical devices operating on a network according to the subject technology may be performed through an information system server 30, referred to as a remote data server (RDS). According to aspects of the subject technology, a network interface module incorporated into a medical device (e.g., an infusion pump or a vital sign measurement device) ignores all network traffic that is not from an authenticated RDS. The primary responsibility of the RDS of the subject technology is to track the location and status of all networked medical devices with a NIM and maintain open communications.

[0029] In some embodiments, the drug delivery modules 16, 18, 20, 22 include a plug-in port for expansion. Thus, a new drug delivery module can be attached to the PCU 12 by plugging into the port coupling connector, which may include electrical terminals so that the added drug delivery module 16, 18, 20, 22 can send information to and receive information from the control module 14. In some embodiments, the added drug delivery module 16, 18, 20, 22 can also receive power from the control module 14 through the plug-in port. The control module 14 may include a main display, memory, and processor (see FIG. 10), and may be configured to display operating parameters and drug delivery status, as well as additional information associated with each of the drug delivery modules 16, 18, 20, 22. According to various embodiments, the module display may also display physiological data (e.g., vital signs) associated with the patient.

[0030] The main display (e.g., I / O 54) can be configured to display one or more user interfaces for displaying operating parameters or other data associated with the modules 16, 18, 20, 22 and / or physiological characteristics associated with the patient. The main display can include multiple user interfaces, where each individual user interface graphically displays information for a corresponding one of the medication modules, including information also displayed on the corresponding module display. In some embodiments, the control module 14 includes a communication module (including, for example, an antenna) that is configured to communicate wirelessly with the controller or with a network.

[0031] refer to Figure 1, when the drug delivery modules 16, 18, 20, 22 initiate an infusion of a drug to a patient, the control module 14 is configured to create and manage an infusion session within the memory of the control module (or associated module). For purposes of the present disclosure, an infusion session includes state information of the PCU 12, its control module 14, and / or its associated modules, which is recorded and saved to the memory during a specific time period. The state information includes, but is not limited to, a record of parameter values ​​utilized by the PCU, its control modules, and / or its associated modules during a period of time, and / or a record of physiological data collected during the period of time. During the infusion, physiological data associated with the patient is recorded in the session, and operating parameter values ​​and any modifications to the operating parameters of the PCU, its control modules, and / or modules are also recorded in the session.

[0032] If not logged into PCU 12, the clinician can approach a sensor (e.g., 54, 60) on PCU 12 to scan his or her badge, and the PCU can attempt to authenticate the clinician by sending the clinician's scanned identification to server 30. The clinician's badge can contain a radio frequency identification device (RFID) that is read by a scanner integrated with the PCU or a portable scanner associated with the PCU. The clinician can scan his or her badge at the control module 14 to identify and authorize the clinician to initiate the administration of the drug. Once the clinician is associated with the PCU and / or one or more modules, the clinician's identity is associated with the session. The same applies to patients. The clinician can use a portable scanner to scan the patient's wristband, or use a sensor on the PCU 14 (or its control module) to associate the patient with the PCU and / or one or more modules (and the session).

[0033] The control unit 14 of the PCU 12 is configured to generate and display (e.g., in a display 201) a graphical representation of the infusion session that includes a graphical visualization of all parameters of the infusion during the session and any modifications to the parameters, as well as physiological data obtained during the session. The graphical representation may include pseudo-identifiers for unknown data until such data is replaced with known identifiers. At this point, the graphical representation is displayed using the known patient identifiers.

[0034] Figure 2A 2 is a conceptual diagram illustrating an example system architecture including an example resource management unit according to aspects of the subject technology. In the depicted example, the care delivery system 200 includes an intelligent control module (ICM) 202. The ICM 202 (or infusion device control system) provides direct control of connected medical devices to help clinicians provide more centralized control and management of the devices.

[0035] The ICM 202 provides a modular interface system through which various biometric sensors 216 used in a medical environment can be connected in a common manner to facilitate control of connected medical devices. For example, the biometric sensors 216 can include one or more of a heart rate monitor, an oxygen sensor, and an intravenous (IV) flow rate monitor, all of which can be connected to the ICM 202 to facilitate centralized control of one or more infusion devices in addition to input by a clinician. As will be further described, the ICM 202 can be connected to a bispectral index (BIS) sensor 216 to assess the depth of anesthesia during surgery.

[0036] According to various embodiments, the ICM 202 is a stand-alone device, separate from the infusion device(s). In some embodiments, the ICM 202 is a mobile device having a form factor similar to a tablet computer. The ICM 202 can be portable and have a rechargeable power source (e.g., a battery). In some embodiments, the ICM 202 can be configured to be integrated with the infusion device 214 (e.g., share power with the infusion device 214). The ICM 202 can also be connected to a server and / or cloud-based system for further data entry, data coordination, and reporting. Examples of cloud-based systems include a cloud-based drug information database 224 (or prescription set) and a hospital network 226 including an electronic medical record (EMR) system or database 228.

[0037] The hospital network 226 may also include a code team 230 system and / or network that responds to code alerts. The code team 230 includes specialists 232 (human or AI), pharmacies 234, biomedical technicians 236 (human or AI), crisis management resources 242, supply infrastructure 240, and additional resources 238 for responding to requests made to the code team 230.

[0038] In the depicted example, the ICM 202 includes a control unit 208, which includes one or more processors and / or control software and / or control algorithms. In some embodiments, the control unit 208 includes connection circuits. In some embodiments, the control unit 208 includes software to enable closed-loop and semi-closed-loop control capabilities for one or more medical devices at the point of use. In some embodiments, the ICM 202 provides an external interface, such as a user interface 204, for interaction between an IV infusion pump 214 and one or more different physiological or biometric sensors 216, and for providing input parameters that can be used to control the titration of an IV infusion of a medication to a patient.

[0039] In some embodiments, the closed loop system provides control of the IV infusion of medication by the infusion device 214 based on feedback provided by the biometric sensor 216 used to monitor the treatment being performed. In the event that the IV medication is not delivered due to an abnormal condition such as the IV line being blocked, leaking, or not connected to the patient, the sensor 216 will indicate that the patient is not responding to the treatment. The subject technology provides feedback (e.g., notifications or alarms) to the clinician to alert the clinician to possible fault conditions that should be resolved before a critical situation occurs in some cases.

[0040] The ICM 202 can be combined with control software (including, for example, one or more algorithms in unit 208) that can be customized for specific or general medical treatments. The ICM 202 can receive infusion status information from the infusion device 214. The infusion status information can include, for example, the identification of the drug, the flow rate at which the drug is administered to the patient by the infusion device, VTBI (volume to be infused), delivery duration, upstream or downstream pressure, and the like. Although the infusion device 214 can have its own safety system, the ICM 202 can be pre-programmed to determine safety events, such as events specific to a particular procedure. The ICM 202 can determine that a safety event may occur within a predetermined time period based on sensor data from (one or more) sensors 216 and infusion status information (e.g., programmed into the ICM or determined by an AI based on a training model of the procedure being performed).

[0041] A closed-loop control system as described herein generally refers to a system that does not rely on external manual input to deliver therapy. Once configured, the closed-loop system can provide therapy autonomously, receive feedback from one or more sensors 216, and automatically adjust therapy as needed based on the feedback. For example, the ICM 202 can determine an expected trend of a physiological characteristic during a predetermined time period during the administration of a medication based on sensor data over a previous time period, the dosage of the medication provided to the patient, and one or more physical parameters of the patient. The ICM 202 can then cause the infusion device to adjust the dosage of the medication so that the physiological characteristic follows the expected trend over the predetermined time period.

[0042] The ICM provides several advantages as a unit separate from the medical device. For example, the advancement of sensors (e.g., biometric sensors 216) can be much faster than the development of infusion pump systems (e.g., pump devices 214), and therefore the control system can adapt to these changes more quickly. The control algorithm may need to be updated to address changes in treatment methods, available drugs, and patient physiology. For this reason, it may be desirable to have the algorithm reside in a component different from the pump system in order to adapt to more frequent changes. In addition, machine learning and artificial intelligence can account for patient changes associated with physiological characteristics such as age, genetics, health history, and other characteristics and environmental factors. Systems that include such capabilities may involve large databases and complex programs, requiring powerful microprocessors and data storage capabilities to perform the required timely and accurate calculations required. These systems are generally not able to run on systems that currently only have IV pumps available, but can reside on servers 30 or other cloud-based systems that can be accessed from the ICM.

[0043] In addition, the ICM 202 of the subject technology can be applicable to various pump systems and sensor inputs. The ICM 202 can also be configured to add wireless, Bluetooth, and LAN connections to pump systems that are currently unavailable. For example, FIG. 2 shows an ICM 202 having a wireless connection 212 for communicating with a network system 244 at a hospital. Adding such communications to a pump system 214 can enable other capabilities, such as remote monitoring and control of an infusion pump, and facilitate access to an EMR 228. Therefore, by integrating electrical and processing components that are separate from the pump, the subject technology facilitates the integration of additional capabilities without modifying the housing and electronics of the pump. Separating the physiological sensing and control system from the infusion pump system can further provide a more streamlined regulatory approval process.

[0044] According to various embodiments, the ICM 202 facilitates separation of the control software 208 from the embedded firmware 206 and sensors of the pump, which can facilitate a scalable and rapidly configurable system to provide closed-loop control of medical treatment. In addition, the ICM 202 can be configured to operate with multiple sensors via electrical connectors and / or wireless communications. The ICM 202 can include one or more microprocessors and algorithms to provide signal conditioning and / or conversion of sensor signals to appropriate physiological characteristics of the connected medical device. The parameters can then be used in the control algorithm to provide control to, for example, an infusion pump to deliver the necessary medication or fluid to obtain the desired clinical outcome. As used herein, "connecting" a device or "operably connecting" a device can include establishing a physical (e.g., wired) or virtual (e.g., wireless) connection between the devices.

[0045] The user interface 204 of the ICM 202 may include a display module or a touch-sensitive display module configured to provide a user interface for displaying information related to the patient's physiological state and the system control state. In some embodiments, the user interface 204 includes a circuit within the ICM 202 housing that provides display information to an external display device. An example of such an external display device includes a multi-parameter monitor (MPM) 210. The MPM 210 can, for example, display various vital statistics (e.g., electrocardiogram (ECG), blood oxygen saturation level (SpO2)) of a patient in an operating room so that the vital statistics are visible to clinicians in the room (e.g., all clinicians). The display on the ICM 202 can be mirrored via an associated MPM 210 to provide information to devices connected to the MPM 210 and / or clinicians involved in the treatment.

[0046] The ability of ICM 202 to connect to another display (e.g., MPM 210) provides modular scalability. For example, in some use cases, a wider user interface may be beneficial. A wider user interface may include the display of data and graphics, for which a larger high-resolution display may be used. Some use cases may benefit from a display with minimal information and a corresponding user interface to support such a configuration. A smaller, space-saving and / or lower-cost locally connected display may then be used.

[0047] According to various embodiments, the ICM 202 includes a Resource Management Unit (RMU) 206. The RMU 206 stores protocol information (e.g., information about processes and steps associated with treatments and patients) so that the information is easily accessible in the ICM 202. In some embodiments, the RMU 206 provides information to the user interface 204, thereby allowing the system to more efficiently (e.g., using fewer device resources (such as memory, power, processing cycles, user interface area, etc.) present and navigate related information (e.g., using touch input on a touch screen). According to various embodiments, the RMU 206 guides the user to the sequence of steps and required information at the appropriate time, thereby avoiding spending resources on information that is inopportune or irrelevant to the current detected condition.

[0048] In some embodiments, the ICM 202 can access additional resources through the communication capabilities of the RMU 206. For example, the RMU 206 can access additional resources related to drug information and dosage calculations from internal or remote storage (e.g., from the drug information database 224, from a centralized). In some embodiments, when a specific drug is to be administered, the RMU 206 can cause the user interface 204 and / or other operably connected user devices to display a patient's dosage calculator. In some embodiments, the dosage calculator is a weight-based calculator that takes into account the patient's weight (e.g., the patient's weight is provided to the ICM 202 by manual input by a clinician or based on information received from the EHR database 228). In some embodiments, the calculation of weight-based drugs can be easily accessed through the user interface 204 or one or more user devices that are communicatively connected to the ICM 202. The patient's electronic health record can also be easily accessed directly through the ICM 202 to provide key health and allergy information to the clinician. Additional resources related to drug information that the ICM 202 accesses via the RMU 206 may include information about the compatibility of drugs that the patient is prescribed to receive. In some embodiments, the RMU 206 can cause the user interface 204 and / or other user device to display mixing ratio instructions. For example, the RMU 206 can cause the user interface 204 to specify the current or programmed flow rate of the first fluid from the syringe pump 220, the current or programmed flow rate of the second fluid from the syringe pump 222, and the current or programmed flow rate of the infusion fluid from the infusion bag 218, so as to administer the appropriate mixture to the patient during the infusion.

[0049] In one example, the RMU 206 can access additional resources by allowing the clinician to electronically deliver or make a pharmacy request to the pharmacy 234 via the ICM 202. The RMU 206 can cause the user interface 204 to display controls that allow the clinician to summon one or more specialists for a consultation (e.g., virtually using a camera communicatively connected to the ICM 202 and / or data from the biometric sensor 216; or requesting an in-person consultation at the patient's location). In some embodiments, the RMU 206 can connect the clinician to the AI. The RMU 206 can cause the user interface 204 to display controls that allow the clinician to send a code alert so that additional resources and personnel (e.g., a person or AI) can respond to the medical problem. The RMU 206 can cause the user interface 204 to display controls for equipment requests or other resources needed for the patient. Thus, in the event that a hospital code needs to be issued, the clinician can simply use the RMU 206 to bring up a list, which will then present the appropriate code that can be used for the specific request sent via the hospital network 244. In some implementations, the user interface may include a control element that, when activated, sends a control message to a device in communication with the RMU 206 to request a resource.

[0050] Figure 2B The present invention shows aspects of the subject technology. Figure 2A FIG. 1 is an exemplary system architecture in which multiple infusion sets provide medications to a single expansion kit. In the depicted example, two infusion pumps 220 and 222 are connected to a patient control unit 214 of an infusion device 214. The pumps 220 and 222 are connected to one or more infusion sets, such as a multi-connector set 250 (e.g., a Y-connector), which then provide a combination of medications to the patient via an IV administration line connected to a single intravenous cannula.

[0051] The depicted multi-connector kit 250 is connected to a first syringe containing propofol and a second syringe 222 that administers remifentanil. A first flow meter 252 (e.g., inserted into the line) monitors the flow of the drug from the first syringe 220, and a second flow meter 254 monitors the flow of the drug from the second syringe 222. The third connector of the multi-connector kit 250 is shown connected to a third pump 223, which administers a diluent such as saline. In some embodiments, multiple drugs can flow into a single expansion kit, and each pump 220, 222, 223 can be electronically controlled by the patient control unit 215 to provide a precise mixture for uniform administration to the patient.

[0052] The flow sensors 252, 254 may be used to provide verification of drug delivery. This provides the benefit of additional feedback to the control software 208, which may be used to better control the administration of the drug and help reduce usage. It will also provide record keeping verification to prevent drug diversion. The flow sensors may be thermal or other electromechanical types that would be directly connected to the ICM 202.

[0053] The system uses two syringe pumps to administer medications, each of which controls a specific medication. Anesthesiologists typically use a multi-lumen or Y-shaped connector to allow different anesthetics to be infused through a single intravenous cannula (with or without the infusion of other intravenous fluids). According to various embodiments, the RMU 206 stores operating procedures and program workflows for operating procedures, including the order in which medications are used. The ICM 202 is connected to the infusion device 214 via the patient control unit 215 and communicates electronically with the patient control unit to monitor the order of operations programmed into multiple pumps during the procedure, including parameter changes (e.g., flow rate, VTBI, etc.). The flow rate can vary independently of the clinician's actions.

[0054] In some embodiments, the ICM 202 can monitor for blockages across multiple pump channels and adjust pump operation of blocked channels and / or unblocked channels to ensure patient and pump safety. In the depicted example, the flow rate from each pump 220, 222 is provided by the flow sensors 252, 254 to the ICM 202, which then acts as a buffer between the flow sensors and other sensors 216 and the patient control unit 215. In this way, the ICM 202 intercepts signals that would normally be provided directly to the patient control unit 215, so that the ICM 202 can act as a watchdog to detect flow events and can adjust the flow rate and / or sensor data before providing the flow and / or sensor data to the patient control unit 215 based on the stored operating program and the data received from the connected sensors 216. In this regard, the patient control unit 215 does not need to be modified and continues to operate according to its current programming, while the ICM 202 can be used by the clinician to make adjustments and / or expand the functionality of the infusion device 214.

[0055] When the first pump stops to change the drug container, the ICM 202 can cause the second pump to change operation, or can reorder the order of pump operation between multiple pumps so that the patient is not adversely affected. For example, if one pump is close to empty and the second pump is operating at a high flow rate, the system can slow down the high flow rate pump to avoid a bolus delivered by the high flow rate pump. In some embodiments, the ICM 202 can be adjusted based on received parameters such as the type or size of the infusion set connected, the length of the infusion line, the type of treatment being implemented, the type of medication, the head height, the flow rate (e.g., from sensors 252, 254), and / or the like. In some embodiments, sensors can be included on the line to detect the type of substance flowing through the kit (e.g., similar to the flow meter setup shown in the above figure). In this way, the ICM 202 can perform rapid results to confirm that the line is connected to the correct medication, for example - by performing a pH test, conductivity, spectral, optical, acoustic or other measurable properties on the fluid. The ICM 202 may prevent an infusion device or other system component from operating if an approved drug or infusion set is not detected, or until an override instruction is received from a clinician.

[0056] Figure 3A is a first example conceptual diagram of managing multiple infusion pumps using an intelligent control module in a closed-loop or semi-closed-loop environment in accordance with various aspects of the subject technology. In the depicted example, the ICM 202 includes a control algorithm 302 and a multi-pump control watchdog algorithm 304. In this regard, the ICM 202 is operably connected to each pump p1-pn (e.g., through one or more corresponding patient control units 215) and is configured to control each pump by adjusting the internal operating parameters of the pump. As depicted, the ICM 202 (and / or the algorithm) monitors real-time infusion information 306, such as operating parameters, container type, setup information, infusion status (e.g., container status), etc., and based on this information, readjusts the control parameters as needed to provide therapy to the patient. Although Figure 3A Not shown, the ICM 202 may additionally or alternatively receive real-time sensor information associated with the patient to re-adjust control parameters required to provide therapy. According to various embodiments, a clinician or other system (e.g., an EMR system) may provide additional parameters 308 to the ICM 202 to facilitate monitoring and / or control of a connected pump.

[0057] As used herein, "real time" may refer to the availability of processing at or near the time when the associated item is generated or detected. The algorithm 302 may be stored locally in the memory of the ICM 202, or in some embodiments, dynamically downloaded from the server 30 and / or database 37. In some embodiments, the algorithm 302 may include input values ​​derived from monitoring or laboratory results, etc. The algorithm 302 may use advanced processing capabilities, such as artificial intelligence, machine learning, and neural network processing.

[0058] As about Figure 1 As described, the infusion device 214 may include a modular infusion platform that can be expanded to handle more than one type of drug delivery to a patient using multiple drug delivery modules (e.g., modules 16, 18, 20, 22, 220, 222). Different patients require different levels of treatment, as well as different parameters treated by different devices. Each individual infusion module and different types of infusion devices can usually operate differently, resulting in a variety of parameter changes (and docking possibilities), which may confuse or distract clinicians during infusion and other drug delivery procedures. During surgery and in situations where it is difficult to use the infusion device directly, precise control and coordination of the device may also be difficult. Failure to maintain control of the device may increase the patient's health risks. For example, under manual control, the amount of time to provide the patient with a drug at a level within the desired range may fluctuate based on, for example, the clinician's attention. The length of time that the patient is outside the desired range will have an impact on the program, the patient, recovery, and the resources used to administer the treatment. In addition, some treatments require repeated work steps, which may be prone to errors or complacency, which may lead to adverse events.

[0059] refer to Figure 2A and Figure 3A In operation, the ICM 202 is operably connected to a plurality of medical devices, and upon identification of a medical device, the user interface software determines one or more predetermined treatments associated with the medical device. For example, the software may receive an identifier of the medical device upon connection to an infusion device 214, and then query the database 37 (e.g., via the network 10) for available treatments associated with the infusion device. A selection control may then present the treatment to the clinician for selection. When a selection of a treatment is made, the system determines which sensor devices 204 associated with the treatment are operably connected to the ICM 202, and identifies and configures one or more corresponding algorithms 302, 304 for operation of the connected medical device based on real-time data received from the connected one or more sensors 216.

[0060] Each pump p1-pn is configured to accept programming from the ICM 202. In this manner, a user of the ICM 202 can directly program a corresponding pump by selecting a pump via the user interface 204 and selecting one or more parameters to be set or adjusted. The ICM 202 can then provide the parameters to the pump, and the pump modifies its operation accordingly. According to various embodiments, in response to receiving the infusion-related information 306, the ICM 202 operating using the watchdog algorithm 304 can automatically adjust the pump parameters X of the corresponding pumps p1-pn. p1 -X pn .

[0061] In some embodiments, the control parameter can be set by the clinician and remain stable as long as treatment is proceeding as planned and there are no unexpected results (e.g., out-of-bounds readings). The control parameter x is received from the closed-loop algorithm and passed unchanged to each corresponding pump, or adjusted and the same adjusted value is passed to each pump.

[0062] In some embodiments, the watchdog algorithm 304 can be configured to convert control parameters for a single treatment into control parameters for multiple treatments. For example, the control algorithm 302 can be configured to control the administration of a single drug from a single pump and can provide control parameters X for administering a single drug X to a patient. The watchdog algorithm 304 can be configured to control the administration of multiple drugs based on the parameters of drug X. In this regard, the watchdog algorithm 304 can convert control parameters x into control parameters x. p1 , x p2 ,...x pn and pass the control parameters to the corresponding pumps p1-pn. Based on the treatment configuration selected by the clinician via the user interface 204, the algorithm 304 can be configured to change a given parameter by a given amount for each pump. For example, each drug for each pump can be assigned a weight based on the pharmacokinetic profile of the drug provided by the pump, and the algorithm 304 can provide a weight to each pump when providing the parameter x p1 , x p2 ,...x pn A predetermined weighted adjustment of the parameter x is previously performed for each pump.

[0063] As an example, the control loop algorithm 302 may be configured to maintain a patient in an anesthetized state using propofol. However, the clinician may choose to administer propofol and remifentanil to the patient. The watchdog algorithm 304 implemented by the ICM 202 may be configured to control two pumps to administer propofol and remifentanil (e.g., for propofol) based on a single control parameter x provided by the control loop algorithm 302. In this regard, the ICM 202 (and the watchdog algorithm 304) may be used to repurpose the control loop algorithm 302 without changing the original algorithm.

[0064] According to various embodiments, the ICM 202 includes alarm software. In some cases, a malfunction, failure, or need for attention at a medical device or sensor connected to the ICM 202 may generate one or more alarms. In situations where multiple devices are connected to the ICM, alarms that may not require immediate attention (e.g., a warning that a syringe is nearly empty) may be employed, and a hierarchy of information may be employed that provides information about what needs to be addressed. Notifications may be provided by means other than audio alarms, which may be distracting to all clinicians involved in the procedure.

[0065] The algorithm 302 can also monitor all connected devices to predict potential failures before they occur, so that clinicians can take timely action on them before a situation that requires immediate action occurs. In some embodiments, the algorithm 302 can combine information from various sensors to identify problems or the possibility of problems. For example, in the case of anesthesia, if the patient's bispectral index sensor 216 (BIS) shows an increase in BIS values ​​and changes in hemodynamic parameters, and the flow sensor 250 and / or one or more sensors in the infusion device 214 indicate that the increase in BIS values ​​is inversely proportional to the administration of the drug being infused, then the ICM 202 can indicate that the patient is not responding to receiving the drug as expected. In such an embodiment, the level of potential failures can be displayed on the ICM 202, thereby providing guidance to clinicians on what steps need to be taken to make the treatment safe and meet the requirements (e.g., corresponding to the target treatment parameters). For example, the fault code on the user interface 204 can appear together with an indication of one or more potential causes. The ICM 202 can also display a fault checklist that shows potential checks to be performed, such as whether the IV line is connected, unblocked, or whether the sensor is connected.

[0066] As another example, anesthesia may require the administration of a predetermined amount of medication to achieve the desired goals of hypnosis, immobility, and reflex suppression during surgery. It may be administered as a combination of a hypnotic and an opioid, with the anesthesiologist manually titrating the dose or infusion rate of the two drugs to provide the optimal balance. Using the bispectral index sensor 216 (BIS), the ICM 202 can monitor the depth of anesthesia and remotely control the infusion device to administer the appropriate amount of IV medication while preventing loss of consciousness or excessive depth of anesthesia during medical treatment, thereby improving patient outcomes. As previously described, the ICM 202, when configured, can adjust a single pump solution to a multi-pump solution to deliver a hypnotic and an opioid based on a predetermined algorithm for delivering one of the drugs.

[0067] As another example, the ICM 202 can be connected to a sensor configured as a blood glucose monitor and maintain the patient's blood glucose by controlling the administration of insulin and / or glucose solutions from an infusion device based on intelligent modeling and continuous blood glucose measurements. Blood glucose (BG) disorders, such as stress-induced hypoglycemia and hyperglycemia, can be common complications for ICU patients. In addition, patients with type 1 and type 2 diabetes may be susceptible to hyperglycemia, as well as severe hypoglycemia due to overcorrection of insulin. In one example, IV infusion of insulin and / or glucose can be controlled by the ICM 202 using a closed-loop configuration with input from continuous BG measurements to maintain BG levels within a desired range.

[0068] Figure 3B is a second example conceptual diagram of managing an infusion pump using an intelligent control module in a closed-loop or semi-closed-loop environment in accordance with various aspects of the subject technology. In the depicted example, control parameters provided to a connected pump are dynamically adjusted based on real-time therapy information provided by the pump.

[0069] As previously described, the ICM 202 can be configured in a feedback loop with multiple pumps. In this regard, the pumps p1-pn are configured to accept programming from the ICM 202 while providing infusion information as a form of feedback to the ICM 202. According to various embodiments, the algorithm 302 can operate the pumps in a closed loop based on the infusion information 306 received from the pumps and the sensor information provided by the connected sensors 216, the treatment target control parameters 308, and / or the patient or drug information provided by the clinician via the user interface 204 or from an external system such as a hospital information system 30 (e.g., an EMR server).

[0070] In the depicted embodiment, the algorithm 302 is a closed-loop algorithm. The closed-loop algorithm 302 may be loaded on the ICM 202, or control parameters may be provided from an external system such as the hospital information system 30. In this regard, the closed-loop algorithm 302 may be a static algorithm, and the ICM 202 (including, for example, a watchdog algorithm) may be configured between the closed-loop algorithm 302 and the pumps it controls. In operation, the ICM 202 intercepts commands provided by the closed-loop algorithm 302 to one or more pumps p1-pn, and controls the pumps based on the commands and real-time operating parameters and infusion status information 306 and treatment target control parameters 308 from the pumps. The ICM 202 modifies the intercepted commands (e.g., based on the real-time operating parameters and infusion status information 306 and treatment target control parameters 308) to control the therapeutic effect of the therapy provided by the pumps without input to the closed-loop algorithm.

[0071] In the depicted example, the ICM 202 receives a control parameter x from a closed-loop algorithm 302. Based on the received real-time operating parameter and infusion status information 306 and the therapeutic target control parameter 308, the ICM 202 determines that rather than passing the control parameter to the pump(s), the control parameter should be adjusted differently for each pump. For example, the ICM 202 may determine that pump n is blocked, or that the drug container is empty. Therefore, the ICM 202 may determine that the control parameter value should be decreased before being sent to the first pump p1 and should be increased before being sent to the second pump p2. No additional parameters may be sent to pump n, or pump n may be instructed to terminate infusion, enter standby mode, power off, and / or provide an alarm.

[0072] In another example, the therapy provided by the pumps can be an induced anesthetic state, and the sensor information received by the ICM 202 can include EEG activity of the patient to whom the first and second therapies are provided (e.g., from the sensor 216). The first pump p1 can administer a first anesthetic drug, and the second pump p2 can administer a second anesthetic drug. In response to the EEG activity (and other infusion information 306 or target parameters 308), the ICM 202 (by programming the pumps) can cause a decrease in the flow of the first anesthetic drug while causing an increase in the flow of the second anesthetic drug. A third drug or fluid provided by a third pump can be terminated, not adjusted, or control parameters can not be sent to the third pump.

[0073] Figure 3C302 is a third example conceptual diagram of managing an infusion pump using an intelligent control module in a closed-loop or semi-closed-loop environment according to various aspects of the subject technology. In some embodiments, the watchdog algorithm 304 may not modify the control parameters received from the closed-loop algorithm, but may give instructions to the closed-loop algorithm that adjustments are required. The instructions may include a code or other information indicating an event that requires adjustment (e.g., occlusion, alarm, patient injury, etc.). The instructions may include information identifying the source of the event (e.g., which pump, which drug, etc.). In some embodiments, the instructions may include a treatment goal that is violated. In some embodiments, the instructions may include a proposed device-specific (e.g., a rate for a specific pump or drug) or generally applicable to treatment (e.g., total infusion volume). The algorithm 302 may be configured to receive adjustments, for example, in the form of parameter value changes. If the watchdog algorithm 304 determines that pump n is blocked or the corresponding drug container is empty, the watchdog algorithm may not make changes, but warn the algorithm of an error or deviation condition. Then, the control algorithm 302 makes adjustments, and the watchdog passes the adjusted parameters to each pump. As mentioned previously, the watchdog algorithm can make static or weighted adjustments before forwarding the parameters to the pump.

[0074] Figure 4 An example process 440 for managing multiple infusion pumps using an intelligent control system in a closed-loop or semi-closed-loop environment in accordance with various aspects of the subject technology is described. Figures 1 to 3C The various blocks of the example process 440 and the components and / or processes described herein are described. One or more of the blocks of the process 400 can be implemented by a control device such as, for example, the ICM 202 or its components, the interface 14, or one or more associated computing devices. As previously described, the example process 400 can operate under the control of an artificial intelligence, which can analyze the sensor data and make any decisions on behalf of the clinician in the example process 400. If a hard decision cannot be made (e.g., certain thresholds are not met), the ICM 202 (including, for example, a processor such as the RMU 206) can suggest a soft decision to the clinician, who can then confirm, reject, or change the selection to treat the patient.

[0075] According to the depicted example process 400, the ICM 202 provides an infusion communication system for managing multiple infusion pumps in a closed-loop or semi-closed-loop environment. The watchdog control algorithm 304 of the ICM 202 intercepts a first command (402) provided by the closed-loop control algorithm 302 to a first infusion pump. As previously described, the first command can be configured to adjust a first therapy provided by the first infusion pump based on the sensor measurement provided to the closed-loop control algorithm 302.

[0076] For example, the closed-loop control algorithm 302 can be configured to automatically adjust one or more infusion devices and / or pumps based on information such as sensor measurements provided by one or more sensors 216 associated with the patient, sensors associated with the pump(s) (e.g., flow sensors 250, 252), and infusion information provided by the infusion pump(s). For example, the algorithm 302 can be configured to maintain the patient in a particular therapeutic state (e.g., a hypnotic or sleep state) by controlling the amount of medication delivered by the pump(s), and dynamically adjust the amount based on monitoring the patient with the sensor 216 to obtain an indication of how the patient is responding to the medication and / or how stable the patient is within the therapeutic state.

[0077] In the depicted process 400, the ICM 202 receives a treatment target control parameter 308 to evaluate and modify a first treatment (404) based on real-time parameters of a second treatment provided by a second infusion pump. As previously described, the first treatment may include a first administration of a first drug to the patient, and the second treatment may include a second administration of a second drug to the patient. The treatment target control parameter 308 may be an operating range for sensor measurements (e.g., a bispectral index range) or a target for sensor measurements. For example, the ICM 202 may control the pump, including modifying the control parameters (x1-xn) received from the closed-loop algorithm 302 to maintain the patient in a state consistent with the target. In this regard, the target control parameter may be a threshold, such as a flow rate or pressure threshold associated with one or more of the connected pumps, or may be an upper or lower limit on a parameter.

[0078] The ICM 202 receives the infusion information 306, including real-time operating parameters and infusion status information associated with the first and second infusion pumps (406). According to various embodiments, the infusion information may be received by the control loop algorithm 302 or the watchdog algorithm 304, or both.

[0079] The ICM 202 modifies the intercepted first command based on the infusion information 306 (e.g., real-time operating parameters and infusion status information) and the treatment target control parameters 308 to control the treatment effects of the first and second treatments without input to the closed-loop algorithm (408). In this example, although the closed-loop algorithm 302 can receive feedback from various pumps and sensors, the algorithm does not receive any other extraneous input from the ICM 202 related to or associated with the modification. In other words, in some embodiments, the modification is performed without knowledge of and independently of the closed-loop algorithm 302.

[0080] In some embodiments, the therapeutic effect is a predetermined anesthetic hypnotic state, and the sensor measurements include electroencephalographic activity of the patient to whom the first and second therapies are provided. In some embodiments, the therapeutic effect includes a stabilized cardiac output, and the sensor measurements include a measure of the patient's cardiac output.

[0081] In one example, the ICM 202 receives an indication that a container for a second medication is nearly empty and the second infusion pump is operating at a high flow rate. In this regard, the ICM 202 can cause the second infusion pump to slow the flow rate of the second administration in response to the indication. In this regard, the patient can be prevented from receiving a bolus of the second medication when the first medication is empty.

[0082] In another example, the ICM 202 monitors commands sent by the closed-loop control algorithm to the first and second infusion pumps. Based on the monitoring, the ICM 202 intercepts the second command before or at the same time as the first command is intercepted, and determines that the first command should be processed before the second command to control the therapeutic effect. In this example, the ICM 202 delays providing the second command to the second infusion pump until the first command is conditioned and provided to the first infusion pump.

[0083] In another example, the first treatment includes a first administration of a first anesthetic drug and the second treatment includes a second administration of a second anesthetic drug. The ICM 202 determines a decrease in the flow of the second administration and, in response, increases the flow of the first administration based on the decrease in the flow of the second administration to maintain the patient in a predetermined hypnotic anesthetic state. As described in other embodiments, the increase is not provided to the closed-loop control algorithm.

[0084] In some embodiments, the ICM 202 (optionally) receives an indication that the first therapy delivery failed (410). For example, the indication of the delivery failure can be received based on the infusion status information. For example, the pump can provide a fault status code as part of the status information it reports to the ICM 202 (and, for example, other hospital systems).

[0085] ICM 202 (optionally) modifies the intercepted first command in response to the indication of the delivery failure without providing the modification to the closed-loop control algorithm (412).

[0086] In some embodiments, the ICM 202 detects the type of fluid flowing through the infusion line via a sensor 250, 252 operably connected to the infusion line of the first treatment, and the ICM 202 prevents the first infusion pump from providing the first treatment or the second infusion pump from providing the second treatment based on intercepting commands sent to the first and second infusion pumps 220, 222 until the detected fluid type is confirmed for use with the first and second treatments.

[0087] In some embodiments, the ICM 202 identifies an infusion set for a first therapy (e.g., by being scanned by a scanner or detected by an RFID) and, based on intercepting commands sent to the first and second infusion pumps, prevents the first infusion pump from providing the first therapy or the second infusion pump from providing the second therapy until the infusion set is confirmed to be used for the first and second therapies.

[0088] In some embodiments, based on infusion information associated with the second infusion pump, the ICM 202 determines that the infusion line of the second infusion pump is blocked, and modifies the intercepted first command so that the flow rate of the first infusion pump is adjusted, without providing the adjusted flow rate to the closed-loop algorithm.

[0089] Many of the above-described example steps of processes 400 and 440 and related features and applications may also be implemented as software processes designated as sets of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium) and may be run automatically (e.g., without user intervention). When these instructions are run by one or more processing units (e.g., one or more processors, cores of processors, or other processing units), they cause the processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, and the like. Computer-readable media do not include carrier waves and electronic signals transmitted over wireless or wired connections.

[0090] Where appropriate, the term "software" is intended to include firmware residing in a read-only memory or an application program stored in a magnetic storage device that can be read into the memory for processing by a processor. In addition, in some embodiments, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while maintaining different software aspects of the subject disclosure. In some embodiments, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that implement the software aspects described herein together are within the scope of the subject disclosure. In some embodiments, when the software programs are installed to operate on one or more electronic systems, these software programs define one or more specific machine implementations of the operations that run and execute the software programs.

[0091] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program may be deployed to run on one computer or on multiple computers located at one site or distributed over multiple sites and interconnected by a communications network.

[0092] Figure 5 is a conceptual diagram of an example electronic system 500 for managing multiple infusion pumps using an intelligent control system in a closed-loop or semi-closed-loop environment according to aspects of the subject technology. The electronic system 500 may be a system for executing Figures 1 to 4 A specially configured computing device that provides the components and software associated with one or more portions or steps of the process, including but not limited to the ICM 202, the information system server 30, the database 37, the computing hardware within the patient care device 12, or the remote device 32 (e.g., a mobile device). Figure 1-4 The electronic system 500 may be representative of the disclosure of the present invention. In this regard, the electronic system 500 may be a personal computer or mobile device specially configured for infusion, such as a smart phone, a tablet computer, a laptop computer, a PDA, an augmented reality device, a wearable device (such as a watch or wristband or glasses), or a combination thereof, or other touch screen or television having one or more processors embedded therein or coupled thereto, or any other type of computer-related electronic device with network connectivity.

[0093] The electronic system 500 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, the electronic system 500 includes a bus 508, a processing unit 512, a system memory 504, a read-only memory (ROM) 510, a permanent storage device 502, an input device interface 514, an output device interface 506, and one or more network interfaces 516. In some implementations, the electronic system 500 may include or be integrated with other computing devices or circuits for operation of the various components and processes previously described.

[0094] Bus 508 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 500. For example, bus 508 communicatively connects one or more processing units 512 with ROM 510, system memory 504, and permanent storage device 502.

[0095] From these various memory units, the one or more processing units 512 retrieve instructions to execute and data to process in order to perform the processes of the subject disclosure. In various implementations, the one or more processing units may be a single processor or a multi-core processor.

[0096] ROM 510 stores static data and instructions required by one or more processing units 512 and other modules of the electronic system. On the other hand, permanent storage device 502 is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 500 is turned off. Some embodiments of the subject disclosure use a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) as permanent storage device 502.

[0097] Other embodiments use removable storage devices (such as floppy disks, flash drives and their corresponding disk drives) as permanent storage devices 502. Like permanent storage devices 502, system memory 504 is a read-write memory device. However, unlike storage devices 502, system memory 504 is a volatile read-write memory, such as random access memory. System memory 504 stores some instructions and data that the processor needs at runtime. In some embodiments, the processes disclosed in the subject matter are stored in system memory 504, permanent storage devices 502, and / or ROM 510. From these various memory units, one or more processing units 512 retrieve instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0098] The bus 508 is also connected to an input device interface 514 and an output device interface 506, which are specifically configured to perform one or more of the described infusion features. The input device interface 514 enables a user to communicate information and select commands to the electronic system. Input devices used with the input device interface 514 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 506 enables, for example, the display of images generated by the electronic system 500. Output devices used with the output device interface 506 include, for example, a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include devices such as a touch screen, which function as both an input and an output device.

[0099] In addition, if Figure 5As shown, bus 508 also couples electronic system 500 to a network (not shown) via network interface 516. Network interface 516 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or a radio circuit for connecting to a wireless access point. Network interface 516 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a network (such as the Internet) that is part of a computer network (such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or an intranet) or a plurality of networks. Any or all components of electronic system 500 may be used in conjunction with the subject disclosure.

[0100] The functions described above can be implemented in computer software, firmware, or hardware. The technology can be implemented using one or more computer program products. Programmable processors and computers can be included in mobile devices or packaged as mobile devices. Processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuits. General and special computing devices and storage devices can be interconnected through a communication network.

[0101] Some embodiments include specially configured electronic components such as microprocessors, storage, and memory that store computer program instructions in machine-readable or computer-readable media (also referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, compact disk-read only (CD-ROM), compact disk-recordable (CD-R), compact disk-rewritable (CD-RW), read-only digital versatile disks (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable A computer readable medium may store a computer program executable by at least one processing unit and include multiple sets of instructions for performing various operations. Examples of computer programs or computer code include machine code (such as produced by a compiler), and files including higher-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0102] Although the above discussion primarily refers to a specifically configured microprocessor or multi-core processor executing software, some embodiments are performed by one or more similarly configured integrated circuits, such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). In some embodiments, such an integrated circuit runs instructions stored on the circuit itself.

[0103] As used in this specification and any claims of this application, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical devices configured to implement one or more of the described infusion features. These terms do not include people or groups of people. For the purposes of this specification, the terms display or being displayed means displayed on an electronic device. As used in the specification and any claims of this application, the terms "computer-readable medium" and "computer-readable media" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other transient signals.

[0104] To provide interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and the input from the user may be received in any form, including voice, speech, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0105] Embodiments of the subject matter described in this specification may be implemented in a computing system that includes a back-end component, such as a data server, or includes a middleware component, such as an application server, or includes a front-end component, such as a client computer with a graphical user interface or a web browser, through which a user can interact with the embodiment of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0106] A computing system may include a client and a server. The client and the server are usually remote from each other and may interact via a communication network. The relationship between the client and the server is due to the computer programs running on their respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., an HTML page) to a client device (e.g., to display data to a user interacting with the client device and to receive user input from a user interacting with the client device). Data generated at the client device (e.g., the result of the user interaction) may be received from the client device at the server.

[0107] Those skilled in the art will appreciate that various illustrative blocks, modules, elements, parts, methods and algorithms described herein can be implemented as electronic hardware, computer software or a combination of the two. In order to illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, parts, methods and algorithms are generally described above with regard to their functions. Whether this function is implemented as hardware or software depends on specific application and the design constraints imposed on the overall system. For each specific application, the described function can be implemented in different ways. Various parts and blocks can be arranged differently (for example, arranged in different orders, or partitioned in different ways), and all can not deviate from the scope of subject technology.

[0108] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The accompanying method claims present elements of the various steps in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0109] The subject technology as a description of the terms:

[0110] For convenience, various examples of aspects of the present disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the subject technology. The identification of the figures and reference numbers is provided below only as an example and for illustrative purposes, and the clauses are not limited by these identifications.

[0111] Item 1: A method comprising: an infusion device control system to: intercept a first command provided by a closed-loop control algorithm to a first infusion pump, the first command being configured to adjust the delivery of a first fluid by the first infusion pump based on sensor measurement results provided to the closed-loop control algorithm; receive a treatment target control parameter to modify the delivery of the first fluid based on real-time parameters of the delivery of a second fluid by a second infusion pump; receive real-time operating parameters and infusion status information for the first infusion pump and the second infusion pump; and modify the intercepted first command based on the real-time operating parameters and infusion status information and the treatment target control parameters to control the delivery of the first fluid and the second fluid.

[0112] Clause 2: The method of clause 1, further comprising: receiving an indication of a delivery failure of the first fluid based on the infusion status information; and modifying the intercepted first command in response to the indication of the delivery failure.

[0113] Clause 3: The method according to clause 1 or clause 2 further includes: receiving an indication that the container for the second fluid is nearly empty and the second infusion pump is operating at a high flow rate; and in response to the indication, causing the second infusion pump to slow down the flow rate of delivery of the second fluid.

[0114] Clause 4: The method according to any one of clauses 1-3 further includes: determining that the infusion line of the second infusion pump is blocked based on the infusion status information of the second infusion pump, and modifying the intercepted first command so that the flow rate of the first infusion pump is adjusted.

[0115] Clause 5: The method according to any one of clauses 1-4 further includes: monitoring, by the infusion communication system, commands sent by the closed-loop control algorithm to the first infusion pump and the second infusion pump; intercepting, by the infusion communication system based on the monitoring, the second command before or at the same time as intercepting the first command; determining that the first command should be processed before the second command to control the delivery of at least one of the first fluid and the second fluid; and delaying providing the second command to the second infusion pump until the first command is adjusted and provided to the first infusion pump.

[0116] Clause 6: A method according to any one of clauses 1-5, wherein the delivery of the first fluid and the second fluid produces an effect, wherein the effect is a predetermined anesthetic hypnotic state, and the sensor measurement results include electroencephalographic activity of the patient to whom the first fluid and the second fluid are delivered.

[0117] Clause 7: The method according to clause 6, wherein the first infusion pump is configured to deliver a first anesthetic drug and the second infusion pump is configured to deliver a second anesthetic drug, wherein the method further comprises: determining a reduction in the flow rate of delivery of the second anesthetic drug, and increasing the flow rate of delivery of the first anesthetic drug based on the reduction in the flow rate of delivery of the second anesthetic drug to maintain the patient in a predetermined anesthetic hypnotic state, wherein the increase in flow rate is not provided to the closed-loop control algorithm.

[0118] Clause 8: The method of any of clauses 1-7, wherein the delivery of the first fluid and the second fluid produces an effect, wherein the effect comprises a stabilized cardiac output, and the sensor measurement comprises a measure of the patient's cardiac output.

[0119] Clause 9: The method according to any one of clauses 1-8 further includes: detecting the type of the first fluid flowing through the infusion line via a sensor operably connected to the infusion line of the first fluid; preventing the first infusion pump from delivering the first fluid or the second infusion pump from delivering the second fluid based on intercepting commands sent to the first infusion pump and the second infusion pump by the infusion communication system until the detected type of the first fluid is confirmed to be scheduled for delivery by the first infusion pump and the second infusion pump.

[0120] Clause 10: The method according to any one of clauses 1-8 further includes: identifying an infusion set for the first fluid; and preventing the first infusion pump from delivering the first fluid or the second infusion pump from delivering the second fluid by the infusion communication system based on intercepting commands sent to the first infusion pump and the second infusion pump until the infusion set is confirmed to be scheduled for delivery by the first infusion pump and the second infusion pump.

[0121] Clause 11: An infusion device control system, comprising: an infusion device, which includes at least one of the first infusion pump and the second infusion pump; at least two connection ports, the at least two connection ports are configured to be communicatively connected to the infusion device and the sensor; and wherein the infusion device control system is configured to perform a method according to any one of clauses 1 to 10.

[0122] Clause 12: A system comprising: one or more processors; a memory device comprising non-transitory computer readable instructions, which when executed by the one or more processors cause the one or more processors to perform the method according to any one of clauses 1 to 10.

[0123] Clause 13: A memory device comprising non-transitory computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of clauses 1 to 10.

[0124] Item 14: A method comprising: an infusion device control system to: intercept a first command provided by a closed-loop control algorithm to a first infusion pump, the first command being configured to adjust a first therapy provided by the first infusion pump based on sensor measurements provided to the closed-loop control algorithm; receive a treatment target control parameter for modifying the first therapy based on real-time parameters of a second therapy provided by a second infusion pump; receive real-time operating parameters and infusion status information for the first infusion pump and the second infusion pump; and modify the intercepted first command based on the real-time operating parameters and infusion status information and the treatment target control parameters to control the therapeutic effects of the first therapy and the second therapy.

[0125] Clause 15: The method of clause 14, further comprising: receiving an indication of a delivery failure of the first therapy based on the infusion status information; and modifying the intercepted first command in response to the indication of the delivery failure.

[0126] Clause 16: The method of clause 14, wherein the first treatment comprises a first administration of a first drug to the patient and the second treatment comprises a second administration of a second drug to the patient, wherein the method further comprises: receiving an indication that a container for the second drug is nearly empty and the second infusion pump is operating at a high flow rate; and in response to the indication, causing the second infusion pump to slow the flow rate of the second administration.

[0127] Clause 17: The method according to Clause 14 further includes: determining that the infusion line of the second infusion pump is blocked based on the infusion status information of the second infusion pump, and modifying the intercepted first command so that the flow rate of the first infusion pump is adjusted.

[0128] Clause 18: The method according to Clause 14 further includes: monitoring, by the infusion communication system, commands sent by the closed-loop control algorithm to the first and second infusion pumps; intercepting, by the infusion communication system based on the monitoring, the second command before or at the same time as intercepting the first command; determining that the first command should be processed before the second command to control the therapeutic effect; and delaying providing the second command to the second infusion pump until the first command is adjusted and provided to the first infusion pump.

[0129] Clause 19: The method of clause 14, wherein the therapeutic effect is a predetermined anesthetic hypnotic state and the sensor measurements include electroencephalographic activity of a patient to whom the first therapy and the second therapy are provided.

[0130] Clause 20: A method according to clause 19, wherein the first treatment comprises a first administration of a first anesthetic drug and the second treatment comprises a second administration of a second anesthetic drug, wherein the method further comprises: determining a reduction in the flow of the second administration, and increasing the flow of the first administration based on the reduction in the flow of the second administration to maintain the patient in a predetermined anesthetic hypnotic state, wherein the increase in flow is not provided to the closed-loop control algorithm.

[0131] Clause 21: The method of any of clauses 14-20, wherein the treatment effect comprises a stabilized cardiac output, and the sensor measurement result comprises a measure of the patient's cardiac output.

[0132] Clause 22: The method of any of clauses 14-21, further comprising: detecting the type of fluid flowing through the infusion line via a sensor operably connected to the infusion line of the first treatment; preventing the first infusion pump from providing the first treatment or the second infusion pump from providing the second treatment based on intercepting commands sent to the first infusion pump and the second infusion pump by the infusion communication system until the detected fluid type is confirmed for the first treatment and the second treatment.

[0133] Clause 23: The method according to any one of clauses 14-21 further includes: identifying an infusion set for the first treatment; and preventing the first infusion pump from providing the first treatment or the second infusion pump from providing the second treatment based on intercepting commands sent to the first infusion pump and the second infusion pump by the infusion communication system until the infusion set is confirmed to be used for the first and second treatments.

[0134] Further considerations:

[0135] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The accompanying method claims present elements of the various steps in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0136] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. The preceding description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to be given the full scope consistent with the language claims, wherein unless specifically so stated, referring to an element in the singular is not intended to mean "one and only one", but "one or more". Unless otherwise specifically stated, the term "some" refers to one or more. Male pronouns (e.g., his) include female and neutral genders (e.g., her and its), and vice versa. Titles and subtitles, if any, are used only for convenience and do not limit the invention described herein.

[0137] As used herein, the term website may include any aspect of a website, including one or more web pages, one or more servers for hosting or storing web-related content, etc. Therefore, the term website can be used interchangeably with the terms web page and server. The predicates "configured to", "operable to", and "programmed to" do not imply any specific tangible or intangible modification of the subject, but are intended to be used interchangeably. For example, a processor being configured to monitor and control an operation or component may also mean that the processor is programmed to monitor and control an operation or the processor is operable to monitor and control an operation. Similarly, a processor being configured to execute code may be interpreted as the processor being programmed to execute code or being operable to execute code.

[0138] The term automatically, as used herein, may include being performed by a computer or machine without user intervention; for example, by being responsive to instructions of a predicate action by a computer or machine or other initiating mechanism. The word "exemplary" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0139] Phrases such as "aspects" do not mean that the aspect is essential to the subject technology, or that the aspect applies to all configurations of the subject technology. The disclosure related to the aspect can apply to all configurations, or one or more configurations. An aspect can provide one or more examples. Phrases such as aspects can refer to one or more aspects, and vice versa. Phrases such as "implementations" do not mean that such implementations are essential to the subject technology, or that such implementations are applicable to all configurations of the subject technology. The disclosure related to the implementations can apply to all implementations, or one or more implementations. An implementation can provide one or more examples. Phrases such as "implementations" can refer to one or more implementations, and vice versa. Phrases such as "configurations" do not mean that such configurations are essential to the subject technology, or that such configurations are applicable to all configurations of the subject technology. The disclosure related to the configurations can apply to all configurations, or one or more configurations. A configuration can provide one or more examples. Phrases such as "configurations" can refer to one or more configurations, and vice versa.

Claims

1. A method comprising: Controlled by the infusion device: intercepting a first command provided by a closed-loop control algorithm to a first infusion pump, the first command being configured to adjust delivery of a first fluid by the first infusion pump based on sensor measurements provided to the closed-loop control algorithm; receiving a therapy target control parameter for modifying delivery of a first fluid based on a real-time parameter of delivery of a second fluid by a second infusion pump; receiving real-time operating parameters and infusion status information for the first infusion pump and the second infusion pump; and The intercepted first command is modified based on the real-time operating parameter and the infusion status information and the treatment target control parameter to control the delivery of the first fluid and the second fluid.

2. The method according to claim 1, further comprising: receiving an indication of a failure in delivery of the first fluid based on the infusion status information; and Responsive to the indication of the delivery failure, the intercepted first command is modified.

3. The method according to claim 1 or 2, further comprising: receiving an indication that a container for the second fluid is nearly empty and that the second infusion pump is operating at a high flow rate; and In response to the indication, the second infusion pump is caused to slow the flow rate of delivery of the second fluid.

4. The method according to any one of claims 1 to 3, further comprising: Determining that the infusion line of the second infusion pump is blocked based on the infusion state information of the second infusion pump, The intercepted first command is modified so that the flow rate of the first infusion pump is adjusted.

5. The method according to any one of claims 1 to 4, further comprising: monitoring, by an infusion communication system, commands sent by a closed-loop control algorithm to the first infusion pump and the second infusion pump; intercepting, by the infusion communication system based on the monitoring, a second command before or simultaneously with intercepting the first command; determining that the first command should be processed before the second command to control delivery of at least one of the first fluid and the second fluid; and Providing the second command to the second infusion pump is delayed until the first command is conditioned and provided to the first infusion pump.

6. The method of any one of claims 1-5, wherein the delivery of the first fluid and the second fluid produces an effect, wherein the effect is a predetermined anesthetic hypnotic state, and the sensor measurements include electroencephalographic activity of a patient to whom the first fluid and the second fluid are delivered.

7. The method of claim 6, wherein the first infusion pump is configured to deliver a first anesthetic drug and the second infusion pump is configured to deliver a second anesthetic drug, wherein the method further comprises: determining a reduction in the flow rate of delivery of the second anesthetic agent, and Based on the decrease in the flow rate of the second anesthetic drug delivered, increasing the flow rate of the first anesthetic drug delivered to maintain the patient in a predetermined anesthetic hypnotic state, wherein said increase in said flow rate is not provided to said closed-loop control algorithm.

8. The method of any one of claims 1-7, wherein delivery of the first fluid and the second fluid produces an effect, wherein the effect comprises a stabilized cardiac output, and the sensor measurement comprises a measure of the patient's cardiac output.

9. The method according to any one of claims 1 to 8, further comprising: detecting, via a sensor operably connected to an infusion line for the first fluid, a type of the first fluid flowing through the infusion line; The infusion communication system prevents the first infusion pump from delivering the first fluid or the second infusion pump from delivering the second fluid based on intercepting commands sent to the first infusion pump and the second infusion pump until the type of the first fluid detected is confirmed to be scheduled for delivery by the first infusion pump and the second infusion pump.

10. The method according to any one of claims 1 to 8, further comprising: identifying an infusion set for the first fluid; and The infusion communication system prevents the first infusion pump from delivering the first fluid or the second infusion pump from delivering the second fluid based on intercepting commands sent to the first infusion pump and the second infusion pump until the infusion pump is confirmed to be scheduled for delivery by the first infusion pump and the second infusion pump.

11. An infusion device control system, comprising: an infusion device, comprising at least one of the first infusion pump and the second infusion pump; at least two connection ports configured to communicatively connect to the infusion device and the sensor; and Wherein, the infusion device control system is configured to execute the method according to any one of claims 1 to 10.

12. A system comprising: one or more processors; A memory device comprising non-transitory computer-readable instructions which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 10.

13. A memory device comprising non-transitory computer-readable instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 10.

14. A method comprising: The infusion equipment control system: intercepting a first command provided by a closed-loop control algorithm to a first infusion pump, the first command being configured to adjust a first therapy provided by the first infusion pump based on sensor measurements provided to the closed-loop control algorithm; receiving a therapy target control parameter for modifying the first therapy based on a real-time parameter of a second therapy provided by a second infusion pump; receiving real-time operating parameters and infusion status information for the first infusion pump and the second infusion pump; and The intercepted first command is modified based on the real-time operating parameter and the infusion status information and the treatment target control parameter to control the treatment effects of the first treatment and the second treatment.

15. The method according to claim 14, further comprising: receiving an indication of a delivery failure of the first therapy based on the infusion status information; and Responsive to the indication of the delivery failure, the intercepted first command is modified.

16. The method of claim 14, wherein the first treatment comprises a first administration of a first drug to the patient and the second treatment comprises a second administration of a second drug to the patient, wherein the method further comprises: receiving an indication that a container for the second medication is nearly empty and that the second infusion pump is operating at a high flow rate; and In response to the indication, the second infusion pump is caused to slow the flow rate of the second administration.

17. The method according to claim 14, further comprising: Determining that the infusion line of the second infusion pump is blocked based on the infusion state information of the second infusion pump, The intercepted first command is modified so that the flow rate of the first infusion pump is adjusted.

18. The method according to claim 14, further comprising: monitoring, by an infusion communication system, commands sent by a closed-loop control algorithm to the first infusion pump and the second infusion pump; intercepting, by the infusion communication system based on the monitoring, a second command before or simultaneously with intercepting the first command; determining that the first command should be processed before the second command to control the treatment effect; and Providing the second command to the second infusion pump is delayed until the first command is conditioned and provided to the first infusion pump.

19. The method of claim 14, wherein the therapeutic effect is a predetermined anesthetic hypnotic state and the sensor measurements include electroencephalographic activity of a patient to whom the first therapy and the second therapy are provided.

20. The method of claim 19, wherein the first treatment comprises a first administration of a first anesthetic drug and the second treatment comprises a second administration of a second anesthetic drug, wherein the method further comprises: determining a reduction in flow rate of the second application, and increasing the flow rate of the first administration to maintain the patient in a predetermined anesthetic hypnotic state based on the decrease in the flow rate of the second administration, The increase in flow rate is not provided to the closed-loop control algorithm.

21. The method of any one of claims 14-20, wherein the therapeutic effect comprises a stabilized cardiac output and the sensor measurement comprises a measure of the patient's cardiac output.

22. The method according to any one of claims 14 to 21, further comprising: detecting, via a sensor operably connected to an infusion line of the first treatment, a type of fluid flowing through the infusion line; The first infusion pump is prevented from providing the first therapy or the second infusion pump is prevented from providing the second therapy by the infusion communication system based on intercepting commands sent to the first infusion pump and the second infusion pump until the detected fluid type is confirmed for the first therapy and the second therapy.

23. The method according to any one of claims 14 to 21, further comprising: identifying an infusion set for use with the first treatment; and The first infusion pump is prevented from providing the first therapy or the second infusion pump is prevented from providing the second therapy by the infusion communication system based on intercepting commands sent to the first infusion pump and the second infusion pump until an infusion set is confirmed for the first therapy and the second therapy.

Images