System and method for intelligently controlling a medical device

Abstract

A system and method for intelligently controlling a medical device. An external infusion control device is operably connected to the infusion device and one or more sensors and configured to control the infusion device based on sensor data provided by the sensors and user input provided at the control device. The control device provides a user interface for displaying and, upon receiving a therapy selected by a user, verifies that the sensors for the therapy are operably connected to the control device and that the control device is operably connected to the infusion device that may be controlled by the sensor data. One or more algorithms are obtained, for example, by being downloaded from a server, and control the infusion device based on the sensor data, and execution of the selected therapy is facilitated by the control device based on the sensor data received from the one or more sensor devices.

Description

[Technical field]

[0001] The present disclosure relates generally to control devices configured to facilitate operation of a medical device and configured to communicate with a remote device. [Background technology]

[0002] The patient care unit may include a modular infusion platform that is expandable with multiple drug delivery modules and handles multiple types of drug delivery to patients. Different patients require different levels of therapy and different parameters for different devices. Individual infusion devices may operate differently and may include different types of user interfaces, resulting in a wide variety of display types and parameter variations that may confuse or distract clinicians during infusions and other drug delivery procedures. During surgery and under conditions where direct access to the infusion device or devices may be difficult, precise control and adjustment of the device may be difficult. Failure to maintain control of the device increases health risks to patients in a healthcare facility. For example, under manual control, the time that the drug is delivered to the patient at a level that is within the desired range may vary based on, for example, the attentiveness of the clinician. The time the patient spends outside the desired range may impact the procedure, the patient, recovery, and resources used to deliver the therapy. Additionally, some therapies require repetitive work steps that are prone to error or complacency, which may lead to adverse events. Summary of the Invention [Means for solving the problem]

[0003] According to various aspects, the present technology provides systems and methods for intelligently controlling medical devices, particularly infusion devices. The intelligent control module (ICM) of the present technology provides direct control over connected medical devices, assisting clinicians to provide more centralized control and management of the devices. The ICM provides a modular interface system whereby various sensors used in a medical environment can be connected in a common manner to facilitate control over connected medical devices. For example, a heart rate monitor, an oxygen sensor, and an IV flow monitor can all be connected to the ICM to facilitate centralized control of one or more infusion devices in addition to input by a clinician. The ICM may further connect to servers and cloud-based systems for further data input, data coordination, and reporting.

[0004] According to various aspects, an infusion control device includes a non-transitory machine-readable memory and a processor operably connected to a display and the memory, the processor configured to: provide a user interface to the display, prompt a user to select a therapy via the user interface, receive the selected therapy from the user interface, verify that one or more sensor devices required for the selected therapy are operably connected to the infusion control device, verify that the infusion device is operably connected to the infusion control device and that the infusion device is controllable based on information derivable from the sensor devices, obtain a first algorithm configured to operate the infusion device based on real-time data received from the one or more sensor devices, and facilitate execution of the selected therapy based on sensor data received from the one or more sensor devices. Other aspects include corresponding systems, methods, and computer program products for embodiments of corresponding devices and features thereof.

[0005] The method includes receiving an indication that a control device is operably connected to one or more infusion devices, the control device being physically separate from the one or more infusion devices; presenting for the control device a user interface configured to provide a selection of one or more predefined treatments associated with the one or more infusion devices and configured to display one or more graphical data modules based on the selection; receiving, at the control device, a selection of a first treatment of the one or more predefined treatments provided by the user interface; determining, at the control device, based on receiving the selection of the first treatment, that one or more sensor devices are operably connected to the control device for providing data associated with the selected first treatment; and determining, based on determining that the one or more sensor devices are operably connected to the control device, that one or more sensor devices are operably connected to the control device for providing data associated with the selected first treatment. downloading from the server to the control device a first algorithm configured to operate the one or more infusion devices based on real-time data received from the devices, generating a default organization of one or more respective graphic data modules in a user interface based on the one or more sensor devices and the downloaded first algorithm, where at least one of the one or more respective graphic data modules is configured to receive configuration parameters associated with operation of the one or more infusion devices, prompting the configuration parameters, receiving the configuration parameters via the at least one respective graphic data module, and controlling the one or more infusion devices based on the real-time data received from the one or more sensor devices, the downloaded first algorithm and the received configuration parameters. Other aspects include corresponding systems, apparatus and computer program products of embodiments of the corresponding methods and features thereof.

[0006] It should be understood that other configurations of the present technology will become readily apparent to those skilled in the art from the following detailed description, and that various configurations of the present technology are shown and described by way of example. As will be understood, the present technology is capable of other and different configurations, and its several details are capable of modification in various other respects, all without departing from the scope of the present technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature, and not as restrictive.

[0007] For a better understanding of the various described embodiments, reference should be made to the following description of the embodiments in connection with the following drawings, in which like reference characters refer to corresponding parts throughout the drawings and description, and in which: [Brief description of the drawings]

[0008] [Figure 1A] 1 depicts an example of an organized patient care system for a health care organization, in accordance with an aspect of the present technology. [Figure 1B] 1 illustrates an example patient care unit including a control unit and a connected drug delivery module, in accordance with various aspects of the present technology. [Figure 2A] 1 is a conceptual diagram illustrating an example infusion control system integrating an example decision module with one or more medical systems and one or more sensing devices, in accordance with aspects of the present technology. [Figure 2B] 1 depicts an example modular user interface configured to dynamically connect to, receive data from, and control different infusion therapies, in accordance with aspects of the present technology. [Diagram 3] 1 depicts an example process for intelligently controlling an injection, in accordance with aspects of the present technique. [Figure 4] 1 is a conceptual diagram illustrating an example electronic system for intelligently controlling an injection, in accordance with aspects of the present technique. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Reference will now be made to the embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide an understanding of the various described embodiments. However, it will be apparent to those skilled 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 have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0010] The present technology provides an intelligent control module (ICM) that includes a unit that provides processing for control algorithms and connectivity that, when in use, enables closed-loop and semi-closed-loop control capabilities over one or more medical devices. In some embodiments, the ICM provides an external interface between an IV infusion pump and one or more different physiological sensors, providing input parameters that can be used to control the titration of IV infusion of a drug to a patient. In this regard, the ICM can incorporate control software (e.g., including one or more algorithms) that can be tailored to specific or general drug therapies.

[0011] A closed-loop control system generally refers to a system that does not rely on external manual input to deliver therapy. Once configured, a closed-loop system can autonomously deliver therapy, receive feedback from one or more sensors, and automatically adjust therapy as needed based on the feedback. A semi-closed-loop control system is similar to a closed-loop control system, except in some circumstances where adjustments to therapy may depend on external input. In some embodiments, a semi-closed-loop control system may be referred to as a decision support system.

[0012] According to various embodiments, the ICM can facilitate the control software being separated from the embedded firmware of both pumps and from the sensors, facilitating a scalable and fast configured system to provide closed-loop control of drug therapy. Additionally, the ICM can be configured to operate with multiple sensors via electrical connectors and / or wireless communication. The ICM may include one or more microprocessors and algorithms to provide signal processing and / or conversion of sensor signals into appropriate physiological parameters for the connected medical device. The parameters may then be used in a control algorithm to, for example, control an infusion pump to deliver the necessary drug or fluid for a desired clinical outcome. As used herein, "connecting" or "operably connecting" devices may include establishing a physical (e.g., wired) or virtual (e.g., wireless) connection between the devices.

[0013] Having the ICM be a separate unit from the medical device offers several advantages. For example, advances in sensors can be much faster than the development of infusion pump systems, so the control system can adapt to these changes more quickly. It is desirable to update the control algorithms to address changes in treatment methods, available drugs, and patient physiology. For this reason, having the algorithms in a component separate from the pump system is desirable to accommodate more frequent changes. Additionally, machine learning and artificial intelligence can account for patient variations in physiological parameters, such as age, genetics, medical history, and other characteristics, as well as environmental factors. Systems incorporating this type of capability can include large databases and complex programs that require powerful microprocessors and data storage capabilities to perform the necessary calculations in a timely and accurate manner. These systems generally cannot operate alone on currently available systems with IV pumps.

[0014] Additionally, the ICM of the present technology is adaptable to a variety of pump systems and sensor inputs. The ICM may be further configured to add wireless, Bluetooth, and LAN connectivity to pump systems that do not currently have it available. Adding this type of communication to a pump system may enable other capabilities, such as remote monitoring and control of the infusion pump and access to the patient's EMR. Thus, by integrating the electrical and processing components separate from the pump, the present technology facilitates the integration of additional capabilities without the need to modify the pump housing and electronics. Separating the physiological sensing and control system from the infusion pump system may further provide a more streamlined regulatory approval process.

[0015] FIG. 1A depicts an example of an organized patient care system 100 of a healthcare organization according to an embodiment of the present technology. In FIG. 1A, patient care devices (or generally "medical devices") 12 are connected to a hospital network 10. The term patient care device (or "patient care device") may be used synonymously with the term patient care unit (or "patient care unit"), both of which may include various ancillary medical devices, such as infusion pumps, vital signs monitors, drug administration devices (e.g., cabinets, totes), drug preparation devices, automated administration devices, modules coupled to one of the above (e.g., a syringe pump module configured to attach to an infusion pump), or other similar devices. Each element 12 is connected to the internal healthcare network 10 by a transmission channel 31. The transmission channel 31 may be any wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some embodiments, network 10 also includes computer systems located in various departments throughout the hospital. For example, network 10 of FIG. 1A optionally includes computer systems associated with approvals, accounting, biomedical engineering, clinical laboratories, central supply, one or more unit station computers, and / or medical decision support systems. As described below, network 10 may include separate sub-networks. In the illustrated example, network 10 includes device network 40 through which patient care devices 12 (and other devices) communicate according to normal operation.

