Modular injection control device and method

Abstract

The infusion control module is electrically connected to a patient care unit, such as a drug infusion system, and is configured to receive an instruction that it is electronically coupled to the mainframe of the patient care unit, and to switch the patient care unit to a mode in which the patient care unit is controlled by the control module. The control module determines that the patient care unit is programmed to deliver drugs using an infusion device module coupled to the mainframe, determines that the drugs are suitable for a treatment pre-programmed in the infusion control module, and operates the infusion device module to deliver drugs according to the treatment while electronically coupled to the mainframe infusion controller.

Description

Technical Field

[0001] This application generally relates to the control of infusion devices.

Background Art

[0002] A patient care unit may include a modular infusion platform that can be extended with multiple drug delivery modules to handle the delivery of two or more types of drugs to a patient. Different patients require different levels of treatment and different parameters for different devices. Each individual infusion device may operate differently and may include different types of user interfaces, resulting in a wide variety of display types and parameter variations that can potentially confuse or distract a clinician during infusion and other drug delivery procedures.

[0003] Furthermore, modern infusion devices are mobile and can administer drugs to a patient as the patient moves between care areas throughout a medical environment such as a hospital organization. The inability to maintain control of the device in different environments increases the health risk to patients in a medical facility. Additionally, some infusion devices may not be suitable for switching between different medical environments, especially when rapid patient movement between different care units with different life-saving emergencies and different devices may be required.

Summary of the Invention

[0004] The subject technology provides devices, systems, and methods for intelligently controlling medical devices, more specifically infusion devices, using modular infusion control devices. The intelligent infusion control module of the subject technology directly controls connected infusion devices, helping clinicians provide more centralized control and management of the devices. The control module provides a modular interface system that attaches to legacy devices and provides an interface with external sensors and devices to facilitate control of connected medical devices. The module is configured to take over control of drug delivery by pump, then disconnect from the pump, and continue control of drug delivery using a different pump. The control module can further connect to server and cloud-based systems for further data entry, data reconciliation, and reporting.

[0005] In this regard, the subject art includes an infusion control module configured to receive an instruction that it is electronically coupled to a mainframe infusion controller, the mainframe infusion controller to control one or more infusion device modules coupled to the mainframe infusion controller, the infusion control module to determine that the mainframe infusion controller is programmed to control drug delivery using the infusion device modules coupled to the mainframe infusion controller, the infusion control module to determine that the drug is suitable for a treatment pre-programmed within the infusion control module, and the infusion control module to cause the infusion device modules to deliver the drug according to the treatment while electronically coupled to the mainframe infusion controller. Other embodiments include corresponding devices, methods, and computer program products for implementing corresponding systems and their features.

[0006] A mechanical implementation method includes the steps of: receiving an instruction from an infusion control module that the infusion control module is electronically coupled to a mainframe infusion controller, wherein the mainframe infusion controller is configured to control one or more infusion device modules coupled to the mainframe infusion controller; determining by the infusion control module that the mainframe infusion controller is programmed to deliver a drug using the infusion device modules coupled to the mainframe infusion controller; determining by the infusion control module that the drug is suitable for a treatment pre-programmed within the infusion control module; and causing the infusion device modules to deliver the drug according to the treatment while electronically coupled to the mainframe infusion controller. Other embodiments include corresponding devices, systems, and computer program products for carrying out the corresponding methods and their features.

[0007] It will be understood that other configurations of the subject art will be readily apparent to those skilled in the art from the following detailed description, and here the various configurations of the subject art are shown and described as examples. As will be understood, the subject art is capable of other and different configurations, and some of its details can be modified in various other ways, all without departing from the scope of the subject art. Therefore, the drawings and detailed description should be considered as examples and not as limitations.

[0008] For a better understanding of the various described implementations, please refer to the embodiments for carrying out the invention described below in conjunction with the following drawings. Similar reference numbers refer to corresponding parts throughout the drawings and description. [Brief explanation of the drawing]

[0009] [Figure 1A] This figure shows an example of an in-facility patient care system in a medical organization, based on the aspects of the subject technology. [Figure 1B]Figure 1A shows a detailed view of a part of an exemplary patient care unit, illustrating various aspects of the subject technology. [Figure 2] This figure shows a patient care unit having connected infusion device modules 18, 20 configured to deliver fluids, a mainframe infusion controller, and a modular infusion control device, according to various aspects of the subject technology. [Figure 3-1] This is an exemplary flowchart for controlling an injection device using a modular injection control module, according to an aspect of the subject technology. [Figure 3-2] This is an exemplary flowchart for controlling an injection device using a modular injection control module, according to an aspect of the subject technology. [Figure 3-3] This is an exemplary flowchart for controlling an injection device using a modular injection control module, according to an aspect of the subject technology. [Figure 3-4] This is an exemplary flowchart for controlling an injection device using a modular injection control module, according to an aspect of the subject technology. [Figure 4] This figure shows an exemplary process for controlling an injection device using a modular injection control module, according to an aspect of the subject technology. [Figure 5] This is a conceptual diagram illustrating an exemplary electronic system for controlling an injection device using a modular injection control module, according to an aspect of the subject technology. [Modes for carrying out the invention]

[0010] Here, we refer to the implementation configurations, and examples are shown in the attached drawings. The following description provides numerous specific details to help understand the various implementation configurations described. However, it will be apparent to those skilled in the art that the various implementation configurations described can be implemented without these specific details. In other cases, well-known methods, procedures, components, circuits, and networks are not described in detail so as not to obscure the nature of the implementation configurations unnecessarily.

[0011] The subject technology provides an intelligent infusion control module, which includes a mobile unit that provides processing for control algorithms and a connection that enables closed-loop and semi-closed-loop control functions on one or more medical devices at the time of use. In some implementations, the control module is configured to operably connect to a legacy infusion device interface to provide operable support and technical extensions to legacy equipment. In this way, the control module can be coupled to an infusion pump, take over control of the pump's control system, and provide updated functionality to an existing pump system. Under control, the basic system of the pump for drug delivery can continue to operate using the legacy circuitry, with monitoring, control, and management provided by the control module. In this regard, the pump is extended by the technology provided by the control module without further modification of the pump mechanism.

[0012] The control module may further provide an external interface between the pump and one or more different physiological sensors and provide input parameters used to control the titration of IV infusion of medication to the patient. In this regard, the control module may incorporate control software (e.g., including one or more algorithms) that can be tailored to specific or general medical procedures.

[0013] A closed-loop control system generally refers to a system that does not rely on external manual input to deliver treatment. Once configured, a closed-loop system can autonomously deliver treatment, receive feedback from one or more sensors, and automatically adjust the treatment as needed based on that feedback. A semi-closed-loop control system is similar to a closed-loop control system, except that in some situations, adjustments to treatment may rely on external input. In some implementations, a semi-closed-loop control system is sometimes called a decision support system.

[0014] Depending on the implementation, the control module of the subject technology may be separate from the embedded firmware and sensors of both pumps and may utilize control software that can facilitate a scalable and rapidly configured system for providing closed-loop control of medical procedures. Furthermore, the control module may be configured to operate with a number of sensors by electrical connectors and / or wireless communication. The module may include one or more microprocessors and algorithms for providing signal conditioning and / or conversion of sensor signals to appropriate physiological parameters of the connected infusion device. The parameters can then be used in the control algorithm to provide control to the infusion pump for delivering, for example, the required 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 devices.

[0015] Controlling the pump as a separate unit by a control module offers several advantages. For example, advances in sensors can be much faster than the development of the infusion pump system, and therefore the control system can respond more quickly to these changes. It may be desirable to update the control algorithm to address changes in treatment methods, available medications, and patient physiology. For this reason, it may be desirable to have the algorithm reside in the control module rather than the pump system to accommodate more frequent changes. Furthermore, machine learning and artificial intelligence can account for patient variability related to physiological parameters such as age, genetics, health history, and other characteristics and environmental factors. Systems incorporating such capabilities may include large databases and complex programs that require powerful microprocessors and data storage capabilities to perform the necessary timely and accurate calculations. If such systems generally cannot run on systems currently available with IV pumps alone, the control module can be connected to and leveraged by such systems to facilitate the operation of the connected infusion device.

[0016] In addition, the control module of the subject technology is adaptable to various pump systems and sensor inputs. The control module may be further configured to add wireless, Bluetooth®, and LAN connectivity to pump systems for which such connectivity is not currently available. Adding such communication to the pump system may enable remote monitoring and control of the infusion pump, as well as other functions such as access to the patient's EMR. Thus, by integrating electrical and processing components separate from the pump, the subject technology facilitates the integration of additional functions without requiring modifications to 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.

[0017] Figure 1A shows an example of an in-facility patient care system 100 of a medical organization according to an embodiment of the subject technology. In Figure 1A, a patient care unit 12 (or, more generally, a “medical device” or “infusion device”) is connected to a hospital network 10. A patient care unit (or “PCU”) may include a variety of auxiliary medical devices, such as an infusion pump, vital sign monitor, drug dispensing device (e.g., cabinet, tote), drug preparation device, automated dispensing device, a module combined with any of the aforementioned (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 medical network 10 by a transmit channel 31. The transmit channel 31 is any wired or wireless transmit channel, e.g., a 502.11 wireless local area network (LAN). In some implementations, the network 10 also includes computer systems installed in various departments throughout the hospital. For example, network 10 in Figure 1A optionally includes an inpatient department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, and a computer system associated with one or more unit station computers and / or medical decision support systems. As will be further described below, network 10 may include separate subnetworks. In the illustrated example, network 10 includes a device network 40 through which patient care units 12 (and other devices) communicate according to their normal operation.

[0018] In addition, the in-facility patient care system 100 may incorporate a separate information system server 30. Furthermore, although the information system server 30 is shown as a separate server, its functions and programming may be integrated into a separate computer if desired by the facility's information system design engineer. The in-facility 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 assistance, and mobile devices such as laptops, tablet computers, augmented reality devices, or smartphones, and consist of software for communicating with the information system server 30 via the network 10.

[0019] The patient care unit 12 comprises a system for providing patient care, such as that described by Eggers et al., which is incorporated herein by reference for that purpose. The patient care unit 12 may include or incorporate a pump, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), therapeutic devices, and other drug delivery devices that may be used in accordance with the teachings described herein. In the illustrated example, the patient care unit 12 comprises a control module 14, also called a mainframe infusion controller 14, connected to one or more functional modules 16, 18, 20, 22. The mainframe infusion controller 14 includes a central processing unit (CPU) 50 connected to memory, e.g., random access memory (RAM) 58, and one or more interface devices such as a user interface device 54 for communicating with additional modules or devices, an encoded data input device 60, a network connection 52, and an auxiliary interface 62. The mainframe injection controller 14 also includes, though not necessarily, a main non-volatile storage unit 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 aforementioned elements.

