Intelligent control of patient-controlled drug delivery

Abstract

Intelligent control of patient-controlled drug delivery is disclosed. An infusion control device detects a patient-controlled drug request device in operable communication with the infusion control device. The infusion control apparatus identifies a sensor apparatus in operable communication with the infusion control apparatus and a drug delivery device separate from the infusion control apparatus. The infusion control device selects a drug control algorithm for approving a drug request received by a patient-controlled drug request device. The infusion control device identifies a patient using a patient-controlled drug request device and receives patient physiological data from a sensor device. The infusion control apparatus receives a request for a medicament to be delivered to a patient by a medicament delivery device. The infusion control device determines whether the patient is authorized to perform the medication request. And based on a determination that the patient is authorized, the infusion control device causes delivery of the medicament to the patient.

Description

Technical Field

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

[0002] Patient-controlled analgesia (PCA) is a method for clinical pain relief that can be more convenient for both clinicians and patients. This method typically involves the use of an infusion pump that is programmed to allow the delivery of a predefined amount of analgesic (e.g., a bolus dose) when the patient desires. Some implementations of PCA include means for the patient to request the delivery of analgesics. There may be situations where a patient should not receive a dose of a drug (e.g., an analgesic). For example, the patient may be unconscious or otherwise in an unstable state, be oversedated, or someone else may be diverting the drug from the patient. However, the safety features for stopping the administration of the drug are limited and may be designed only for specific devices that implement such features. Summary of the Invention

[0003] Accordingly, there is a growing need for PCA control devices (such as via a conventional infusion pump) that implement a drug control algorithm to control drug delivery. This disclosure discusses various implementations of devices, systems, and methods for implementing pause control (e.g., via a drug control algorithm) at various drug delivery devices (e.g., a conventional infusion pump, a fluid infusion pump) by determining which devices (e.g., sensor devices) are in a system that includes a drug delivery device and the identity of the patient using the system.

[0004] According to various implementations, the system includes a patient-controlled drug request device and one or more drug delivery devices in operable communication with the patient-controlled drug request device. The infusion control device can be interchangeably coupled to any of a variety of patient care systems and implement pause control of the drug that a patient of the system can request. For example, a clinician can couple the infusion control device to a patient care system that includes a conventional infusion pump and a patient-controlled drug request device that has an input that a patient can use to request a dose of the syringe. The infusion control device can implement a drug control algorithm to control a patient's use of the patient-controlled drug request device by authorizing the patient's request for drug delivery.

[0005] The various technical improvements of the devices, systems, and methods described herein compared to conventional PCA systems. Although the present disclosure will explicitly recite some technical improvements, by virtue of the disclosed embodiments, it will also make other improvements obvious to those skilled in the art. For example, the embodiments described herein provide interoperability to a PCA system by implementing pause control at a system that includes appropriate sensors, data, and components for controlling the delivery of drugs, even when the system does not include any specific software for implementing the control of the delivery of drugs. Further, embodiments of the systems, devices, and methods described herein can improve the functionality of the computers and / or computing devices used in various embodiments of the PCA system by optimizing the computational and power requirements of a system that requires pause control for more than one drug and / or when there are more than one way to implement pause control for a particular drug. For example, certain embodiments can determine that one or more sensor devices in operable communication with a patient care system can provide data for use by a drug control algorithm to control the delivery of more than one drug, and can reduce the power of sensor devices that are not needed based on the drugs that a patient can request and / or the selected drug control algorithm. Further, the system can use the described embodiments to control drug delivery in combination with other devices (e.g., lock boxes, multiparameter monitors) that can individually limit or otherwise control aspects of patient access to the patient care system.

[0006] The various embodiments of the present disclosure use an infusion control device that includes one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: detecting a patient-controlled drug request device in operable communication with the infusion control device; based on detecting the patient-controlled drug request device, identifying (i) one or more sensor devices and (ii) one or more drug delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more drug delivery devices are in operable communication with the infusion control device; based on identifying the one or more sensor devices and the one or more drug delivery devices, selecting a drug control algorithm for approving a drug request received by the patient-controlled drug request device; using the patient-controlled drug request device to identify the patient; receiving patient physiological data from one or more sensor devices in operable communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device of the one or more drug delivery devices; determining whether the patient is authorized to execute the drug request based on a function of the drug control algorithm, the patient physiological data, and the history of drug administration to the patient; and based on determining that the patient is authorized to execute the drug request by means of the drug control algorithm, causing the drug to be delivered via the one or more drug delivery devices.

[0007] According to various aspects, a machine-implemented method includes: at an infusion control device including one or more processors and a memory storing instructions: detecting a patient-controlled drug request device in operable communication with the infusion control device; based on detecting the patient-controlled drug request device, identifying (i) one or more sensor devices and (ii) one or more drug delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more drug delivery devices are in operable communication with the infusion control device; based on identifying the one or more sensor devices and the one or more drug delivery devices, selecting a drug control algorithm for approving a drug request received by the patient-controlled drug request device; using the patient-controlled drug request device to identify the patient; receiving patient physiological data from one or more sensor devices in operable communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device of the one or more drug delivery devices; determining whether the patient is authorized to execute the drug request based on a function of the drug control algorithm, the patient physiological data, and a history of drug administration to the patient; and based on determining that the patient is authorized to execute the drug request by means of the drug control algorithm, causing the drug to be delivered via the one or more drug delivery devices.

[0008] According to various aspects, a system includes a drug delivery device in operable communication with a control unit for controlling the delivery of a drug to a patient via the drug delivery device, wherein the control unit includes a handheld electronic drug request device, one or more processors, and a memory including instructions that, when executed by the one or more processors, cause the performance of operations and include the following: determining that the handheld electronic drug request device is electrically coupled to the drug delivery device for the delivery of the drug to the patient; in response to determining that the handheld electronic drug request device is electrically coupled to the drug delivery device, receiving information regarding a patient profile associated with the patient from the drug delivery device; presenting user interface elements including information regarding a patient profile associated with the patient on a display integrated in the handheld electronic drug request device; while the user interface elements are presented on the display integrated in the handheld electronic drug request device, receiving, via touch-activated controls of the handheld electronic drug request device, a patient request to deliver a certain dose of the drug to the patient; and in response to the patient request, causing a certain dose of the drug to be delivered to the patient. Other aspects include implementations of corresponding devices, methods, and computer program products for corresponding systems and their features.

[0009] Other configurations of the present subject matter will become apparent to those skilled in the art from the following detailed description, in which various configurations of the present subject matter are illustrated and described by way of example. As will be recognized by those skilled in the art, the present subject matter is capable of other and different configurations, and several details thereof can be modified in various other respects, all without departing from the scope of the present subject matter. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] To better understand the various described embodiments, reference should be made to the following description in conjunction with the accompanying drawings. In the drawings and description throughout, like reference numerals will always refer to corresponding parts:

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

[0012] Figure 2A An example of an institutional patient care system for a healthcare organization in accordance with aspects of the present subject matter is described.

[0013] Figure 2B is a close-up view of a portion of an example patient care device in accordance with various aspects of the present subject matter Figure 2A as shown in

[0014] Figures 3A - 3E An example configuration of a system in accordance with various aspects of the present subject matter is described, the system including an infusion control device operably communicable with one or more drug delivery devices.

[0015] Figure 4 An example process for implementing a drug control algorithm at an infusion control device operably communicable with one or more drug delivery devices in accordance with various aspects of the present subject matter is described.

[0016] Figure 5 is a conceptual diagram showing an example electronic system for operating an analgesia administration system in accordance with aspects of the present subject matter. DETAILED DESCRIPTION

[0017] Reference will now be made to embodiments, examples of which are illustrated in the drawings. In the following description, numerous specific details are set forth in order to provide an understanding of the various described embodiments. However, one of ordinary skill in the art will understand that the various described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0018] Figure 1An example of an institutional patient care system 100 of a healthcare organization in accordance with aspects of the present subject matter is described. In Figure 1 , a patient care device 12 (“PCD”) (sometimes referred to as a “patient care unit” (“PCU”) or more generally as a “medical device”) is connected to a healthcare network 110. The patient care device 12 can include or be communicatively coupled to various ancillary medical devices such as drug delivery devices (e.g., infusion pumps, syringe pumps), vital sign monitors, drug dispensing devices (e.g., cabinets, suitcases), drug preparation devices, automated dispensing devices, modules coupled to one of the above drug delivery devices (e.g., a syringe pump module configured to attach to an infusion pump), patient-controlled analgesia (PCA) rods, or other similar devices. Each element of the patient care device 12 can be connected to the healthcare network 110 by a transmission channel 131. The transmission channel 131 can be any suitable wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some embodiments, the healthcare network 110 also includes computer systems located in various departments throughout the hospital. For example, the healthcare network 110 optionally includes computer systems associated with one or more of the following: an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and / or a medical decision support system. As described further below, the healthcare network 110 can include discrete sub-networks. In the example described, the healthcare network 110 includes a device network 140 through which the patient care device 12 (and other devices) can communicate according to normal operation. According to some embodiments, the devices and support services of the healthcare network 110 or a portion thereof can be cloud-based, e.g., the servers and services (e.g., databases, APIs, etc.) are located away from the hospital and / or distributed across multiple remote locations or regions.

[0019] In addition, the institutional patient care system 100 can include a separate information system server 130, the functions of which will be described in more detail below. Additionally, although the information system server 130 is shown as a separate server, the functions and programming of the information system server 130 can be incorporated into another computer, such as a hospital information system server or a cloud-based server, if desired by the engineers designing the institutional information system. The institutional patient care system 100 can also include one or more device terminals 132 for connecting and communicating with the information system server 130. The device terminals 132 can include personal computers, personal data assistants, mobile devices (such as laptops, tablets, augmented reality devices, or smartphones) configured with software for communicating with the information system server 130 via the healthcare network 110. The information system server 130 can receive and provide information about patients and / or their treatments, such as measurements from patient monitoring devices (not shown), patient entries via one of the device terminals 132, or events from the patient care devices 12.

[0020] The patient care device 12 can include or incorporate pumps, physiological monitors (such as heart rate, blood pressure, electrocardiogram (ECG), electroencephalogram (EEG), pulse oximeter, and other patient monitors), treatment devices, and can use other drug delivery devices (e.g., infusion control devices configured to be operably coupled to the patient care device 12 or another device within the patient care system 100) in accordance with the teachings described herein. In the example described, the patient care device 12 includes a control module (also referred to as interface unit 14) that is connected to one or more functional modules 16, 18, 20, 22. The interface unit 14 includes a central processing unit (CPU) 50 connected to a memory, such as memory 58 (e.g., random access memory (RAM)), and one or more interface devices, such as a user interface device 54 (e.g., a display screen and / or keyboard), a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. Although not required, the interface unit 14 also includes a primary non-volatile storage unit (e.g., disk 56) for storing software and data, such as a hard disk drive or non-volatile flash memory, and one or more internal buses 64 for interconnecting the above elements.

[0021] In various embodiments, the user interface device 54 is a touch screen for displaying information to a user and allowing the user to input information by touching defined areas of the screen. Additionally or alternatively, the user interface device 54 may include any device 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 barcode format. Additionally or alternatively, the data input device 60 may be any device for inputting encoded data into a computer, such as one or more devices for reading magnetic strips, radio frequency identification (RFID) devices, where digital data encoded in an RFID tag or smart tag (defined below) is captured by the data input device 60 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage medium. Other examples of the data input device 60 include voice-activated or recognition devices or portable personal data assistants (PDAs). 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 Figure 1 the data input device 60 is shown as being disposed within the interface unit 14, it will be appreciated 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 communication means. The auxiliary interface 62 may be an RS-232 communication interface; however, any other means for communicating with peripheral devices, such as printers, patient monitors, infusion pumps, or other medical devices, may be used without departing from the subject technology. Additionally, the data input device 60 may be a separate functional module, such as functional modules 16, 18, 20, and 22, and be configured to communicate with the interface unit 14 or any other system on the network using appropriate programming and communication protocols.

[0022] The network connection 52 may be a wired or wireless connection, such as via 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 telephone modems, MIB systems, RS232 interfaces, auxiliary interfaces, optical links, infrared links, radio frequency links, microwave links, or WLAN connections or other wireless connections.

[0023] The functional modules 16, 18, 20, 22 are any devices associated with the interface unit 14 for providing care to a patient and / or for monitoring a patient's condition. As Figure 1As shown, at least one of the functional modules 16, 18, 20, 22 can be an intravenous infusion pump, such as for delivering drugs or other fluids to a patient. For example, the functional module 16 can be an infusion pump module. Each of the functional modules 16, 18, 20, and 22 can be any patient treatment or monitoring device, including but not limited to an infusion pump, an injection pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, or an intracranial pressure monitor, etc. In other examples, the functional modules 18, 20, and / or 22 can include devices other than the infusion pump module, including a printer, a scanner, a barcode reader, or any other peripheral input, output, or input / output device