[0016] In addition, the organized patient care system 100 may incorporate a separate information system server 30, the functionality of which is described in detail below. Further, although the information system server 30 is shown as a separate server, the functionality and programming of the information system server 30 may be incorporated in other computers as desired by engineers designing the organizational information system. The organized patient care system 100 may further include one or more device terminals 32 for connecting to and communicating with the information system server 30. The device terminals 32 may include personal computers, personal data assistants, mobile devices, such as laptops, tablet computers, augmented reality devices, or smartphones, configured with software for communication with the information system server 30 over the network 10.

[0017] The patient care device 12 comprises a system for providing patient care, such as that described in U.S. Patent No. 5,713,856 to Eggers et al., which is incorporated herein by reference. The patient care device 12 may include or incorporate pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeters, and other patient monitors), therapeutic devices, and other drug delivery devices may be utilized in accordance with the teachings described herein. In the illustrated example, the patient care device 12 comprises a control module 14, also referred to as an interface unit 14, which is connected to one or more functional modules 16, 18, 20, 22. The interface unit 14 includes a central processing unit (CPU) 50 connected to a memory, e.g., a random access memory (RAM) 58, one or more interface devices, such as a user interface device 54, a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. The interface unit 14 also includes, but is not necessarily limited to, a non-volatile main memory 56, such as a hard disk drive or non-volatile flash memory, for storing software and data, and one or more internal buses 64 for interconnecting the above-mentioned elements.