[0020] In various implementations, the user interface device 54 is a touchscreen for displaying information to the user and allowing the user to input information by touching a designated area of ​​the screen. Additionally or alternatively, the user interface device 54 may include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. The data input device 60 may be a barcode reader capable of scanning and interpreting data printed in a barcoded format. Additionally or alternatively, the data input device 60 may be any device for inputting encoded data into a computer, such as a device for reading magnetic strips, an RFID (Radio-Frequency Identification) device in which digital data encoded on an RFID tag or smart label (as 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 personal digital assistant (PDA). Depending on the type of interface device used, the user interface device 54 and the data input device 60 may be the same device. Although the data input device 60 is shown in Figure 1A as being located within the mainframe infusion controller 14, it is recognized that the data input device 60 may be integrated within the pharmacy system 34 or located externally and communicate with the pharmacy system 34 via an RS-232 serial interface or any other suitable means of communication. The auxiliary interface 62 may be an RS-232 communication interface, but any other means of communication with peripheral devices such as a printer, patient monitor, infusion pump, or other medical device may be used without departing from the subject art.In addition, the data input device 60 may be separate functional modules such as modules 16, 18, 20, and 22, and may be configured to communicate with the mainframe injection (controller) device 14 or any other system on the network using appropriate programming and communication protocols.

[0021] The network connection 52 may be a wired or wireless connection such as Ethernet, WiFi, BLUETOOTH®, Integrated Services Digital Network (ISDN) connection, Digital Subscriber Line (DSL) modem, or cable modem. Any direct or indirect network connection may be used, including, but not limited to, a telephone modem, MIB system, RS232 interface, auxiliary interface, optical link, infrared link, radio frequency link, microwave link or WLANS connection, or other wireless connection.

[0022] The functional modules 16, 18, 20, 22 are any devices for providing care to a patient or monitoring the patient's condition. As shown in FIG. 1A, at least one of the functional modules 16, 18, 20, 22 may be an infusion pump module such as an intravenous infusion pump for delivering a drug or other fluid to the patient. For the purposes of this discussion, functional module 16 is an infusion pump module. Each of the functional modules 16, 18, 20, 22 may be any patient treatment or monitoring device, including, but not limited to, an infusion pump, syringe pump, PCA pump, epidural pump, enteral pump, blood pressure monitor, pulse oximeter, EKG monitor, EEG monitor, heart rate monitor or intracranial pressure monitor. The functional modules 16, 18, 20 and / or 22 may be a printer, scanner, barcode reader, near field communication reader, RFID reader, or any other peripheral input, output, or input / output device.

[0023] Each of the functional modules 16, 18, 20, and / or 22 communicates directly or indirectly with the mainframe infusion controller 14, which provides overall monitoring and control of the device 12. The functional modules 16, 18, 20, and / or 22 can be physically and electronically connected in series to one or both ends of the mainframe infusion controller 14, as shown in FIG. 1A or as detailed by Eggers et al. However, it is recognized that there are other means for connecting the functional modules and the mainframe infusion controller that can be utilized without departing from the subject technology. Devices such as pumps or patient monitoring devices that provide sufficient programmability and connectivity can operate as stand-alone devices and communicate directly with the network without being connected via a separate mainframe infusion controller 14. As described above, additional medical devices or peripheral devices can be connected to the patient care unit 12 via one or more auxiliary interfaces 62.

[0024] Each of the functional modules 16, 18, 20, 22 can include module-specific components 76, a microprocessor 70, volatile memory 72 for storing information, and non-volatile memory 74. Although FIG. 1B shows four functional modules, note that any number of devices can be directly or indirectly connected to the mainframe infusion controller 14. The number and types of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. The module-specific components 76 include any components necessary for the operation of a particular module, such as the pumping mechanism of the infusion pump module 16.

[0025] Each functional module may be capable of operating independently to some extent, but the mainframe injection controller 14 monitors and controls the overall operation of device 12. For example, as will be described in more detail below, the mainframe injection controller 14 provides programming instructions to functional modules 16, 18, 20, and 22 and monitors the status of each module.

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

[0027] Data moving between various data sources can be converted into network-compatible data using existing technologies, and the movement of information between medical devices and the network can be achieved by various means. For example, the patient care unit 12 and the network 10 may communicate via automated interaction, manual interaction, or a combination of both. Automated interaction may be continuous or intermittent and may be conducted via a direct network connection 52 (as shown in Figure 1A), or via an RS232 link, MIB system, RF link such as BLUETOOTH®, IR link, WLANS, digital cable system, telephone modem, or other wired or wireless means. Manual interaction between the patient care unit 12 and the network 10 may involve physically transferring data between systems, intermittently or periodically, using, for example, a user interface device 54, an encoded data input device 60, barcodes, computer disks, portable data support devices, memory cards, or any other medium for storing data. The means of communication in various forms are bidirectional, allowing access to data from as many points as possible within the distributed data sources. Decision-making can be done at various locations within the network 10.

[0028] In accordance with the subject technology, all direct communication with medical devices operating on a network may be performed via an information system server 30 known as a remote data server (RDS). According to aspects of the subject technology, a network interface module incorporated into a medical device, such as an infusion pump or a vital sign measuring device, ignores all network traffic that does not originate from an authenticated RDS. The primary responsibility of the RDS in the subject technology is to track the location and status of all networked medical devices with a NIM and to maintain open communication.

[0029] Depending on the implementation, the server 30 may include a prescription collection and / or a pharmacy information system. The pharmacy information system may enable a safer physician's drug ordering process. A pharmacy website (e.g., provided by the server) may provide physicians with a list of available drugs they can choose from. The pharmacy website may include a drug library with a list of available drugs, but may also include and present to physicians drug names related to recommended dosages and dose limits established or adopted by the healthcare facility. A more accurate medication process should result if physicians do not need to manually enter drug names and drug administration numbers (e.g., infusion rate, time, etc.) related to drug administration, but only need to select items from a computer screen.

[0030] If a clinical order is for the administration of a specific medication plan, the order is sent to the facility's pharmacy information system 30. The pharmacy reviews the order, and once it is ready, it may be sent to the nurses' station for matching with the appropriate patient. The prescription book is an approved list of drugs for use within a healthcare facility (e.g., available for orders for patients). Within the scope of the prescription book, there may be approved usage information and / or concentration and drug range instructions for the facility. As further described, the prescription book may be used to define a drug library for one or more medical devices, which may then be provided to infusion pumps within the hospital network. Within the library is drug information such as drug name, concentration, diluent volume, strength, minimum or maximum infusion parameters for the drug, and other parameters. The establishment of these parameters by the prescription book via system 30, and also by establishing parameters for orders outside the prescription book, helps maintain consistency throughout the healthcare environment and ensure that orders are understandable and executed as expected by other devices within system 30 (e.g., infusion pumps).

[0031] Referring further to Figure 1A, the patient care unit 12 can operate in several different modes or personalities, each personality defined by a configuration database. The configuration database may be an internal database 56 within the patient care unit 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, prescribed treatments, medical history, medical records, identification of the patient care provider, physiological characteristics, or psychological characteristics. Where used herein, patient-specific information also includes care provider information (e.g., identification of a physician) or the location of the patient care unit 12 within the hospital or the hospital's computer network. Patient care information may be entered via interface devices 52, 54, 60, or 62 and may originate from anywhere within the network 10, such as a pharmacy server, inpatient server, or laboratory server.

[0032] The memories 56, 58 of the mainframe infusion controller 14 may include, but are not limited to, one or more drug libraries, one or more event logs, and pump configuration settings, such as profiles used in specific clinical areas such as ICU and PED. The memory may be electronically loadable memory such as non-volatile memory (e.g., EEPROM). Drug libraries stored in the pump (including, for example, information such as drug name, range of delivery parameter values ​​such as appropriate concentration, dosage units, and dose limits) can be used to perform drug calculation-based infusion in a clinical setting.

[0033] The drug library stored in the pump's memory may include clinical order settings, such as limits (also referred to herein as “guardrails”) set by the clinical institution for each drug in the library. Such limits may take the form of maximum and minimum doses for each drug, which may depend on patient factors or other factors related to drug delivery. For example, dose limits may vary depending on the patient’s weight or body surface area (“BSA”), the room or ward in the healthcare facility where the drug is being used (e.g., neonatal intensive care unit (NCU), intensive care unit (ICU), etc.), and other factors. If a nurse sets the pump to operate outside the range between the limits for a particular drug, an alarm may be provided. In some cases, the alarm may be disabled, and in other cases, it may not be disabled. Healthcare facilities may establish “soft” limits for each drug that can be disabled by a nurse, and “hard” limits that cannot be disabled. If a limit is exceeded, a pump data log or other processor communicating with the infusion pump may record each such limit event for later analysis if the attempted setting is higher than the maximum dose or lower than the minimum dose.

[0034] The pump also includes a display for showing a user interface, including a control panel from which the user can program a patient care unit 12 (e.g., including a mainframe 14 and / or connected modules), and a display screen for showing drug entries from a drug library. Each of the associated drug delivery parameter sets includes information selected from a group of parameters, including drug concentration, drug delivery rate, drug dose, and bolus size. The electronically loaded drug library includes a list of available mode options that specify a unit available to represent drug delivery information, and the drug infusion pump provides the user with a list of available mode options to make a selection when the electronically loaded drug library is in the pump. In the case of a syringe pump, the electronically loaded drug library may include a list of syringe manufacturers' names that identify syringes that can be used with the drug infusion pump, and the drug infusion pump provides the user with a list of syringe manufacturers' names to make a selection when the electronically loaded drug library is in the pump. The loaded drug library may include a list of syringe sizes that identify syringes that can be used with the drug infusion pump, and the drug infusion pump provides the user with a list of syringe sizes to make a selection when the electronically loaded drug library is in the pump. In the case of a peristaltic pump, the electronically loaded drug library may include a list of infusion set manufacturers. The loaded drug library may include a set of features, each of which can be switched on or off, and the pump provides the user with only the features from the set of features that are switched on when the electronically loaded drug library is in the pump.

[0035] Figure 1B is a detail view of a portion of the exemplary patient care unit 12 shown in Figure 1A, according to various aspects of the subject technology. Figure 1B shows two functional infusion pump modules 18, 20 (e.g., “infusion pumps”) mounted on either side of the mainframe infusion controller 14, along with their respective displays and control keys, the mainframe infusion controller can program both infusion pumps. The infusion device includes a door 5a and a handle 5b that locks the door in the closed position for operation, unlocks and opens the door to access the internal pump and sensing mechanism, and loads a dosing set for the pump. When the door 5a is open, tubing can be connected to the pump 20. When the door 5a is closed, tubing operates with the pump mechanism, upstream and downstream pressure sensors, and other equipment of the pump. A display 5c, such as an LED display, is located in a plan view of the door in this embodiment and may be used to visually communicate various information related to the pump 20, such as warning instructions (e.g., alarm messages). Control keys 5e-5h may be present to program and control the operation of the infusion pumps as needed. In some implementations, control keys may be presented as interactive elements on a display 5c (e.g., a touchscreen display). The mainframe and / or functional module may also include an audio warning device in the form of a speaker (not shown).

[0036] The mainframe infusion controller 14 of the patient care unit 12 includes a display 6a for visually communicating various information such as the operating parameters of the connected pump and warning instructions and warning messages, and control keys 6b and 6c for selecting and / or setting control parameters and / or options for controlling the patient care unit 12 and connected modules. The mainframe infusion controller 14 may also include a speaker for providing audible warnings. In some implementations, the display 6a may be implemented as a touchscreen display. In such implementations, the control keys 6b may be omitted or the number of control keys 6b may be reduced by providing corresponding interactive elements through a graphical user interface presented via the display 6a. In some implementations, each control key 6b (or 6c) may select a corresponding option displayed on the display 6b.

[0037] The mainframe infusion controller 14 may include a communication system (not shown) that allows the mainframe infusion controller 14 to communicate with external devices such as a medical facility server or other computers, a portable processor such as a handheld communication device or laptop computer, or other information devices to which clinicians may need to transfer information and download drug libraries to function modules 16, 18, 20, 22 (such as pumps). The communication module may be used to transfer access and interaction information for clinicians encountering the mainframe infusion controller or devices coupled thereto (e.g., pump 20 or barcode scanner). The communication system may include one or more of the following: a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH® system, or other wired or wireless systems. Alternatively, the barcode scanner and communication system may be included integrally with the infusion pump 20, for example, when the mainframe infusion controller is not used, or in addition to the mainframe infusion controller 14. Furthermore, the information input device does not need to be wired to the medical device, and information may be transmitted via a wireless connection. In addition, other types of modules, such as syringe pump modules, patient-controlled analgesia modules, endotidal CO2 monitoring modules, and oximeter monitoring modules, may be connected to the pump module or mainframe infusion controller.

[0038] Figure 2 shows a patient care unit 12 having connected infusion device modules 18,20 configured to deliver fluid, a mainframe infusion controller 14, and a modular infusion control device 114. Each of the infusion device modules 18,20 may include a memory for storing instructions and a processor configured to execute the instructions, causing the module to perform at least some of the steps of the method disclosed herein (e.g., the memory and the processor). Although two infusion device modules 18,20 are described herein, it will be understood that one or more infusion device modules may be used in the patient care unit 12.

[0039] Each infusion device module 18,20 can be electronically coupled to the mainframe infusion controller 14 via its respective connector port 110 associated with the mainframe. As used herein, the term “port” includes physical interconnections on an electronic device that interface with the corresponding physical interconnections of other electronic devices for electronic connection and communication with those other electronic devices. Each connector port 110a-110e may include electrical terminals so that the coupled infusion device modules 18,20 can send and receive information to and from the mainframe 14. In some implementations, the infusion device modules may also receive power from the mainframe 14 via the connector ports 110. In this regard, the connector ports may be located directly on the side of the mainframe so that the module is directly electrically connected to the connector ports when the module is mounted on the mainframe. Alternatively, the connector ports may be located on the side of another module so that the first drug delivery module is electronically coupled to the mainframe via other modules. For example, module 20 is electrically coupled to the mainframe infusion controller 14 via ports 110d and 110b.

[0040] When the infusion device module is installed, the mainframe infusion controller 14 may receive an indication that the module has been electronically coupled to the mainframe via a connector port associated with the mainframe. The mainframe may then, in response to receiving the indication, dynamically display graphical channel indicators 112 representing the module on the mainframe's display screen. According to some implementations, each channel indicator 112 is displayed facing the connector port and drug delivery module corresponding to the indication.

[0041] Depending on the implementation, an illustrated infusion control module 114 is provided that can also be coupled to a mainframe infusion controller 14 via port 110. As will be further described, the infusion control module 114 includes a processor and memory, is electrically coupled to the mainframe infusion controller 14, and is configured to take over control of patient care devices (e.g., the mainframe 14 and / or coupled infusion device modules). In some implementations, the control module 114 may have the same size and profile as the other infusion device modules 18,20. In some implementations, the control module 114 may be large enough to include its processing circuitry and memory, as well as the connection port 110, and may be a different size or shape from the other connected modules, while still allowing physical and electrical interconnection between the functional modules, the control module, and the mainframe devices.

[0042] If authorized, the infusion control module 114 may directly control connected medical devices, including the mainframe infusion controller 14 and / or operable-connected infusion device modules 18,20, to help clinicians provide more centralized control and management of the devices. For the purposes of this disclosure, the interaction between the infusion control module and the patient care unit 12 will be described with respect to the mainframe infusion controller 14 and / or operable-connected infusion device modules 18,20. In some implementations, it will be understood that the mainframe infusion controller 14 and / or operable-connected infusion device modules 18,20 may be integrated to function as a single PCU device.

[0043] The infusion control module 114 provides a modular interface system that allows various sensors used in a medical environment to be connected to the control module 114 in a common manner to facilitate control of other connected medical devices 14, 18, 20. For example, connected sensors may include one or more of heart rate monitors, oxygen sensors, and intravenous (IV) flow monitors, all of which can be connected to the infusion control module 114 to facilitate centralized control of one or more infusion devices, in addition to input by a clinician. Connection to various sensors is also possible by hijacking the connected sensor and programmable sensor control of another device as part of the control of the control module 114 of the connected device.

[0044] The infusion control module 114 may further connect to a server and / or cloud-based system for further data entry, data adjustment, and reporting. An example of a cloud-based system is a hospital network 10 that includes a cloud-based drug information database (or prescription collection) and an electronic medical record (EMR) system 30 or database 37.

[0045] In some implementations, the infusion control module 114 includes control software that provides processing of control algorithms and software that enables closed-loop and semi-closed-loop control functions on the connecting circuit and / or one or more medical devices at the time of use. In some implementations, the infusion control module 114 provides an external interface, e.g., a user interface 116, for providing input parameters that can be used for interaction between the infusion device modules 18,20 and one or more different physiological or biometric sensors, and for controlling the titration of IV infusion of drugs into a patient. In some implementations, when connected to the mainframe infusion control device 14, the infusion control module 114 may control the operation of interface elements 6a-6c (e.g., physical and / or virtual) for the purpose of interaction between the infusion device modules and sensors, and for providing input parameters.

[0046] In some implementations, the infusion control module 114 provides control for IV infusion of medication by the infusion pump (e.g., of the infusion device module) according to feedback provided by physiological / biometric sensors used to monitor the treatment being performed. In situations where IV medication is not delivered as a result of an abnormal condition such as the IV line being blocked, leaking, or not connected to the patient, the sensors may indicate that the patient is not responding to the treatment. The infusion control module 114 may detect such activity and provide feedback (e.g., notification or alarm) to the clinician to warn the clinician of a possible malfunction condition that needs to be addressed before a potentially serious situation occurs.

[0047] The infusion control module 114 may incorporate control software (e.g., including one or more algorithms within the unit) that can be adapted to specific or general medical procedures. The infusion control module 114 may receive infusion status information from the mainframe device 14 or the infusion device modules 18, 20. Infusion status information may include, for example, drug identification, the flow rate of drug administration to the patient by the infusion device, VTBI (Voltage To Infuse), delivery duration, and upstream or downstream pressure. While the infusion pump and / or module may have its own safety system, the infusion control module 114 may be pre-programmed to determine safety events, such as events specific to a particular procedure. Based on sensor data from connected sensors and infusion status information, the infusion control module 114 may determine that a safety event is likely to occur within a given period (e.g., programmed into the ICM or determined by AI based on a training model of the procedure being performed).

[0048] The closed-loop control systems described herein generally refer to systems that do not rely on external manual input to deliver treatment. Once configured, the closed-loop system can autonomously deliver treatment, receive feedback from one or more sensors, and automatically adjust the treatment as needed based on the feedback. For example, during drug administration, the infusion control module 114 may determine the expected trend of physiological characteristics over a given period based on sensor data from previous periods, the dose of drug delivered to the patient, and one or more physical parameters of the patient. The infusion control module 114 may then cause the infusion device to adjust the drug dose so that the physiological characteristics follow the expected trend over the given period.

[0049] Having the infusion control module 114 as a separate modular unit electrically and detachably connected to the PCU 12 as a module offers several advantages. For example, advances in sensors (e.g., biometric sensors) connected to or controlled by the infusion control module 114 may be much faster than developments in the PCU 12 or other modules, and therefore the control system can respond more quickly to these changes. It may be desirable to update the control algorithm to address changes in treatment methods, available medications, and patient physiology. For this reason, it may be desirable to have the algorithm reside in a component separate from the pump system to accommodate more frequent changes. Furthermore, machine learning and artificial intelligence can account for patient variability related to physiological characteristics such as age, genetics, health history, and other traits and environmental factors. Systems incorporating such capabilities may include large databases and complex programs that require powerful microprocessors and data storage capabilities to perform the necessary timely and accurate calculations. These systems generally cannot run on systems currently available with IV pumps alone, but may reside on server 30 or other cloud-based systems accessible from the infusion control module 114.

[0050] In addition, the infusion control module 114 of the subject technology may be adaptable to various pump systems and sensor inputs (e.g., using the universal connector port 112). The infusion control module 114 may be further configured to add wireless, Bluetooth®, and LAN connectivity to pump systems that do not currently have the connector port 110. For example, Figure 1C shows an infusion control module 114 having a wireless connection 120 for communicating with a hospital network system 40. Adding such communication to the PCU 12 may enable remote monitoring and control of the infusion pump, as well as other functions such as easier access to the EMR. Thus, by integrating separate electrical and processing components from the mainframe infusion control device 14, the subject technology facilitates the integration of additional functions without requiring modifications to the mainframe housing and electronics. Separating the physiological sensing and control system from the infusion pump system may further provide a more streamlined regulatory approval process.

[0051] Depending on the implementation, the infusion control module 114 can have separate control software from the embedded firmware of the pump and sensors, thereby facilitating a scalable and rapidly configured system for providing closed-loop control of medical procedures. Furthermore, the infusion control module 114 may be configured to operate with a number of sensors by electrical connectors and / or wireless communication. The infusion control module 114 may include one or more microprocessors and algorithms for providing signal conditioning and / or conversion of sensor signals to appropriate physiological characteristics of the connected medical devices. Parameters can then be used in the control algorithm to provide control to, for example, the mainframe infusion controller 14 and / or infusion pump to deliver the necessary drugs or fluids for the 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 devices.

[0052] The user interface associated with the infusion control module 114 may include a display module or touch-sensitive display module configured to provide a user interface for displaying information about the patient's physiological state and the system control status. In some implementations, the infusion control module 114 includes circuitry that provides display information to an external display device (e.g., terminal 32). The external display may display various vital statistics of a patient in the operating room (e.g., electrocardiogram (ECG), oxygen saturation (SpO2)) so that the vital statistics are visible to the clinician in the operating room (e.g., all clinicians). In some implementations, the display on the infusion control module 114 may be mirrored via an associated external display to provide information to devices connected to the infusion control module 114 and / or clinicians involved in the procedure.

[0053] In various implementations, the software of the infusion control module 114 can store protocol information (e.g., information about treatment and patient-related processes and steps) and make the information easily accessible within the infusion control module 114. In some implementations, the software provides information to the user interface, enabling the system to present and navigate relevant information more efficiently (e.g., using fewer device resources such as memory, power, processing cycles, and user interface area) (e.g., using touch input on a touchscreen). In various implementations, the software guides the user through the necessary steps and information in the correct order at the appropriate time, thereby avoiding the expenditure of resources on information that is out of sync with or irrelevant to the currently detected state.

[0054] In some implementations, the infusion control module 114 may access additional resources related to drug information and dosage calculation from internal or remote storage (e.g., a drug information database). In some implementations, the infusion control module 114 may display information about the specific drug being administered on a user interface and / or other operably connected user device.

[0055] Depending on the implementation, when coupled to the mainframe injection controller 14, the control module 114 instructs the mainframe injection controller to switch from default mode to remote control mode. In this regard, in response to the injection control module being coupled to the mainframe injection controller, the user of the PCU 12 may be prompted to confirm that the control module 114 can take over control of the PCU (e.g., via the display 6a). In some implementations, whether the user can provide confirmation may depend on the user's authentication level. The authentication level may be automatically determined by the injection control module 114 based on access to authentication information from the mainframe 14 (e.g., obtained based on logging into the mainframe by scanning a badge).

[0056] When in control mode, the operational parameters related to infusion may be controlled by the infusion control module 114, while the basic pump system developed for the pump (e.g., calculating and / or controlling the volume per mechanical rotation) may continue to be managed by the pump. For example, the infusion control module 114 may take over control of the titration rate, infusion start and stop, and may consume alarms provided by modules 18,20 for its own use. However, background functions such as maintaining a programmed flow rate (e.g., once programmed) may be left to the pump system of modules 18,20, thereby leaving modules 18,20 to function as zombie modules. Under closed-loop control, the infusion control module 114 may monitor and command changes in operational parameters in real time to maintain the patient in a specified state (e.g., by keeping physiological sensor measurements within the target zone). Under semi-closed-loop control, the infusion control module 114 may prompt the user for confirmation of parameter changes (e.g., via display 6a). In some implementations, the injection control module 114 simply monitors and provides reports of the monitored status, alarms, and measurements to the display 6a or an external system.

[0057] Depending on the implementation, the infusion control module 114 may be disconnected from the first mainframe infusion controller 14a (e.g., physically removed) and reconnected to the second mainframe infusion controller 14b. In this regard, the infusion control module 114 may locally store infusion data, patient information, and other medical information in its memory, and as a result, when connected to a new mainframe, infusion treatment may be continued using the new mainframe infusion controller and its connected module, or a new infusion initiated on that device may make treatment-based decisions based on historical data acquired on the first device.

[0058] When moved to a new second infusion system, the infusion control module 114 may transfer data obtained from the first system to the second system. The module may first perform a handshake and / or data check and / or firmware check with the new system. The infusion control module 114 may then determine the features available in the new system to continue the treatment pre-provided by the infusion control module using different PCU / mainframe infusion controllers. For example, the infusion control module 114 may query the new mainframe 14b to determine which infusion channels are active and which drugs are loaded for administration through the channels. The infusion control module 114 may determine that one or more drugs loaded for administration to the new PCU are compatible with the infusion treatment pre-programmed in the infusion control module 114 while the module is coupled to the first mainframe infusion controller 14a.

[0059] In some implementations, the infusion control module 114 may map drug therapy programmed within the infusion control module 114 to infusion device modules 18,20 coupled to a new mainframe infusion controller 14b. In some implementations, the mapping may be based on a comparison between operating parameters programmed in the new second mainframe infusion controller 14 and parameters programmed in the infusion control module 114. These parameters may include, for example, identification of the drug or drug type, the flow rate of drug delivery to the patient by the infusion device, VTBI (volume to be infused), delivery duration, and upstream or downstream pressure.

[0060] Once an available channel for continuing the infusion therapy is identified, the infusion control module 114 may prompt the user (e.g., via display 6a) to select at least one of the channels to be delivered according to the therapy or the available drug. The user may then select the drug to be used for the therapy. In some implementations, the infusion control module 114 may transmit operating parameter values ​​and / or pharmacokinetic information to a new mainframe 14b for use in delivering the therapy.

[0061] Figure 3 shows an exemplary flow diagram 200 for controlling an injection device using a modular injection control module, according to an aspect of the subject art. For illustrative purposes, various blocks of the exemplary process flow 200 are described herein with reference to Figures 1A, 1B, and 2, as well as the relevant components and / or processes described herein.

[0062] As described above, the infusion control module 114 is electronically coupled to the patient care unit (PCU 12) (e.g., the mainframe infusion controller 14 and / or one or more of its functional modules) to initiate the exemplary process 200. In the illustrated example, the infusion control module 114 queries the PCU 12 to determine whether the device 14 is compatible with the infusion control module 114 (202). The determination may be based on the communication of one or more messages between the ICM 114 and the PCU 12. In some implementations, the determination may be based on the physical or virtual connection status between the ICM 114 and the PCU 12.

[0063] The injection control module 114 identifies itself to the PCU 12 and provides the PCU 12 with a security identifier or code via one or more messages (204). The injection control module 114 may also determine which sensors are connected to the injection control module 114 or where they were previously connected on another system before being connected to this PCU 12 (206). In some implementations, sensor information may be provided by the PCU 12 (for example, based on sensors connected to the PCU or coupled modules). The PCU 12 receives the identity and security code instructions and, based on them, determines whether access should be permitted to the injection control module 114 (208). For example, if the identifier of the ICM 114 is not included in the list of permitted ICMs, the determination may be negative. As another example, if the security code provided by the ICM 114 is unknown, expired, or invalid, the determination may be negative. If the PCU 12 does not accept the received identity and / or code, the process terminates.

[0064] Upon accepting the identity and / or code, the PCU12 may provide the infusion control module 114 with information about its operating system (210). For example, the PCU12 may identify the infusion device modules 18,20 currently coupled to the mainframe infusion controller 14, and / or which modules are available for use, and / or which modules are programmed with operating parameters and the values ​​of those parameters. The PCU12 may identify one or more drugs (e.g., loaded) associated with the pump modules 18,20 that are currently running or programmed to run, and may identify the current state of each pump module (e.g., whether the pump module is actively infusing drugs). In some implementations, the aforementioned information may be provided by the PCU12 in response to a query for information from the infusion control module 114.

[0065] As previously mentioned, the infusion control module 114 may assume control (e.g., commander) of the display screen 6a and / or input interface control units 6b,6c of the PCU 12. In this regard, the infusion control module 114 may prompt the user to select a process to execute or to set up a treatment. For example, the infusion control module 114 may prompt the user to select a blood glucose treatment, a vasoconstriction treatment, etc. The user may then select the appropriate treatment and use the user interface control unit to input patient parameters, sensor targets and / or limits, as well as other operating parameters for the treatment (212). For example, the user may select an anesthetic treatment, a drug such as propofol, the amount to be administered, a bispectral index (BIS) sensor, and a predetermined target for BIS sensor measurement corresponding to the depth of anesthesia.

[0066] In some implementations, the PCU 12 (or the controlled module) identifies the control algorithm and / or the control level of the injection control module 114 and / or modules 18,20 required for control (214). This level may correspond to the verification required for the ICM 114 to perform an automated action. At the first level, for example, the ICM 114 may simply recommend adjustment via the PCU 12 during injection. At the second level, the ICM 114 may directly control the module during injection without user input. Sensor inputs may be received via the injection control module 114 or directly by the PCU 12. The PCU 12 may verify the state of the sensors and ensure that all systems are valid, operational, and ready to be passed to the injection control module 114 for direct control by the injection control module 114. The user may adjust the level of control over the PCU 12 by the injection control module 114 by providing appropriate inputs to the user interfaces 6a, 6b, 6c (215).

[0067] Subsequently, the infusion control module 114 may prompt the user to confirm that the infusion control module 114 may begin controlling the PCU 12 (or any module connected thereto) (216). The user may cancel, or upon confirmation, the infusion control module 114 may begin controlling the PCU 12 (or any module connected thereto). In this regard, the infusion control module 114 may begin titration control. In some implementations, the infusion control module 114 monitors sensor measurements and begins titrating the drug based on the measurements. The infusion control module 114 may generate sensor and drug trend data displays for display on a display screen (220) and may record the same data (222). The infusion control module 114 may cause the PCU 12 to display a user interface along with the generated trend displays and other real-time monitoring data (224). At any time, the user may terminate control of the PCU 12 by the infusion control module 114 by providing appropriate input, for example, in user interfaces 6a, 6b, 6c (226).

[0068] Figure 4 shows an exemplary process 400 for controlling an injection device using a modular injection control module, according to an aspect of the subject art. For illustrative purposes, various blocks of the exemplary process 400 are described herein with reference to Figures 1A, 1B, 2, and 3, and the relevant components and / or processes described herein. One or more blocks of the process 400 may be implemented by one or more computing devices, including, for example, an injection control module 114, a PCU 12, modules 18, 20, a server 30, or a client computing device 32. In some implementations, one or more blocks may be implemented based on one or more machine learning algorithms. In some implementations, one or more blocks may be implemented by one or more different processors or devices, apart from the other blocks. Furthermore, in some implementations, multiple blocks of the exemplary process 400 may be performed in parallel (for example, blocks 402 and 404 may be performed in parallel), insofar as the blocks of the exemplary process 400 are described as occurring sequentially or linearly for illustrative purposes. In addition, the exemplary blocks of process 400 do not need to be performed in the order shown, and / or one or more of the exemplary blocks of process 400 do not need to be performed.

[0069] In various implementations, the infusion control module 114 receives an indication that the infusion control module 114 is electronically coupled to the patient care unit (PCU) 12 (402). In various implementations, the mainframe infusion controller of the PCU is configured to control one or more infusion device modules 18,20 coupled to the PCU. The infusion control module 114 may be electronically coupled to the PCU 12 by the connector port 110 of the control module 114, which physically interfaces with the connector port 110 of the mainframe infusion controller 14 and interconnects with it. The infusion control module 114 may also be coupled via a port on the control module 114 that interfaces with the connector ports of modules 18,20, which in turn may be coupled to the mainframe infusion controller 14. In this regard, modules 18,20 may include pass-through circuits that allow the mainframe infusion controller 14 and the infusion control module 114 to be recognized as coupled regardless of the intervening module. In some implementations, the second physical connector port 110d may detachably connect the injection control module 114 to an injection device module (for example, the injection device module 20 as shown in Figure 2).

[0070] In response to the infusion control module 114 being coupled to the PCU, the control module may prompt the user to confirm that the control of the PCU (e.g., the mainframe infusion controller 14 and / or connected infusion device modules) is switched from the default mode, where the PCU controls the PCU, to a remote control mode, where the PCU controls the infusion control module when electronically coupled to the PCU. In response to receiving user confirmation, the control module and / or PCU are switched to remote control mode. While in remote control mode, the control module 114 may control certain functions of the PCU, such as the start and stop times of the delivered drug and the titration rate, according to the treatment selected in the control module 114. Depending on the various implementations, the PCU may maintain control of basic functions, such as maintaining a programmed flow rate of the drug (which can be adjusted in real time by the control module 114, for example).

[0071] The infusion control module 114 determines that the PCU is programmed to control the delivery of each drug using infusion device modules 18,20 coupled to the mainframe infusion controller (404). As previously stated, the infusion control module 114 may determine the capabilities of the PCU 12, including identifying the functional modules connected to the PCU (for example, to the mainframe 14), whether those modules include infusion pumps, the type of pump, the drugs loaded for pump administration, and / or operating parameters for configuring the pumps. The control module 114 may determine that the mainframe infusion controller 14 is programmed to control the delivery of two or more drugs using two or more infusion device modules 18,20.

[0072] The infusion control module 114 determines that the drug currently associated with the PCU is suitable for a treatment pre-programmed in the infusion control module (406). In this regard, the control module may be pre-programmed to control a specific treatment (e.g., anesthesia). Pre-programming may be achieved by pre-connecting to another PCU 12, or the treatment may be selected when the control module is electronically coupled to the current PCU 12. For example, after electronic coupling and performing the initial configuration setup action as described with respect to Figure 2, or as part of the configuration setup action, the control module 12 may prompt the user to select a treatment to be monitored and / or controlled by the control module 114. For example, the treatment may be anesthesia or blood glucose management.

[0073] The infusion control module 114 may prompt the user to select or confirm the use of a drug loaded by the PCU 12. For example, the control module 114 may determine that two or more modules 18,20 are active on the PCU and each is available to deliver a drug, and may enumerate the modules on the display 6a for user selection. The user may then select one or more of the enumerated drugs to be delivered according to the treatment provided by the control module 114.

[0074] In some implementations, the infusion control module 114 may determine that the drug loaded by the PCU is suitable for a treatment pre-programmed in the infusion control module while the infusion control module is coupled to a different mainframe device. For example, the infusion control module 114 may be programmed for an anesthetic treatment and pre-programmed to use propofol for the treatment. When the control module 114 is coupled to the PCU 12, the module may determine that remifentanil is available from the PCU 12. The module 114 may then prompt the user to confirm the use of remifentanil instead of propofol.

[0075] In some implementations, the infusion control module 114 may transmit programmed parameters and pharmacokinetic information from the infusion control module to the mainframe infusion controller while the infusion control module is coupled to a different mainframe device. In this way, the control module 114 may be used to transfer the entire treatment plan for a patient from a first PCU that administers the medication for the patient to a second PCU, and the treatment is continued for the patient in the second PCU. The second PCU may use the transferred parameters and pharmacokinetic information with the same type of medication, or use and / or convert the parameters and / or pharmacokinetic information for use with a similar type of medication (e.g., remifentanil instead of propofol, or vice versa). In some implementations, the control module 114 maps the drug treatment programmed in the infusion control module when it was electronically coupled to the previous PCU (based on parameters and / or medication types programmed to the mainframe infusion controller, for example) to the current PCU (or, for example, an infusion device module coupled to the mainframe of the current PCU).

[0076] In the illustrated example, the infusion control module 114, while electronically coupled to the PCU, instructs the infusion device module to deliver the drug according to the treatment (408). As previously mentioned, the control module 114 may also set, for example, the operating parameters of the mainframe infusion controller 14 or the infusion device modules 18,20, and the PCU may operate as if the parameters were received directly without the control module. However, the control module 14 coupled to the PCU may continuously monitor the PCU and its modules and adjust parameters (e.g., flow rate, VTBI, bolus volume, etc.) in real time to ensure that drug administration maintains the patient in the desired state (e.g., based on physiological sensor measurements).

[0077] In various implementations, the drug may be delivered to an infusion device module (e.g., module 18 or 20) coupled to the mainframe infusion controller 14 by the control module 114 sending one or more signals from the infusion control module 114 to the mainframe infusion controller via a physical interconnect (e.g., port 110b in Figure 2). In some implementations, the drug may be delivered to the infusion device module by the control module 114 sending one or more signals from the infusion control module to an infusion device module (e.g., module 20) via a second physical interconnect (e.g., port 110d in Figure 2). In some implementations, when coupled to the PCU, the control module 114 may obtain one or more parameter limits (e.g., guardrails) related to the drug and / or patient from the server 30. The control module 114 then monitors drug delivery for violations of one or more parameter limits and, in response to violations, may instruct the PCU to adjust parameters related to the administration of the drug to the patient (e.g., adjust the drug flow rate).

[0078] In some implementations, for example, during the setup or startup of the control module (e.g., Figure 2), the control module 114 determines that the PCU is programmed to receive sensor data from sensors operably coupled to the PCU. The biometric sensors used with the control module 114 and / or the PCU may include an HR monitor, an oxygen sensor, and an intravenous (IV) flow monitor, all of which can facilitate centralized control of one or more infusion pumps provided by the PCU, in addition to input from the clinician. In some implementations, the sensors may also include a bispectral index (BIS) sensor for assessing the depth of anesthesia during surgery.

[0079] The control module 114 may then determine that the sensor is suitable for treatment and prompt the user to confirm the use of the sensor in connection with drug delivery by the treatment. The control module 114 may receive user confirmation that the sensor is being used in connection with delivery, receive sensor data from the sensor, and then adjust the parameters of the infusion device module during treatment based on the sensor data.

[0080] Many of the exemplary processes 400 described above, as well as related features and applications, may also be implemented as software processes designated as a set of instructions recorded on a computer-readable storage medium (also called a computer-readable medium), and may be 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, and EPROMs. Computer-readable media do not include carrier waves and electronic signals transmitted via wireless or wired connections.

[0081] The term “software” means, where appropriate, firmware residing in read-only memory, or applications stored in magnetic storage devices that can be loaded into memory for processing by a processor. Furthermore, in some implementations, multiple software embodiments of the subject disclosure can be implemented as subparts of a larger program, while remaining separate software embodiments of the subject disclosure. In some implementations, multiple software embodiments can also be implemented as separate programs. Finally, any combination of separate programs that implement together the software embodiments described herein is within the scope of the subject disclosure. In some implementations, a software program defines one or more specific mechanical implementations that, when installed to operate on one or more electronic systems, perform and execute the operations of the software program.

[0082] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, such as a standalone program or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. Computer programs may, but do not, correspond to files in a file system. A program can be part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), a single file dedicated to the program in question, or multiple collaborative files (e.g., a file containing one or more modules, subprograms, or parts of code). Computer programs can be deployed to run on one computer, or on multiple computers located in one site, or distributed across multiple sites and interconnected by a communication network.