[0024] Each of the functional modules 16, 18, 20, and 22 communicates directly or indirectly with the interface unit 14, which provides overall monitoring and control of the patient care device 12. As Figure 1 shown, the functional modules 16, 18, 20, and 22 can be physically and electronically connected to one or both ends of the interface unit 14 in a serial manner. However, it should be recognized that other means can be utilized for connecting the functional modules to the interface unit without departing from the subject technology. It will also be understood that a device such as a pump or a patient monitoring device that provides sufficient programmability and connectivity can be capable of operating as a stand-alone device and can communicate directly with the network without the need to be connected through a separate interface unit 14. As described above, additional medical devices or peripheral devices can be connected to the patient care device 12 through one or more auxiliary interfaces 62.

[0025] Each of the functional modules 16, 18, 20, and 22 can include module-specific components 76, a microprocessor 70, volatile memory 72, and non-volatile memory 74 for storing information. In some embodiments, the functional module can include hardware components similar to those of the interface unit 14, including but not limited to a CPU 50 connected to the memory 58, one or more interface devices such as the user interface device 54, an encoded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. It should be noted that although Figure 1 four functional modules are shown, any number of devices can be directly or indirectly connected to the interface unit 14. The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. The module-specific components 76 include any components required to operate a particular module, such as a pumping mechanism for an infusion pump module (e.g., the infusion pump module 22 as Figures 2A - 2B shown).

[0026] According to various embodiments, although each functional module may be capable of operating independently (e.g., as described with respect to interface unit 14 and its hardware components), interface unit 14 is configured to monitor and control the overall operation of patient care device 12. For example, interface unit 14 may provide programming instructions to functional modules 16, 18, 20, 22 and monitor the status of each module.

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

[0028] Data between various data sources can be converted to network-compatible data by the prior art, and information movement between the medical device and the network can be achieved through various means. For example, patient care device 12 and healthcare network 110 may communicate via automated interaction, manual interaction, or a combination of automated and manual interaction. Automated interaction may be continuous or intermittent and may occur via network connection 52 (as Figure 1 shown) or via an RS232 link, a MIB system, an RF link (such as Bluetooth), an IR link, a WLAN, a digital cable system, a telephone modem, or other wired or wireless communication means. Manual interaction between patient care device 12 and healthcare network 110 involves physically transferring data intermittently or periodically between the systems using, for example, user interface device 54, coded data input device 60, barcodes, computer disks, portable data assistants, memory cards, or any other medium for storing data. The communication means for each aspect is two-way and can access data from as many distributed data source points as possible.