[0018] 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 can include any means for displaying and inputting information, such as a monitor, printer, keyboard, softkeys, mouse, track ball, and / or light pen. The data input device 60 can 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 can be any device for inputting encoded data into a computer, such as a device for reading magnetic stripes, a radio-frequency identification (RFID) device in which digital data encoded on an RFID tag or smart label (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 any other analog or digital storage medium. Other examples of the data input device 60 include a voice-activated 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. In FIG. 1A, the data input device 60 is shown disposed within the interface unit 14, but it should be appreciated that the data input device 60 may be integrated within the medication system 34 or may be external and communicate with the medication system 34 through an RS-232 serial interface or any other suitable communication means. The auxiliary interface 62 may be an RS-232 communication interface, but any other means for communicating with peripheral devices such as printers, patient monitors, infusion pumps or other medical devices may be used without departing from the present technology.In addition, data input device 60 may be a separate functional module, such as modules 16, 18, 20 and 22, and may be configured to communicate with controller 14 or any other system on the network using appropriate programming and communication protocols.

[0019] The network connection 52 may be a wired or wireless connection, for example, via Ethernet, WiFi, Bluetooth, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem or a cable modem. Any 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, or a WLANs connection or other wireless connection.

[0020] Functional modules 16, 18, 20, 22 may be any device for providing care to a patient or for monitoring a patient's condition. As shown in FIG. 1A, at least one of functional modules 16, 18, 20, 22 may be an infusion pump module, such as an intravenous infusion pump for delivering medication or other fluids to a patient. For purposes of this description, functional module 16 is an infusion pump module. Each of functional modules 18, 20, 22 may be any patient treatment or monitoring device, including, but not limited to, an infusion pump, a syringe pump, a 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. Functional modules 18, 20 and / or 22 may be a printer, a scanner, a bar code reader, or any other peripheral input, output, or input / output device.

[0021] Each functional module 16, 18, 20, 22 communicates directly or indirectly with the interface unit 14, which provides overall monitoring and control of the device 12. The functional modules 16, 18, 20, 22 may be physically and electronically connected in a serial manner to one or both ends of the interface unit 14, as shown in FIG. 1A or as detailed in Eggers et al. However, it will be appreciated that there are other means for connecting the functional modules to the interface units that may be utilized without departing from the present technology. It will also be appreciated that devices such as pumps or patient monitoring devices that provide sufficient programmability and connectivity may operate as standalone devices and communicate directly with the network without being connected through a separate interface unit or control unit 14. As discussed above, additional medical or peripheral devices may be connected to the patient care device 12 through one or more auxiliary interfaces 62.

[0022] Each functional module 16, 18, 20, 22 may include module specific components 76, a microprocessor 70, a volatile memory 72 for storing information, and a non-volatile memory 74. It should be noted that although four functional modules are shown in FIG. 1A, any number of devices may be directly or indirectly connected to the central controller 14. The number and types of functional modules described herein are for illustrative purposes and are not intended to limit the scope of the technology in any way. Module specific components 76 include any components necessary for operation of a particular module, such as a pumping mechanism for the infusion pump module 16.

[0023] Each functional module is capable of at least some level of independent operation, while interface unit 14 monitors and controls the overall operation of device 12. For example, as described in more detail below, interface unit 14 provides programming instructions to functional modules 16, 18, 20, 22 and monitors the status of each module.

[0024] The patient care device 12 can operate in several different modes or personalities, each personality being defined by a configuration database. The configuration database may be a database 56 internal to the patient care device or an external database 37. A particular configuration database is selected based at least in part on patient specific information, such as the patient's location, age, physical characteristics or medical characteristics. Medical characteristics include, but are not limited to, the patient's diagnosis, treatment prescription, medical history, medical records, patient care personnel identification, physiological characteristics or psychological characteristics. As used herein, patient specific information also includes care personnel information (e.g., physician identification) or the location of the patient care device 10 within the hospital or hospital computer network. The patient care information may be entered through the interface device 52, 54, 60 or 62 or may originate from elsewhere in the network 10, such as from a medication server, an approval server, a laboratory server, etc.

[0025] Medical devices incorporating aspects of the present technology may include a Network Interface Module (NIM) that allows the medical device to participate as a node in a network. For clarity, the present technology is described as operating in an Ethernet network environment using the Internet Protocol (IP), but it should be understood that the concepts of the present technology are equally applicable in other network environments, and such environments are intended to be within the scope of the present technology.

[0026] Data to and from the various data sources can be converted to network compatible data by existing technology, and the movement of information between the medical devices and the network can be accomplished by various means. For example, the patient care devices 12 and the network 10 may communicate through automatic interaction, manual interaction, or a combination of both automatic and manual interaction. Automatic interaction may be continuous or intermittent and may occur through a direct network connection 54 (as shown in FIG. 1A) or through an RS232 link, a MIB system, an RF link such as Bluetooth, an IR link, WLANs, a digital cable system, a telephone modem, or other wired or wireless communication means. Manual interaction between the patient care devices 12 and the network 10 includes physically transferring data between the systems, intermittently or periodically, using, for example, a user interface device 54, a coded data entry device 60, a bar code, a computer disk, a portable data assistant, a memory card, or any other medium for storing data. The various aspects of the communication means are bidirectional with access to the data from as many points of the distributed data sources as possible. The decision may occur at various locations within the network 10. For example, but not by way of limitation, the decision may be made within the HIS server 30, the decision support 48, the remote data server 49, the medical department or unit station 46, or the patient care device 12 itself.

[0027] All direct communication with medical devices operating on a network in accordance with the present technology may be performed through an information system server 30 known as a remote data server (RDS). In accordance with aspects of the present technology, a network interface module incorporated within a medical device, e.g., an infusion pump or a vital signs measurement device, ignores all network traffic that does not originate from an authenticated RDS. The primary responsibility of the RDS of the present technology is to track the location and status of all networked medical devices with NIMs and to maintain open communication.

[0028] FIG. 1B illustrates an example PCU 12 including a control module 14 with connected drug delivery modules 16, 18, 20, 22 according to various aspects of the present technology. In some embodiments, the drug delivery modules 16, 18, 20, 22 include plug-in ports for expansion. Thus, new drug delivery modules may be attached to the PCU 12 by mating connectors through the plug-in ports, which may include electrical terminals so that the added drug delivery modules 16, 18, 20, 22 may send information to and receive information from the control module 14. In some embodiments, the added drug delivery modules 16, 18, 20, 22 may also receive power from the control module 14 through the plug-in ports. The control module 14 may include a main display 201, memory and a processor (see FIG. 4) and may be configured to display operating parameters and drug delivery status, as well as further 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.

[0029] The main display 201 is configured to display one or more user interfaces 210 for display of operating parameters or other data associated with the modules 16, 18, 20, 22 and / or physiological parameters associated with the patient (see FIG. 2B). The main display 201 may also include multiple user interfaces 210, each of which visually displays information for a respective one of the drug modules, including the information displayed on the corresponding module display. In some embodiments, the control module 14 includes a communications module (e.g., including an antenna) configured to wirelessly communicate with a controller or network.

[0030] 1A and 1B, when the drug delivery modules 16, 18, 20, 22 start an infusion of a drug to a patient, the control module 14 is configured to create and manage an infusion session in the memory of the control module (or associated modules). For purposes of this disclosure, an infusion session includes state information of the PCU 12, its control module 14 and / or its associated modules, which is recorded and stored in memory for a particular period of time. 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 the 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 the operating parameter values ​​and any modifications of the operating parameters of the PCU, its control modules and / or modules are also recorded in the session.

[0031] If not already logged into the PCU 12, the clinician may scan his or her badge in proximity to a sensor (e.g., 54, 60) on the PCU 12, and the PCU may attempt to authenticate the clinician by transmitting the scanned identification of the clinician to the server 30. The clinician's badge may incorporate a radio frequency identification device (RFID) that is read by a scanner integrated into the PCU or a portable scanner associated with the PCU. The clinician may scan his or her badge with the control module 14 to identify and authorize the clinician and initiate administration of the medication. Once the clinician is associated with the PCU and / or modules, the clinician's identification is associated with the session. The same applies to the patient. The clinician may scan the patient's wristband with a portable scanner or may use a sensor on the PCU 14 (or its control module) to associate the patient with the PCU and / or modules (and session).

[0032] The control unit 14 of the PCU 12 is configured to generate a graphical representation of the infusion session and display the graphical representation (e.g., on the display 201), the graphical representation including a graphical visualization of all parameters of the infusion during the session and any modifications of the parameters together with the physiological data acquired during the session. The graphical representation may include pseudo identifiers for the unknown data until the unknown data is replaced by known identifiers. The graphical representation is then displayed with the known patient identifiers.

[0033] FIG. 2A is a conceptual diagram illustrating an example infusion control system 200 that integrates an example decision module with one or more medical systems and one or more sensing devices, according to aspects of the present technology. In the illustrated example, the ICM 202 includes multiple configurable hardware interfaces 203 that receive inputs from various sensors and data sources 204. The ICM is connected via the interfaces 203 to one or more medical devices 206 that include an infusion pump 206a, such as an actuator pump, a syringe pump (e.g., BD Alaris™ PK Syringe Pump), a large volume infusion pump (e.g., BD Alaris™ Plus Infusion Pump), or a modular infusion pump (e.g., BD Alaris™ Infusion System or BD Alaris™ Medley Infusion Pump), simultaneously. The ICM may incorporate algorithms to remotely control IV infusion of drugs or fluids by the infusion pump. As described below, the ICM 202 may be configured to dynamically load one or more algorithms and control the infusion in different ways. For example, the algorithm may control a Pharma Kinetic (PK) infusion, a Titration Controlled Infusion (TCI) infusion, a Proportional Integral Derivative (PID) infusion, or other proprietary / trademark protected controlled infusion.

[0034] Depending on the sensor I / O requirements or signal processing requirements, the ICM 202 may be configured with adapters 203 supporting the connection of various sensors 204 and / or medical devices 206. Sensors may require analog or digital I / O with specific power supply requirements. The modular I / O adapters 203 can interface with standard digital I / O available in the decision module, i.e., USB, UART, data bus. The I / O modules then interface with the needs of external sensors, e.g., analog, optical, custom wireless, e.g., UWB, ZigBee, Bluetooth Low Energy. The I / O modules may include additional processing, i.e., microcontroller or digital signal processor hardware. The I / O modules may be designed to support multiple sensors or may be designed to support sensors supplied by a single vendor.

[0035] According to various embodiments, embedded firmware and / or software drivers supporting the I / O module type built into each I / O module 203 form an extensible "plug and play" capability. I / O modules 203 may be added to the ICM 202 as needed. If a particular I / O function is deemed common or required by default, certain adapter capabilities (e.g., BLE, standard serial interfaces, etc.) may be included by default within the decision module.

[0036] In some embodiments, sensor inputs (e.g., for closed loop control) may be acquired via the network interface 205. In one example, various sources connecting one or more clinically relevant input sources to the ICM 202 may provide data to support control decisions (including, for example, controlling closed loop use cases). One example may include sensor inputs from a patient care system, such as CareFusion's Care Coordination Engine (CCE). The CCE may receive data from an electronic medical record or directly from a sensor or other device and transmit the data via the network interface 205. Other inputs may include multi-parameter monitors.

[0037] The IV infusion device 12 or other delivery device may be controlled directly by the ICM 202 using serial, wired or wireless network connectivity (Ethernet or WIFI), other wireless connectivity such as BLE. If specialized connectivity may be required, a predefined I / O module 203 corresponding to the type of device may be connected. Thus, external devices that may be connected to the ICM 202 may include, for example, a badge RFID reader (e.g., for tasks such as NFC tap to associate patient, sensor, pump, clinician login), a biometric identification device (e.g., fingerprint or retinal scanner), or a backup battery for power loss or emergency use.

[0038] The ICM 202 further includes a display module 208 configured to provide a user interface for the display of information related to the patient's physiological status as well as system control status. In some embodiments, the display module 208 includes circuitry within the ICM 202 housing that provides display information to an external display device. The ability to connect to other displays provides modular scalability. For example, if a use case requires a rich user interface with a clinician display including data and graphs, a larger, high resolution display can be used. If a use case requires a display with minimal information and UI to support configuration, a smaller, space saving and lower cost locally connected display can be used.

[0039] The ICM may be connected to a local display by a cable or may be directly attached, forming a composite module pair. The ICM 202 may be configured to have little or no local display capabilities (e.g., "headless") or may be configured to connect wirelessly (e.g., via Bluetooth) to a mobile device such as a smartphone or tablet and display information via a mobile application running on the remote device. Display information may also be provided to an external clinician display or a portal for displaying other information specific to the portal. In some embodiments, the ICM may include an integrated display device. In some embodiments, the ICM 202 may share a display with one or more medical devices 206. For example, both the infusion pump 206a and the ICM 202 may share a single external display for displaying information and / or controlling infusion parameters.

[0040] The ICM 202 may include network hardware for wirelessly connecting to a wireless hub or other network device 209 of the network 10, 40, thereby providing network communication with the server 30, PCU 12, or other network-enabled device operatively connected (e.g., via the network 10, 40) to the cloud-based system. For example, patient information may be downloaded by the ICM 202 from an external system, infusion limits associated with the ICM set based on the patient information, and infusion flow rates are provided by connected infusion devices controlled by the ICM based on the limits and / or patient information. In some embodiments, the ICM 202 may be remotely connected to the PCU 12 or infusion pump through the server 30 and / or the network 10, 40. For example, the ICM may be implemented as a mobile or remote device 32.

[0041] In some embodiments, the ICM 202 may be connected to multiple shared displays, which may be used as display dashboards where multiple treatments are required to facilitate the screen real estate challenge in critical care environments. A user interface may be provided for each display, and each interface (e.g., widgets) containing treatment-specific data modules is associated with a display.

[0042] Additionally, in some implementations where multiple ICMs 202 are used, decision module redundancy can be used to support fault-tolerant operation. For example, when I / O modules 205 are connected on an I / O bus, each may be accessed by other decision modules on the bus. The decision modules may operate in a redundant mode and take over functionality from a defective or failed element of the cluster.

[0043] In some embodiments, the ICM 202 may include an integrated camera. In some embodiments, the ICM 202 may incorporate face tracking so that the display can swivel and rotate with a motorized bracket so that the display image faces the HCP needing the information. This can be useful when the surgeon must move around the patient multiple times during surgery.

[0044] A camera may be incorporated as part of a vision system, which may further incorporate RFID or BLE used to track surgical instruments or devices being used at the bedside. With visual tracking, the camera may be used to identify the location of the ICM 202. This may be in addition to or instead of tracking that currently requires the HCP to count and store the location of devices, instruments, dressings and sponges to ensure they are not misplaced or left behind in the patient during surgery, thus reducing errors (e.g., Retained Sponges and Instrument (RSI) errors). For example, a visual inspection system may be further incorporated within the ICM to identify and count the number of sponges used to better predict the amount of blood they contain. This information can then be used by the hemodynamic control algorithm 216 to better manage the amount of fluid required to be infused into the patient. Large amounts of blood loss have been associated with poor surgical outcomes, along with patients with hemodynamic instability. Thus, the hemodynamic and fluid management control system of the present technology may provide improved safety and better patient recovery.

[0045] FIG. 2B depicts an example modular user interface 210 configured to dynamically connect to, receive data from, and control different infusion therapies, according to aspects of the present technology. As described above, the user interface 210 is generated for display by the ICM 202 and configured to facilitate connecting the external sensors 204 to one or more medical devices 206 based on user input. The interface 210 provides selection controls 212, e.g., menus, for selection of one or more therapies associated with the infusion device (or other medical device). The interface is also configured to receive the sensor data and display one or more graphic control modules 214 that provide the data to a processing module, which may interface with the interface to control the infusion device. Once a therapy 216 is selected, the interface 210 may dynamically reconfigure itself to display one or more predefined modules 214 corresponding to the selected therapy.

[0046] Thus, the user interface 210 is configured to facilitate control of medical devices based on sensor data received from a selected sensor. Once a therapy is selected, available sensors (e.g., sensors connected to the ICM) may be displayed by the interface. A default user interface may be displayed, or the user interface may be reconfigured based on which therapy, medical device, and / or sensor is selected for use. Data modules 214 (e.g., widgets) may be added or removed from the interface as desired or required to display patient and therapy data for a particular therapy being controlled by the ICM. Using the user interface 210 and / or data modules, the clinician may maintain control of an ongoing medical therapy (e.g., infusion) according to a selected therapy type (e.g., anesthesia). The clinician may receive and respond to alerts, accept or reject recommendations, and set targets (e.g., drug concentrations).

[0047] According to various embodiments, during operation, the ICM 202 operatively connects to a medical device 206 and upon recognizing the medical device, software in the user interface 210 determines one or more predefined therapies associated with the medical device. For example, the software may receive an identifier for the medical device when connected to the infusion device and then query the database 37 (e.g., over the network 10) for available therapies associated with the infusion device. A selection control 212 may then provide the therapies to the clinician for selection.

[0048] Each therapy may be associated with one or more modules 214 for controlling an infusion device based on input data. In some embodiments, the modules 214 may receive input data (e.g., parameters) from a clinician via the modules while being displayed on the interface 210. In some embodiments, each module may be associated with one or more external sensors 204, and when connected (e.g., to the I / O module 205), at least a portion of the data may be received from the associated sensor 204. The sensors may be automatically discoverable and / or registerable by the system (e.g., using plug-and-play technology).

[0049] According to various embodiments, the ICM 202 may host one or more clinical control algorithms 216. The algorithms 216 may be pushed down to the ICM over the communications network 10. Depending on the treatment selection, the appropriate control algorithm can be selected for the configuration of the I / O module 203.

[0050] Once a treatment selection is made, the system determines which sensor devices 204 associated with the treatment are operatively connected to the ICM 202 and identifies and selects a corresponding algorithm 216a configured to operate the connected medical device based on real-time data received from the connected sensors 204. As used herein, "real-time" may mean availability for processing at or near the time an associated item is generated or detected. The algorithm 216 may be stored locally in the memory of the ICM 202 or, in some embodiments, may be dynamically downloaded from the server 30 and / or database 37. In some embodiments, the algorithm may include input values ​​derived from monitoring or testing results, etc. The algorithm 216 may employ advanced processing capabilities, such as artificial intelligence, machine learning, and neural net processing. When the algorithm is stored locally in the memory of the ICM 202, the ICM 202 may examine the algorithm for use by the ICM 202. For example, an algorithm may be associated with an identifier or other information that can be used to determine characteristics of the algorithm, such as version, distributor, creator, etc. The identifier or other information may be evaluated locally or may use a server to determine if the algorithm is suitable for use. For example, a stored algorithm may be out of date or may be recalled. In such a case, ICM 202 may initiate a download of a newer version. If the algorithm is inspected and approved, ICM 202 may continue as described.

[0051] According to various embodiments, the ICM 202 identifies one or more modules 214a corresponding to the selected therapy and / or the selected algorithm 216a and generates a default organization of the identified modules 214a in the user interface 210. As illustrated in FIG. 2B, the identified modules may then be displayed in the user interface 210 and may begin receiving data from the respective sensor devices 204a. Some modules 214 may be configured to receive user input via the user interface 210, e.g., configuration parameters associated with the operation of the infusion device. In some cases, the module 214a may prompt the user for configuration parameters and may control a connected medical device based, at least in part, on the parameters received from the user via the module.

[0052] When a new sensor is connected, the system may query the database 37 to determine what algorithms are associated with the sensor, determine the respective data modules 214, and update the user interface 210 to display the data modules 214 associated with the new sensor. The interface 210 may then be used to control a medical device via the partially determined data modules. Furthermore, due to the modularity of the interface 210, when an updated algorithm becomes available for a particular sensor, the user interface 210 may be configured to load the new algorithm and replace the currently running algorithm with the newly loaded algorithm.

[0053] The user interface 210 may further include a data module 214 for displaying various checklists. The checklists may be used, for example, prior to surgery to ensure familiarity with the patient's condition and the steps to be performed. This may be performed as an ad-hoc discussion between the involved caregivers. Infusion pump set-up is typically based on the user's experience and familiarity and may lead to errors, such as IV lines crossing between drugs, lines being connected incorrectly, sets being improperly prepared, IV equipment not properly wiped, etc. When the ICM 202 detects the connection of a certain type of infusion device, it may query the database 37 based on the type of infusion device and obtain a checklist for the setup of the device. In some embodiments, the checklists may be incorporated into the corresponding algorithms loaded by the ICM.

[0054] The checklist may include several steps that require confirmation from the clinician. Confirmation may be by the clinician pressing a key on the ICM or by automatic initiation by scanning a bar code, RFID, or connecting a BLE enabled device. The checklist may define the sequence and confirmation of steps that need to be performed. By way of example, the ICM 202 may read information and communicate with the device to identify the IV expansion set being used, the priming volume, which IV pump is being used for the drug, how the IV lines are connected, and / or the setting of occlusion alarm limits based on the IV setup.

[0055] The ICM 202 may further include alarm software. A fault, failure or need for attention in a medical device or sensor connected to the ICM 202 may generate one or more alarms. When multiple devices are connected to the ICM, a hierarchy can be used to provide information about what needs to be done for alarms that may not require immediate attention (e.g., a warning that a syringe is nearing empty). Notification can be provided by means other than an audio alarm that would be distracting to all clinicians involved in the procedure.

[0056] The ICM may also monitor all connected devices and use algorithms to predict potential problems before they occur, allowing clinicians to act in a timely manner before a situation arises that requires emergency action.

[0057] In some embodiments, the user interface 210 may display a side bar and provide alerts that the clinician can then interrogate to determine what action needs to be taken. Alerts may be color coded to indicate source, status, and priority. By way of illustration, yellow may indicate that an item should be monitored and, if possible, attended to, such as IV line pressure starting to rise from baseline (e.g., a precursor to an occlusion), syringe volume dropping to a first predetermined threshold amount, and / or syringe volume not sufficient to complete an infusion command (e.g., 20% with X minutes to empty), AC line disconnected, or battery power providing X minutes of run time and multiple sensor short term data interrupts (indicating poor contact).

[0058] Orange may indicate that an item should be monitored as soon as possible to ensure that therapy is not interrupted. For example, IV line pressure is within a predefined threshold range (e.g., 80% of occlusion alarm), an occlusion alarm is possible within a predefined number of minutes, syringe volume has dropped to a second predefined threshold amount, and / or syringe volume is not sufficient to complete the infusion (e.g., infusion command is 10% with X minutes to empty), or AC line has been disconnected, and / or battery power is at a predefined level (e.g., providing 10% and / or only X minutes of runtime). Red may identify items that require immediate attention and / or that will or have already stopped the system (pump, ICM control) and require the clinician to manage and / or manually control the system. In such cases, the medical device (e.g., pump) may provide an audio and / or visual alarm. A red alert may be provided, for example, when the syringe is empty, the IV line is blocked, the AC line is disconnected, or the battery power is depleted.

[0059] In some embodiments, software running on the ICM 202 may combine information from various sensors and identify a problem or potential problem. For example, in the case of anesthesia, if the patient's bi-spectral index sensor 204 (BIS) indicates an increase in the BIS value along with a change in hemodynamic parameters, and the flow sensor 204 and / or a sensor in the pump 206a indicate that the increase in the BIS value is inversely proportional to the dose of drug being infused, the ICM 202 may indicate that the patient is not responding as expected from receiving the drug. In this type of embodiment, a hierarchy of potential faults may be displayed on the ICM 202 to provide guidance to the clinician on what steps to take. For example, a color code of a fault on the ICM 202 may be manifested by an indication of one or more potential causes. The ICM 202 may also display a fault checklist and indicate that it has performed potential checks, for example, checking that an IV line is connected and unobstructed or that a sensor is connected.

[0060] Computer program code for carrying out operations of the present technology may be written in an object-oriented programming language, such as JAVA, Smalltalk, or C++. However, computer program code for carrying out operations of the present technology may also be written in conventional procedural programming languages, such as the "C" programming language, interpreted scripting languages, such as Perl, or functional (or fourth generation) programming languages, such as Lisp, SML, Forth, etc. Software may be written to be compatible with HLA-7 requirements.

[0061] FIG. 3 depicts an example process for intelligently controlling an injection, according to aspects of the present technology. For purposes of explanation, the various blocks of the example process 300 are described herein with reference to FIGS. 1 and 2 and the components and / or processes described herein. One or more of the blocks of the process 300 may be performed by a control device, e.g., by one or more computing devices, including, e.g., the ICM 202 or components thereof. In some embodiments, one or more of the blocks may be performed separately from other blocks and by one or more different processors or devices. Further for purposes of explanation, the blocks of the example process 300 are described as occurring serially or linearly. However, multiple blocks of the example process 300 may occur in parallel. In addition, the blocks of the example process 300 need not be performed in the order shown, and / or one or more of the blocks of the example process 300 may not be performed.

[0062] In the illustrated example, the ICM 202 is operatively connected (302) to the infusion device 206a. For example, the ICM 202 may be operatively connected to the infusion device via wireless pairing or via a wired connection.

[0063] A user interface 210 is presented (304) for the control device. As described above, the user interface may be configured to provide a selection of one or more predefined therapies associated with the infusion device and to display one or more graphical data modules based on the selection. In some embodiments, the user interface 210 may be presented by the ICM 202. In some embodiments, the user interface 210 may be generated by the ICM 202 and presented on an external display device (e.g., a display device associated with the infusion device or a mobile device). In some embodiments, the user interface 210 may be generated by the server 30 and provided and rendered by the ICM 202 or an external display device.

[0064] A first therapy selection of one or more predetermined therapies is received at the control device (306). For example, and referring briefly to FIG. 2B, Therapies A through D may be displayed in a selection control 212 and a user / clinician may select “Therapy C”. Based on receiving the selection of the first therapy (e.g., “Therapy C”), the ICM 202 may determine (308) that one or more sensor devices are operably connected to the control device for providing data associated with the selected first therapy. The sensor devices 204 may include an infusion parameter sensor, such as a flow monitor or a pressure monitor, or may include a physiological monitor, such as an oxygen sensor, heart rate sensor, or blood pressure sensor, that is connected to a patient and configured to measure a physiological signal from the patient. Determining that a sensor is operably connected may include, for example, determining the sensor 204 and / or sensor data associated with (or, e.g., required for) the selected therapy and then determining if the sensor is connected to the ICM (e.g., by polling the I / O module 205 or by checking internal registration information).

[0065] In the illustrated example, the ICM 202 obtains (e.g., downloads) 310 a first algorithm from the server to the ICM based on determining that one or more sensor devices are operably connected to the control device. According to various embodiments, the first algorithm is configured to operate the infusion device based on real-time data received from the one or more sensor devices. In some embodiments, the first algorithm is configured to operate the infusion device in a closed-loop mode based on real-time data received from the one or more sensor devices. In some embodiments, the ICM 202 verifies that the one or more sensor devices are associated with a first therapy and type of infusion device before downloading the first algorithm and proceeding to step 312 (below).

[0066] The ICM 202 then generates an organization of one or more respective graphical data modules within the user interface based on the one or more sensor devices and the downloaded first algorithm (312). In this regard, at least one of the one or more respective graphical data modules may be configured to receive configuration parameters associated with operation of the infusion device.

[0067] As described above with respect to FIG. 2B, before the organization of the one or more respective graphic data modules is generated, the ICM 202 may select one or more respective graphic data modules 214a from a plurality of predefined graphic data modules 214 based on the selection of the first treatment and the type of the one or more sensor devices 204a.

[0068] 3, the ICM 202 prompts (314) for configuration parameters and receives (316) the configuration parameters via at least one respective graphical data module. In some embodiments, the prompting may be by providing a designated control for receiving input of the parameters via the respective graphical data module. In some embodiments, parameters are required for operation and the module may specifically request input of the parameters before the ICM 202 begins control of the injection.

[0069] The ICM 202 then controls the infusion device based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameters (318). In some embodiments, if the first algorithm facilitates a closed-loop mode, the infusion device may be controlled in a closed-loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameters.

[0070] The ICM 202 may act as an extension of the PCU 12 or the infusion pump via the user interface 210. For example, the ICM 202 may allow for input of infusion parameters, such as the flow rate or amount of medication provided by the infusion device (e.g., via module 214a), and allow for control of the infusion pump based on the input. Additionally, the ICM 202 may download data from other sources, make decisions based on the acquired data and user input, and control the medical device based on an analysis of that data.

[0071] In some embodiments, the ICM 202 may receive information from the infusion device that pertains to or identifies a patient. The ICM 202 may connect to a cloud-based system that is configured to store patient data (e.g., over a network) and download patient order information associated with the patient from the cloud-based system. The ICM 202 may then determine limits for the infusion information based on the patient order information and control the flow rate of the drug provided by the infusion device based on the determined limits. The limits may be determined, for example, by indexing a lookup table based on the patient identification or by querying a server based on the identification.

[0072] According to various embodiments, the modularity of the system provides scalability and a longer life cycle through dynamic updates. For example, a new sensor may be operatively connected to the ICM 202. When the ICM 202 detects the new sensor, the ICM 202 may download a second algorithm associated with the new sensor, update the user interface, and display a new data module associated with the new sensor. Data may then be received from the new sensor and displayed via the new data module. The infusion device may then be controlled in a closed loop mode based on the real-time data received from the new sensor and the one or more sensor devices, the downloaded first and second algorithms, and the received configuration parameters.

[0073] The system may subsequently receive a new algorithm associated with a first sensor of the one or more sensor devices. The new algorithm may be configured to operate the infusion device based on real-time data received from the first sensor. The ICM 202 may automatically replace the first algorithm with a third algorithm and begin controlling the infusion device based on the real-time data received from the one or more sensor devices, the new algorithm, and the received configuration parameters.

[0074] During operation, sensor measurements are received from each sensor and provided to a first algorithm. The algorithm processes the values ​​and provides parameters for adjusting the operation of the infusion device based at least in part on the processing. The ICM 202 may then adjust the operation of the infusion device based on the received parameters.

[0075] In the case of multiple simultaneous closed-loop therapies (e.g., IV glycemic control and hemodynamic stability), the ICM 202 can host simultaneous therapies running one or more closed-loop algorithms with simultaneous connections to different sensors and actuators. Alternative embodiments use multiple ICMs, each running a single closed-loop therapy.

[0076] In some embodiments, multiple data modules may utilize the same sensor and / or the same algorithm. In some embodiments, the ICM 202 may control multiple (different) medical devices simultaneously based on data from the same sensor (e.g., via the user interface 210 and / or modules therein). In one example, the ICM 202 may be configured, upon connecting to a second medical device and receiving a second selection of a second treatment (e.g., from the selection control 212), to verify that at least one corresponding sensor is operably connected to the ICM 202, identify and obtain (e.g., download) a corresponding algorithm, and display at least one graphical data module associated with receiving data from the at least one sensor and controlling the medical device. The ICM 202 may then control the infusion device while simultaneously controlling the second medical device based on the real-time data received from the at least one sensor and the second algorithm.

[0077] In some embodiments, multiple data modules 214 may utilize data from the same sensor. For example, at least one sensor 204 corresponding to a first selected therapy may be one of one or more sensor devices to provide data associated with a second selected therapy. In this manner, an infusion device and a different medical device may then be controlled based on the same data received from the same sensor 204. Each device may be controlled by a different algorithm (and / or data module 214, for example), such that an infusion device may be controlled based on inputting the same data to a first algorithm, and a medical device may be controlled based on inputting the same data to a second algorithm.

[0078] In some embodiments, the ICM 202 may be operatively connected to two infusion devices. In this regard, a second algorithm may be downloaded to the ICM 202 from a server, and the second infusion device may be controlled based on real-time data received from one or more sensor devices and the second algorithm. The second infusion device may be operated based on an additional sensor connected to the control device. Based on detecting the additional sensor being detected (e.g., by the ICM 202), a second algorithm may be downloaded from the server, and the user interface may be updated to display an additional data module associated with the additional sensor, as described above. Data is received from the additional sensor, and the received data is displayed via the additional data module. Further, in some embodiments, the second infusion device may be controlled in a closed loop mode based on real-time data received from the additional sensor, the downloaded first and / or second algorithms, and / or the received configuration parameters.

[0079] Many of the above-described examples 300 and related functions and applications may also be implemented as software processes specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium) and executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, 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, etc. Computer-readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0080] The term "software" is meant to include, as appropriate, firmware resident in read-only memory or applications stored in magnetic storage that can be loaded into memory for processing by a processor. Also, in some embodiments, multiple software aspects of the disclosure can be implemented as subparts of a larger program while still maintaining separate software aspects of the disclosure. In some embodiments, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that together implement the software aspects described herein is within the scope of the disclosure. In some embodiments, the software program, when installed to operate on one or more electronic systems, defines one or more specific machine implementations that execute and perform the operations of the software program.