[0083] Figure 5 is a conceptual diagram showing an exemplary electronic system 500 for controlling an injection device using a modular injection control module, according to an aspect of the subject art. The electronic system 500 may include, but is not limited to, a PCU 12, a mainframe injection controller 14, a control module 114, function modules 16, 18, 20, 22, a server 30, a terminal 32, and / or any computing device or associated module or terminal computing hardware disclosed herein, for executing one or more parts or steps of processes 200 and 400, or software related to the components and methods provided by Figures 1 to 3. The electronic system 500 may be a personal computer, or a mobile device such as a smartphone, tablet computer, laptop, PDA, augmented reality device, wearable such as a watch or band or glasses, or a combination thereof, or another touchscreen or television having one or more embedded or combined processors, or any other type of computer-related electronic device having network connectivity.

[0084] The electronic system 500 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 500 includes a bus 508, a processing unit 512, system memory 504, read-only memory (ROM) 510, a permanent storage device 502, an input device interface 514, an output device interface 506, and one or more network interfaces 516. In some implementations, the electronic system 500 may include, or be integrated with, other computing devices or circuits for the operation of the various components and methods described above.

[0085] Bus 508 collectively represents all system, peripheral, and chipset buses that communicate with numerous internal devices of the electronic system 500. For example, bus 508 communicates with the processing unit 512 to the ROM 510, system memory 504, and permanent storage device 502.