[0029] Figure 2A An example of an institutional patient care system of a healthcare organization in accordance with aspects of the present subject matter is described. Figure 2A The patient care device 200 shown is similar or identical to Figure 1 patient care device 12 therein and includes four fluid infusion pumps 16, 18, 20, and 22 (e.g., as in Figure 1Also referred to as functional modules 16, 18, 20, and 22 herein, each pump is operatively engaged with a corresponding fluid administration device 30, 32, 34, and 36. Fluid supplies 38, 40, 42, and 44, which can take various forms but are shown as bottles in this case, are inverted and suspended above the pumps. The fluid supplies can also take the form of bags or other types of containers. In the example described, the patient care device 200 and the fluid supplies 38, 40, 42, and 44 are both mounted to a roller stand or rod 46. The particular fluid supply and its orientation within the care area (e.g., mounting location, mounting height, mounting type, etc.) can generate one or more interaction records. For example, the set of interaction records can be partially generated by detecting a scannable code associated with the set prior to use. Once scanned, the interaction records can be recorded for use as described herein.

[0030] As Figure 2A shown in the example embodiment of, each administration device 30, 32, 34, and 36 is connected between a corresponding fluid supply 38, 40, 42, and 44 and a patient 48 such that the patient 48 can receive fluid from all of the fluid supplies. The administration device can be actively identified, for example, by scanning by a clinician, or can be passively identified, for example, by wireless or optical detection of the administration device. As with the fluid supplies, once identified, interaction records can be generated to identify one or more of the administration device and the clinician, programming module, pump, administration device positioning (e.g., administration location (e.g., left forearm, right upper arm, etc.).

[0031] Each of the fluid infusion pumps 16, 18, 20, and 22 can be used to infuse each of the fluids in the fluid supplies into the patient 48. The fluid infusion pumps 22, 24, 26, and 28 are flow control devices that will act on the corresponding tubes or fluid conduits of the fluid administration devices to move the fluid from the fluid supplies through the conduits to the patient 48. Because separate pumps are used, each pump can be individually set to the pumping or operating parameters required to infuse a particular medical fluid from the corresponding fluid supply into the patient at a particular rate prescribed by the clinician for that fluid. Activities performed by the pump or the clinician for infusing a particular medical fluid can be associated with one or more interactions that can be recorded and processed as described.

[0032] Figure 2B is part of an example patient care device according to various aspects of the present subject matter Figure 1 A close-up view of a portion of the example patient care device shown in. Figure 2BTwo functional modules are shown; a functional injection pump module 18 and a functional infusion pump module 20 mounted on both sides of the interface unit 14, as well as respective displays and control keys. The functional infusion pump module 20 includes a door 5a and a handle 5b. The handle 5b is used to lock the door in the closed position for operation, unlock and open the door to access the internal pumping and sensing mechanisms, and load the administration device for the pump. When the door 5a is open, the tube can be connected to the pump module 20. When the door 5a is closed, the tube is operatively engaged with the pumping mechanism, upstream and downstream pressure sensors, and other devices of the pump. In this embodiment, a display 5c (such as an LED display) is located in a plan view on the door and can be used to visually communicate various information related to the pump module 20, such as an alarm indication (e.g., an alarm message). There may be control keys 5e - 5h for programming and controlling the operation of the infusion pump as needed. In some embodiments, the control keys may be presented as interactive elements on the display 5c (e.g., a touch screen display). The main frame and / or functional modules may also include an audio alarm device in the form of a speaker (not shown).

[0033] The interface unit 14 of the patient care device 12 includes a display 6a for visually communicating various information (such as the operating parameters of the connected pump, alarm indications, and alarm messages); and control keys 6b and 6c for selecting and / or setting control parameters and / or for controlling options of the patient care device 12 and the connected modules. The interface unit 14 may also include a speaker to provide an audible alarm. In some embodiments, the display 6a may be implemented as a touch screen display. In such an embodiment, by providing corresponding interactive elements through a graphical user interface presented via the display 6a, the number of control keys 6b may be omitted or reduced. In some embodiments, each control key 6b (or 6c) may select a corresponding option displayed in the display 6a.

[0034] The interface unit 14 may include a communication system (not shown) through which the interface unit 14 can communicate with external devices (such as a medical facility server or other computer) and portable processors (such as a handheld communication device or a portable computer) or other information devices that a clinician may use to transmit information and download a drug library to the functional modules 16, 18, 20, 22 (e.g., the infusion pump 20). In some embodiments, the main frame infusion controller may communicate (e.g., via a wired connection or wirelessly) with a patient - controlled drug request device 306, which will be described in more detail below with reference to Figure 3A The communication system can be used to transmit access and interaction information for a clinician encountering the main frame infusion controller or a device coupled thereto (e.g., the fluid infusion pump module 22 or a barcode scanner). The communication system may include a radio frequency (RF) system, an optical system such as infrared, Bluetooth TMone or more of a system or other wired or wireless systems. The barcode scanner and the communication system may alternatively be included integrally with the infusion pump 20, such as in the case of not using a main frame infusion controller, or in addition to being used with the main frame control unit 14. Additionally, the information input device does not need to be hardwired to the medical device, and the information can also be transmitted via a wireless connection. Further, other types of modules may be connected to the pump module or the main frame infusion controller, such as an injection pump module, a patient-controlled analgesia module, an end-tidal CO2 (ETCO2) monitoring module, a pulse oximeter monitoring module, etc.

[0035] For purposes of the present disclosure, the interface unit 14 and / or the information server 130 may include software and associated algorithms for implementing the various features described herein. The hardware, software, and associated algorithms are collectively referred to herein as the patient care system. In some embodiments, the interface unit 14 operates the patient care system, in which internal processing and decision control are used to approve dose requests made by the patient-controlled drug request device 306. In some embodiments, the dose request may be forwarded from the interface unit 14 to the information server 130 for approval. In some embodiments, at the interface unit 14 that receives the dose request, the interface unit may process and approve the dose request based on obtaining patient profile information from the information system server 130 (e.g., from the EMR system).

[0036] During operation of the patient care system, when patient 48 activates the connected patient-controlled drug request device 306, the interface unit 14 (including, for example, microprocessor 50) receives a dose request signal via the patient dose request line 303 (or via wireless communication). If the interface unit 14 determines (e.g., in conjunction with profile data obtained from an internal database or via the information system server 130) that there are no restrictions on administering the requested bolus dose of the drug, the interface unit 14 may send a signal to the connected pump controller to instruct the pump unit associated with the request to administer the requested bolus dose. The interface unit 14 also provides coordination of activities between functional units such as the pump and the ETCO2 unit. For example, a clinician may set the patient care device 12 to provide PCA administration and set the ETCO2 unit to monitor the ETCO2 parameters of a PCA patient. Optionally, one or more additional monitors such as a pulse oximeter unit may be communicatively connected to the patient care system and set to monitor blood oxygen saturation and pulse rate. The clinician may specify minimum and / or maximum values for ETCO2, respiratory rate, and / or other monitored parameters, thereby effectively setting a range of acceptable values for these parameters. If a patient's ETCO2 parameter is outside the selected acceptable range (such as when it becomes less than the minimum level set by the clinician or greater than the maximum level set by the clinician), the ETCO2 monitor may send a trigger signal to the interface unit 14. In response, the interface unit 14 may activate visual and / or audible alarms (e.g., via the display 310 associated with the infusion control device 300, as described below), pause the operation of the pump, adjust the flow rate of the pump, and / or perform another predetermined function. For example, in response to an out-of-range ETCO2 measurement in patient 48, the interface unit 14 may stop all further administration of the analgesic until an unacceptable low or high ETCO2 value and / or respiratory rate situation is resolved, such as by clinician intervention or patient change. Alternatively, the interface unit 14 may simply lock out the infusion control device 300 so that the patient cannot obtain further self-administration. Thus, after appropriate values have been set, the patient control system provides communication and coordination between the interface unit, the pump, and the ETCO2 unit to ensure greater safety and reduce the risk of harm due to respiratory depression.

[0037] In some embodiments, rather than the interface unit 14 only pausing the operation of the pump in response to a signal from the ETCO2 unit or another functional module being out of range, the interface unit 14 may also include program instructions for monitoring changes in the CO2 concentration data or other data generated by the ETCO2 unit and determining whether to interfere with the patient's control of the pump module based on the changes in the monitored data, such as the rate of change. In some embodiments, the interface unit 14 is configured to receive data from an infusion control device (such as regarding Figure 3AThe described infusion control device 300 receives instructions, including information regarding a determination of whether to interfere with a patient's control of one or more drug delivery devices (e.g., pump modules, syringe modules) and / or whether to provide additional instructions for monitoring specific health parameters.

[0038] Typically, medical fluid administration devices have more components than Figures 1 - 2B shown. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. For the sake of clarity of illustration, these other devices are not included in the drawings. Refer to FIGS. 3-4 and the related description below regarding how the patient-controlled drug request device 306 operates in conjunction with the components and devices of the patient care system 100, including the patient care device 200.

[0039] Figures 3A - 3E An example configuration of a system in accordance with various aspects of the present subject matter is described, the system including an infusion control device 300 operably communicable with one or more drug delivery devices (e.g., functional modules 16 and 18 and / or their constituent components). According to various embodiments, the infusion control device 300 is provided to engage the patient care device 12 with one or more external devices and provide control and / or oversight of the patient care device 12 based on these connected external devices.

[0040] Figure 3AAn example block diagram of a system including an infusion control device 300 is described. In some embodiments, the infusion control device 300 is a modular device separate from the patient care device 12. In this regard, the infusion control device 300 can be detachably coupled to the patient care device 12 as a functional module of the patient care device 12, or additionally or alternatively coupled to any one of the functional modules 16, 18, 20, or 22. In the example described, the infusion control device 300 forms a communication connection with the interface unit 14 of the patient care device 12 through a communication connection formed with the lockbox 302, which is configured and arranged to secure a portion of the patient care device 12 (e.g., the interface unit 14 and / or the functional modules 16 and 18). In some embodiments, the infusion control device 300 can be detachably coupled to the patient care device 12 without being connected to the lockbox 302. That is, the infusion control device 300 can be interoperable to work with different configurations of the patient care system, such as being capable of being directly coupled to the patient care device 12 or a component that houses the patient care device 12 (or a portion thereof), such as the lockbox 302. In some embodiments, the infusion control device 300 includes a first type of connector for coupling to the patient care device 12 and a second type of connector for coupling to the lockbox 302. In some embodiments, the infusion control device 300 is configured to detect the presence of the lockbox 302 while being operably coupled to the patient care device 12. In some embodiments, based on detecting that the lockbox 302 is around the patient care device 12, the infusion control device 300 performs additional operations to prompt the patient 48 to provide credentials and to receive the credentials provided by the patient 48 and provide the credentials to the patient care device 12.

[0041] The infusion control device 300 can include a display module 310 for displaying various information that may be relevant to the patient 48 or the clinician. For example, the display module 310 can indicate the status of the sensor device 314 and / or the drug delivery device of the patient care device 12, and / or information regarding the drug requests of the patient 48. In some embodiments, the display module 310 of the infusion control device 300 is configured to display one or more user interface elements corresponding to the user interface elements displayed at the user interface device 54 of the patient care device 12. When the clinician is authorized to use the patient care device 12, the coupled infusion control device 300 can aggregate the interface input system (e.g., the displays 6a and / or 5c and / or the controllers 6b / 6c and / or 5e-h) to the clinician via the display module 310 of the infusion control device 300. This aggregation can be particularly useful when the patient care device 12 is secured by the lockbox 302.

[0042] According to various embodiments, the lockbox 302 includes a housing that completely surrounds the patient care device 12, including any attached functional modules and associated medications, and protects the patient care device 12 and its corresponding functional modules from physical manipulation by persons who do not have access to the lockbox 302 (e.g., the patient 48). In some embodiments, the medications within the infusion pump of the functional module are secured in a manner that is enclosed within the lockbox 302. In some embodiments, the lockbox 302 can be extended to accommodate and secure a medication bag for use with different types of pumps (e.g., peristaltic pumps). In some embodiments, the lockbox 302 is self-powered and includes a power source within the lockbox 302 (e.g., not accessible to persons outside the lockbox 302 when the lockbox 302 is secured). In some embodiments, the lockbox 302 has one or more automatic doors (or lids), and the power for the lockbox door / lid and / or the infusion control device 300 can be provided or supplemented by the power source 312 of the patient care device 12.

[0043] According to various embodiments, the infusion control device 300 can form an electronic communication connection with the lockbox control interface 304 of the lockbox 302, where the lockbox control interface 304 is configured to enclose and prevent access to at least a portion of the patient care device 12. In some embodiments, after the lockbox control interface 304 establishes an electronic communication connection, the infusion control device 300 receives a wireless credential at the input interface of the infusion control device 300, and the infusion control device 300 transmits the wireless credential to the patient care device 12 via the electronic communication connection within the lockbox control interface 304. In some embodiments, after receiving and transmitting the credential, the infusion control device 300 receives an indication from the patient care device 12 via the electronic communication connection as to whether the patient 48 is authorized to request a dose of medication to be delivered. In some embodiments, based on receiving an indication that the patient 48 is authorized to request a dose of medication to be delivered, the infusion control device 300 uses a selected medication control algorithm (e.g., the medication control algorithm 308) to determine whether the medication request submitted by the patient 48 is an authorized medication request. If the patient 48 is not authorized to request a dose of medication, the lockbox control interface 304 and / or the display module 310 of the infusion control device 300 can block the delivery of the dose and display an indication that the credential was not verified.

[0044] According to some embodiments, after the infusion control device 300 forms an operable communication connection with the patient care device 12 (e.g., via a communication connection formed with the lockbox 302), the infusion control device 300 detects the patient-controlled medication request device 306 (e.g., a PCA wand or a dose request device). The patient-controlled medication request device 306 can be integrally connected or detachably coupled to the infusion control device 300, or the patient-controlled medication request device 306 can be attached to another device of the patient care system 100 (e.g., via input data from the input device 60). In some embodiments, the data input device 60 can receive communication from a connection component of the patient-controlled medication request device 306 (e.g., an auxiliary connector, such as the patient dose request line 303). In some embodiments, the patient-controlled medication request device 306 includes wireless communication components (e.g., Bluetooth circuitry) and is configured to form a wireless connection with one or more of the infusion control device 300, the lockbox 302, the interface unit 14, and / or one or more functional modules of the patient care device 12. In some embodiments where the patient-controlled medication request device 306 is integrally attached to or detachably coupled to the infusion control device 300, the infusion control device 300 provides information about the patient-controlled medication request device 306 to the patient care device 12, and this information can be provided in conjunction with (e.g., simultaneously with) a data request regarding the patient care device 12.

[0045] In some embodiments, the patient-controlled medication request device 306 includes a display 320, which can be a touchscreen display. The display 320 can be used to display information related to drug delivery, including patient-interactive user interface elements that the patient 48 can select to cause operations to be performed by a combination of the patient-controlled medication request device 306, the infusion control device 300, and / or other components of the patient care system 100. For example, the display 320 can first display user interface elements that the patient 48 can select to cause a certain dose of drug to be delivered, and then (e.g., after a predefined duration after the drug has been delivered) can display a pain assessment user interface where the patient 48 can provide a response indicating the level of pain the patient 48 is experiencing. In some embodiments, the interaction of the patient 48 with the pain assessment user interface can be included in the operation of the drug control algorithm 308 to determine whether the patient 48 is authorized to receive the requested dose of the drug. For example, if the patient 48 indicates that they are experiencing a high level of pain soon after receiving the requested dose of the drug, the infusion control device 300 can determine that the drug is ineffective in treating a type of pain experienced by the patient 48, or that the drug was not actually delivered to the patient 48 (e.g., due to a mechanical problem or drug diversion).

[0046] In some embodiments, the patient-controlled medication request device 306 can be used to identify the patient 48 either in a voucher receipt mechanism or in a manner associated with the patient 48 (e.g., via an identifier stored by the patient-controlled medication request device 306). In some embodiments, the patient 48 provides a voucher (e.g., patient identity 316 and / or information verifying that the patient 48 corresponds to the patient identity 316) to the infusion control device 300 via a user input to the infusion control device 300 (e.g., an integrated touchscreen and interface) or a coupled electronic device external to the lockbox 302 (e.g., a biometric sensor of the patient-controlled medication request device 306). According to various embodiments, after receiving the voucher, the infusion control device 300 sends the voucher and / or the patient identity 316 to the patient care device 12, and the patient care device 12 or another component of the patient care system 100 can authenticate the voucher.

[0047] In some embodiments, the patient 48 can provide image data to a camera associated with or integrated into the patient-controlled medication request device 306, and the patient care device 12 can authenticate the patient 48 based on the image. In some embodiments, a voucher is received from a badge scanned by the RFID scanner or another card-reading device of the lockbox control interface 304. In some embodiments, the scanned data received at the lockbox control interface 304 is provided to the data input device 60 of the patient care device 12 (e.g., as a proxy for data to be collected at the barcode reader of the data input device 60).

[0048] In some embodiments, after providing the voucher, the infusion control device 300 receives an indication (e.g., an alert response) indicating whether the patient 48 is authorized to request a dose of one or more medications configured to be requested by the patient-controlled medication request device 306. In some embodiments, the patient 48 must provide the voucher to other devices of the patient care system 100 other than the patient care device 12 to enable the functionality of the patient-controlled medication request device 306. In some embodiments, the voucher for the patient 48 is provided to the information system server 130 and is used to access patient history information, patient treatment, and / or patient physiological data. In some embodiments, the information (communications, data) received by the interface unit 14 is provided to the infusion control device 300. For example, the function module 16 can communicate to the interface unit 14 information that the syringe pump including the function module 16 is not working properly, and the interface unit 14 can provide this information to the infusion control device 300 (e.g., via the lockbox control interface 304).

[0049] According to various embodiments, the infusion control device 300 is configured to automatically identify one or more sensor devices 314 (e.g., an ETCO2 sensor, an SpO2 sensor, etc.) and one or more drug delivery devices (e.g., functional modules 16 and 18, which may include an infusion pump, a syringe, and / or its mechanical components) that are in operable communication with the infusion control device 300 (e.g., via an operable communication connection with the patient care system 100). The infusion control device 300 may identify one or more sensor devices 314 in response to detecting the patient-controlled drug request device 306; or it may do so at different times (such as when the infusion control device 300 is connected to the patient care device 12 and / or when the patient 48 requests drug delivery). In some embodiments, one or more of the identified sensor devices 314 are integrated (e.g., embedded, attached, or otherwise disposed) into the patient-controlled drug request device 306. For example, the handle of the patient-controlled drug request device 306 may include a camera sensor configured to receive an image of the patient 48 and / or a touch-sensitive surface configured to receive patient input. According to various embodiments, the infusion control device 300 may use the patient identity 316 to confirm the patient's identity or otherwise authenticate the patient 48. The patient identity 316 may also be used to retrieve patient physiological data or other data about the patient 48 described herein, and then the infusion control device 300 may use this data to authorize a request for a drug dose to be delivered. For example, patient data indicating that the patient 48 has a particular sensitivity (e.g., is more likely to lose consciousness or otherwise be unstable due to PCA) may be used by the infusion control device 300 as part of selecting the drug control algorithm 308 and / or for selecting patient health thresholds to compare with sensor data to determine whether delivery control criteria are met.

[0050] Based on identifying a sensor device 314 and a drug delivery device that are electrically coupled to and in electronic communication with the infusion control device 300, the infusion control device 300 automatically selects a drug control algorithm 308 to control drug delivery from the coupled drug delivery device (e.g., implement pause control). The drug control algorithm 308 can be used to approve drug requests received by the patient-controlled drug request device 306. In this regard, the drug control algorithm 308 can perform operations to confirm that the patient is authorized to self-administer from the coupled drug delivery device and provide an instruction to deliver the drug to the drug delivery device only when approved by the algorithm. As will be further described, authorization can include confirming the patient's identity and confirming that the drug can be safely delivered based on the patient's physiological data, the pharmacokinetic properties of the drug being delivered, and / or the history of the patient's drug administration. In some embodiments, the infusion control device 300 obtains the drug control algorithm 308 from the local memory of the infusion control device 300. In some embodiments, the infusion control device 300 is configured to download the drug control algorithm 308 from a different electronic device (such as the information system server 130).

[0051] In some embodiments, the infusion control device 300 selects a plurality of drug control algorithms, and each respective drug control algorithm in the plurality of drug control algorithms can be specific to a particular drug delivery device connected to the device. In this regard, the infusion control device 300 can detect the drug delivery device connected to the device 300 and select one or more appropriate algorithms for each detected drug delivery device. In some embodiments, the infusion control device 300 determines the required algorithm based on the drug associated with the patient 48 (e.g., in a patient profile accessed based on the patient's identity), the type of drug delivery device connected to the device 300, and / or sensor data (e.g., via the connected sensors) that can be obtained by the infusion control device 300 when the patient 48 is using the patient-controlled drug request device 306. In some embodiments, the infusion control device 300 detects that the patient care device 12 includes multiple types of drug delivery devices.

[0052] In an example scenario, the patient care device 12 can include a first type of drug delivery device, such as a syringe configured to be manually pressed to inject a first drug into the patient 48; and a second type of drug delivery device, such as an intravenous infusion pump integrally coupled with an electronic actuation system (e.g., including mechanical fingers) for causing a dose of a second drug to be delivered to the patient 48. Then, the drug control algorithm 308 can be selected based on the two drug delivery devices detected and identified by the infusion control device 300.

[0053] According to various embodiments, a patient - controlled drug request device 306 is configured to request delivery of a set of drugs corresponding to a set of patient treatments, which may be received by an infusion control device 300 from an information system server 130. In some embodiments, the power of one or more sensor devices 314 of the patient care system 100 may be reduced or increased based on a set of drug treatments configured to be delivered by a connected drug delivery device. In some embodiments, when a set of treatments is determined, the infusion control device 300 may determine that a particular sensor device 314 (e.g., an ETCO2 sensor device) is needed to obtain patient physiological data to determine whether a request for a drug corresponding to the set of treatments should be approved and / or biometric verification by an imaging sensor of the patient - controlled drug request device 306 is required to access at least one of the drugs associated with the set of treatments. The infusion control device 300 may then confirm that the particular sensor device 314 is connected and, if not, prompt the clinician to connect the sensor device 314 and reject the drug request until the sensor device 314 is connected and the data received from the sensor device 314 can be evaluated by an algorithm. In some embodiments, the infusion control device 300 may cause power to be delivered to the identified sensor device 314 (e.g., ETCO2) required for a given treatment and may reduce the power to another sensor device 314 not required for the implementation of the treatment.

[0054] According to various embodiments of the present disclosure, when the patient - controlled drug request device 306 receives a request for a drug to be delivered, a drug control algorithm 308 of the infusion control device 300 receives an indication of the request and determines whether the request for the drug is authorized by applying sensor data from one or more sensor devices 314 in operable communication with the infusion control device 300. In some embodiments, a patient 48 is authorized to perform the determination of the drug request based on biometric verification that the patient 48 actually performed the user input that caused the drug request (e.g., to prevent drug diversion). For example, the patient - controlled drug request device 306 may include a camera, and the infusion control device 300 may cause imaging data to be obtained by the camera of the patient - controlled drug request device 306 in response to detecting the request. The obtained image data may be used (e.g., by the patient care device 12 and / or the information system server 130) to perform facial recognition of the patient 48 to verify that the patient 48 performed the input at the patient - controlled drug request device 306.

[0055] As will be discussed in more detail below, sensor data can be used to determine whether one or more delivery control criteria are met (e.g., achieved) prior to delivering a dose of medication to patient 48. In some embodiments, the delivery control criteria are a set of one or more preconditions (e.g., preconditions of patient care system 100 and / or patient 48) that must be met before a medication delivery request made by patient 48 is authorized. Additionally or alternatively, the delivery control criteria can be used to determine how much medication to deliver, and / or the timing of delivery available to deliver a dose of medication to patient 48. In some embodiments, the delivery control criteria are implemented as part of medication control algorithm 308.

[0056] The delivery control criteria can include a threshold medical condition or state that patient 48 is determined to be in prior to patient 48 being able to receive medication (e.g., whether patient 48 is unstable and / or unconscious). Relevant aspects (e.g., values of biometrics) of the patient's current medical condition or state can be determined based on measurements from one or more sensor devices 314 identified by infusion control device 300 and / or patient data obtained via different components of patient care system 100. In one example, the delivery control criteria can be met based on a biometric detected by sensor device 314 that meets a patient health threshold for the corresponding biometric, where the biometric reflects an aspect of the patient's medical condition or state.

[0057] In some embodiments, patient health thresholds are set and / or adjusted based on patient data indicating that patient 48 has a pre-existing medical condition and / or sensitivity to a particular type of medication. The patient health thresholds or other delivery control criteria can also be related to the type of medication requested and / or the pharmacokinetic properties of the medication, which can be identified by infusion control device 300 as part of detecting the medication delivery device of patient care device 12. For example, determining whether the delivery control criteria are met can include determining an estimated effect that the medication is likely to have on patient 48 based on the dose requested by patient 48, patient demographics, and the pharmacokinetic properties of the medication, and determining whether delivering the medication to patient 48 will cause the patient's biometric to reach or exceed the patient health threshold based on the estimated effect.

[0058] Additionally or alternatively, satisfaction of one or more delivery control criteria may be based on other aspects of the patient care system 100. In some embodiments, determining whether a delivery control criterion is satisfied may include first determining the mechanical state of one of the drug delivery devices of the patient care device 12. Based on determining that the mechanical components of the drug delivery device are operating properly and are capable of delivering a dose of drug to the patient 48, the delivery control criterion may be satisfied. In some embodiments, when it is determined that the patient 48 is requesting a drug to be delivered by a first type of drug delivery device (e.g., an infusion pump), the infusion control device 300 uses a first delivery control criterion associated with the mechanical components, and when it is determined that the patient 48 is requesting a drug to be delivered by a second type of drug delivery device (e.g., a fluid infusion pump), the infusion control device 300 uses a second delivery control criterion associated with the mechanical components.

[0059] In some embodiments, satisfaction of the delivery control criterion may include identifying the mechanical state of the drug delivery device and selecting a patient health threshold based on the mechanical state. For example, in determining whether a particular delivery control criterion is satisfied, when a drug is requested from a first type of drug delivery device, a biometric of the patient 48 may be compared to a first patient health threshold, and when the same type of drug is requested from a second type of drug delivery device, the same biometric of the patient 48 may be compared to a second patient health threshold. In some embodiments, the selection may additionally or alternatively be based on the precision and / or accuracy of the respective drug delivery device type for the delivery dose.

[0060] Satisfaction of the drug delivery criterion may be based on biometric verification of the patient identity 316 and / or other data collected about the patient 48 in addition to biometrics (e.g., historical data regarding previous drug deliveries to the patient 48, such as pain assessments made after a previous drug dose was delivered to the patient 48). For example, after the patient 48 provides a credential to the patient care device 12 (e.g., via the lockbox 302) as part of determining the patient identity 316, subsequent requests by the patient 48 for a drug delivery dose may require additional credentials and / or biometrics to verify whether the requester (e.g., the patient 48) corresponds to the patient identity 316. Satisfaction of the delivery control criterion may be based on verifying additional biometric data that the patient 48 corresponds to the patient identity 316. In another example, satisfaction of the delivery control criterion may be based on verifying that a pain assessment performed by the patient 48 after a previous dose is consistent with assessments made after one or more further doses.

[0061] After the infusion control device 300 determines whether the requested dose is authorized to be delivered to the patient 48, the infusion control device 300 communicates with the patient care device 12. According to some embodiments, such communication can be performed via the lockbox control interface 304. In some embodiments, additionally or alternatively to communicating a failed request to the patient care device 12, the infusion control device 300 can also directly communicate to the pump control interface 318 that the patient 48 is not authorized to receive the requested dose, which is an internal interface in the patient care device 12. The communication by the infusion control device 300 with the pump control interface 318 can include instructions for implementing pause control at the drug delivery device corresponding to the functional module 16.

[0062] Figures 3B - 3E An example configuration of the infusion control device 300 is shown. As described herein, the components of the infusion control device 300 (e.g., the main body 334, the sub-assemblies 332-A and 332-B, etc.) are modular and can be reoriented relative to each other to achieve different layouts. Those skilled in the art will understand that the example configuration Figures 3A - 3E described is not the only configuration and / or layout that the infusion control device 300 can use, and additional configurations and / or layouts not shown herein can also be implemented. With the modular capabilities of the infusion control device 300 arranged in different configurations as described hereinafter, the infusion control device 300 provides a technical improvement by providing flexibility and adaptability to accommodate different sets of electronic devices that may be needed to provide care for the patient 48. According to various embodiments, the infusion control device 300 can be electrically coupled to the interface unit 14 of the patient care device 12, which can include proprietary software different from the default software of the infusion control device 300. The infusion control device 300 can be configured to identify aspects of the interface unit 14 and the functional modules to which it is connected for controlling and / or interacting with the drug control algorithm 308 used by the interface unit 14.

[0063] Figure 3BShows a first example configuration of an infusion control device 300. The infusion control device 300 has a body 334, which includes a display module 310. According to some embodiments, the infusion control device 300 includes a plurality of universal connectors (e.g., universal coupling sockets 330-1, 330-2, and 330-3 (collectively referred to as coupling sockets 330) shown on the top side of the device). In some embodiments, each of the universal coupling sockets 330-1 and 330-2 on the body 334 of the infusion control device 300 is configured to couple to different types of electronic components, including one or more sub-assemblies of the infusion control device 300. For example, a first type of sub-assembly, sub-assembly 332-A for accommodating a drug request device 306, can be coupled to the universal coupling socket 330-1 or 330-2 provided on the right side of the body 334, and a second type of sub-assembly, sub-assembly 332-B, can be coupled to the universal coupling socket 330-1 or 330-2 on the left side of the body 334 of the infusion control device 300.

[0064] Each of the sub-assemblies 332-A and 332-B includes: a corresponding one or more connectors (e.g., connector 336-1), which are configured to couple to the coupling sockets 330-1 and 330-2 of the body 334 of the infusion control device 300; and / or other electronic components (e.g., lockbox 302, lockbox control interface 304, and / or interface unit 14), which are configured to be used in combination with the infusion control device 300. According to some embodiments, when the coupling socket 330-1 or 330-2 of the body 334 of the infusion control device 300 is coupled to a sub-assembly of the infusion control device 300 or another electronic device (e.g., interface unit 14 and / or patient care device 12, lockbox 302), the infusion control device 300 identifies one or more drug control algorithms 308 and / or patient care software operations associated with the electronic device.

[0065] For example, according to the coupling of the sub-assembly 332-A (including the patient-controlled drug request device 306) to the universal coupling socket 330-1 or 330-2 on one side of the body 334, the infusion control device 300 can automatically identify one or more drug control algorithms 308 to implement, which are specific to patient-controlled analgesia that can be delivered via drug requests from the patient-controlled drug request device 306. According to various embodiments, when the infusion control device 300 is connected to a specific drug request device 306 and a patient care device 12 (e.g., connected to the interface unit 14), the control device can automatically identify the drug control algorithm 308 for controlling the drug delivery from the patient care device 12 (e.g., initiating a bolus) using the specific patient-controlled drug request device 306.

[0066] Figure 3CShows a second example configuration of the infusion control device 300, which includes Figure 3B the same sub-assemblies 332-A and 332-B as shown in. The sub-assemblies 332-A and 332-B are coupled to different general coupling sockets 330-1 and 330-2 (e.g., not coupled to any sub-assemblies in the Figure 3B first example configuration shown). Thus, as described above, the infusion control device 300 identifies the coupled modules in the same manner as in the Figure 3B configuration (or another arrangement), and is capable of performing in the same manner. In the second example configuration, the general coupling socket 330-3 is disconnected from any sub-assemblies. In some embodiments, when the coupling socket 330-3 is decoupled from either of the sub-assemblies 332-A and 332-B, the coupling socket 330-3 can be coupled to one or more of the following: (i) a different sub-assembly including different electronic components configured to be used with the infusion control device 300, (ii) a connector of the patient care device 12, and / or (iii) a connector of the lockbox 302 and / or the lockbox control interface 304.

[0067] As Figure 3C shown, the display module 310 can be configured in a vertical or horizontal manner. In some embodiments, the infusion control device 300 can identify whether the user interface of the infusion control device 300 should be presented in a display mode corresponding to the vertical configuration (e.g., portrait display mode) or in a display mode corresponding to the horizontal configuration (e.g., landscape display mode) based on the configuration connected to the general coupling socket 330. Thus, the infusion control device 300 can provide an effective and intuitive means for adjusting the user interface (and the corresponding component arrangement) to enable the infusion control device 300 to be used with various infusion devices and modules.

[0068] Figure 3D Shows a third example configuration of the infusion control device 300, which includes Figure 3B and 3CThe sub-assemblies 332-A and 332-B shown in, and the infusion control device 300 is coupled to the interface unit 14 of the patient care device 12, which may include a display 6a separate from the display module 310 on the body 334 of the infusion control device 300. According to some embodiments, the patient care device 12 may be configured to perform any of the previously described software operations in conjunction with the infusion control device 300. In some embodiments, the infusion control device 300 is capable of interacting with the proprietary software of the patient care device 12 (e.g., via an electronic handshake with the patient care unit) to identify the drug control algorithm 308 or other software operations associated with the corresponding electronic components of the patient care device 12. The infusion control device 300 may identify that the patient care device 12 includes a display 6a configured to display a user interface related to patient care. Based on the identification of the display 6a of the patient care device 12, the infusion control device 300 may be configured to cause the user interface to be presented on the display 6a in the patient care device 12 (or cause the user interface in the patient care device 12 to be presented on the display module 310 on the body 334 of the infusion control device 300). In some embodiments, the infusion control device 300 is configured to receive signals from one or more sensor devices 314 or other electronic components not physically connected to the infusion control device 300 (e.g., via a Bluetooth connection).

[0069] Figure 3E A fourth example configuration of the infusion control device 300 is shown, in which the body 334 and / or the sub-assemblies 332-A and 332-B are coupled to the hardware rack 350 of the lockbox 302, which may be configured with further corresponding coupling sockets 330 (as Figure 3C shown) for electronically coupling the infusion control device 300 to the lockbox control interface 304. In some embodiments, the hardware rack 350 may house wires for coupling the coupling sockets 330 (not shown) provided by the rack to the lockbox 302 and / or the patient care unit housed within the lockbox 302. In some embodiments, the lockbox control interface 304 forms a part of or is provided on the lower surface of the hardware rack 350.

[0070] In some embodiments, in response to the infusion control device 300 being coupled to the lockbox 302 (e.g., via the hardware rack 350), the display module 310 displays one or more authentication user interfaces for providing patient and / or caregiver credentials to the lockbox control interface 304. In some embodiments, although the infusion control device 300 is coupled to the lockbox 302 and / or the lockbox control interface 304, and the infusion control device 300 includes a sub-assembly 332-A that includes the drug request device 306, the patient 48 may provide credentials to the lockbox 302 via one or more electronic components of the patient-controlled drug request device 306 (e.g., via fingerprint scanning, iris scanning, and / or facial recognition enabled by one or more imaging sensors located on the patient-controlled drug request device 306). In some embodiments, access to the door of the lockbox 302 (e.g., adding, removing, or replacing the drug in the patient care device 12) may be directly activated through the user interface of the infusion control device 300 (e.g., without the need for a physical lock and key).

[0071] Thus, in some embodiments, the universal connection socket 330 of the infusion control device 300 allows for the formation of an integrated functional arrangement of components including the patient care device 12, the lockbox 302, and the infusion control device 300, such that any pump and / or syringe provided to the patient care device 12 may be used in conjunction with one or more drug control algorithms 308 accessible by the infusion control device 300. In some embodiments, when the infusion control device 300 is coupled to the lockbox 302, the settings of the patient care device 12 may be configured using the infusion control device 300 without the need to open the door of the lockbox 302. In some embodiments, the infusion control device 300 is configured to identify one or more sensors of the lockbox 302 (e.g., a camera located on the lockbox 302).

[0072] Figure 4 Example processes for implementing a drug control algorithm 308 at an infusion control device 300 operably communicating with one or more drug delivery devices are described in accordance with various aspects of the present subject matter. For ease of explanation, reference is made herein to Figure 1-3 depicts the various blocks of the example process 400, as well as the associated components and / or processes described herein. One or more blocks of the example process 400 may be implemented, for example, by one or more computing devices, including, for example, one or more of interface unit 14, information system server 130, functional modules 16, 18, 20, and 22, infusion control device 300, and / or client computing device. In some embodiments, one or more blocks may be implemented using machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and by one or more different processors or devices. Additionally, for purposes of explanation, in some embodiments, the blocks of the example process 400 are described as occurring serially or linearly, such that multiple blocks in the example process 400 may occur in parallel (e.g., blocks 406 and 408 may occur in parallel, and any of blocks 404, 406, and 408 may occur after a patient 48 requests delivery of a dose as described in block 410). According to some embodiments, the blocks of the example process 400 need not be executed in the order shown, and one or more blocks in the example process 400 need not be executed.

[0073] In the example described, the blocks of the example process 400 are performed by infusion control device 300. Infusion control device 300 detects that the patient-controlled medication request device 306 is in operable communication with infusion control device 300 (as described in block 402). In some embodiments, the patient-controlled medication request device 306 is integrally attached to infusion control device 300. In some embodiments, the patient-controlled medication request device 306 is physically separate from infusion control device 300 but is electrically coupled to infusion control device 300 via a wired or wireless connection. In some embodiments, infusion control device 300 is configured to detect and couple to patient care device 12 and then detect the patient-controlled medication request device 306 after being detachably coupled to patient care device 12 (and / or otherwise forming an electronic communication connection with patient care system 100). For example, infusion control device 300 may be detachably coupled to a lockbox 302 (e.g., via lockbox control interface 304), which may enclose patient care device 12.

[0074] Infusion control device 300 identifies one or more sensor devices 314 and one or more drug delivery devices separate from the infusion control device 300 based on detecting a patient-controlled drug request device 306, where the one or more sensor devices 314 and the one or more drug delivery devices are in operable communication with the infusion control device 300 (as described in block 404). For example, the infusion control device 300 can detect one or more functional modules 16, 18, 20, and 22 of the patient care device 12. In some embodiments, the infusion control device 300 detects which drugs each corresponding drug delivery device is delivering or is programmed to deliver to the patient 48, and which corresponding drugs are available for the patient-controlled drug request device 306 to request. The infusion control device 300 can detect the sensor device 314 of the patient-controlled drug request device 306 (e.g., a camera sensor, a touch-sensitive surface, an embedded grip sensor for detecting health parameters) and / or other sensor devices 314 (e.g., ETCO2, SPO2, etc.) operably connected to the patient care device 12. In some embodiments, when the infusion control device 300 detects one or more drug delivery devices, the infusion control device 300 identifies one or more of the fluid administration devices 30, 32, 34, and 36 and / or the fluid supplies 38, 40, 42, and 44. In some embodiments, the infusion control device 300 selects a drug control algorithm 308 based on the corresponding fluid administration device of the fluid supply of one or more drug delivery devices. In some embodiments, the infusion control device 300 is configured to detect the operating parameters of one or more fluid infusion pumps and provide user input (e.g., a menu-driven graphical user interface) for viewing and / or changing the detected operating parameters.

[0075] Based on identifying one or more sensor devices 314, the patient physiological data received from the sensors, the operating parameters, and / or one or more drug delivery devices, the infusion control device 300 selects a drug control algorithm 308 for approving the drug requests received by the patient-controlled drug request device 306 (as described in block 406). The infusion control device 300 can select the drug control algorithm 308 from a set of predefined drug control algorithms 308 that the infusion control device 300 stores locally in the memory of the infusion control device. For example, the infusion control device 300 can store a set of specific drug control algorithms 308 for a set of specific default treatments that the infusion control device 300 can automatically implement without further instruction from the patient 48.

[0076] According to some embodiments, when the infusion control device 300 selects a drug control algorithm 308 that is not locally stored, the infusion control device 300 may download the selected drug control algorithm 308 from a server that is in operative communication with the patient care system 100 and / or the infusion control device 300 (e.g., the information system server 130). In some embodiments, the infusion control device 300 may select a drug control algorithm 308 from a library available at the device network 140 of the healthcare network 110. In some embodiments, the infusion control device 300 may identify a locally stored drug control algorithm 308 to implement and may also identify another drug control algorithm 308 that is not locally stored on the infusion control device 300 and that would be more effective for the patient 48 (e.g., based on patient physiological data) and / or more effective to implement, based on one or more sensor devices 314 detected by the infusion control device 300. When the infusion control device 300 identifies other drug control algorithms 308 that are not locally stored but are more effective than the locally stored algorithms, the infusion control device 300 may temporarily implement the locally stored drug control algorithm 308 until the other drug control algorithms 308 are downloaded, installed, or otherwise made available to the infusion control device 300.

[0077] The infusion control device selects a drug control algorithm 308 for monitoring and controlling a drug delivery device based on detecting the connected device. For example, when the corresponding drug delivery device includes a syringe (e.g., as part of an integrated infusion pump 18), the infusion control device 300 selects a first algorithm specific to the syringe, and when the corresponding drug delivery device is a large volume pump, the infusion control device 300 selects a second algorithm specific to the large volume pump. Additionally or alternatively, the drug control algorithm 308 can be selected based on detecting a specific sensor device 314 or a set of sensor devices. For example, a first drug control algorithm using a first delivery control criterion can be used based on detecting a first type of sensor device 314 (e.g., an ETCO2 sensor) in operable communication with the infusion control device 300, and a second drug control algorithm using a second delivery control criterion can be used based on detecting a second type of sensor device 314 (e.g., a heart rate monitor) in operable communication with the infusion control device 300. In some embodiments, the drug control algorithm 308 can be selected based on determining which one or more of the multiple sensor devices 314 detected by the infusion control device 300 will be more accurate. For example, the infusion control device 300 can detect the presence of two types of sensor devices 314 in operable communication with the patient care device 12, which sensor devices (e.g., an ETCO2 sensor device and a heart rate sensor device) are capable of detecting whether the patient 48 is in a stable condition. Based on determining that a specific sensor device 314 among the multiple sensor devices is more accurate for detecting the medical condition and / or status of the patient 48, the infusion control device 300 can select the corresponding drug control algorithm 308 that uses data from the specific sensor device.

[0078] According to some embodiments, the infusion control device 300 may monitor software associated with the patient control device 12 and / or module-specific components 76 of the functional modules 16, 18, 20, and 22. In some embodiments, when the infusion control device 300 determines that the software or module-specific component 76 has implemented a pause control at the corresponding functional module, the infusion control device 300 may determine to pass the patient request to the PCD software or module-specific component 76, or deactivate and / or override the pause control implemented by the PCD software or module-specific component 76. In some embodiments, as part of performing the operations of the selected drug control algorithm 308, the infusion control device 300 may provide minimum and / or maximum values of ETCO2, respiratory rate, and / or other monitored parameters. Such minimum and / or maximum values may be set in addition to or alternatively to the values set by the clinician at the interface unit 14. These minimum and / or maximum values may be used by the infusion control device 300 (e.g., as a delivery control criterion) to determine whether to pass the patient request to the PCD software or module-specific component 76, or deactivate and / or override the pause control implemented by the PCD software or module-specific component 76.

[0079] The infusion control device 300 identifies the patient 48 using the patient-controlled drug request device 306 (as described in block 408). In some embodiments, the patient-controlled drug request device 306 obtains a credential from the patient 48 and may then forward the credential to the PCD 12 for use in authenticating the patient (e.g., by determining the patient identity 316). In some embodiments, a sensor device in one or more of the sensor devices identified by the infusion control device 300 is used to obtain the credential as biometric data. For example, the infusion control device 300 may detect that the patient-controlled drug request device 306 includes a fingerprint scanner, and based on the detected fingerprint scanner, the infusion controller 300 may cause the patient-controlled drug request device 306 to instruct the patient 48 to perform a fingerprint scan and verify the identity of the patient 48 based on the obtained fingerprint. In some embodiments, after identifying the patient identity 316, the infusion control device 300 may subsequently identify and / or verify the patient 48 (e.g., as part of determining that a particular drug request made by the patient 48 is authorized) by querying a patient record system or database (e.g., on the information system server 130).

[0080] The infusion control device 300 receives patient physiological data from one or more sensor devices that are in operable communication with the infusion control device 300 (as described in block 410). For example, one or more sensor devices may include an SPO2 sensor device configured to measure the amount of oxygen in the patient's blood, which can be used to determine whether patient 48 is at risk of having a low oxygen level indicative of a particular medical condition or state (e.g., becoming unconscious or otherwise unstable due to oversedation by a drug that patient 48 is requesting to be delivered or another drug that affects the relevant patient physiological data). As part of an example method 400, the patient physiological data can be applied to a drug control algorithm 308 to determine whether a drug request made by patient 48 is authorized and / or for other operations performed by the infusion control device 300. For example, the patient physiological data may include biometric metrics that are used by the drug control algorithm 308 to determine whether one or more delivery control criteria are met to authorize a drug request made by patient 48. In some embodiments, the patient physiological data can be used by the infusion control device 300 to determine which corresponding drugs patient 48 can request via the patient-controlled drug request device 306 (e.g., based on a stored list of patient treatments associated with patient 48 and / or physiological data thresholds or values).

[0081] The infusion control device 300 receives a request to deliver a drug to a patient by a drug delivery device in one or more drug delivery devices (as described in block 412). In some embodiments, the patient requests delivery of a drug by activating a control on the patient-controlled drug request device 306 (e.g., an optional portion of the display 320 of the drug request device 306). In some embodiments, the patient can request delivery of a drug by selecting a user interface element shown within the display 320 of the patient-controlled drug request device 306. In some embodiments, additional information (e.g., information for verifying the patient's identity and / or patient physiological data related to the request) is collected when patient 48 is requesting delivery of a drug dose. In some embodiments, when patient 48 initiates a request for a drug to be delivered, one or more sensor devices in the patient-controlled drug request device 306 begin collecting identity or physiological data, and the selected drug control algorithm determines whether the request is authorized based on the received data.

[0082] In response to receiving a request for a drug to be delivered to patient 48, the selected drug control algorithm 308 of the infusion control device 300 determines whether patient 48 is authorized to execute the drug request based on patient physiological data and the history of drug administration to the identified patient (as described in block 414). According to some embodiments, determining whether patient 48 is authorized to execute the request is based on comparing sensor data to be collected by the sensor device with one or more patient health thresholds (e.g., comparing the concentration value of exhaled CO2 detected by an ETCO2 sensor device of one or more sensor devices with a threshold indicating that patient 48 has become or may become unconscious or otherwise unstable).

[0083] According to some embodiments, when determining whether patient 48 is authorized to execute the drug request, the infusion control device 300 receives data for determining whether one or more delivery control criteria are met. For example, satisfaction of the delivery control criteria can be based on comparing a biometric of patient 48 with a patient health threshold (e.g., a guardrail), where the patient health threshold is configured to identify whether patient 48 is unstable, unconscious, or impaired due to drug delivery, and / or whether drug delivery will cause patient 48 to exhibit such a health condition. In some embodiments, whether drug delivery will cause the biometric to reach or exceed the corresponding patient health threshold can be based on the pharmacokinetic properties of the requested drug (e.g., by estimating the impact on the corresponding biometric of patient 48 based on the pharmacokinetic properties). For example, the infusion control device 300 can determine that the pharmacokinetic properties of the requested drug will cause a change in the value of the measured biometric of patient 48 (e.g., an estimated impact) such that it can cause patient 48 to become unstable. Based on this determination, the drug control algorithm 308 can prevent delivery of the requested drug, or implement a patient health threshold with a minimum or maximum value that takes into account the potential change in the value of the biometric.

[0084] In some embodiments, alternative patient health thresholds can be implemented for the corresponding biometric based on the sensor device used to detect the value of the biometric (e.g., based on the sensitivity of the corresponding sensor device, or the type of biometric that one or more sensor devices are configured to detect). For example, if one or more sensor devices include a first type of ETCO2 sensor (e.g., a sidestream sensor), a first patient health threshold for the biometric (e.g., the concentration of CO2 exhaled by patient 48) can be used, and if one or more sensor devices include a second type of ETCO2 sensor (e.g., a mainstream sensor), a second patient health threshold can be used. That is, based on the increased sensitivity and / or continuity of monitoring by the second type of ETCO2 sensor, the second patient health threshold can be closer to the value indicating a critical condition than the first patient health threshold.

[0085] According to some embodiments, one or more additional delivery control criteria may be used to determine whether patient 48 is authorized to request drug delivery. In some embodiments, the infusion control device 300 may receive information regarding the pharmacokinetic properties of the drug requested by patient 48, biometric metrics detected via the patient-controlled drug request device 306 when patient 48 requests drug delivery (e.g., image data from a camera, data from an electronic fingerprint scanner embedded in the handle of the patient-controlled drug request device 306), and / or another type of patient input provided to the patient-controlled drug-request device 306. For example, after a previous dose has been provided to patient 48, a pain assessment user interface may be presented on the display module 310 associated with the patient-controlled drug-request device 306 and may prompt the patient to provide input. The input provided by patient 48 to the pain assessment user interface may be used to determine whether the requested delivery to patient 48 is authorized.

[0086] In some embodiments, the number of previous drug delivery requests by patient 48 (e.g., within a predefined time period) may be used to determine whether patient 48's current drug request meets the delivery control criteria. For example, patient 48 may be allowed to take three dose units of the drug per hour. Patient 48 may be allowed to select the number of dose units to receive, but not exceed a set maximum. In another example, a patient health threshold may be set based on whether one or more previous drug deliveries have caused patient 48 to be overly sedated and / or ineffective in reducing patient 48's pain. That is, a first patient health threshold (e.g., a predefined patient health threshold) may be used by default, and a second patient health threshold may be used in place of the first patient health threshold based on patient 48 having a negative response to a previous dose (e.g., when patient 48's biometric metrics are below the first patient health threshold). As another example, patient physiological data from a previous request by patient 48 may indicate that shortly after receiving delivery of the requested drug, patient 48 performed a pain assessment and indicated that they still felt a heightened level of pain, which may indicate that the previous dose of drug delivery was ineffective (e.g., due to the drug being diverted from patient 48 or otherwise failing to be delivered correctly). Based on patient data related to performing a pain assessment after a previous drug request, satisfaction of additional delivery control criteria may be requested to authorize the current drug request, where satisfaction of the additional delivery control criteria requires verification (e.g., based on biometric data) that patient 48 actually initiated the drug request (e.g., the patient-controlled drug request device 306 may prompt the user to provide image or fingerprint data to verify that patient 48 corresponds to patient identity 316).

[0087] According to some embodiments, one or more delivery control criteria may depend on the device (e.g., be dynamically adjustable) based on the type of drug delivery device identified for delivering a certain dose of drug to patient 48. For example, for a particular patient health parameter associated with delivering a particular drug via a first type of drug delivery device (e.g., an infusion pump), there may be a first drug control threshold, and for the same particular patient health parameter associated with delivering the particular drug via a second type of drug delivery device (e.g., an intravenous infusion pump), there may be a second drug control threshold. Additionally or alternatively, different drug control thresholds may be based on the respective control levels available for the respective pump types.

[0088] In some embodiments, one or more patient physiological data are provided to a machine learning model. The machine learning model may be trained with patient-specific data of patient 48 (e.g., historical drug delivery data) and / or patient data of a patient population. In this regard, the machine learning model may map the results to patient physiological data (e.g., based on patient demographics, drugs, and / or drug doses). The infusion control device 300 may receive a drug request authorization indication from the machine learning model based on the mapped results of the patient physiological data received by the machine learning model. In some embodiments, the machine learning model may indicate other information related to the drug request. For example, the machine learning model may indicate the amount of time before the drug request submitted by patient 48 is estimated to meet the delivery control criteria (e.g., based on the respective values of patient physiological data within a particular time period). In some embodiments, an indication from the machine learning model is provided to the infusion control device 300, which may, in response to receiving the indication, cause the drug delivery to be temporarily restricted by one or more drug delivery devices of the patient care device 12. In some embodiments, based on the amount of time indicated by the machine learning model before the drug request submitted by patient 48 is estimated to meet the delivery control criteria, the patient-controlled drug request device 306 may be caused to refrain from presenting any selectable elements to patient 48 to request drug delivery. In some embodiments, based on the amount by which a particular delivery control criteria is not met, the display 320 of the patient-controlled drug request device 306 may display a time-based indication (e.g., a countdown timer) indicating when the drug will be deliverable (e.g., based on when the particular condition causing the non - meeting of the delivery control criteria will cease to exist).

[0089] Based on determining that patient 48 is authorized to execute a drug request, the infusion control device 300 delivers a drug via one or more drug delivery devices (as described in block 416). According to some embodiments, the infusion control device 300 is configured to cause delivery of a drug via various types of drug delivery devices, and the infusion control device 300 detects the type of drug delivery device that is being used to deliver the drug requested by patient 48. In some embodiments, the infusion control device 300 provides information to the interface unit 14, and the interface unit 14 may convert the information into programming instructions that the interface unit 14 is configured to provide to the functional modules 16, 18, 20, and 22. In this regard, the infusion control device 300 may indicate to the interface unit 14 how to control the modules to which it is connected. For example, the infusion control device 300 may provide flow control instructions to the respective fluid infusion pumps of one or more drug delivery devices. In some embodiments, the infusion control device 300 is configured to provide instructions to the interface unit 14 in response to an instruction-based input to control keys 6b and / or 6c.

[0090] In some embodiments, after the drug control algorithm 308 determines that patient 48 is not authorized to receive the requested dose of a drug, the infusion control device 300 blocks patient 48 from receiving delivery of the drug for a predetermined amount of time (e.g., pause control duration). In some embodiments, the infusion control device 300 presents an indication (e.g., notifies a user interface element) to patient 48 indicating an error in authorizing the drug request and / or additional drug delivery information, or indicating that the request is not authorized. For example, the display 320 of the patient-controlled drug request device 306 may present an indication of one or more aspects of the patient's physiological data related to the denied drug request authorization, and / or the amount of time until patient 48 will be able to request delivery of the drug.

[0091] In some embodiments, delivery of a first drug may not meet one or more drug delivery criteria, but the same patient physiological data can be used to determine that delivery of a different drug is authorized. For example, when patient 48 is blocked from receiving delivery of a first drug within a predetermined amount of time (e.g., based on values of one or more delivery control criteria exceeding a particular threshold), infusion control device 300 can determine that a second drug, different from the first drug, will be authorized to be delivered to patient 48 by another drug delivery device associated with (e.g., connected to) infusion control device 300. Based on the same or similar patient physiological data that failed to meet (e.g., satisfy) the delivery control criteria for authorizing the first drug request, infusion control device 300 can determine that patient 48 is authorized to receive a dose of the second drug. That is, there can be different guardrails for delivery of the second drug compared to the first drug delivery for a particular health parameter. In some embodiments, when a request for a first drug is not authorized, patient care system 100 can prompt patient 48 (e.g., via a display on the drug delivery device) asking patient 48 if patient 48 would like to receive the second drug. Patient 48 can then confirm the selection of the second drug via a patient-controlled drug request device 306 (e.g., by activating a control on the device or via a touchscreen input on a display 320 of patient-controlled drug request device 306).

[0092] In some embodiments, after a drug control algorithm has been selected, infusion control device 300 is configured to detect a different device (e.g., an external sensor) that forms an electronic communication connection with infusion control device 300, or a different device of patient care system 100. In some embodiments, after detecting the different device that forms an electrical connection, infusion control device 300 identifies a second drug control algorithm for authorizing a drug dose request for patient 48, the second drug control algorithm being associated with the different device and different from drug control algorithm 308 (e.g., the first drug control algorithm). After identifying the second drug control algorithm, infusion control device 300 can replace the first drug control algorithm with the second drug control algorithm. That is, infusion control device 300 can be configured to dynamically optimize drug control by switching the drug control algorithm 308 being used when a change in the composition of patient care system 100 is detected.

[0093] Many of the above-described operations of example process 400, as well as related features and applications, may also be implemented as a software process that is specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium) and that can be automatically executed (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, cores of a processor, or other processing units), they cause the processing unit 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 disk drives, EPROMs, and the like. "Computer-readable media" does not include carrier waves and electronic signals transmitted wirelessly or by wire connection.

[0094] The term "software" means, in appropriate circumstances, firmware residing in read-only memory or an application stored on a magnetic storage device that can be read into memory for processing by a processor. Additionally, in some embodiments, multiple software aspects of the present subject matter disclosure may be implemented as sub-parts of a larger program while retaining the distinct software aspects of the present subject matter disclosure. In some embodiments, multiple software aspects may also be implemented as separate programs. Finally, any combination of separate programs that co-implement the software aspects described herein is within the scope of the present subject matter disclosure. In some embodiments, a software program, when installed to operate on one or more electronic systems, defines one or more specific machine implementations that run and execute the operations of the software program.

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

[0096] Figure 5 is a conceptual diagram showing an example electronic system 500 for operating an analgesic administration system in accordance with aspects of the present subject matter technology. The electronic system 500 may be software associated with one or more parts or steps of Figure 1 process 400 or byFigure 1 a computing device for performing the components and processes provided in FIGS. 1 to 3, including but not limited to an information system server 130, computing hardware within a patient care device 12, or an administration set 32. In combination with the disclosure regarding Figures 1 to 4 , the electronic system 500 may be representative. In this regard, the electronic system 500 may be a personal computer or a mobile device such as a smart phone, a tablet computer, a laptop computer, a PDA, an augmented reality device, a wearable device such as a watch or a bracelet or glasses, or a combination thereof, or any other touch screen or television with one or more processors embedded therein or coupled thereto, or any other type of computer-related electronic device having network connectivity.

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

[0098] The bus 508 collectively represents all system buses, peripheral buses, and chipset buses that communicatively connect the many internal devices of the electronic system 500. For example, the bus 508 communicatively connects the processing unit 512 to the ROM 510, the system memory 504, and the permanent storage device 502.

[0099] From these various memory units, the processing unit 512 retrieves the instructions to be executed and the data to be processed in order to perform the processes of the present subject matter disclosure. In different embodiments, the processing unit may be a single-processor or multi-core processor.

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

[0101] Other embodiments use a removable storage device (such as a floppy disk, flash drive, and their corresponding disk drives) as the permanent storage device 502. Similar to the permanent storage device 502, the system memory 504 is also a read-write memory device. However, different from 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 during operation. In some embodiments, the processes of the present subject matter are 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 be executed and the data to be processed in order to execute the processes of some embodiments.

[0102] The bus 508 is also connected to an input device interface 514 and an output device interface 506. The input device interface 514 enables a user to convey information to the electronic system and select commands. Input devices used with the input device interface 514 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 506 enables, for example, images generated by the electronic system 500 to be displayed. Output devices used with the output device interface 506 include, for example, a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include a device that combines an input device and an output device, such as a touch screen.

[0103] In addition, as Figure 5 shown, the bus 508 also couples the electronic system 500 to a network (not shown) through a network interface 516. The network interface 516 can include, for example, a wireless access point (such as Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. The network interface 516 can also include hardware (such as Ethernet hardware) for connecting a computer to a network of computers (such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or an intranet) or a portion of a network of networks (such as the Internet). Any or all components of the electronic system 500 can be used in conjunction with the present subject matter.

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

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

[0106] Although the discussion above mainly refers to a microprocessor or multi-core processor running software, some embodiments are executed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuit itself.

[0107] As used in this specification and in any claims of this application, the terms "computer", "server", "processor", and "memory" all refer to electronic or other technological devices. These terms exclude individuals or groups. For the purposes of the specification, the term "display" or "displaying" means displaying on an electronic device. As used in this specification and in any claims of this application, the terms "a plurality of computer-readable media" and "a computer-readable medium" are entirely limited to tangible, physical objects that store information in a form readable by a computer. These terms exclude any wireless signals, wired download signals, and any other transient signals.

[0108] To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other types of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. Additionally, the computer can 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 a user client device in response to a request received from the web browser.

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

[0110] The computing system can include clients and servers. The clients and servers are typically remote from each other and can interact through a communication network. The relationship of client and server arises from running on corresponding computers and having a client-server relationship to each other. In some implementations, the server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., the results of user interaction) can be received at the server from the client device.

[0111] Those skilled in the art will recognize that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability of hardware and software, the various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in different ways for each particular application. The various components and blocks may be arranged differently (e.g., arranged in a different order or partitioned in a different manner), all without departing from the scope of the claimed subject matter.

[0112] Description of the claimed subject matter in clause form:

[0113] Various examples of aspects of the present disclosure are described for convenience as numbered clauses (1, 2, 3, etc.). These clauses are provided as examples and do not limit the claimed subject matter. The identification of figures and reference numerals is provided below only as an example and for illustrative purposes, and the clauses are not limited by those identifications.

[0114] Clause 1. An infusion control device, comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: detecting a patient-controlled drug request device in operable communication with the infusion control device; identifying, in operable communication with the infusion control device, (i) one or more sensor devices and (ii) one or more drug delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more drug delivery devices are in operable communication with the infusion control device; selecting, based on the identification of the one or more sensor devices and the one or more drug delivery devices, a drug control algorithm for approving a drug request received by the patient-controlled drug request device and for controlling the delivery of one or more drugs to be delivered by the one or more drug delivery devices; using the patient-controlled drug request device to identify a patient; receiving patient physiological data from the one or more sensor devices identified as being in operable communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device of the one or more drug delivery devices; determining, based on a function of the drug control algorithm, the patient physiological data, and a history of drug administration to the patient, whether the patient is authorized to execute the drug request; and causing the delivery of the drug via the one or more drug delivery devices based on determining that the patient is authorized to execute the drug request using the drug control algorithm.

[0115] Clause 2. The infusion control device according to Clause 1, wherein determining whether the patient is authorized to execute the request is based on meeting one or more delivery control criteria related to one or more of the following: determination that a biometric metric of the patient exceeds a patient health threshold for administering the drug; pharmacokinetic properties of the drug being requested; biometric metrics detected via the patient-controlled drug request device; and pain assessment performed after a prior delivery of the drug in response to a prior request for the drug.

[0116] Clause 3. The infusion control device according to Clause 1 or Clause 2, wherein the operation further includes: providing the patient physiological data to a machine learning model; and receiving a drug request authorization indication from the machine learning model, wherein the drug request authorization indication is used to determine whether the patient is authorized to receive the requested dose of the drug.

[0117] Clause 4. The infusion control device according to any one of Clauses 1 to 3, wherein the operation further includes, before identifying the one or more drug delivery devices: forming an electronic communication connection with a lockbox control interface configured to enclose and prevent access to at least a portion of the one or more drug delivery devices; receiving a wireless credential at an input interface of the infusion control device; transmitting the wireless credential by the infusion control device to the one or more drug delivery devices via the electronic communication connection with the lockbox control interface; after the transmission, receiving an indication from the one or more drug delivery devices via the electronic communication connection as to whether the patient is authorized to request a dose of the drug to be delivered; and using the drug control algorithm to determine whether a drug request submitted by the patient is an authorized drug request based on receiving the indication that the patient is authorized to request a dose of the drug to be delivered.

[0118] Clause 5. The infusion control device according to any one of Clauses 1 to 4, wherein: Detecting the one or more drug delivery devices includes: When the corresponding drug delivery device is a first type of drug delivery device including a syringe (the syringe is configured to be manually pressed to inject a first drug into the patient), selecting a first algorithm for delivering the drug via the first type of drug delivery device as the drug control algorithm, the first algorithm including instructions for causing the syringe to inject the first drug into the patient; and When the corresponding drug delivery device is a second type of drug delivery device including an intravenous infusion pump (the intravenous infusion pump is integrally coupled with an electronic actuation system for causing a dose of a second drug to be delivered to the patient), selecting a second algorithm for delivering the drug via the second type of drug delivery device as the drug control algorithm, the second algorithm including instructions for causing delivery via the intravenous infusion pump.

[0119] Clause 6. The infusion control device according to any one of Clauses 1 to 5, wherein the operation further includes: Determining one or more therapies for which the patient-controlled drug request device can receive drug requests from the patient; Based on the determination of one or more therapies enabled by the patient-controlled drug request device, selecting one or more drug control algorithms for each corresponding therapy of the one or more therapies; and Providing each corresponding drug control algorithm of the one or more drug control algorithms for use in combination with the patient-controlled drug request device.

[0120] Clause 7. The infusion control device according to any one of Clauses 1 to 6, wherein the operation further includes, after the drug control algorithm is selected: Detecting an electronic connection of different devices to the infusion control device; Identifying a second drug control algorithm associated with the different device and distinct from the drug control algorithm for authorizing a request for a dose of the drug for the patient; and Using the second drug control algorithm in place of the selected drug control algorithm.

[0121] Clause 8. The infusion control device according to any one of Clauses 1 to 7, wherein the drug control algorithm is configured to prevent drug delivery of a specific drug when the patient physiological data does not meet one or more predefined delivery control criteria required to authorize the dose of the drug to be delivered.

[0122] Clause 9. The infusion control device according to Clause 8, wherein the operation further includes, after preventing drug delivery of the specific drug based on a determination that the patient is not authorized to execute the request: Preventing the patient from receiving delivery of the specific drug for a predetermined amount of time.

[0123] Clause 10. The infusion control device according to Clause 9 further includes: when the patient is blocked from receiving the delivery of the specific drug within a predetermined amount of time: receiving a second request for another drug different from the specific drug to be delivered to the patient by another drug delivery device among the one or more drug delivery devices; and determining, based on the patient physiological data that has not met one or more delivery control criteria for authorizing the request, that the patient is authorized to execute the second request for the other drug; and causing the delivery of the other drug via the one or more drug delivery devices based on determining that the patient is authorized to execute the second request.

[0124] Clause 11. The infusion control device according to Clause 9 further includes: after determining that the patient is not authorized to execute the first request, determining that the patient physiological data that has not met the delivery control criteria will meet other delivery control criteria for authorizing a request for the delivery of another drug; and prompting the patient that the other drug can be used for delivery based on determining that the request for the delivery of the other drug will be authorized based on the patient physiological data.

[0125] Clause 12. The infusion control device according to any one of Clauses 1 to 11, wherein the identification of the one or more sensor devices and the one or more drug delivery devices is performed based on detecting that the patient-controlled drug request device is in operable communication with the infusion control device.

[0126] Clause 13. The infusion control device according to any one of Clauses 1 to 12 further includes: a body, the body including: a display, and one or more universal coupling sockets configured to receive corresponding sub-assemblies of the infusion control device; one or more sub-assemblies, wherein: each of the plurality of sub-assemblies is configured to form an operable connection with each of the universal coupling sockets; each of the one or more sub-assemblies includes corresponding constituent electronic components of the infusion control device; each of the one or more sub-assemblies includes a universal connector configured to be operably coupled with one or more universal connection coupling sockets of the body, wherein according to the corresponding universal connector of the corresponding sub-assembly of the one or more sub-assemblies becoming coupled with the corresponding connection point of the body, the constituent electronic components of the infusion control device become operably coupled with other constituent electronic components of the body.

[0127] Clause 14. The infusion control device according to Clause 13, wherein: the one or more sub-components include a first sub-component of a first type, wherein the first sub-component includes the drug request device, and the one or more sub-components include a second sub-component of a second type, wherein the second sub-component includes a sensor device among the one or more sensor devices.

[0128] Clause 15. The infusion control device according to Clause 13 or Clause 14, wherein each of the one or more universal coupling sockets is configured to be coupled to one of the following: a patient care unit, the patient care unit including proprietary software different from the default software of the infusion control device; a lockbox and / or a lockbox control interface associated with the lockbox, and / or a hardware rack associated with the lockbox; and a sensor device among the one or more sensor devices, the sensor device being different from another sensor device associated with the one or more sub-components.

[0129] Clause 16. A method, comprising: at an infusion control device including one or more processors and a memory storing instructions: detecting a patient-controlled drug request device in operable communication with the infusion control device; based on detecting the patient-controlled drug request device, identifying (i) one or more sensor devices and (ii) one or more drug delivery devices separated from the infusion control device, wherein the one or more sensor devices and the one or more drug delivery devices are in operable communication with the infusion control device; based on identifying the one or more sensor devices and the one or more drug delivery devices, selecting a drug control algorithm for approving a drug request received by the patient-controlled drug request device; using the patient-controlled drug request device to identify the patient; receiving patient physiological data from the one or more sensor devices in operable communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device among the one or more drug delivery devices; determining whether the patient is authorized to execute the drug request based on a function of the drug control algorithm, the patient physiological data, and a history of drug administration to the patient; and based on determining that the patient is authorized to execute the drug request using the drug control algorithm, causing the drug to be delivered via the one or more drug delivery devices.

[0130] Clause 17. The method according to Clause 16, wherein determining whether the patient is authorized to execute the request is based on meeting one or more delivery control criteria related to one or more of the following: determination that a biometric metric of the patient exceeds a patient health threshold for administering the drug; pharmacokinetic properties of the drug being requested; biometric metrics detected via the patient-controlled drug request device; and pain assessment performed after a prior delivery of the drug in response to a prior request for the drug.

[0131] Clause 18. The method according to claim 16 or Clause 17, further comprising: providing the patient physiological data to a machine learning model; and receiving a drug request authorization indication from the machine learning model, wherein the drug request authorization indication is used to determine whether the patient is authorized to receive the requested dose of the drug.

[0132] Clause 19. The method according to any one of claims 16 to 18, further comprising: before identifying the one or more drug delivery devices: forming an electronic communication connection with a lockbox control interface configured to enclose and prevent access to at least a portion of the one or more drug delivery devices; receiving a wireless credential at an input interface of the infusion control device; transmitting, by the infusion control device via the electronic communication connection with the lockbox control interface, the wireless credential to the one or more drug delivery devices; after the transmission, receiving, via the electronic communication connection, an indication of whether the patient is authorized to request a dose of the drug to be delivered from the one or more drug delivery devices; and using the drug control algorithm to determine whether a drug request submitted by the patient is an authorized drug request based on receiving the indication that the patient is authorized to request a dose of the drug to be delivered.

[0133] Clause 20. The method according to any one of claims 16 to 19, wherein: detecting the one or more drug delivery devices includes: when the corresponding drug delivery device is a first type of drug delivery device including a syringe (the syringe being configured to be manually depressed to inject a first drug into the patient), selecting a first algorithm for delivering the drug via the first type of drug delivery device as the drug control algorithm, the first algorithm including instructions for causing the syringe to inject the first drug into the patient; and when the corresponding drug delivery device is a second type of drug delivery device including an intravenous infusion pump (the intravenous infusion pump being integrally coupled with an electronic actuation system for causing a dose of a second drug to be delivered to the patient), selecting a second algorithm for delivering the drug via the second type of drug delivery device as the drug control algorithm, the second algorithm including instructions for causing delivery via the intravenous infusion pump.

[0134] Clause 21. The method according to any one of clauses 16 to 20, further comprising: determining one or more therapies for which the patient-controlled drug request device is capable of receiving drug requests from the patient; based on the determination of the one or more therapies enabled by the patient-controlled drug request device, selecting one or more drug control algorithms for each respective therapy of the one or more therapies; and providing each respective drug control algorithm of the one or more drug control algorithms for use in combination with the patient-controlled drug request device.

[0135] Clause 22. The method according to any one of clauses 16 to 21, further comprising: after the drug control algorithm is selected: detecting an electronic connection of different devices to the infusion control device; identifying a second drug control algorithm associated with the different devices and distinct from the drug control algorithm for authorizing a request for a dose of the drug for the patient; and using the second drug control algorithm in place of the selected drug control algorithm.

[0136] Clause 23. The method according to any one of clauses 16 to 22, wherein the drug control algorithm is configured to prevent the delivery of a specific drug when the patient physiological data does not meet one or more delivery control criteria required to authorize the dose of the drug to be delivered.

[0137] Clause 24. The method according to clause 23, further comprising: wherein, after preventing the drug delivery of the specific drug based on a determination that the patient is not authorized to execute the request: preventing the patient from receiving the delivery of the specific drug for a predetermined amount of time.

[0138] Clause 25. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of an infusion control device in operative communication with one or more drug delivery devices, cause the performance of the following operations, the operations including: detecting a patient-controlled drug request device in operative communication with the infusion control device; based on detecting the patient-controlled drug request device, identifying (i) one or more sensor devices and (ii) one or more drug delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more drug delivery devices are in operative communication with the infusion control device; based on identifying the one or more sensor devices and the one or more drug delivery devices, selecting a drug control algorithm for approving a drug request received by the patient-controlled drug request device; using the patient-controlled drug request device to identify a patient; receiving patient physiological data from the one or more sensor devices in operative communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device of the one or more drug delivery devices; determining whether the patient is authorized to execute the drug request based on a function of the drug control algorithm, the patient physiological data, and a history of drug administration to the patient; and based on determining that the patient is authorized to execute the drug request using the drug control algorithm, causing the drug to be delivered via the one or more drug delivery devices.

[0139] It should be understood that the specific order or hierarchy of steps in the disclosed processes is an illustration of example methods. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process can be rearranged. Some of the steps may be executed synchronously. The accompanying method claims present the elements of the various steps in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0140] The foregoing description is provided to enable a person of ordinary skill in the art to practice the various aspects described herein. The foregoing description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be apparent to a person of ordinary skill in the art, and the general principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language of the claims, where a reference to a singular element is not intended to mean "one and only one" but "one or more" unless specifically stated otherwise. The term "some," unless specifically stated otherwise, means one or more. Masculine pronouns (e.g., "his") include feminine and neuter (e.g., "her" and "its"), and vice versa. Headings and subheadings (if any) are used for convenience only and do not limit the invention described herein.

[0141] As used herein, the term "website" can include any aspect of a website, including one or more web pages, one or more servers for hosting or storing web-related content, etc. Thus, the term "website" can be used interchangeably with the terms "web page" and "server." The predicate verbs "configured to," "operable to," and "programmed to" do not imply any specific tangible or intangible modification of the subject, but are intended to be used interchangeably. For example, a processor configured to monitor and control operations or components can also mean a processor programmed to monitor and control operations or a processor operable to monitor and control operations. Similarly, a processor configured to run code can be interpreted as a processor programmed to execute the code or a processor operable to execute the code.

[0142] As used herein, the term "automatic" can include performance by a computer or machine without user intervention; e.g., by instructions in response to a predicate verb action by a computer or machine or other initiating mechanism. The word "example" as used herein means "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as superior to or better than other aspects or designs.

[0143] Phrases such as "aspect" do not imply that such an aspect is essential to the subject technology or that such an aspect applies to all configurations of the subject technology. The disclosure related to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. Phrases such as "aspect" may refer to one or more aspects, and vice versa. Phrases such as "embodiment" do not imply that such an embodiment is essential to the subject technology or that such an embodiment applies to all configurations of the subject technology. The disclosure related to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. Phrases such as "embodiment" may refer to one or more embodiments, and vice versa. Phrases such as "configuration" do not imply that such a configuration is essential to the subject technology or that such a configuration applies to all configurations of the subject technology. The disclosure related to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. Phrases such as "configuration" may refer to one or more configurations, and vice versa.

[0144] As used herein, the term "determine" or "determining" encompasses a variety of actions. For example, "determine" may include performing calculations, operations, processing, derivation, generation, acquisition, lookup (e.g., looking up in a table, database, or another data structure), ascertainment, etc. via a hardware element without user intervention. Additionally, "determine" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. via a hardware element without user intervention. "Determine" may include parsing, selecting, picking, establishing, etc. via a hardware element without user intervention.

[0145] As used herein, the term "provide" or "providing" encompasses a variety of actions. For example, "providing" may include storing a value at a location in a storage device for subsequent retrieval, directly transmitting the value to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to the value, and similar actions. "Providing" may also include encoding, decoding, encrypting, decrypting, verifying, validating, etc. via a hardware element.

[0146] As used herein, the term "message" encompasses a variety of formats for conveying (e.g., transmitting or receiving) information. A message can include a machine-readable aggregation of information, such as an XML document, a fixed-field message, a comma-separated message, or a similar format. In some embodiments, a message can include a signal for transmitting one or more representations of information. Although recited in the singular, it will be understood that a message can be composed of multiple parts, transmitted, stored, received, etc.

[0147] As used herein, a "user interface" (also referred to as an interactive user interface, a graphical user interface, or a UI) can refer to a web-based interface that includes data fields and / or other control elements for receiving input signals or providing electronic information and / or for providing information to a user in response to any received input signal. Control elements can include dials, buttons, icons, selectable regions, or other perceivable markers presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiate an exchange of data of the device presenting the UI. The UI can be implemented, in whole or in part, using technologies such as hyper-text mark-up language (HTML), FLASH TM , JAVA TM ,.NET TM , web services, or Rich Site Summary (RSS). In some embodiments, the UI can be included in a stand-alone 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 described aspects. The communication can be to or from a medical device, a diagnostic device, a monitoring device, or a server with which they communicate.

[0148] As used herein, the terms "correspond" or "corresponding" encompass a structural, functional, quantitative, and / or qualitative correlation or relationship between two or more objects, data sets, information, and / or the like, preferably where the corresponding or associative relationship can be used to transform one or more of the two or more objects, data sets, information, and / or the like to appear to be the same or equal. The corresponding relationship can be evaluated using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning evaluation model, or a combination thereof.

Claims

1. An infusion control device, comprising: one or more processors; as well as A memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: detecting a patient controlled medication request device in operable communication with the infusion control device; identifying, in operable communication with the infusion control device, (i) one or more sensor devices and (ii) one or more drug delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more drug delivery devices are in operable communication with the infusion control device; selecting, based on identifying the one or more sensor devices and the one or more medication delivery devices, a medication control algorithm for approving a medication request received by the patient-controlled medication request device and for controlling delivery of one or more medications to be delivered by the one or more medication delivery devices; identifying a patient using the patient-controlled medication request device; receiving patient physiological data from one or more sensor devices identified to be in operable communication with the infusion control device; receiving a request for a drug to be delivered to a patient by a drug delivery device of the one or more drug delivery devices; determining whether the patient is authorized to perform a medication request based on a function of the medication control algorithm, the patient physiological data, and a history of medication administration to the patient; as well as Based on determining using the medication control algorithm that the patient is authorized to perform the medication request, delivery of the medication via the one or more medication delivery devices is caused.

2. The infusion control device of claim 1, wherein: The determining whether the patient is authorized to perform the request is based on satisfying one or more delivery control criteria related to one or more of: a determination that a biological indicator of the patient exceeds a patient health threshold for administration of the drug; the pharmacokinetic properties of the drug; a biometric indicator detected via the patient-controlled medication request device; as well as The pain assessment is performed after a prior delivery of the medication in response to a prior request for the medication.

3. The infusion control device of claim 1, wherein: The operations also include: providing the patient physiological data to a machine learning model; and A medication request authorization indication is received from the machine learning model, wherein the medication request authorization indication is used to determine whether the patient is authorized to receive a requested dose of a medication.

4. The infusion control device of claim 1, wherein: The operations further include, prior to identifying the one or more drug delivery devices: forming an electronic communication connection with a lockbox control interface configured to seal and prevent access to at least a portion of the one or more drug delivery devices; receiving wireless credentials at an input interface of the infusion control device; transmitting, by the infusion control device, the wireless credentials to the one or more drug delivery devices via the electronic communication connection with the lockbox control interface; subsequent to the transmitting, receiving, via the electronic communication connection, from the one or more medication delivery devices an indication of whether the patient is authorized to request a dose of medication to be delivered; as well as Based on receiving an indication that the patient is authorized to request a dose of medication to be delivered, the medication control algorithm is used to determine whether the medication request submitted by the patient is an authorized medication request.

5. The infusion control device of claim 1 , wherein: Detecting the one or more drug delivery devices comprises: when the corresponding drug delivery device is a first type of drug delivery device including a syringe, selecting a first algorithm for delivering the drug via the first type of drug delivery device as the drug control algorithm, wherein the syringe is configured to be manually depressed to inject a first drug into the patient, the first algorithm including instructions for causing the syringe to inject the first drug into the patient; and When the corresponding drug delivery device is a second type of drug delivery device including an intravenous infusion pump, a second algorithm for delivering the drug via the second type of drug delivery device is selected as the drug control algorithm, wherein the intravenous infusion pump is integrally coupled with an electronic actuation system for causing a dose of the second drug to be delivered to the patient, and the second algorithm includes instructions for causing delivery via the intravenous infusion pump.

6. The infusion control device of claim 1, wherein: The operations also include: determining one or more therapies for which the patient-controlled medication request device is capable of receiving a medication request from the patient; selecting one or more medication control algorithms for each respective one of the one or more therapies based on determining the one or more therapies initiated by the patient-controlled medication request device; and Each respective one of the one or more medication control algorithms is provided for use in conjunction with the patient-controlled medication request device.

7. The infusion control device of claim 1, wherein: The operations further include, after the medication control algorithm is selected: detecting electronic connection of different devices to the infusion control device; identifying a second medication control algorithm associated with the different device and distinct from the medication control algorithm for authorizing a request for a dose of the medication for the patient; and The second medication control algorithm is used in place of the selected medication control algorithm.

8. The infusion control device of claim 1, wherein: The medication control algorithm is configured to prevent delivery of a particular medication when the patient physiological data does not meet one or more delivery control criteria that need to be met to authorize a dose of the medication to be delivered.

9. The infusion control device of claim 8, wherein: The operations further include, after preventing medication delivery of the particular medication based on a determination that the patient is not authorized to perform the request: The patient is prevented from receiving delivery of the particular medication for a predetermined amount of time.

10. The infusion control device of claim 9, wherein: The operations also include: When the patient is prevented from receiving delivery of the particular medication for a predetermined amount of time: receiving a second request for another drug, different from the particular drug, to be delivered to the patient by another drug delivery device of the one or more drug delivery devices; and determining that the patient is authorized to perform a second request for the other medication based on the patient's physiological data not meeting one or more delivery control criteria for authorizing the request; and Based on determining that the patient is authorized to perform the second request, delivery of the other medication via the one or more medication delivery devices is caused.

11. The infusion control device of claim 9, further comprising: After determining that the patient is not authorized to perform the request, determining that the patient physiological data that did not meet the delivery control criteria will meet other delivery control criteria for authorizing the request for delivery of another medication; and Based on determining that another request for delivery of the other medication will be authorized based on the patient physiological data, the patient is prompted that the other medication is available for delivery.

12. The infusion control device of claim 1, wherein: Identifying the one or more sensor devices and the one or more drug delivery devices is performed based on detecting that the patient-controlled medication request device is in operable communication with the infusion control device.

13. The infusion control device of claim 1 , further comprising: A subject, the subject comprising: Display, and one or more universal coupling receptacles configured to receive corresponding subassemblies of the infusion control device; One or more subcomponents, where: each of the plurality of subassemblies is configured to form an operable connection with each of the universal coupling receptacles of the body; Each of the one or more subassemblies includes respective component electronics of the infusion control device; and Each of the one or more subcomponents includes a universal connector, which is configured to be operably coupled to one or more universal coupling sockets of the main body, wherein the constituent electronic components of the infusion control device become operably coupled to other constituent electronic components of the main body according to the corresponding universal connector of the corresponding subcomponent of the one or more subcomponents becoming coupled to the corresponding connection point of the main body.

14. The infusion control device of claim 13, wherein: Each of the one or more universal coupling sockets is configured to be coupled with one of: a patient care unit comprising proprietary software that is distinct from default software of the infusion control device; a lock box and / or a lock box control interface associated with the lock box, and / or a hardware rack associated with the lock box; as well as A sensor device of the one or more sensor devices, the sensor device being distinguishable from another sensor device associated with the one or more subassemblies.

15. A method comprising: At an infusion control device comprising one or more processors and a memory storing instructions: detecting a patient controlled medication request device in operable communication with the infusion control device; identifying, based on detecting the patient-controlled medication request device, (i) one or more sensor devices and (ii) one or more medication delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more medication delivery devices are in operable communication with the infusion control device; selecting a medication control algorithm for approving a medication request received by the patient-controlled medication request device based on identifying the one or more sensor devices and the one or more medication delivery devices; identifying a patient using the patient-controlled medication request device; receiving patient physiological data from the one or more sensor devices in operable communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device of the one or more drug delivery devices; determining whether the patient is authorized to perform a medication request based on a function of the medication control algorithm, the patient physiological data, and a history of medication administration to the patient; as well as Based on determining using the medication control algorithm that the patient is authorized to perform the medication request, delivery of the medication via the one or more medication delivery devices is caused.

16. The method according to claim 15, wherein: The determining whether the patient is authorized to perform the request is based on satisfying one or more delivery control criteria related to one or more of the following: a determination that a biological indicator of the patient exceeds a patient health threshold for administration of the drug; the pharmacokinetic properties of the drug being requested; a biometric indicator detected via the patient-controlled medication request device; as well as A pain assessment is performed after a prior delivery of the medication in response to a prior request for the medication.

17. The method according to claim 15, further comprising: providing the patient physiological data to a machine learning model; as well as A medication request authorization indication is received from the machine learning model, wherein the medication request authorization indication is used to determine whether the patient is authorized to receive a requested dose of a medication.

18. The method according to claim 15, further comprising: Prior to identifying the one or more drug delivery devices: forming an electronic communication connection with a lockbox control interface configured to seal and prevent access to at least a portion of the one or more drug delivery devices; receiving wireless credentials at an input interface of the infusion control device; transmitting, by the infusion control device, the wireless credentials to the one or more drug delivery devices via the electronic communication connection with the lockbox control interface; subsequent to the transmitting, receiving, via the electronic communication connection, from the one or more medication delivery devices an indication of whether the patient is authorized to request a dose of medication to be delivered; as well as Based on receiving an indication that the patient is authorized to request a dose of medication to be delivered, the medication control algorithm is used to determine whether the medication request submitted by the patient is an authorized medication request.

19. The method of claim 15, wherein: Detecting the one or more drug delivery devices comprises: when the corresponding drug delivery device is a first type of drug delivery device including a syringe, selecting a first algorithm for delivering the drug via the first type of drug delivery device as the drug control algorithm, wherein the syringe is configured to be manually depressed to inject a first drug into the patient, the first algorithm including instructions for causing the syringe to inject the first drug into the patient; and When the corresponding drug delivery device is a second type of drug delivery device including an intravenous infusion pump, a second algorithm for delivering the drug via the second type of drug delivery device is selected as the drug control algorithm, wherein the intravenous infusion pump is integrally coupled with an electronic actuation system for causing a dose of the second drug to be delivered to the patient, and the second algorithm includes instructions for causing delivery via the intravenous infusion pump.

20. A non-transitory computer readable storage medium comprising instructions that, when executed by one or more processors of an infusion control device in operable communication with one or more drug delivery devices, cause performance of the following operations, the operations comprising: detecting a patient controlled medication request device in operable communication with the infusion control device; identifying, based on detecting the patient-controlled medication request device, (i) one or more sensor devices and (ii) one or more medication delivery devices separate from the infusion control device, wherein the one or more sensor devices and the one or more medication delivery devices are in operable communication with the infusion control device; selecting a medication control algorithm for approving a medication request received by the patient-controlled medication request device based on identifying the one or more sensor devices and the one or more medication delivery devices; identifying a patient using the patient-controlled medication request device; receiving patient physiological data from the one or more sensor devices in operable communication with the infusion control device; receiving a request for a drug to be delivered to the patient by a drug delivery device of the one or more drug delivery devices; determining whether the patient is authorized to perform a medication request based on a function of the medication control algorithm, the patient physiological data, and a history of medication administration to the patient; as well as Based on determining using the medication control algorithm that the patient is authorized to perform the medication request, delivery of the medication via the one or more medication delivery devices is caused.

Images