[0081] A computer program (also known as a program, software, software application, script or code) may be written in any form of programming language, including compiled or interpreted, declarative or procedural, and 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 correspond to a file in a file system, but this does not necessarily have to be the case. A program may be stored in part 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 several coordinated files (e.g. a file storing one or more modules, subprograms or parts of code). A computer program may be deployed to be executed on one computer or on several computers located at one site or distributed across several sites and interconnected by a communication network.

[0082] Application of the ICM to control infusion pumps and / or other medical devices may be used for closed loop treatment of various conditions, such as anesthesia, blood conditions, blood transfusions, care or medicinal transitions, chemotherapy, enteral treatments, exfiltration, fluid balance conditions, glycemic conditions, hemodynamic conditions, hydration, infiltration, nutritional therapy, patient controlled analgesia, patient or fluid temperature conditions, vasopressor ventilation, according to various aspects of the present technology. In such embodiments, the ICM 202 may receive inputs based on one or more intelligent models and / or protocols and / or simulations and make decisions to control the infusion devices. Such models, protocols and simulations may be based at least in part on machine learning algorithms that process training data inputs based on a population of patients with similar conditions to the patient being treated. For example, vasopressor-based therapies may require frequent bolus administration and adjustments of infusion rates to expedite and avoid harmful periods of hypotension or hypertension. The embodiments described above may also be used to control sepsis treatments that require antibiotic administration and fluid resuscitation to correct hypotension. This type of IV fluid management is important for septic patients, and controlling the timing, type and amount of fluid administered is critical, as too much IV fluid can also be harmful.