[0086] From these various memory units, the processing unit 512 retrieves instructions to execute and data to process in order to carry out the process of the subject disclosure. The processing unit may be a single-processor or a multi-core processor in different implementations.

[0087] ROM 510 stores static data and instructions required by processing unit 512 and other modules of the electronic system. Meanwhile, the permanent memory device 502 is a read / write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 500 is stopped. Some implementations of the subject disclosure use a mass storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent memory device 502.

[0088] Other implementations use a removable storage device (e.g., a floppy disk, flash drive, and its corresponding disk drive) as the permanent storage device 502. Similar to the permanent storage device 502, the system memory 504 is a read-write memory device. However, unlike the storage device 502, the system memory 504 is a volatile read-write memory, such as random-access memory. The system memory 504 stores some of the instructions and data that the processor needs at runtime. In some implementations, the process of the subject disclosure is stored in the system memory 504, the permanent storage device 502, and / or the ROM 510. From these various memory units, the processing unit 512 retrieves the instructions to execute and the data to process in order to execute the process in some implementations.

[0089] Bus 508 also connects to input and output device interfaces 514 and 506. Input device interface 514 allows the user to transmit information and select commands to the electronic system. Input devices used with input device interface 514 include, for example, an alphanumeric keyboard and a pointing device (also called a "cursor control device"). Output device interface 506 allows, for example, the display of images generated by the electronic system 500. Output devices used with output device interface 506 include, for example, printers and display devices such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Some implementations include devices such as touchscreens that function as both input and output devices.

[0090] Furthermore, as shown in Figure 5, the bus 508 also connects the electronic system 500 to a network (not shown) via a network interface 516. The network interface 516 may include, for example, a wireless access point (e.g., Bluetooth® or WiFi) or wireless circuitry for connecting to a wireless access point. The network interface 516 may also include hardware (e.g., Ethernet hardware) for connecting the computer to a part of a computer network, such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or an intranet, or the Internet. Any or all components of the electronic system 500 can be used in conjunction with the subject disclosure.

[0091] The functions described above can be implemented in computer software, firmware, or hardware. These techniques can be carried out using one or more computer program products. Programmable processors and computers can be contained in or packaged as mobile devices. Processes and logical flows can be carried out by one or more programmable processors and one or more programmable logic circuits. General-purpose and dedicated computing devices and storage devices can be interconnected via communication networks.

[0092] Some implementations include electronic components such as microprocessors, storage devices, and memory that store computer program instructions in machine-readable or computer-readable media (also called computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROMs), recordable compact discs (CD-Rs), rewritable compact discs (CD-RWs), read-only digital multipurpose discs (e.g., DVD-ROMs, dual-layer DVD-ROMs), various recordable / rewritable DVDs (e.g., DVD-RAMs, DVD-RWs, DVD+RWs, etc.), flash memory (e.g., SD cards, miniSD cards, microSD cards, etc.), magnetic and / or solid-state hard drives, read-only and recordable Blu-ray® discs, ultra-high-density optical discs, any other optical or magnetic media, and floppy disks. Computer-readable media are executable by at least one processing unit and can store computer programs containing instruction sets for performing various operations. Examples of computer programs or computer code include files containing machine language, such as that generated by a compiler, and high-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0093] The above discussion primarily refers to microprocessors or multicore processors that run software, but some implementations are executed 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 within the circuit itself.