[0083] As another example, anesthesia may require the administration of a predetermined amount of medication during surgery to achieve the required endpoints of hypnosis, stillness, and suppression of reflexes. It may be given 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 best balance. Using a bi-spectral index sensor 204 (BIS), the ICM 202 may monitor the depth of anesthesia and remotely control the infusion device to administer the appropriate amount of IV medication while simultaneously preventing awakening or excessive depth of anesthesia during drug therapy, thereby improving patient outcomes.

[0084] As another example, the ICM 202 may be connected to a sensor 204 configured as a blood glucose monitor and may maintain the patient's blood glucose by controlling the administration of an infusion device of insulin and / or dextrose solution based on intelligent modeling and continuous blood glucose measurements. Blood glucose (BG) disorders, such as stress-induced hypoglycemia and hyperglycemia, can be common complications in patients in the ICU. In addition, type 1 and 2 diabetic patients are prone to hyperglycemia as well as severe hypoglycemia as a result of insulin overcorrection. For this reason, IV infusion of insulin controlled by the ICM 202 using a closed loop configuration with input from continuous BG measurements is an ideal application for IV infusion of inulin and dextrose to maintain BG levels within a desired range.

[0085] FIG. 4 is a conceptual diagram illustrating an example electronic system 400 for intelligently controlling an infusion according to aspects of the present technology. The electronic system 400 may be a computing device for execution of one or more portions or steps of the process 400 or software associated with the components and processes provided by FIGS. 1-3, including but not limited to the information system server 30, the database 37, the computing hardware in the patient care device 12, the control unit 14, the respective modules 16, 18, 20, 22, or the remote device 32 (e.g., a mobile device). The electronic system 400 may be representative in combination with the present disclosure relating to FIGS. 1-4. In this regard, the electronic system 400 may be a personal computer, or a mobile device such as a smartphone, a tablet computer, a laptop, a PDA, an augmented reality device, a watch or a wearable such as a band or glasses, or a combination thereof, or other touch screen or a television with one or more processors embedded or coupled thereto, or any other type of computer-related electronic device with network connectivity.

[0086] The electronic system 400 may include various types of computer readable media and interfaces for various other types of computer readable media. In the illustrated example, the electronic system 400 includes a bus 408, a processing unit 412, a system memory 404, a read-only memory (ROM) 410, a persistent storage device 402, an input device interface 414, an output device interface 406, and one or more network interfaces 416. In some implementations, the electronic system 400 may include or be integrated with other computing devices or circuits for operation of the various components and processes described above.

[0087] Bus 408 collectively represents all system, peripheral and chipset buses that communicatively connect the various internal devices of electronic system 400. For example, bus 408 communicatively connects processing unit 412 with ROM 410, system memory 404 and persistent storage device 402.

[0088] From these various memory units, the processing unit 412 retrieves instructions to execute and data to process in order to carry out the processes of the present disclosure. In different implementations, the processing unit can be a single processor or a multi-core processor.

[0089] The ROM 410 stores static data and instructions required by the processing unit 412 and other modules of the electronic system. The persistent storage device 402, on the other hand, is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 400 is turned off. Some embodiments of the present disclosure use a mass storage device (such as a magnetic or optical disk and corresponding disk drive) as the persistent storage device 402.

[0090] Other embodiments use a removable storage device (such as a floppy disk, flash drive, and corresponding disk drive) as the persistent storage device 402. Like the persistent storage device 402, the system memory 404 is a read-write memory device. However, unlike the storage device 402, the system memory 404 is a volatile read-write memory, such as a random access memory. The system memory 404 stores some of the instructions and data that the processor needs during execution. In some embodiments, the processes of the present disclosure are stored in the system memory 404, the persistent storage device 402, and / or the ROM 410. From these various memory units, the processing unit 412 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[0091] The bus 408 also connects to an input device interface 414 and an output device interface 406. The input device interface 414 allows a user to communicate information and selected commands to the electronic system. Input devices used with the input device interface 414 include, for example, alphanumeric keyboards and pointing devices (also called "cursor control devices"). The output device interface 406 allows, for example, the display of images generated by the electronic system 400. Output devices used with the output device interface 406 include, for example, printers and display devices such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Some implementations include devices such as touch screens that function as both input and output devices.

[0092] 4, the bus 408 also couples the electronic system 400 to a network (not shown) via a network interface 416. The network interface 416 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. The network interface 416 may also include hardware (e.g., Ethernet hardware) for connecting the computer to a network of computers such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or a network of computers such as an intranet or a portion of a network of networks such as the Internet. Any or all of the components of the electronic system 400 may be used in conjunction with the present disclosure.

[0093] The functions described above may be implemented in computer software, firmware, or hardware. One or more computer program products may be used to implement the technology. Programmable processors and computers may be included in or packaged as mobile devices. Processes and logic flows may be executed by one or more programmable processors and by one or more programmable logic circuits. General purpose and special purpose computing devices and storage devices may be interconnected via a communications network.

[0094] Some embodiments include electronic components, such as a microprocessor, storage, and memory, that store computer program instructions on a machine-readable or computer-readable medium (also referred to as a computer-readable storage medium, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact disc (CD-ROM), recordable compact disc (CD-R), rewritable compact disc (CD-RW), read-only digital versatile disc (e.g., DVD-ROM, double-layer DVD-ROM), various recordable / rewritable DVDs (DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and / or solid state hard drives, read-only and recordable Blu-Ray® disks, extra-high density optical disks, any other optical or magnetic medium, and floppy disks. The computer readable medium may store a computer program that is executable by at least one processing unit and includes a set of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as produced by a compiler, and files containing high-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0095] While the above description primarily refers to microprocessors or multi-core processors executing software, some implementations are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs), in some implementations, such integrated circuits execute instructions stored on the circuitry itself.

[0096] The terms "computer," "server," "processor," and "memory" as used herein and in any claims of this application all refer to an electronic device or other technological device. These terms exclude a person or group of people. For purposes of this specification, the terms display or displaying mean displaying on an electronic device. The terms "computer-readable medium" and "computer-readable mediums" as used herein and in any claims of this application are entirely limited to tangible physical objects that store information in a form readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0097] To provide for user interaction, embodiments of the subject matter described herein 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 a user, and a keyboard and pointing device, e.g., a mouse or track ball, by which the user can provide input to the computer. Other types of devices may be used to provide for user interaction as well, e.g., feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic input, speech input, or tactile input. Additionally, the computer may interact with the user by sending and receiving documents to and from a device used by the user, e.g., by sending a web page on a web browser on the user's client device in response to a request received from the web browser.

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

[0099] A computing system may include clients and servers. Clients and servers are generally remote from each other and may interact through a communications network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server sends data (e.g., HTML pages) to a client device (e.g., to display the data to a user interacting with the client device and receive user input from the user). Data generated at the client device (e.g., the result of user interaction) may be received from the client device by the server.

[0100] Those skilled in the art will appreciate that the various exemplary blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability of hardware and software, the various exemplary blocks, modules, elements, components, methods, and algorithms have been described generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. The described functionality may be implemented in various ways for each particular application. The various components and blocks may be configured differently (e.g., arranged in a different order or divided in a different way) all without departing from the scope of the present technology.

[0101] Examples of clauses of this technology

[0102] Various examples of aspects of the present disclosure are described for convenience as numbered clauses (1, 2, 3, etc.). These are provided as examples and are not intended to limit the technology. Figure and reference number identification is provided below for illustrative purposes only, and the clauses are not limited by those identifications.

[0103] Clause 1. An infusion control device comprising a non-transitory machine-readable memory and a processor operably connected to a display and the memory, wherein the processor is configured to: provide a user interface on the display, prompt a user to select a therapy via the user interface, receive the selected therapy from the user interface, verify that one or more sensor devices required for the selected therapy are operably connected to the infusion control device, verify that one or more intravenous infusion devices are operably connected to the infusion control device and that the one or more intravenous infusion devices are controllable based on information derivable from the sensor devices, obtain a first algorithm configured to operate the one or more intravenous infusion devices based on real-time data received from the one or more sensor devices, and facilitate execution of the selected therapy based on sensor data received from the one or more sensor devices, wherein at least a portion of the sensor data is processed via the first algorithm.

[0104] Clause 2. The infusion control device of clause 1, wherein the processor is further configured to operably connect an infusion control device, which is physically separate from the one or more intravenous infusion devices, to a first infusion device of the one or more intravenous infusion devices, and based on receiving a selection of a treatment, generate a default organization of one or more respective graphical data modules in the user interface based on the one or more sensor devices and the first algorithm, wherein at least one of the one or more respective graphical data modules is configured to receive configuration parameters associated with operation of the first infusion device, and the processor is further configured to receive the configuration parameters via the at least one respective graphical data module, and control the first infusion device based on real-time data received from the one or more sensor devices, the first algorithm and the received configuration parameters.

[0105] Clause 3. The infusion control device of clause 2, wherein the first algorithm is configured to operate the first infusion device in a closed-loop mode based on real-time data received from the one or more sensor devices, and controlling the first infusion device includes controlling the first infusion device in a closed-loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm and the received configuration parameters.

[0106] Clause 4. The infusion control device of clause 3, further configured to: detect an additional sensor operatively connected to the control device; and based on detecting the additional sensor, download a second algorithm associated with the additional sensor from the server to the control device; update a user interface, display an additional data module associated with the additional sensor, receive data from the additional sensor, display the data received via the additional data module, and control the first infusion device in a closed loop mode based on the real-time data received from the additional sensor and the one or more sensor devices, the downloaded first and second algorithms and the received configuration parameters.

[0107] Clause 5. The infusion control device of any one of clauses 2 to 4, wherein the processor is further configured to receive a third algorithm associated with a first sensor of the one or more sensor devices, the third algorithm configured to operate the first infusion device based on real-time data received from the first sensor, automatically replace the first algorithm with the third algorithm, and control the first infusion device based on the real-time data received from the one or more sensor devices, the third algorithm and the received configuration parameters.

[0108] Clause 6. The infusion control device of any one of clauses 2 to 5, wherein the one or more sensor devices comprise a physiological monitor connected to the patient and configured to measure physiological signals from the patient, the real-time data including measurements of the physiological signals, and the processor is further configured to provide the measurements to a first algorithm, receive parameters for adjusting operation of the first infusion device from the first algorithm based on providing the measurements to the first algorithm, and adjust operation of the first infusion device based on the received parameters.