[0094] As used in the specification and any of the claims of this application, the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technical devices. These terms exclude people or groups of people. For the purposes of this specification, the terms “display” or “displaying” mean to display on an electronic device. As used in the specification and any of the claims of this application, the terms “computer readable medium” and “computer readable media” are strictly limited to tangible physical objects that store information in a computer-readable format. These terms exclude any radio signals, wired download signals, and any other transient signals.

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

[0096] Embodiments of the subject matter described herein may be implemented in a computing system that includes, for example, a backend component as a data server, or a middleware component as an application server, or a frontend component, for example, a client computer having a graphical user interface or a web browser on which a user can interact with an implementation of the subject matter described herein, or in any combination of one or more such backend, middleware, or frontend components. Components of the system may be interconnected by digital data communications of any form or medium, such as a communication network. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad-hoc peer-to-peer networks).

[0097] A computing system can include clients and servers. Clients and servers are generally separated from each other and may interact via a communication network. The relationship between the client and server is established by computer programs running on each computer that have a client-server relationship with each other. In some embodiments, the server sends data (e.g., an HTML page) to the client device (e.g., to display data to a user interacting with the client device and to receive user input from the user). The server can receive data generated on the client device (e.g., the results of user interaction) from the client device.

[0098] Those skilled in the art will recognize that the various exemplary blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To demonstrate that hardware and software are thus interchangeable, the various exemplary blocks, modules, elements, components, methods, and algorithms have been described above in general terms of their function. Whether such functions are implemented as hardware or software depends on the specific application and design constraints imposed on the overall system. The described functions can be implemented in various ways for each specific application. The various components and blocks may be arranged differently (e.g., in a different order or partitioned in a different way) without deviating from the scope of the subject art.

[0099] The specific order or hierarchy of steps in the disclosed process is to be understood as an example of an exemplary method. It is understood that the specific order or hierarchy of steps in the process may be rearranged based on design preferences. Some steps may be performed simultaneously. The claims for the attached method present elements of various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented.

[0100] Examples of subject matter as clauses Various examples of aspects of this disclosure are described for convenience as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the subject art. Drawing and reference numeral identifications are provided below for illustrative purposes only and the clauses are not limited by these identifications.

[0101] Clause 1. An infusion control module comprising: a non-temporary machine-readable storage medium storing instructions; an instruction that, by an instruction, indicates that the infusion control module is electronically coupled to a mainframe infusion controller, and the mainframe infusion controller is configured to control one or more infusion device modules coupled to the mainframe infusion controller; the infusion control module determines that the mainframe infusion controller is programmed to control drug delivery using the infusion device modules coupled to the mainframe infusion controller; the infusion control module determines that the drug is suitable for a treatment pre-programmed within the infusion control module; and the infusion control module, while electronically coupled to the mainframe infusion controller, causes the infusion device modules to deliver the drug according to the treatment, comprising one or more processors.

[0102] Clause 2. The infusion control module described in Clause 1, wherein the mainframe infusion controller is programmed to deliver two or more drugs using two or more infusion device modules, and one or more processors are further configured to prompt the user by instruction to select at least one of two or more drugs to be delivered according to the treatment via the infusion control module, and to receive the drug selection based on the prompt.

[0103] Clause 3. Determining that a drug is suitable for a treatment preprogrammed in the infusion control module includes determining that a drug is suitable for a treatment preprogrammed in the infusion control module while the infusion control module is coupled to a different mainframe device, as described in Clause 1 or 2.

[0104] The infusion control module described in Clause 4.1 or more processors, by instruction, map a plurality of drug therapies programmed in the infusion control module to a plurality of infusion device modules coupled to a mainframe infusion controller, based on parameters programmed in the mainframe infusion controller, when electronically coupled to different mainframe devices, wherein the parameters include one or more drug types.

[0105] The infusion control module described in Clause 5.1, further configured by instruction to transmit programmed parameters and pharmacokinetic information from the infusion control module to a mainframe infusion controller while the infusion control module is coupled to a different mainframe device.