[0109] Clause 7. An infusion control device as described in any one of clauses 2 to 6, wherein the processor is further configured to select one or more respective graphic data modules from a plurality of predefined graphic data modules based on a selected treatment selection and a type of one or more sensor devices before generating a default organization of the one or more respective graphic data modules.

[0110] Clause 8. The infusion control device of any one of clauses 2 to 7, further configured to: operably connect the control device to the medical device; receive a second selection of a second treatment from the user interface; and based on receiving the second selection, determine that at least one sensor corresponding to the second treatment is operably connected to the control device; download from the server a second algorithm configured to operate the medical device based on real-time data received from the at least one sensor; display at least one graphical data module associated with receiving data from the at least one sensor and controlling the medical device; and simultaneously control the first infusion device while controlling the medical device based on the real-time data received from the at least one sensor and the second algorithm.

[0111] Clause 9. The infusion control device of any one of clauses 2 to 8, wherein the processor is further configured to verify that one or more sensor devices are associated with the selected treatment and the first infusion device type before downloading the first algorithm and generating the organization within the user interface.

[0112] Clause 10. An infusion control device as described in any one of clauses 2 to 9, wherein the processor is further configured to operably connect an infusion control device, which is physically separate from the second infusion device, to a second infusion device of the one or more intravenous infusion devices, download a second algorithm from the server to the control device, and control the second infusion device based on real-time data received from the one or more sensor devices and the second algorithm.

[0113] Clause 11. The infusion control device of clause 10, wherein the processor is further configured to adjust a parameter of the second infusion device based on an alert from the first infusion device.

[0114] Clause 12. An infusion control device as described in any one of clauses 1 to 11, wherein the infusion control device further comprises a display.

[0115] Clause 13. A method of intelligently controlling intravenous infusion, comprising the steps of: receiving an indication that a control device is operably connected to one or more intravenous infusion devices, the control device being physically separate from the one or more intravenous infusion devices; presenting for the control device a user interface configured to provide a selection of one or more predefined treatments associated with the one or more intravenous infusion devices and configured to display one or more graphical data modules based on the selection; receiving at the control device a selection of a first treatment of the one or more predefined treatments provided by the user interface; determining at the control device that one or more sensor devices are operably connected to the control device for providing data associated with the selected first treatment based on receiving the selection of the first treatment; and downloading from the server to the control device a first algorithm configured to operate one or more intravenous infusion devices based on real-time data received from the one or more sensor devices; generating a default organization of one or more respective graphic data modules in a user interface based on the one or more sensor devices and the downloaded first algorithm, where at least one of the one or more respective graphic data modules is configured to receive configuration parameters associated with operation of the one or more intravenous infusion devices; prompting the configuration parameters; receiving the configuration parameters via the at least one respective graphic data module; and controlling the one or more intravenous infusion devices based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameters.

[0116] Clause 14. The method of clause 13, wherein the first algorithm is configured to operate the first infusion device in a closed loop mode based on real-time data received from the one or more sensor devices, and controlling the first infusion device includes controlling the first infusion device in a closed loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm and the received configuration parameters.

[0117] Clause 15. The method of clause 14, further comprising the steps of detecting a new sensor operatively connected to the control device; and based on detecting the new sensor, downloading a second algorithm associated with the new sensor from the server to the control device; updating a user interface and displaying a new data module associated with the new sensor; receiving data from the new sensor and displaying the received data via the new data module; and controlling the first infusion device in a closed loop mode based on the real-time data received from the new sensor and the one or more sensor devices, the downloaded first and second algorithms and the received configuration parameters.

[0118] Clause 16. The method of any one of clauses 13 to 15, further comprising the step of verifying that one or more sensor devices are associated with the first treatment and the first infusion device type before downloading the first algorithm and generating a default organization within the user interface.

[0119] Clause 17. The method of any one of clauses 13 to 16, further comprising the steps of receiving a third algorithm associated with a first sensor of the one or more sensor devices, the third algorithm configured to operate the first infusion device based on real-time data received from the first sensor, automatically replacing the first algorithm with the third algorithm, and controlling the first infusion device based on the real-time data received from the one or more sensor devices, the third algorithm and the received configuration parameters.

[0120] Clause 18. The method of any one of clauses 13 to 17, wherein the one or more sensor devices comprise a physiological monitor connected to the patient and configured to measure physiological signals from the patient, and the real-time data includes measurements of the physiological signals, the method further comprising the steps of providing the measurements to a first algorithm, receiving parameters for adjusting operation of the first infusion device from the first algorithm based on providing the measurements to the first algorithm, and adjusting operation of the first infusion device based on the received parameters.

[0121] Clause 19. The method according to any one of clauses 13 to 18, wherein the method further comprises the step of selecting one or more respective graphic data modules from a plurality of predefined graphic data modules based on the first treatment selection and the one or more sensor device types before generating a default organization of the one or more respective graphic data modules.

[0122] Clause 20. The method of any one of clauses 13 to 19, further comprising the steps of: operably connecting the control device to the medical device; receiving, from the user interface for the medical device, a second selection of a second treatment from the one or more predetermined treatments provided by the user interface; and based on receiving the second selection, verifying that at least one sensor corresponding to the second treatment is operably connected to the control device; downloading from the server a second algorithm configured to operate the medical device based on real-time data received from the at least one sensor; displaying at least one graphical data module associated with receiving data from the at least one sensor and controlling the medical device; and simultaneously controlling the first infusion device while controlling the medical device based on the real-time data received from the at least one sensor and the second algorithm.

[0123] Clause 21. The method of clause 20, wherein the at least one sensor corresponding to the second treatment is one of one or more sensor devices for providing data associated with the selected first treatment, and the method further includes controlling the first injection device and the medical device based on the same data received from the at least one sensor, wherein the first injection device is controlled based on input of the same data to a first algorithm and the medical device is controlled based on input of the same data to a second algorithm.

[0124] Clause 22. The method of any one of clauses 13 to 21, further comprising the steps of: identifying a patient designated to receive treatment from the first infusion device based on information received from the first infusion device; operably connecting the controlling device to a cloud-based system configured to store patient data; downloading patient order information associated with the patient from the cloud-based system; receiving, at the controlling device, infusion information from the first infusion device comprising a flow rate or amount of drug provided by the first infusion device; determining, at the controlling device, limits for the infusion information based on the patient order information; and controlling, at the controlling device, the flow rate of drug provided by the first infusion device based on the determined limits for the infusion information.

[0125] Clause 23. The method of any one of clauses 13 to 22, further comprising the steps of operably connecting the infusion control device to a second infusion device of the one or more intravenous infusion devices, the infusion control device being physically separate from the second infusion device, downloading a second algorithm from the server to the control device, and controlling the second infusion device based on real-time data received from the one or more sensor devices and the second algorithm.

[0126] Clause 24. The method of claim 23, further comprising adjusting a parameter of the second infusion device based on an alert from the first infusion device.

[0127] Clause 25. A non-transitory machine-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method according to any one of clauses 13 to 24.

[0128] Further considerations

[0129] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of an example approach. It is understood that the specific order or hierarchy of steps in the processes may be rearranged based on design preferences. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

[0130] The above description is provided to enable those skilled in the art to practice the various aspects described herein. The above description provides various examples of the present technology, and the technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects set forth herein, but are to be accorded the full scope consistent with the claims of the language, and references to elements in the singular are not intended to mean "only one" unless otherwise specified, but rather "one or more". The term "some" refers to one or more, unless otherwise specified. Masculine pronouns (e.g., his) include feminine and neuter (e.g., her and its), and vice versa. Headings and subheadings, if any, are used for convenience only and are not intended to limit the invention described herein.

[0131] The term website as used herein may include any aspect of a website, including one or more web pages, one or more servers used to host or store web-related content, and the like. Thus, the term website may be used interchangeably with the terms web page and server. The terms "configured to," "operable to," and "programmed to" do not imply any particular material or non-material modification of the subject matter, but rather are intended to be used interchangeably. For example, a processor configured to monitor and control an operation or component may also mean that the processor is programmed to monitor and control the operation or that the processor is operable to monitor and control the operation. Similarly, a processor configured to execute code may be interpreted as a processor programmed to execute code or operable to execute code.

[0132] The term automatic as used herein may include execution by a computer or machine without user intervention, for example, by instructions in response to a predicated action by a computer or machine or other initiation 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.

[0133] A phrase such as "aspect" does not imply that such aspect is essential to the technology, nor does it imply that such aspect applies to all configurations of the technology. A disclosure regarding an aspect may apply to all configurations, or to one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects, and vice versa. A phrase such as "embodiment" does not imply that such embodiment is essential to the technology, nor does it apply to all configurations of the technology. A disclosure regarding an embodiment may apply to all configurations, or to one or more examples. An embodiment may provide one or more examples. A phrase such as "embodiment" may refer to one or more examples, and vice versa. A phrase such as "configuration" does not imply that such embodiment is essential to the technology, nor does it apply to all configurations of the technology. A disclosure regarding a configuration may apply to all configurations, or to one or more configurations. A configuration may provide one or more examples. A phrase such as "a configuration" may refer to one or more configurations, and vice versa.

Claims

1. a non-transitory machine-readable memory; a processor operatively connected to the display and to the memory; 1. An infusion control device comprising: The processor, providing a user interface on said display; prompting a user via said user interface to select a treatment; receiving a treatment selected from the user interface; Verifying that one or more sensor devices required for the selected therapy are operably connected to the infusion control device; determining that one or more intravenous infusion devices are operatively connected to said infusion control device and that said one or more intravenous infusion devices are controllable based on information derivable from said sensor device; obtaining a first algorithm configured to operate the one or more intravenous infusion devices based on real-time data received from the one or more sensor devices; and facilitating execution of the selected therapy based on sensor data received from the one or more sensor devices. It is configured as follows: At least a portion of the sensor data is processed through the first algorithm.

2. The processor, operatively connecting the infusion control device to a first one of the one or more intravenous infusion devices, the infusion control device being physically separate from the one or more intravenous infusion devices; based on receiving the selection of the treatment, generating a default organization of one or more respective graphic data modules in the user interface based on the one or more sensor devices and the first algorithm, at least one of the one or more respective graphic data modules configured to receive configuration parameters associated with operation of the first infusion device; receiving said configuration parameters via said at least one respective graphic data module; Controlling the first infusion device based on the real-time data received from the one or more sensor devices, the first algorithm, and the received configuration parameters. The infusion control device of claim 1 , further configured to:

3. the first algorithm is configured to operate the first infusion device in a closed loop mode based on the real-time data received from the one or more sensor devices; 3. The injection control device of claim 2, wherein controlling the first injection device includes controlling the first injection device in the closed loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameters.

4. The processor, Detecting an additional sensor operably connected to the control device; Based on detecting the additional sensor, downloading a second algorithm associated with the additional sensor from a server to the control device; updating the user interface to display additional data modules associated with the additional sensors; receiving data from the additional sensor and displaying the received data via the additional data module; and controlling the first infusion device in the closed-loop mode based on real-time data received from the additional sensor and the one or more sensor devices, the downloaded first and second algorithms, and the received configuration parameters. The infusion control device of claim 3 further configured to:

5. The processor, receiving a third algorithm associated with a first sensor of the one or more sensor devices, the third algorithm configured to operate the first infusion device based on real-time data received from the first sensor; automatically replacing the first algorithm with the third algorithm; and controlling the first infusion device based on real-time data received from the one or more sensor devices, the third algorithm, and the received configuration parameters.

5. An infusion control device according to claim 2, further configured to:

6. the one or more sensor devices comprise a physiological monitor configured to be connected to a patient and to measure physiological signals from the patient, the real-time data including measurements of the physiological signals; The processor, providing the measurements to the first algorithm; receiving parameters from the first algorithm for adjusting operation of the first infusion device based on providing the measurements to the first algorithm; adjusting the operation of the first infusion device based on the received parameters.

6. An infusion control device according to claim 2, further configured to:

7. Prior to generating the default organization of the one or more respective graphics data modules, the processor: selecting the one or more respective graphic data modules from a plurality of predefined graphic data modules based on the selection of the selected treatment and the type of the one or more sensor devices; 7. An infusion control device according to claim 2, further configured to:

8. The processor, operatively connecting the control device to a medical device; receiving a second selection of a second treatment from the user interface; based on receiving the second selection, Verifying that at least one sensor corresponding to the second treatment is operably connected to the control device; downloading from a server a second algorithm configured to operate the medical device based on real-time data received from the at least one sensor; displaying at least one graphical data module associated with receiving data from the at least one sensor and controlling the medical device; and controlling the first infusion device while simultaneously controlling the medical device based on the real-time data received from the at least one sensor and the second algorithm.

8. An infusion control device according to claim 2, further configured to:

9. The processor, Verifying that the one or more sensor devices are associated with the selected therapy and the first infusion device type prior to downloading the first algorithm and generating the organization within the user interface.

9. An infusion control device according to any one of claims 2 to 8, further configured to:

10. The processor, operatively connecting the infusion control device to a second infusion device of the one or more intravenous infusion devices, the infusion control device being physically separate from the second infusion device; downloading a second algorithm from a server to the control device; Controlling the second infusion device based on the real-time data received from the one or more sensor devices and the second algorithm.

10. An infusion control device according to any one of claims 2 to 9, further configured to:

11. The processor, Adjusting parameters of the second infusion device based on an alert from the first infusion device. The infusion control device of claim 10 further configured to:

12. The infusion control device of claim 1 , further comprising a display.

13. 1. A method for intelligently controlling an intravenous infusion, comprising: receiving an indication that a control device is operably connected to one or more intravenous infusion devices, the control device being physically separate from the one or more intravenous infusion devices; presenting, for the control device, a user interface configured to provide a selection of one or more predetermined therapies associated with the one or more intravenous infusion devices and configured to display one or more graphical data modules based on the selection; receiving, at the control device, a selection of a first treatment of the one or more predetermined treatments provided by the user interface; based on receiving the selection of the first treatment, at the control device, determining that one or more sensor devices are operably connected to the control device for providing data associated with the selected first treatment; based on determining that the one or more sensor devices are operably connected to the control device, downloading from a server to the control device a first algorithm configured to operate the one or more intravenous infusion devices based on real-time data received from the one or more sensor devices; generating a default organization of one or more respective graphic data modules in the user interface based on the one or more sensor devices and the downloaded first algorithm, at least one of the one or more respective graphic data modules configured to receive configuration parameters associated with operation of the one or more intravenous infusion devices; prompting said configuration parameters; receiving said configuration parameters via said at least one respective graphic data module; controlling the one or more intravenous infusion devices based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameters; The method includes:

14. the first algorithm is configured to operate a first infusion device in a closed loop mode based on the real-time data received from the one or more sensor devices; 14. The method of claim 13, wherein controlling the first infusion device comprises controlling the first infusion device in the closed loop mode based on the real-time data received from the one or more sensor devices, the downloaded first algorithm, and the received configuration parameters.

15. The method comprises: detecting a new sensor operably connected to the control device; Based on detecting the new sensor, downloading from the server to the control device a second algorithm associated with the new sensor; updating the user interface to display a new data module associated with the new sensor; receiving data from the new sensor and displaying the received data via the new data module; controlling the first infusion device in the closed loop mode based on real-time data received from the new sensor and the one or more sensor devices, the downloaded first and second algorithms, and the received configuration parameters; The method of claim 14 further comprising:

16. The method comprises: Verifying that the one or more sensor devices are associated with the first therapy and a first infusion device type prior to downloading the first algorithm and generating the default organization within the user interface.

16. The method of any one of claims 13 to 15, further comprising:

17. The method comprises: receiving a third algorithm associated with a first sensor of the one or more sensor devices, the third algorithm configured to operate the first infusion device based on real-time data received from the first sensor; automatically replacing the first algorithm with the third algorithm; controlling the first infusion device based on real-time data received from the one or more sensor devices, the third algorithm, and the received configuration parameters; 17. The method of any one of claims 13 to 16, further comprising:

18. the one or more sensor devices comprise a physiological monitor configured to be connected to a patient and to measure physiological signals from the patient, the real-time data including measurements of the physiological signals; The method comprises: providing the measurements to the first algorithm; receiving parameters from the first algorithm for adjusting operation of the first infusion device based on providing the measurements to the first algorithm; adjusting the operation of the first infusion device based on the received parameters.

18. The method of any one of claims 13 to 17, further comprising:

19. The method further comprises, prior to generating the default organization of the one or more respective graphic data modules, selecting the one or more respective graphical data modules from a plurality of predefined graphical data modules based on the selection of the first treatment and a type of the one or more sensor devices.

19. The method of any one of claims 13 to 18, further comprising:

20. The method comprises: operably connecting the control device to a medical device; receiving, for the medical device, from the user interface, a second selection of a second treatment of the one or more predetermined treatments provided by the user interface; based on receiving the second selection, verifying that at least one sensor corresponding to the second treatment is operably connected to the control device; downloading from the server a second algorithm configured to operate the medical device based on real-time data received from the at least one sensor; displaying at least one graphical data module associated with receiving data from the at least one sensor and controlling the medical device; controlling the first infusion device while simultaneously controlling the medical device based on the real-time data received from the at least one sensor and the second algorithm.

20. The method of any one of claims 13 to 19, further comprising:

21. the at least one sensor corresponding to the second treatment is one of the one or more sensor devices for providing data associated with the selected first treatment; 21. The method of claim 20, further comprising controlling the first infusion device and the medical device based on the same data received from the at least one sensor, wherein the first infusion device is controlled based on input of the same data to the first algorithm and the medical device is controlled based on input of the same data to the second algorithm.

22. The method comprises: identifying a patient designated to receive treatment from the first infusion device based on information received from the first infusion device; operatively connecting the controlling device to a cloud-based system configured to accumulate patient data; downloading patient order information associated with the patient from the cloud based system; receiving, at the control device, infusion information from the first infusion device comprising a flow rate or amount of drug provided by the first infusion device; determining, at the control device, limits for the infusion information based on the patient's order information; controlling, with the control device, the flow rate of the medication provided by the first infusion device based on the determined limit of the infusion information; 22. The method of any one of claims 13 to 21, further comprising:

23. The method comprises: operatively connecting the infusion control device to a second infusion device of the one or more intravenous infusion devices, the infusion control device being physically separate from the second infusion device; downloading a second algorithm from a server to the control device; controlling the second infusion device based on the real-time data received from the one or more sensor devices and the second algorithm; 23. The method of any one of claims 13 to 22, further comprising:

24. The method comprises: adjusting a parameter of the second infusion device based on an alert from the first infusion device.

24. The method of claim 23, further comprising:

25. 25. A non-transitory machine-readable medium storing instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 13 to 24.

Images