[0106] An infusion control module according to any one of Clauses 6.1 or more processors are further configured, by instruction, to receive infusion information relating to the delivery of a drug to a patient, to generate a user interface, and to cause a display device of the mainframe infusion controller to display the user interface, along with infusion control parameters and information relating to the delivery of a drug, based on the received infusion information, as described in any one of Clauses 1 to 5.

[0107] Clause 7. An infusion control module as described in any one of Clauses 1 to 6, further configured such that one or more processors, by instruction, prompt the user to confirm that the infusion control module is coupled to the mainframe infusion controller, and that in response to the infusion control module being coupled to the mainframe infusion controller, the mainframe infusion controller switches from a default mode in which the control of the mainframe infusion controller and the infusion device module is controlled by the mainframe infusion controller to a remote control mode in which the control of the mainframe infusion controller and the infusion device module is controlled by the infusion control module when electronically coupled to the mainframe infusion controller, and in response to receipt of user confirmation, the mainframe infusion controller switches to remote control mode, and the infusion control module controls the start and stop times and titration rate of the drug being delivered according to the treatment while in remote control mode, and the mainframe infusion controller maintains control of the drug flow rate during remote control mode.

[0108] The infusion control module described in Clause 8.1 or more processors are further configured to obtain, by instruction, one or more parameter limits related to a drug from a server, by the infusion control module, in response to an infusion control module coupled to a mainframe infusion controller; monitor drug delivery for violations of one or more parameter limits; and, in response to a violation, instruct the mainframe infusion controller, by the infusion control module, to adjust the drug flow rate.

[0109] The infusion control module described in any one of Clauses 1 to 8, further configured such that one or more processors, by instruction, determine that the infusion control module is programmed to have the mainframe infusion controller receive sensor data from a sensor operably coupled to the mainframe infusion controller, determine that the sensor is suitable for treatment, prompt the user to confirm the use of the sensor in connection with drug delivery by the infusion device module in accordance with the treatment, receive confirmation that the sensor is used in connection with delivery, receive sensor data from the sensor, and have the infusion control module adjust the parameters of the infusion device module during treatment based on the sensor data.

[0110] An injection control module as described in any one of Clauses 1 to 9, further configured such that one or more processors, by instruction, make a first physical interconnection configured to be physically and detachably coupled to a mainframe injection controller, and an instruction that the injection control module is electronically coupled to the mainframe injection controller is received via the first physical interconnection.

[0111] Clause 11. The infusion control module according to Clause 10, which causes the infusion device module to deliver a drug by one or more signals transmitted from the infusion control module to the mainframe infusion controller via a first physical interconnection.

[0112] The infusion control module according to Clause 10, further configured such that one or more processors, by instruction, make a second physical interconnection which is physically and detachably coupled to an infusion device module when a first physical interconnection is physically coupled to a mainframe infusion controller, and cause the infusion device module to deliver a drug by one or more signals transmitted from the infusion control module to the infusion device module via the second physical interconnection.

[0113] Clause 13. A mechanical mounting method comprising: receiving an instruction from an infusion control module that the infusion control module is electronically coupled to a mainframe infusion controller, wherein the mainframe infusion controller is configured to control one or more infusion device modules coupled to the mainframe infusion controller; determining from the infusion control module that the mainframe infusion controller is programmed to deliver a drug using the infusion device modules coupled to the mainframe infusion controller; determining from the infusion control module that the drug is suitable for a treatment pre-programmed within the infusion control module; and causing the infusion control module to deliver the drug to the infusion device modules according to the treatment while it is electronically coupled to the mainframe infusion controller.

[0114] Clause 14. The mechanical implementation method according to Clause 13, wherein the mainframe infusion controller is programmed to deliver two or more drugs using two or more infusion device modules, and the method further includes the steps of prompting a user via an infusion control module to select at least one of two or more drugs to be delivered in accordance with the treatment, and receiving the drug selection based on the prompt.

[0115] Clause 15. The mechanical mounting method according to Clause 13 or 14, wherein the step of determining whether the drug conforms to a treatment preprogrammed in the infusion control module includes the step of determining whether the drug conforms to a treatment preprogrammed in the infusion control module while the infusion control module is coupled to a different mainframe infusion controller.

[0116] Clause 16. The mechanical implementation method according to Clause 15, further comprising the step of mapping a plurality of drug therapies programmed in an infusion control module, when coupled to different mainframe infusion controllers, to a plurality of infusion device modules coupled to a mainframe infusion controller based on parameters programmed in the mainframe infusion controller, wherein the parameters include one or more drug types.

[0117] Clause 17. A mechanical mounting method according to any one of Clauses 13 to 16, further comprising: prompting the user to confirm that the infusion control module is coupled to the mainframe infusion controller, in response to the mainframe infusion controller being coupled to the mainframe infusion controller, from a default mode in which the control of the mainframe infusion controller and the infusion device module is controlled by the mainframe infusion controller to a remote control mode in which the control of the mainframe infusion controller and the infusion device module is controlled by the infusion control module; in response to receiving user confirmation, switching the mainframe infusion controller to the remote control mode; and controlling the start and stop times and titration rate of the drug being delivered according to the treatment by the infusion control module while in the remote control mode, wherein the mainframe infusion controller maintains control of the drug flow rate during the remote control mode.

[0118] Clause 18. An injection control module according to any one of Clauses 13 to 17, comprising the step of receiving an instruction that the injection control module is electronically coupled to a mainframe injection controller via a first physical interconnect of the injection control module, wherein the first physical interconnect is detachably coupled to the injection control module to the mainframe injection controller.

[0119] Clause 19. An infusion control module according to Clause 18, comprising the step of delivering a drug to an infusion device module by transmitting one or more signals from the infusion control module to a mainframe infusion controller via a first physical interconnection, or by transmitting one or more signals from the infusion control module to an infusion device module via a second physical interconnection of the infusion control module, wherein the second physical interconnection is detachably coupled to the infusion control module.

[0120] Clause 20. A non-temporary, machine-readable storage medium containing instructions that, when executed, cause the injection control module to perform the method described in any one of Clauses 13 to 19.

[0121] Further consideration: The specific order or hierarchy of steps in the disclosed process is to be understood as an example of an exemplary method. It is understood that the specific order or hierarchy of steps in the process may be rearranged based on design preferences. Some steps may be performed simultaneously. The claims for the attached method present elements of various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented.

[0122] The preceding description is provided so that any person skilled in the art may practice the various embodiments described herein. The preceding description provides various examples of the subject art, and the subject art is not limited to these examples. Various modifications to these embodiments will be readily apparent to a person skilled in the art, and the comprehensive principles defined herein may be applied to other embodiments. Accordingly, the claims are not intended to be limited to the embodiments shown herein, but should give the full scope consistent with the claims in language, and references to elements in the singular are not intended to mean "one and just one" unless specifically stated so, but rather "one or more." Unless specifically stated, the term "several" refers to one or more. Masculine pronouns (e.g., his) include feminine and neutral genders (e.g., her and its), and vice versa. Where there are headings and subheadings, they are used for convenience only and do not limit the invention described herein.

[0123] The predicates “configured to,” “operable to,” and “programmed to” are intended to be used interchangeably rather than to imply any particular tangible or intangible modification of the subject. For example, a processor configured to monitor and control operations or components may also mean a processor programmed to monitor and control operations, or a processor operable to monitor and control operations. Similarly, a processor configured to execute code may be interpreted as a processor programmed to execute code, or a processor operable to execute code.

[0124] As used herein, the term "automatic" may include, for example, implementation by a computer or machine without user intervention, by a command in response to a predicate act by a computer or machine or other initiation mechanism. The term "example" is used herein to mean "serving as an example or illustration." An embodiment or design described herein as an "example" is not necessarily construed as being preferable or useful to other embodiments or designs.

[0125] Phrases such as “Aspects” do not imply that such aspects are essential to the subject art, nor that such aspects apply to all configurations of the subject art. Disclosures relating to aspects may apply to all configurations, or to one or more configurations. An aspect may provide one or more examples. A phrase such as “One aspect” may refer to one or more aspects, and vice versa. Phrases such as “Embodiment” do not imply that such embodiment is essential to the subject art, nor that such embodiment applies to all configurations of the subject art. Disclosures relating to embodiments may apply to all embodiments, or to one or more embodiments. An embodiment may provide one or more examples. A phrase such as “Embodiment” may refer to one or more embodiments, and vice versa. Phrases such as “Configuration” do not imply that such configuration is essential to the subject art, nor that such configuration applies to all configurations of the subject art. Disclosures relating to configurations may apply to all configurations, or to one or more configurations. A configuration may provide one or more examples. A phrase such as “Configuration” may refer to one or more configurations, and vice versa.

[0126] As used herein, “User Interface” (also known as an interactive user interface, graphical user interface, or UI) may refer to a network-based interface that includes data fields and / or other control elements for receiving input signals, providing electronic information, and / or providing information to a user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other perceptible displays presented through the UI that, when interacted with (e.g., click, touch, select, etc.), initiate data exchange for the device presenting the UI. The UI may be implemented entirely or partially using technologies such as Hypertext Markup Language (HTML), FLASH®, JAVA®, .NET®, C, C++, Web Services, or Rich Site Summary (RSS). In some embodiments, the UI may be contained within a standalone client (e.g., a thick client, a fat client) configured to communicate (e.g., send or receive data) according to one or more of the embodiments described. Communication may take place between it and a medical device or server communicating with it.

[0127] As used herein, the terms “determine” or “determining” encompass a wide range of actions. For example, “determining” may include, without user intervention, computing, calculating, processing, deriving, generating, obtaining, examining (e.g., examining a table, database, or another data structure), and confirming via hardware elements. “Determining” may also include, without user intervention, receiving (e.g., receiving information), accessing (e.g., accessing data in memory) via hardware elements. “Determining” may also include, without user intervention, resolving, selecting, choosing, and establishing via hardware elements.

[0128] As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location on a storage device for subsequent retrieval, transmitting a value directly to a recipient via at least one wired or wireless medium, or transmitting or storing a reference to a value. “Providing” may also include, via hardware elements, encoding, decrypting, encrypting, deciphering, activating, verifying, etc.

[0129] As used herein, the term “message” encompasses a wide variety of formats for transmitting information (e.g., for sending or receiving). A message may include machine-readable collections of information such as XML documents, fixed-field messages, comma-separated messages, JSON, and custom protocols. In some implementations, a message may include signals used to transmit one or more representations of information. Although described in the singular, it will be understood that a message may consist of multiple parts, be transmitted, stored, received, etc.

[0130] As used herein, the terms “selectively” or “selective” can encompass a wide variety of actions. For example, a “selective” process may involve deciding on one option from several options. A “selective” process may involve one or more of dynamically determined inputs, pre-configured inputs, or user-initiated inputs for making a decision. In some implementations, a selective function may include n input switches, where n is the number of inputs used to make a selection.

[0131] As used herein, the terms “correspond” or “corresponding” encompass structural, functional, quantitative, and / or qualitative correlations or relationships between two or more objects, datasets, information, etc., preferably using correspondence or relationships to translate one or more of the two or more objects, datasets, information, etc., to appear the same or equal. Corresponding relationships may be evaluated using one or more of the following: thresholds, ranges, fuzzy logic, pattern matching, machine learning evaluation models, or a combination thereof.

[0132] In any embodiment, generated or detected data may be transferred to a “remote” device or location, where “remote” means a location or device other than the location or device on which the program is run. For example, a remote location could be another location within the same city (e.g., an office, a lab, etc.), another location within a different city, another location within a different state, another location within a different country, etc. Thus, when one item is indicated to be “remote” to another item, it means that the two items may be in the same room but separated, or at least in different rooms or different buildings, and may be at least one mile, ten miles, or at least 100 miles apart. To “communicate” information means to transmit data representing that information as electrical signals over an appropriate communication channel (e.g., a private network or a public network). To “transfer” an item means any means of moving the item from one location to another, whether by physically transporting the item or by other means (where possible), and at least in the case of data, includes physically transporting the medium carrying the data or communicating the data. Examples of communication media include wireless or infrared transmission channels, network connections to other computers or network devices, and the internet, or email transmissions and information recorded on websites.

Claims

1. An injection control module, A non-temporary machine-readable storage medium in which instructions are stored, According to the aforementioned instruction, Upon receiving an instruction that the injection control module is electronically coupled to the mainframe injection controller, the mainframe injection controller is configured to control one or more injection device modules coupled to the mainframe injection controller. The infusion control module determines that the mainframe infusion controller is programmed to control drug delivery using an infusion device module coupled to the mainframe infusion controller, The infusion control module determines that the drug is suitable for a treatment pre-programmed within the infusion control module. The infusion control module, while electronically coupled to the mainframe infusion controller, instructs the infusion device module to deliver the drug according to the treatment. One or more processors configured as follows An injection control module equipped with the following features.

2. The mainframe infusion controller is programmed to deliver two or more drugs using two or more infusion device modules, and one or more processors, by instruction, The infusion control module prompts the user to select at least one of the two or more drugs to be delivered according to the treatment, Based on the prompt, the selection of the drug is received. The injection control module according to claim 1, further configured as follows.

3. Determining that the drug is suitable for the treatment pre-programmed in the infusion control module includes determining that the drug is suitable for the treatment pre-programmed in the infusion control module while the infusion control module is coupled to a different mainframe device. The injection control module according to claim 1 or 2.

4. The one or more processors, by the instruction, Based on parameters programmed in the mainframe infusion controller, a plurality of drug therapies programmed in the infusion control module when electronically coupled to the different mainframe devices are mapped to a plurality of infusion device modules coupled to the mainframe infusion controller, wherein the parameters include one or more drug types. The injection control module according to claim 3, further configured as follows.

5. The one or more processors, by the instruction, While the infusion control module is coupled to the different mainframe device, the infusion control module transmits programmed parameters and pharmacokinetic information from the infusion control module to the mainframe infusion controller. The injection control module according to claim 3, further configured as follows.

6. The one or more processors, by the instruction, The infusion control module receives infusion information regarding the delivery of the drug to the patient. The injection control module generates a user interface, The infusion control module causes the display device of the mainframe infusion controller to display the user interface, along with the infusion control parameters and information regarding the delivery of the drug, based on the received infusion information. An injection control module according to any one of claims 1 to 5, further configured as follows.

7. The one or more processors, by the instruction, In response to the injection control module being coupled to the mainframe injection controller, the user is prompted to confirm that the mainframe injection controller is switched from a default mode in which the control of the mainframe injection controller and the injection device module is controlled by the mainframe injection controller, to a remote control mode in which the control of the mainframe injection controller and the injection device module is controlled by the injection control module when it is electronically coupled to the mainframe injection controller. In response to receiving the user confirmation, the mainframe injection controller is switched to the remote control mode. The infusion control module controls the start and stop times and titration rate of the drug being delivered according to the treatment while in the remote control mode, and the mainframe infusion controller maintains control of the drug flow rate during the remote control mode. An injection control module according to any one of claims 1 to 6, further configured as follows.

8. The one or more processors, by the instruction, From the server, the infusion control module obtains one or more parameter limits related to the drug in response to the infusion control module being coupled to the mainframe infusion controller, The delivery of the drug is monitored for violations of one or more of the aforementioned parameter limitations. In response to the aforementioned violation, the injection control module instructs the mainframe injection controller to adjust the flow rate of the drug. The injection control module according to claim 7, further configured as follows.

9. The one or more processors, by the instruction, The injection control module determines that the mainframe injection controller is programmed to receive sensor data from a sensor operably coupled to the mainframe injection controller, The sensor determines that the treatment is suitable, The user is prompted to confirm the use of the sensor in connection with the delivery of the drug by the infusion device module in accordance with the treatment, Upon receiving confirmation that the sensor will be used in connection with the delivery, The sensor receives sensor data from the aforementioned sensor, The injection control module adjusts the parameters of the injection device module during the treatment based on the sensor data. An injection control module according to any one of claims 1 to 8, further configured as follows.

10. The one or more processors, by the instruction, A first physical interconnection is provided, configured to be physically and detachably coupled to the mainframe injection controller, and the instruction that the injection control module is electronically coupled to the mainframe injection controller is received via the first physical interconnection. An injection control module according to any one of claims 1 to 9, further configured as follows.

11. The infusion control module according to claim 10, wherein the infusion device module is delivered by one or more signals transmitted from the infusion control module to the mainframe infusion controller via the first physical interconnection.

12. The one or more processors, by the instruction, A second physical interconnect is provided, configured to be physically and detachably coupled to the infusion device module when the first physical interconnect is physically coupled to the mainframe infusion controller, and the infusion device module is provided to deliver the drug by one or more signals transmitted from the infusion control module to the infusion device module via the second physical interconnect. The injection control module according to claim 10, further configured as follows.

13. The steps include: receiving an instruction from an injection control module that the injection control module is electronically coupled to a mainframe injection controller, wherein the mainframe injection controller is configured to control one or more injection device modules coupled to the mainframe injection controller; The infusion control module determines that the mainframe infusion controller is programmed to deliver the drug using an infusion device module coupled to the mainframe infusion controller; The infusion control module determines that the drug is suitable for a treatment pre-programmed within the infusion control module. The infusion control module, while electronically coupled to the mainframe infusion controller, instructs the infusion device module to deliver the drug according to the treatment. A mechanical mounting method, including

14. The mainframe infusion controller is programmed to deliver two or more drugs using two or more infusion device modules, and the method is The steps include prompting the user to select at least one of the two or more drugs to be delivered according to the treatment via the infusion control module, The steps include receiving the selection of the drug based on the prompt and The mechanical mounting method according to claim 13, further comprising:

15. The step of determining whether the drug is suitable for the treatment pre-programmed in the infusion control module includes the step of determining whether the drug is suitable for the treatment pre-programmed in the infusion control module while the infusion control module is coupled to a different mainframe infusion controller. The mechanical mounting method according to claim 13 or 14.

16. The method described above is A step of mapping a plurality of drug therapies programmed in the infusion control module when coupled to the different mainframe infusion controllers to a plurality of infusion device modules coupled to the mainframe infusion controllers, based on parameters programmed in the mainframe infusion controllers, wherein the parameters include one or more drug types. The mechanical mounting method according to claim 15, further comprising:

17. The method described above is The steps include prompting the user to confirm, in response to the injection control module being coupled to the mainframe injection controller, that the mainframe injection controller be switched from a default mode in which the control of the mainframe injection controller and the injection device module is controlled by the mainframe injection controller, to a remote control mode in which the control of the mainframe injection controller and the injection device module is controlled by the injection control module, In response to receiving the user confirmation, the mainframe injection controller is switched to the remote control mode. The steps include: controlling the start and stop times and titration rate of the drug being delivered according to the treatment while in the remote control mode using the infusion control module, wherein the mainframe infusion controller maintains control of the drug flow rate during the remote control mode; and A mechanical mounting method according to any one of claims 13 to 16, further comprising:

18. Steps include receiving the instruction that the injection control module is electronically coupled to the mainframe injection controller via a first physical interconnect of the injection control module, wherein the first physical interconnect detachably couples the injection control module to the mainframe injection controller. An injection control module according to any one of claims 13 to 17, including the following:

19. By transmitting one or more signals from the injection control module to the mainframe injection controller via the first physical interconnect, or By transmitting one or more signals from the injection control module to the injection device module via the second physical interconnection of the injection control module, A step of delivering the drug to the infusion device module, wherein the second physical interconnection is detachably coupled the infusion control module to the infusion device module. The injection control module according to claim 18, including the following:

20. A non-temporary machine-readable storage medium that, when executed, stores instructions causing an injection control module to perform the method according to any one of claims 13 to 19.

Images