Safe patient-controlled analgesia

Abstract

A system and method for operating a pain medication administration system is disclosed. A control device is associated with a drug delivery device and configured to receive a first user input including at least a portion of a patient's fingerprint along with a second user input corresponding to a request to administer medication. The control device compares the portion of the fingerprint with previously stored fingerprints to determine the patient's identity, and, in response to receiving the second user input and determining that the patient is an authorized user, uses one or more sensors to obtain one or more signals indicative of the patient's condition. If the patient's condition meets a set of medication delivery criteria, the control device causes the drug delivery device to administer a predetermined amount of medication to the patient.

Description

[Technical Field]

[0001] This application is a non-provisional adaptation of U.S. Provisional Application No. 63 / 027,261, entitled "SECURE PATIENT-CONTROLLED ANALGESIA," filed May 19, 2020, which is incorporated herein by reference in its entirety.

[0002] TECHNICAL FIELD This application relates generally to operating medical devices. [Background technology]

[0003] Patient-Controlled Analgesia (PCA) is a commonly used method for alleviating pain experienced by patients. The method typically involves using a syringe pump that is programmed to allow delivery of pain medication only when desired by the patient. For example, a patient can press a button on the PCA control device when they want to administer a predetermined bolus of pain medication. Thus, if the patient does not press the button, no pain medication is administered.

[0004] However, in some circumstances, it is possible that someone other than the patient may erroneously operate the PCA control device without the patient's knowledge (e.g., the risk of "PCA by proxy"). Therefore, methods and devices for ensuring that the patient has exclusive control of the PCA control device are highly desirable. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] U.S. Patent No. 5,713,856 [Patent Document 2] U.S. Patent No. 5,681,285 Summary of the Invention

[0006] According to various aspects, the technology includes a system comprising a drug delivery device, a drug control device operably connected to the drug delivery device, and a control unit operably connected to the drug delivery device and configured to capture biometric information from a person, wherein the control unit is configured to determine a medication currently being loaded by the drug delivery device, receive via the drug control device a request for the drug delivery device to administer a certain dose of medication and the biometric information captured by the drug control device, verify based on the biometric information that a patient associated with the biometric information is authorized to self-administer the certain dose of medication from the drug delivery device, and in response to receiving the request and the biometric information and verifying that the patient is a user authorized to self-administer the certain dose, obtain one or more signals indicative of the patient's condition by one or more sensors associated with the drug delivery device, and after determining that the patient's condition meets predetermined criteria for allowing the patient to self-administer the medication, cause the drug delivery device to administer the certain dose of medication to the patient.

[0007] In some implementations, the drug control device is a handheld control device, and the request and the biological information are captured within a predetermined period of each other. One or more sensors may be included within the drug control device and activated after the request and the biological information are received by the drug control device.

[0008] In some implementations, the medication control device includes a fingerprint reader, and the biometric information includes at least a portion of the fingerprint. In some implementations, the one or more signals indicative of the patient's condition include an electroencephalogram (EEG) signal, an electrocardiography (ECG) signal, a peripheral capillary oxygen saturation (SpO2) signal, a respiratory rate signal, or a movement signal. In some implementations, determining that the patient's condition meets the predetermined criteria includes determining that the patient is in a conscious state based at least in part on the one or more signals.

[0009] In some implementations, verifying that the patient is authorized to self-administer the fixed dose includes determining the patient's identity, identifying from a hospital information system an amount of medication received by the patient over a period of time based at least in part on the patient's identity or an identifier associated with the drug delivery device, and determining that the amount of medication meets a threshold amount for the period of time.

[0010] In some implementations, the control unit is further configured to acquire one or more signals indicative of the patient's condition and then determine, based on the one or more signals, that a discomfort level associated with the patient is greater than a threshold discomfort level. In some implementations, the one or more sensors include a motion sensor for detecting the patient's movement and one or more physiological monitors for measuring a physiological condition, including a heart rate, blood pressure, an electrocardiogram signal, an electroencephalogram signal, or an oxygen level. The control unit is configured to detect the patient's movement, measure the patient's physiological condition, and determine the discomfort level based on the patient's detected movement satisfying a movement threshold and the physiological condition satisfying a physiological threshold. In some implementations, the drug delivery device includes a controller configured to receive a user input for initiating a request and determine a magnitude of the user input. Administering a dose of the drug to the patient via drug delivery includes administering an amount of the drug according to the magnitude of the user input. Other aspects include corresponding methods, apparatus, and computer program products for further implementations of the system.

[0011] An advantage of using this technology to administer medication to a patient is that the medication can be administered after the patient (or another authorized person) has successfully authenticated using fingerprint biometrics or other trusted identification. Thus, this technology protects patient safety by eliminating the risk of PCA by proxy, since authentication using, for example, fingerprint biometrics cannot be easily replicated.

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

[0013] For a better understanding of the various implementations described, reference should be made to the following description of implementations in conjunction with the following drawings, in which like reference numerals refer to corresponding parts throughout the figures and description, and in which: [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates an example of an institutional patient care system for a healthcare organization, in accordance with aspects of the present technology. [Figure 2A] FIG. 1 illustrates an exemplary patient care device that may be interacted with by a clinician or patient within a healthcare organization, in accordance with aspects of the present technology. [Figure 2B] FIG. 1 is an elevational view showing the use of a PCA pump, an EtCO2 monitoring module, an SpO2 monitoring module, a controller operatively connected to a central server, and showing actual patient interaction with the system. [Figure 3] FIG. 1 illustrates an exemplary patient-controlled analgesia device, in accordance with aspects of the present technology. [Figure 4] FIG. 10 illustrates an exemplary process for operating a patient care device, in accordance with aspects of the present technology. [Figure 5] FIG. 1 is a conceptual diagram illustrating an exemplary electronic system for operating a pain medication delivery system, in accordance with aspects of the present technology. DETAILED DESCRIPTION OF THE INVENTION

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

[0016] The present technology includes systems and methods for administering medication to a patient, including a control device associated with a medication delivery device and configured to receive at least a portion of a patient's fingerprint along with a request to administer the medication. A patient care unit (PCU) or a server on behalf of the PCU compares at least a portion of the fingerprint to previously stored fingerprints to determine the patient's identity, and in response to receiving the request and determining that the patient is an authorized user, obtains (e.g., using one or more sensors) one or more signals indicative of the patient's condition. In response to determining that the patient's condition meets a first set of medication delivery criteria, the PCU or central server causes the medication delivery device to administer a predetermined amount of medication to the patient.

[0017] FIG. 1 illustrates an example of an institutional patient care system 100 for a healthcare organization in accordance with aspects of the present technology. In FIG. 1, patient care devices (or generally, “medical devices”) 12 are connected to a healthcare network 110. The term patient care device (or “PCD”) may be used interchangeably with the term patient care unit (or “PCU”), either of which may include various ancillary medical devices, such as an infusion pump, a vital signs monitor, a medication dispensing device (e.g., a cabinet, a tote), a medication preparation device, an automated dispensing device, a module coupled to one of the foregoing (e.g., a syringe pump module configured to attach to an infusion pump), a patient-controlled analgesia (PCA) wand, or other similar devices. Each element of the patient care device 12 is connected to the healthcare network 110 by a transmission channel 131. The transmission channel 131 may be any wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some implementations, healthcare network 110 also includes computer systems located in various departments throughout the hospital. For example, healthcare network 110 optionally includes computer systems associated with an admissions department, an accounting 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, network 10 may include separate subnetworks. In the illustrated example, healthcare network 10 includes device network 140 through which patient care devices 12 (and other devices) communicate in accordance with normal operation. According to some implementations, the devices and support services of healthcare network 110, or portions thereof, may be cloud-based, with servers and services (e.g., databases, APIs, etc.) located remotely from the hospital and / or distributed across multiple remote locations or regions.

[0018] Additionally, the institutional patient care system 100 may incorporate a separate information system server 130, the functionality of which is described in more detail below. Furthermore, while the information system server 130 is shown as a separate server, the functionality and programming of the information system server 130 may 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 may further include one or more device terminals 132 for connecting to and communicating with the information system server 130. The device terminals 132 may include personal computers, personal data assistants, mobile devices such as laptops, tablet computers, augmented reality devices, or smartphones configured with software for communicating with the information system server 130 over the healthcare network 110. The information system server 130 may receive and provide information regarding the patient and / or the patient's treatment, such as measurements from a patient monitoring device (not shown), patient entry via one of the device terminals 132, or events from the patient care devices 12.

[0019] The patient care device 12 includes a system for providing patient care such as that described in U.S. Patent No. 5,713,856 to Eggers et al., which is incorporated herein by reference for that purpose. The patient care device 12 may include or incorporate pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeters, and other patient monitors), therapeutic devices, and other drug delivery devices may be utilized in accordance with the teachings described herein. In the illustrated example, the patient care device 12 includes a control module 14, also referred to as an interface unit 14, connected to one or more functional modules 16, 18, 20, and 22. The interface unit 14 includes a central processing unit (CPU) 50 connected to memory, e.g., random access memory (RAM) 58, as well as 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. The interface unit 14 also includes, but is not required to include, a main non-volatile storage unit 56, such as a hard disk drive or non-volatile flash memory, for storing software and data, and one or more internal buses 64 for interconnecting the aforementioned elements.

[0020] In various implementations, user interface device 54 is a touchscreen for displaying information to a user and allowing the user to input information by touching defined areas of the screen. Additionally or alternatively, user interface device 54 may include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. Data input device 60 may be a barcode reader capable of scanning and interpreting data printed in barcode format. Additionally or alternatively, data input device 60 may be any device for inputting coded data into a computer, such as a device for reading magnetic strips, a radio-frequency identification (RFID) device in which digital data encoded on an RFID tag or smart label (defined below) is captured by reader 60 via radio waves, a PCMCIA smart card, a radio frequency card, a memory stick, a CD, a DVD, or other analog or digital storage medium. Other examples of data input device 60 include a voice-activated or recognized device or a portable personal data assistant (PDA). Depending on the type of interface device used, user interface device 54 and data input device 60 may be the same device. While data input device 60 is shown in FIG. 1 as being located within interface unit 14, it will be appreciated that data input device 60 may be integrated into pharmacy system 34 or located externally and communicate with pharmacy system 34 via an RS-232 serial interface or any other suitable communication means. Auxiliary interface 62 may be an RS-232 communication interface, although any other means for communicating with peripheral devices such as printers, patient monitors, infusion pumps, or other medical devices may be used without departing from the present technology.Additionally, data input device 60 may be a separate functional module, such as functional modules 16, 18, 20, and 22, and may be configured to communicate with interface unit 14 or any other system on the network using suitable programming and communication protocols.

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

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

[0023] Each functional module 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. The functional modules 16, 18, 20, and 22 may be physically and electronically serially connected to one or both ends of the interface unit 14, as shown in FIG. 1 or as described in detail in Eggers et al. However, it will be recognized that other means for connecting the functional modules to the interface unit may be utilized without departing from the present technology. It will also be understood that devices such as pumps or patient monitoring devices that offer sufficient programmability and connectivity may operate as stand-alone devices and communicate directly with a network without being connected through a separate interface unit 14. As noted above, additional medical or peripheral devices may be connected to the patient care equipment 12 via one or more auxiliary interfaces 62.

[0024] Each functional module 16, 18, 20, and 22 may include module-specific components 76, a microprocessor 70, volatile memory 72, and non-volatile memory 74 for storing information. In some implementations, a functional module may include hardware components similar to those of the control unit 14, including, but not limited to, a CPU 50 connected to memory RAM 58, one or more interface devices, such as a user interface device 54, a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. Note that while four functional modules are shown in FIG. 1 , any number of devices may be directly or indirectly connected to the central controller 14. The number and types of functional modules described herein are for illustrative purposes and in no way limit the scope of the present technology. Module-specific components 76 include any components necessary for the operation of a particular module, such as a pumping mechanism for the infusion pump module 16.

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

[0026] The patient care device 12 can be operable in several different modes or personalities, each defined by a configuration database. As described below, each mode or personality may include a different set of configuration parameters or implement a different drug library. The configuration database may be on the patient care device's internal disk 56 or an external database 137. A particular configuration database (or portion thereof) may be selected based at least in part on patient-specific information, such as the patient's location, age, physical characteristics, or medical characteristics. Medical characteristics include, but are not limited to, the patient's diagnosis, treatment prescription, medical history, medical records, patient care provider identification, physiological characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identification) or the location of the patient care device 12 in the hospital or hospital computer network. Patient care information may be entered via interface devices 52, 54, 60, or 62 or may originate anywhere within the network 10, such as a pharmacy server, an admissions server, or a laboratory server.

[0027] The interface unit 14 of the patient care device 12 also has access to a drug library. Further information regarding drug libraries is contained in U.S. Patent No. 5,681,285 to Ford, which is incorporated herein by reference in its entirety. The drug library may reside within the controller, in accessible local memory, or located elsewhere on the system network but accessible by the controller. For example, "drug library profiles," such as an ICU (intensive care unit) profile, a pediatric profile, and a neonatology profile, may be established in which medications (e.g., drugs), concentrations, and other pumping parameters are configured specific to that care area. A configuration of pumping parameters, including a data set of authorized medications and restrictions on their use, may be available for each drug library profile. Thus, drug library profiles may, but do not necessarily, correspond to various patient care areas of a hospital. Thus, for example, a controller 14 located in a pediatric ward may utilize a pediatric drug library profile that includes a set of permitted medications, pumping parameters, and pumping limits specific to patients classified as pediatric or located in a pediatric ward. Similarly, a controller 14 located in an ICU may utilize an ICU drug library profile that includes a different set of permitted medications, pumping parameters, and pumping limits specific to patients in an intensive care environment and other patients requiring intensive care.

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

[0029] Data exchanged with various data sources can be converted into network-compatible data using existing technology, and information movement between medical devices and the network can be achieved by a variety of means. For example, patient care devices 12 and healthcare network 10 may communicate through automated interaction, manual interaction, or a combination of both automated and manual interaction. Automated interaction can be continuous or intermittent and may occur via a direct network connection 54 (as shown in FIG. 1 ), 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 devices 12 and network 10 includes intermittent or periodic physical transfer of data between systems, using, for example, user interface devices 54, coded data entry devices 60, bar codes, computer disks, portable data assistants, memory cards, or any other medium for storing data. In various embodiments, the communication means is bidirectional communication, accessing data from as many distributed data sources as possible. Decisions may be made at various locations within the healthcare network 10. For example, but not limited to, decisions may be made at the HIS server 30, decision support 48, remote data server 49, hospital department or unit station 46, or within the patient care device 12 itself.

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

[0031] FIG. 2A is an exemplary patient care device that may be interacted with by a clinician or patient within a healthcare organization in accordance with aspects of the present technology. The patient care device 200 shown in FIG. 2 is similar to or identical to the patient care device 12 of FIG. 1 and includes four infusion pumps 22 (e.g., functional module 22 of FIG. 1), 24, 26, and 28, each operatively engaged with a respective infusion administration set 30, 32, 34, and 36. The infusion sources 38, 40, 42, and 44 can take a variety of forms, but in this instance are shown as bottles, inverted and suspended above the pumps. The infusion sources may also take the form of bags or other types of containers. Both the patient care device 200 and the infusion sources 38, 40, 42, and 44 are mounted on a roller stand or pole 46. Particular infusion sources and their orientation within the care area (e.g., mounting location, mounting height, mounting type, etc.) may generate one or more interaction records. For example, an interaction record for a set may be generated in part by detecting a scannable code associated with the set prior to use. Once scanned, an interaction record may be recorded for use as described herein.

[0032] As shown in the exemplary implementation of FIGURE 2A, each administration set 30, 32, 34, and 36 is connected between a respective infusion source 38, 40, 42, and 44 and the patient 48 so that the patient 48 can receive fluids from all sources. The administration sets may be identified actively, such as by scanning by the clinician, or passively, such as by wireless or optical detection of the administration set. As with the infusion sources, once identified, an interaction record may be generated identifying the administration set, the clinician, the programming module, the pump, and the placement of the administration set (e.g., administration location (e.g., left forearm, right upper arm, etc.)).

[0033] Each of the infusion pumps 22, 24, 26, and 28 is used to infuse a respective fluid from the fluid source into the patient 48. The infusion pumps 22, 24, 26, and 28 are flow control devices that act on the respective tubing or infusion conduits of the infusion administration set to move the fluid from the fluid source through the conduits to the patient 48. Because individual pumps are used, each pump can be individually set to the pumping or operating parameters needed to infuse a particular medical fluid from its respective fluid source at a particular rate prescribed for that fluid by a clinician. Activities performed by the pumps or clinician to infuse a particular medical fluid may be associated with one or more interactions that may be recorded and processed as described.

[0034] Medical infusion administration sets typically have many more components than those shown in FIG. 2A. Many have check valves, drip chambers, valved ports, connectors, and other devices familiar to those skilled in the art. These other devices are not included in the drawings for clarity of illustration. For example, the patient care device 200 may include a patient-controlled analgesia (PCA) device that allows the patient 48 to self-administer medications (e.g., pain medications). See FIGS. 3-4 and the associated description below regarding how a PCA device may operate.

[0035] FIG. 2B is an elevational view illustrating the use of a PCA pump, an EtCO2 monitoring module, an SpO2 monitoring module, and a controller operatively connected to a central server, as well as illustrating actual patient interaction with the system. The program module 232 includes memory and programs and, as an example, can be described in terms of the advanced interface unit (100) found in U.S. Patent No. 5,713,856 to Eggers, incorporated herein by reference. The program module generally performs four functions in the patient care system 200b: The program module provides physical attachment of the system 200b to structures such as IV poles and bed rails. The program module provides power to the system 200b. The program module provides an interface between the system 200b and external devices, and, except for certain information, the program module provides the majority of the user interface with the system 200b.

[0036] The program module 232 includes an information display 250, which can be any type of display, such as a liquid crystal display. The display may be used during setup and operational procedures to facilitate data entry and editing. The display may also be used to display various operational parameters, such as the volume to be infused (VTBI) and current time for each infusion pump function module 238, as well as other prompts, advisories, and alarm conditions. The program module 232 includes a plurality of hard keys 252 and soft keys 254 for entering data and commands. The numeric hard keys are used to enter numerical data, while the remainder of the hard keys and soft keys are used to enter operational commands.

[0037] It should be further understood that in this embodiment, functional modules such as the SpO2 module 234 and the EtCO2 module 236 also have processors and memory. Identification information must be permanently stored in the memory of each functional module. The identification information includes a means for uniquely identifying each functional module, preferably a serial number, so that, for example, the event history of each functional module can be tracked and uploaded. The identification information also includes a means for identifying the function of the functional module to the program module 232, such as a code indicating that the functional module is a PCA pump. This information enables the program module 232, which stores multiple software domains, to know which domain to access for the selected functional module. Thus, the identification information stored in each functional module not only uniquely identifies the functional module to the attached interface module, but also identifies the function of the functional module. This identification information includes information specific to each functional module, as well as the software domain corresponding to the type of functional module.

[0038] Functional modules, particularly physiological monitors, may contain their own internal programs in their own memory. For example, certain SpO2 and EtCO2 monitors are distributed by manufacturers in the form of sensors with accompanying "boards" sold as a set. The accompanying boards include processors, memory, and programming for processing the associated sensor data. The boards are typically located, for example, within functional monitoring modules 234 and 236 and can provide display and alarm data. An example of such a display is shown in FIG. 2B, where both functional modules 234 and 236 display data 276 and 278 associated with their particular sensors, respectively. Such sensor / board sets contain their own rule sets for processing the data produced by their respective sensors, including rules regarding when to provide an alarm. However, they may not provide specific processing for pausing the PCA module based on the sensor data. Previously, alarms provided by sensor / board sets could be used to pause the PCA pump. As described in the Background section of this document, such pauses based on internal processors, programming, and rules set by sensors and boards for providing alarms have resulted in false alarms and unnecessary pauses.

[0039] According to one aspect of the present invention, individual patient monitoring modules 234 and 236 may be configured to emit alarms distinct from the PCA control protocol alarm configuration. Such alarms may take the form of lights on the front panels of the monitoring modules 234 and 236, as well as audible alarms. Alarms may also be transmitted to a remote server, either directly and independently by the monitoring modules or via a controller over a wired or wireless connection to the server. Additionally, the PCA control protocol may incorporate data available from the remote server, such as patient test data and pre-existing patient conditions, such as chronic obstructive pulmonary disease (COPD). For example, when the server provides data indicating that the patient has COPD, the PCA control protocol may initially be set to a relatively low PCA pause limit level. The clinician may then modify the PCA pause limit and PCA control protocol rules as needed, via an input device, such as a PDA, keyboard, or other data communication device, based on actual observations of the patient's condition and response to PCA. Additionally, the initial rules and / or configuration of the PCA control protocol may be modified or optimized by the central server based on additional information the central server possesses about the patient or rules or otherwise.

[0040] The rule sets within the monitoring modules 234 and 236 may be allowed to continue their normal operation and provide alerts based on their internal rule sets. Individual monitoring modules 234 and 236 may be disconnected from the program module 232, and therefore from the PCA control protocol, by shutting down and / or removing the module. However, this approach has the disadvantage of not providing the flexibility to allow the monitoring units to continue their normal operation, including generating alerts, outside of the PCA control protocol while avoiding nuisance suspension of PCA infusion. In yet another embodiment, the PCA control protocol may generate alerts and suspend PCA administration based on (unfiltered) instantaneous values ​​from the backup patient monitoring modules 234 and 236. This approach has the disadvantage that the PCA control protocol is susceptible to temporary, short-term fluctuations in the monitoring data, causing nuisance alerts and suspensions.

[0041] FIG. 3 illustrates an example patient-controlled analgesia (PCA) device (also known as a PCA wand) 300 in accordance with aspects of the present technology. For example, the PCA device 300 may be integrated with or part of a patient care device 12 or a module of a patient care device (e.g., functional unit 16 of the patient care device 12 of FIG. 1). Upon receiving input via the PCA device 300, the patient care device 12 is configured to activate one or more infusion devices (e.g., activate an infusion pump to prepare and deliver medication) based on the received user input. While various implementations are directed to the use of biometric information (e.g., fingerprints) to authenticate patients for self-administration of analgesic medications, the present technology is not limited to such and may include the use of other biometric-based authentication (e.g., passcodes, facial recognition, etc.) for self-administration of any type of medication.

[0042] In some implementations, the PCA device 300 includes a housing 306 that houses various electronics and wiring for implementing fingerprint authentication functionality. For example, a biometric sensor 302 may be integrated into the main PCA device 300. The biometric sensor 302 is configured to collect a user's biometric signal to determine the user's identity. The biometric sensor 302 may be a fingerprint reader configured to capture an image of at least a portion of the user's fingerprint. Upon capturing the image, the PCA device 300 transmits the captured image of the user's fingerprint via a wired connection (e.g., wire 310) or wirelessly to a patient care unit, which determines whether the user is authorized to operate the patient care unit. In some implementations, the captured biometric information includes a retinal scan.

[0043] According to some embodiments, for a request to be valid, a biometric must be acquired and a dose of medication must be administered within a predetermined time period (e.g., within 10 seconds or simultaneously) of the request. In some implementations, the biometric sensor 302 is integrated into the PCA device 300 such that a user activates the button 304, and the biometric sensor 302 automatically collects the user's fingerprint when the button is pressed. For example, the biometric sensor 302 and the button 304 may be integrated as a single component within the housing 306. The button 304 may be a physical button (e.g., a mechanical push button) or a virtual button (e.g., a user interface element displayed on a touch-sensitive screen) and configured to control one or more functional units of the patient care device (e.g., functional unit 18 of the patient care device 12 in FIG. 1 ). For example, a user may press the button 304 to cause an infusion pump (e.g., as a functional module of the patient care device) to administer a predetermined amount of medication to the patient (e.g., via intravenous delivery). The amount of medication administered may be based on the amount of force applied to the button when it is pressed (e.g., pressing longer or harder (e.g., with more pressure) may cause a larger amount of medication to be administered). Additionally or alternatively, the amount of medication administered may be based on the frequency with which the button is pressed. In some implementations, if it is determined that the user operating the PCA device 300 is not authorized to administer medication, the PCA device 300 may provide an alert (e.g., visual or audio) and not administer the medication.

[0044] In some implementations, the evaluation of whether to administer a medication is performed by the PCA device 300 (e.g., by a processor and memory included in the PCA device 300). For example, if the user is determined to be an authorized user, a PCA request is sent to the PCA device 300 or a patient care unit coupled to a PCA module (e.g., functional module 234 or 236 in FIG. 2B). On the other hand, if the user is determined to be an unauthorized user, the request is not processed further and the attempt may be logged by the patient care unit or PCA module. A failed attempt may result in one or more feedback, such as a visual or audio alarm, being generated in the PCA device 300.

[0045] In some embodiments, the evaluation of whether to administer a medication is performed by a PCA module. The PCA module receives a request to administer a medication via the PCA device 300 and determines whether the user is an authorized user. If the request is valid, the PCA module forwards the request to a patient care unit, which causes the drug delivery device to administer the prescribed amount of medication. On the other hand, if the user is an unauthorized user, the request is not processed further, and one or more feedback, such as a visual or audio alarm, may be generated in the PCA device 300 or the PCA module. Failed attempts may be logged by the patient care unit in the PCA module.

[0046] For example, a patient may attempt to self-administer multiple doses or a single dose that exceeds a maximum amount of a medication for a particular period of time. In this regard, a second request may be received asking the drug delivery device to administer an additional dose of medication, and the system (e.g., control unit 14 or an associated server) may determine, based on the second request, that the patient is not authorized to self-administer an additional dose of medication from the drug delivery device. In response to the second request, feedback circuitry within the PCA device 300 provides sensory information (e.g., an alarm) to the patient indicating that the additional dose will not be administered.

[0047] In some embodiments, the evaluation of whether to administer a medication is performed by the patient care unit. Each request to administer a medication is sent from the PCA device 300 to the patient care unit along with captured user biometric information (e.g., a fingerprint). If the request is valid, the patient care unit administers the prescribed amount of medication. On the other hand, if the request is an invalid request, the patient care unit may log the unauthorized attempt and sound a visual or audio alarm at the patient care unit, PCA module, or PCA device.

[0048] In some implementations, the patient care device 12 is communicatively coupled to a database (e.g., database 137 of FIG. 1) that stores a set of fingerprints, and upon receiving a fingerprint acquired by the PCA device 300, the patient care device 12 (or a central server) compares the collected fingerprint with fingerprint characteristics previously stored in the database. In some implementations, the database may store fingerprint characteristics of multiple users authorized to control the PCA device 300 for the patient, including the patient themselves, doctors, nurses, and caregivers authorized to treat the patient.

[0049] In some implementations, upon successful fingerprint authentication (or other biometric authentication), the technology may require one or more additional administration criteria (not shown in FIG. 3 ) to be met before the patient care device can administer medication to the patient. For example, the PCA device 300 may include or be connected to additional sensors to collect signals related to the patient's current condition. These additional sensors may include a motion sensor, an EEG sensor, an ECG sensor, an SpO2 sensor, a heart rate monitor, a respiratory rate sensor, a sound sensor (e.g., a microphone), etc. The additional sensors may be directly connected to the patient care device 12 or may transmit sensor data to the patient care device 12 via a wireless connection (e.g., using WiFi or BLUETOOTH®, etc.). After successful fingerprint authentication, the patient care device will administer medication to the patient only if the signals collected by the additional sensors indicate that the patient is in a suitable state to receive the medication. For example, if the motion sensor detects that the patient is moving, the patient care device may not administer medication for safety reasons. As another example, sound sensors can be used to assess a patient's alertness or pain level. The assessment may be based on passive sound monitoring for the amount of noise near the patient (e.g., more noise is likely to indicate the patient is awake) or specific noises indicative of a level of discomfort (e.g., moans or emotional analysis of spoken words). The assessment may also be based on active sound monitoring, where the patient responds to automated prompts such as, "What is your pain level?" The response may be interpreted by the system and provided as input to the dosing decision.

[0050] In some implementations, types of medication administration can be associated with different sets of authorization criteria. For example, a first type of medication can be administered only if the EEG signal, ECG signal, SpO2 signal, heart rate, respiration rate, sound, and movement signals meet a first set of criteria, and a second type of medication can be administered only if the EEG signal, ECG signal, SpO2 signal, heart rate, respiration rate, sound, and movement signals meet a second set of criteria. In some implementations, the criteria may specify a subset of signals or an alternative set of signals that may authorize administration. For example, a drug or medication type may be administered if the EEG signal meets specified criteria or if the respiration rate matches the criteria.

[0051] In some implementations, a patient (or another authorized user) may be legitimately requesting medication (e.g., the request meets fingerprint authentication and one or more additional criteria), but may be requesting too frequently. To prevent overdose, the patient care device 12 may implement a time-based lockout, whereby a request is received, but the drug delivery device does not take any action until the lockout time has elapsed. For example, the lockout time may include a predetermined amount of time between patient-initiated medication requests, or between a clinician-initiated bolus and a subsequent patient-initiated request. The length of the lockout period depends on the patient's physical characteristics and the type of medication being requested.

[0052] 4 illustrates an exemplary process 400 for operating a patient care device in accordance with aspects of the present technology. In some implementations, the patient care device (e.g., patient care device 12 of FIG. 1) includes a drug control device (e.g., PCA device 300 of FIG. 3), a control unit (e.g., interface unit 14 of FIG. 3), and a drug delivery device (e.g., infusion pump 22 operatively engaged with infusion administration set 30 of FIG. 2).

[0053] As a first step, the control unit 14 receives (402) from a control device (e.g., PCA device 300) associated with the control unit 14 or an associated module 16, 18, 20, 22 (e.g., a drug delivery device) a first user input including at least a portion of a patient's fingerprint along with a second user input corresponding to a request to administer a medication. For example, the patient may provide the first and second user inputs in a single action, such as pressing a button integrated with a fingerprint reader as shown in FIG. 3 . The control device transmits at least a portion of the fingerprint and the request to administer a medication to the control unit 14. In other words, the control unit 14 receives a request to the drug delivery device to administer a dose of a medication and biometric information captured by the drug control device.

[0054] The control unit 14 (or server 30 on behalf of the control unit 14) then compares at least a portion of the fingerprint to previously stored fingerprints to determine the patient's identity (404). For example, when a patient is admitted to the hospital, the patient's medical record may be updated with the patient's fingerprint and stored in database 137. The patient care device 12 (or control unit 14 or modules 16, 18, 20, 22) may be associated with the patient by a clinician, and that association is also stored in database 137.

[0055] According to some implementations, the PCA device 300 may be used to capture a patient's fingerprint during the admission process or when a clinician is preparing the patient care device 12 to administer medication to the patient (e.g., at the patient's bedside). The clinician may scan their badge with the control unit 14 to identify the clinician and authorize them to initiate medication administration, and may scan the patient's identification (e.g., a barcode or RFID identifier on a wristband) to associate the patient with the patient care device. The clinician may then be prompted by the control unit 14 to press the patient's fingerprint (or thumbprint) against the biometric sensor 302 to enter the patient's fingerprint into the patient's stored electronic health record or to verify that the correct patient is associated with the pump (based on a previously stored fingerprint associated with the patient in the record).

[0056] In some implementations, the patient care device 12 (or control unit 14 or module 16, 18, 20, 22) may receive a portion of the patient's medical record, including the patient's fingerprint, from the server 30 or database 137. In some implementations, the fingerprint (or a portion thereof) captured by the controlling device is transmitted to the server, which identifies the patient based on the fingerprint. In this manner, or through the association procedure described above performed by a clinician, the patient care device 12 (or PCU 14 or module 16, 18, 20, 22) is associated with one or more authorized users, whose fingerprint characteristics are stored in a database (e.g., database 137 of FIG. 1 ). Thus, upon receiving a request and fingerprint impression from the controlling device, the control unit 14 determines (e.g., by comparison 404) whether the patient is one of the users associated with patients authorized to operate the patient care device to self-administer medication.

[0057] In some implementations, the control unit 14 determines whether the patient is authorized to self-administer a dose of medication from the drug delivery device. In this regard, the control unit 14 may determine the medication currently being loaded by the drug delivery device. Such a determination may be based solely on previous entry of medication identification information or other relevant parameter entry by a clinician at the drug delivery device (e.g., at the interface device 54 or data input device 60). In some implementations, the control unit 14 may query a server and obtain medication identification information from the server based on information available at or received by the control unit (e.g., a patient identifier or an identifier associated with the device 12 or the control unit 14). In some implementations, the request and biometric information and device or patient identifier obtained by the drug control device 300 are transmitted to the server, and the server determines whether the patient is authorized to self-administer a dose of medication from the drug delivery device. In such implementations, the server notifies the control unit 14 whether the patient is authorized.

[0058] In response to receiving a request to administer a medication (e.g., via a second user input) and determining that the patient is an authorized user based on the identification information (406), the patient care device performs one or more additional verifications to identify the patient's condition before administering the medication to the patient. For example, the additional verifications may include determining the patient's condition based on signals collected by one or more sensors integrated with or connected to the patient care device 12 (or the patient control unit 14 or modules 16, 18, 20, 22). See FIG. 3 and associated discussion for more information regarding the collection of one or more sensors and signals.

[0059] To perform additional verification, one or more sensors obtain signals indicative of the patient's condition (408). These signals may be used to determine whether the patient's condition meets predetermined criteria to allow the patient to self-administer medication. In some implementations, the one or more sensors are included in the drug control device. In some implementations, the sensors are activated after the request and biological information are received by the drug control device (e.g., in response to the request and / or the biological information).

[0060] As described with respect to FIG. 3 , the technology may be integrated with or connected to one or more motion sensors, EEG sensors, ECG sensors, SpO2 sensors, heart rate monitors, respiration rate sensors, etc. In some implementations, signals obtained from these sensors may be compared to predetermined patterns or thresholds to determine whether the patient is experiencing a sufficient level of discomfort to justify administration of the requested medication. In other words, the signals are compared to determine whether the patient's condition meets a set of medication delivery criteria. In one example, an EEG waveform may be determined from sensor data and compared to predetermined waveforms indicative of one or more levels of discomfort. If the level of discomfort identified from the EEG waveform meets a predetermined threshold level of discomfort, the medication delivery criteria may be met. In another example, an oxygen sensor may provide oxygen sensor data, which may then be used to determine whether the patient is receiving an appropriate level of oxygen for administration of a particular medication provided by the patient care device 12. For example, a certain range of oxygen levels (e.g., below 85%) may contraindicate the medication. If the drug is not contraindicated for the patient's current oxygen levels, the request for further administration of the drug may be denied.

[0061] In another example, a motion sensor may be used to determine a level of motion associated with a patient. For example, a motion sensor may be used to determine whether the patient is awake and moving (e.g., by sensing periodic motion or a level of motion per period that exceeds a certain threshold) or whether the patient is asleep (e.g., by sensing a lack of motion for a threshold period). If the patient is determined to be asleep, administration of the requested medication may be denied. The level of motion may be associated with a level of discomfort. In such a case, the requested amount of medication may be delivered only upon sensing a level or pattern of motion associated with a threshold level of discomfort.

[0062] For example, a sensor may be used (e.g., by the control unit or drug delivery device) to detect patient movement and measure the patient's physiological state, and then determine a discomfort level based on the detected patient movement meeting an exercise threshold and the physiological state meeting a physiological threshold. The control unit and / or server and / or database may store different thresholds associated with different levels of discomfort. The different thresholds may be cross-referenced to determine the patient's current discomfort level based on the current reading.

[0063] In some implementations, the amount of requested medication may be automatically adjusted by the drug delivery device according to the patient's determined level of discomfort. For example, if the patient is awake but is determined to be motionless and not experiencing discomfort based on sensor data (and / or other data including level of movement, EEG or ECG patterns, SpO2 levels, heart rate, respiratory data, etc.), the amount of medication delivered in response to the request may be reduced. In some implementations, the amount may be adjusted proportionally (or based on a graduated scale) to the determined level of discomfort.

[0064] According to various implementations, if the drug delivery criteria are not met, an alert may be provided to a computing device associated with the clinician. For example, the alert may be sent by the PCU 14 (or the server 30 on behalf of the PCU) to the clinician's mobile device. Additionally or alternatively, the alert may be displayed on a display screen of the PCU or module associated with the requested drug administration, or provided audibly via a speaker integrated with or associated with the PCU or module.

[0065] In response to determining that the patient's condition meets a set of drug delivery criteria, the drug delivery device administers 410 a predetermined amount of drug to the patient. As previously described, each drug may be associated with a different set of drug delivery criteria. For example, a drug may be delivered as long as the user is determined to be at rest (e.g., stationary), regardless of other signals. In another example, a drug may be delivered if the SpO2 level is above a certain threshold and / or if the heart rate is below a certain threshold.

[0066] In some implementations, determining that the patient's state meets the set of drug delivery criteria may include determining that the patient is in a conscious state, which may be indicated, for example, by an EEG (or using an ECG signal) collected from the patient.

[0067] In some implementations, determining that the patient's condition meets a set of medication delivery criteria may include determining that the patient has not received more than a threshold amount of medication in the past predetermined period of time. That is, to prevent overdose, the patient care device implements a lockout period for medication dispensing. The length of the lockout period may vary depending on the medication.

[0068] In some implementations, as described above, determining that the patient's condition meets the first set of drug delivery criteria may include determining that a discomfort level associated with the patient is greater than a threshold discomfort level, the discomfort level associated with the patient being determined based on one or more signals indicative of the patient's condition. For example, the comfort level may be calculated based on a combination of the patient's heart rate and respiratory rate.

[0069] In some implementations, administering the predetermined amount of medication to the patient with the drug delivery device includes administering an amount of medication according to a magnitude of the second user input, for example, a longer or harder press on the control device results in a larger bolus of medication being administered, and a shorter or lighter press results in a smaller bolus of medication being administered.

[0070] Many of the above-described examples 400 and related functions and applications may be implemented as software processes specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium) and may be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause the processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. Computer-readable media excludes carrier waves and electronic signals passed wirelessly or via wired connections.

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

[0072] A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted, declarative or procedural, and may be deployed in any form, including as a standalone 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. A program may be stored in part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0073] FIG. 5 is a conceptual diagram illustrating an exemplary electronic system 500 for operating a pain medication delivery system in accordance with aspects of the present technology. Electronic system 500 may be a computing device for executing software associated with one or more portions or steps of process 400 of FIG. 1 or the components and processes provided by FIGS. 1-3 , including, but not limited to, information system server 30, computing hardware within patient care device 12, or device terminal 32. Electronic system 500 may be representative in combination with the present disclosure relating to FIGS. 1-4 . In this regard, electronic system 500 may be a personal computer, or a mobile device such as a smartphone, tablet computer, laptop, PDA, augmented reality device, wearable such as a watch, band, or eyeglasses, or a combination thereof, or other touch screen or television incorporating or coupled with one or more processors, or any other type of computer-related electronic device with network connectivity.

[0074] 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 persistent storage device 502, an input device interface 514, an output device interface 506, and one or more network interfaces 516. In some implementations, the electronic system 500 may include or be integrated with other computing devices or circuits for operation of the various components and processes described above.

[0075] Bus 508 collectively represents all system, peripheral, and chipset buses that communicatively connect the various internal devices of electronic system 500. For example, bus 508 communicatively connects processing unit 512 with ROM 510, system memory 504, and persistent storage device 502.

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

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

[0078] Other implementations use removable storage devices (such as floppy disks, flash drives, and their corresponding disk drives) as persistent storage device 502. Like persistent storage device 502, system memory 504 is a read-write memory device. However, unlike storage device 502, system memory 504 is a volatile read-write memory, such as random access memory. System memory 504 stores some of the instructions and data needed by the processor during execution. In some implementations, processes of the present disclosure are stored in system memory 504, persistent storage device 502, and / or ROM 510. From these various memory units, processing unit 512 retrieves instructions to execute and data to process in order to execute the processes of some implementations.

[0079] The bus 508 also connects to an input device interface 514 and an output device interface 506. The input device interface 514 allows a user to communicate information and selected commands to the electronic system. Input devices used with the input device interface 514 include, for example, an alphanumeric keyboard and a pointing device (also called a "cursor control device"). The output device interface 506 allows, for example, the display of images generated by the electronic system 500. Output devices used with the output device interface 506 include, for example, a printer and a display device such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some implementations include devices such as a touch screen that function as both an input device and an output device.

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

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

[0082] Some implementations include electronic components such as a microprocessor, storage, and memory that store computer program instructions on a machine-readable or computer-readable medium (also called a computer-readable storage medium, machine-readable media, or machine-readable storage medium). Some examples of such computer-readable media include RAM, ROM, read-only compact disc (CD-ROM), recordable compact disc (CD-R), rewritable compact disc (CD-RW), read-only digital versatile disc (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (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 Blu-Ray® discs, ultra-high density optical discs, any other optical or magnetic media, and floppy disks. The 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 produced by a compiler, and files containing high-level code that are executed by a computer, electronic component, or microprocessor using an interpreter.

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

[0084] As used herein 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 a person or group of people. For purposes of this specification, the terms display or displaying mean displaying on an electronic device. As used herein and in any claims of this application, the terms "computer readable medium" and "computer readable media" are strictly limited to tangible physical objects that store information in a form readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

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

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

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

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

[0089] It is understood that the specific order or hierarchy of steps in the processes disclosed is a description of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

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

[0091] Clause 1. A system comprising a drug delivery device, a drug control device operably connected to the drug delivery device, and a control unit operably connected to the drug delivery device and configured to capture biometric information from a person, wherein the control unit is configured to determine a medication currently loaded by the drug delivery device, receive via the drug control device a request for the drug delivery device to administer a certain dose of medication and the biometric information captured by the drug control device, confirm based on the biometric information that a patient associated with the biometric information is authorized to self-administer the certain dose of medication from the drug delivery device, and in response to receiving the request and the biometric information and confirming that the patient is a user authorized to self-administer the certain dose, obtain one or more signals indicative of the patient's condition by one or more sensors associated with the drug delivery device, and after determining that the patient's condition meets predetermined criteria for enabling the patient to self-administer the medication, cause the drug delivery device to administer the certain dose of medication to the patient.

[0092] Clause 2. The system of clause 1, wherein the medication control device is a handheld control device and the request and biometric information are captured within a predetermined time period of each other.

[0093] Clause 3. The system of clause 2, wherein the one or more sensors are included within the medication control device and are activated after the request and biometric information are received by the medication control device.

[0094] Clause 4. A system according to any of clauses 1 to 3, wherein the medication control device comprises a fingerprint reader and the biometric information comprises a representation of at least a portion of a fingerprint captured by the fingerprint reader.

[0095] Clause 5. A system described in any of clauses 1 to 4, wherein the one or more signals indicative of the patient's condition include an electroencephalogram (EEG) signal, an electrocardiogram (ECG) signal, a peripheral capillary oxygen saturation (SpO2) signal, a respiratory rate signal, or an exercise signal.

[0096] Clause 6. The system of any of clauses 1 to 5, wherein determining that the patient's condition meets predetermined criteria includes determining that the patient is in a conscious state based at least in part on one or more signals.

[0097] Clause 7. The system of any of clauses 1 to 6, wherein verifying that the patient is authorized to self-administer the fixed dose includes identifying the patient's identification information, identifying from a hospital information system an amount of medication received by the patient over a period of time based at least in part on the patient's identification information or an identifier associated with the drug delivery device, and determining that the amount of medication meets a threshold amount for the period of time.

[0098] Clause 8. The system of any of clauses 1 to 7, wherein the control unit is further configured to, after obtaining one or more signals indicative of the patient's condition, determine, based on the one or more signals, that a discomfort level associated with the patient is greater than a threshold discomfort level.

[0099] Clause 9 A system described in any of clauses 1 to 8, wherein the one or more sensors include a motion sensor for detecting the patient's movement and one or more physiological monitors for measuring physiological conditions including heart rate, blood pressure, electrocardiogram signal, electroencephalogram signal, or oxygen level, and the control unit is configured to detect the patient's movement, measure the patient's physiological condition, and determine a discomfort level based on the patient's detected movement satisfying an exercise threshold and the physiological condition satisfying a physiological threshold.

[0100] Clause 10. A system described in any of clauses 1 to 9, wherein the drug delivery device comprises a control unit configured to receive user input to initiate a request and determine the magnitude of the user input, and wherein administering a fixed dose of drug to the patient by drug delivery comprises administering a quantity of drug according to the magnitude of the user input.

[0101] Clause 11 A machine-implemented method comprising: determining a medication currently being loaded by a drug delivery device; receiving, via a drug control device operatively connected to the drug delivery device, a request for the drug delivery device to administer a fixed dose of medication and biometric information captured by the drug control device; verifying based on the biometric information that a patient associated with the biometric information is authorized to self-administer the fixed dose of medication from the drug delivery device; acquiring, by one or more sensors associated with the drug delivery device in response to receiving the request and the biometric information and verifying that the patient is a user authorized to self-administer the fixed dose, one or more signals indicative of the patient's condition; and causing the drug delivery device to administer the fixed dose of medication to the patient after determining that the patient's condition meets predetermined criteria for enabling the patient to self-administer the medication.

[0102] Clause 12. The machine-implemented method of clause 11, wherein the medication control device is a handheld control device and the request and biometric information are captured within a predetermined time period of each other.

[0103] Clause 13. The machine-implemented method of clause 12, wherein the medication control device includes a fingerprint reader, the biometric information includes a representation of at least a portion of a fingerprint captured by the fingerprint reader, and the one or more sensors are included within the medication control device and activated after the request and the representation of at least a portion of the patient's fingerprint are received by the medication control device.

[0104] Clause 14. The machine-implemented method of any of clauses 11 to 13, wherein the one or more signals indicative of the patient's condition include an electroencephalogram (EEG) signal, an electrocardiogram (ECG) signal, a peripheral capillary oxygen saturation (SpO2) signal, a respiratory rate signal, or a movement signal.

[0105] Clause 15. The machine-implemented method of any of clauses 11 to 14, wherein determining that the patient's condition meets predetermined criteria includes determining that the patient is in a conscious state based at least in part on the one or more signals.

[0106] Clause 16. The machine-implemented method of any of clauses 11 to 14, wherein the step of verifying that the patient is authorized to self-administer the fixed dose includes determining patient identification information, identifying from a hospital information system an amount of medication received by the patient over a period of time based at least in part on the patient identification information or an identifier associated with the drug delivery device, and determining that the amount of medication meets a threshold amount for the period of time.

[0107] Clause 17 The machine-implemented method of any of Clauses 11 to 16, wherein the one or more sensors comprise a motion sensor for detecting patient movement and one or more physiological monitors for measuring physiological conditions including heart rate, blood pressure, electrocardiogram signal, electroencephalogram signal, or oxygen level, and the machine-implemented method further comprises the steps of detecting the patient's movement, measuring the patient's physiological condition, and, after obtaining one or more signals indicative of the patient's condition, determining the patient's discomfort level based on the patient's detected movement satisfying a movement threshold and the physiological condition satisfying a physiological threshold, wherein the patient satisfies predetermined criteria including a discomfort level that satisfies the predetermined discomfort threshold.

[0108] Clause 18. The machine-implemented method of any of clauses 11 to 17, wherein the drug delivery device comprises a controller configured to receive a user input to initiate a request and to determine a magnitude of the user input, and wherein administering a dose of drug to the patient by drug delivery comprises administering a quantity of drug according to the magnitude of the user input.

[0109] Clause 19. A patient-controlled analgesia device for administering medication to a patient, comprising: a fingerprint reader for capturing at least a portion of a fingerprint of the patient; an activation button for requesting a drug delivery device communicatively coupled to the patient-controlled analgesia device to administer a predetermined amount of medication to the patient; one or more sensors for capturing one or more signals indicative of a patient's condition; a feedback circuit for indicating an operational status of the patient-controlled analgesia device; and one or more processors, the one or more processors being operable when executed by the one or more processors to determine a medication currently being loaded by the drug delivery device, a request to the drug delivery device to administer a predetermined dose of medication, and a trigger for triggering the one or more sensors for capturing one or more signals indicative of a patient's condition; and a memory containing instructions for causing the device to perform operations including receiving, via an activation button, a fingerprint of a patient identified by the request and biometric information and verifying that the patient is authorized to self-administer a fixed dose of medication from the drug delivery device; obtaining, by one or more sensors associated with the drug delivery device, one or more signals indicative of the patient's condition in response to receiving the request and biometric information and verifying that the patient is an authorized user to self-administer the fixed dose; and causing the drug delivery device to administer the fixed dose of medication to the patient after determining that the patient's condition meets predetermined criteria for allowing the patient to self-administer the medication.

[0110] Clause 20. The patient-controlled analgesia device of clause 19, wherein the operations further include receiving a second request to the drug delivery device to administer an additional dose of medication, determining based on the second request that the patient is not authorized to self-administer the additional dose of medication from the drug delivery device, and using the feedback circuitry to provide sensory information to the patient indicating that the additional dose will not be administered in response to the second request.

[0111] Further considerations: It is understood that the specific order or hierarchy of steps in the processes disclosed is a description of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

[0112] The foregoing description is provided to enable those skilled in the art to practice the various aspects described herein. The foregoing description provides various examples of the present technology, and the technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Accordingly, the claims are not intended to be limited to the aspects set forth herein but are to be accorded the full scope consistent with the claims as they are written, and references to elements in the singular are not intended to mean "only one" unless otherwise specified, but rather "one or more." Unless otherwise specified, the term "some" refers to one or more. Masculine pronouns (e.g., his) include feminine and neuter forms (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.

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

[0114] The term automatic, as used herein, may include performance by a computer or machine without user intervention, e.g., by instructions in response to a predicated action by a computer or machine or other initiating mechanism. The word "exemplary" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

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

[0116] As used herein, the terms "determine" or "determining" encompass a wide variety of actions. For example, "determining" may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, etc., via a hardware element without user intervention. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc., via a hardware element without user intervention. "Determining" may include resolving, selecting, choosing, establishing, etc., via a hardware element without user intervention.

[0117] As used herein, the terms "providing" or "providing" encompass a wide variety of actions. For example, "providing" may include storing a value at a location on a storage device for later retrieval, transmitting a value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, etc. "Providing" may also include encoding, decoding, encrypting, decrypting, verifying, verifying, etc. via a hardware element.

[0118] As used herein, the term "message" encompasses a wide variety of formats for communicating (e.g., sending or receiving) information. A message may include a machine-readable collection of information, such as an XML document, a fixed-field message, a comma-separated message, etc. A message, in some implementations, may include a signal utilized to transmit one or more representations of information. While stated in the singular, it should be understood that a message may be created, sent, stored, received, etc., in multiple parts.

[0119] As used herein, a "user interface" (also referred to as an interactive user interface, graphical user interface, or UI) may refer to a network-based interface that includes data fields and / or other control elements for receiving input signals or providing electronic information and / or for providing information to a user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other recognizable indicators presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiate a data exchange for the device presenting the UI. A UI may be implemented in whole or in part using technologies such as hyper-text markup language (HTML), FLASH®, JAVA®, .NET™, web services, or rich site summaries (RSS). In some implementations, a UI may be included in a standalone client (e.g., thick client, fat client) configured to communicate (e.g., send or receive data) according to one or more of the described aspects. The communication may be between a medical device, a diagnostic device, a monitoring device, or a server in communication therewith.

[0120] 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, etc., and preferably, a correspondence or relationship may be used to render one or more of two or more objects, data sets, information, etc., so that they appear identical or equivalent. Correspondence may be evaluated using one or more of thresholds, value ranges, fuzzy logic, pattern matching, machine learning evaluation models, or combinations thereof.

Claims

1. a drug delivery device; a drug control device operably connected to the drug delivery device; a control unit operably connected to the drug delivery device; a control unit for controlling a plurality of inputs of a signal; determining a medication currently being loaded by the drug delivery device; receiving from the drug control device a request to the drug delivery device to administer a dose of the medication, as captured by the drug control device, and physiological information, as captured by the drug control device; verifying, based on the biometric information, that a patient associated with the biometric information is authorized to self-administer the dose of the medication from the drug delivery device; in response to receiving the request and biometric information and verifying that the patient is an authorized user to self-administer the metered dose; obtaining, by one or more sensors associated with the drug delivery device, one or more signals indicative of a condition of the patient; causing the drug delivery device to administer the dose of the drug to the patient after determining that the condition of the patient meets predetermined criteria for allowing the patient to self-administer the drug. The system is configured as follows:

2. 10. The system of claim 1, wherein the medication control device is a handheld control device and the request and biometric information are captured within a predetermined time period of each other.

3. The system of claim 2 , wherein the one or more sensors are included within the medication control device and are activated after the request and biometric information are captured by the medication control device.

4. 4. The system of claim 1, wherein the medication control device includes a fingerprint reader and the biometric information includes a representation of at least a portion of a fingerprint captured by the fingerprint reader.

5. 5. The system of claim 1, wherein the one or more signals indicative of the patient's condition include an electroencephalogram (EEG) signal, an electrocardiogram (ECG) signal, a peripheral capillary oxygen saturation (SpO2) signal, a respiratory rate signal, or a movement signal.

6. 6. The system of claim 1, wherein determining that the patient's condition meets the predetermined criteria comprises determining that the patient is in a conscious state based at least in part on the one or more signals.

7. verifying that the patient is authorized to self-administer the metered dose; determining the patient's identity; Identifying from a hospital information system an amount of medication received by the patient over a period of time based at least in part on the patient's identity or an identifier associated with a drug delivery device; determining that the amount of drug satisfies a threshold amount for the period of time; The system of any one of claims 1 to 6, comprising:

8. The control unit further comprises: configured, after obtaining the one or more signals indicative of the patient's condition, to determine, based on the one or more signals, whether a discomfort level associated with the patient is greater than a threshold discomfort level; determining that the condition of the patient meets the predetermined criteria includes determining that a discomfort level associated with the patient is greater than the threshold discomfort level. A system according to any one of claims 1 to 7.

9. the one or more sensors: a motion sensor for detecting movement of the patient; one or more physiological monitors for measuring physiological conditions, including heart rate, blood pressure, electrocardiogram signals, electroencephalogram signals, or oxygen levels; wherein the control unit detecting movement of the patient; measuring the physiological condition of the patient; determining the discomfort level based on the detected movement of the patient meeting a movement threshold and the physiological state meeting a physiological threshold; The system of claim 8 , configured to:

10. 10. The system of claim 1, wherein the drug delivery device comprises a control unit configured to receive a user input to initiate the request and to determine a magnitude of the user input, and wherein administering the fixed dose of the drug to the patient by the drug delivery device comprises administering a quantity of the drug according to the magnitude of the user input.

11. A system operation method for operating a system comprising a control unit, a drug control device, and a drug delivery device, comprising: The control unit determining a medication currently being loaded by the drug delivery device; receiving, via the drug control device operatively connected to the drug delivery device, a request for the drug delivery device to deliver a dose of the medication and biological information captured by the drug control device; verifying, based on the biometric information, that a patient associated with the biometric information is authorized to self-administer the dose of the medication from the drug delivery device; in response to receiving the request and biometric information and verifying that the patient is an authorized user to self-administer the metered dose; obtaining, by one or more sensors associated with the drug delivery device, one or more signals indicative of a condition of the patient; causing the drug delivery device to deliver the dose of the medication after determining that the condition of the patient meets predetermined criteria for allowing the patient to self-administer the medication; A method of operating a system, comprising:

12. 12. The method of operating a system of claim 11, wherein the medication control device is a handheld control device and the request and biometric information are captured within a predetermined time period of each other.

13. 13. The system operation method of claim 12, wherein the drug control device includes a fingerprint reader, the biometric information includes a representation of at least a portion of a fingerprint captured by the fingerprint reader, and the one or more sensors are included within the drug control device and activated after the request and the representation of at least a portion of the patient's fingerprint are captured by the drug control device.

14. 14. The method of operating a system according to any one of claims 11 to 13, wherein the one or more signals indicative of the condition of the patient include an electroencephalogram (EEG) signal, an electrocardiogram (ECG) signal, a peripheral capillary oxygen saturation (SpO2) signal, a respiratory rate signal, or a movement signal.

15. 15. The method of operating a system according to any one of claims 11 to 14, wherein determining that the state of the patient meets the predetermined criteria comprises determining, by the control unit, that the patient is in a conscious state based at least in part on the one or more signals.

16. Verifying that the patient is authorized to self-administer the metered dose may be performed by the control unit, determining the patient's identity; Identifying from a hospital information system a quantity of medication received by the patient over a period of time based at least in part on the patient's identity or an identifier associated with a drug delivery device; determining that the amount of drug satisfies a threshold amount for the period of time; 16. A method of operating a system according to any one of claims 11 to 15, comprising:

17. wherein the one or more sensors comprise a motion sensor for detecting movement of the patient and one or more physiological monitors for measuring physiological conditions including heart rate, blood pressure, electrocardiogram signals, electroencephalogram signals, or oxygen levels, and the system operation method further comprises: The control unit detecting movement of the patient; measuring the physiological condition of the patient; after obtaining the one or more signals indicative of the patient's condition, determining a discomfort level based on the detected movement of the patient satisfying a movement threshold and the physiological condition satisfying a physiological threshold, wherein the patient meets predetermined criteria, including the discomfort level satisfying a predetermined discomfort threshold; 17. A method of operating a system according to any one of claims 11 to 16, comprising:

18. 18. A system operation method according to any one of claims 11 to 17, wherein the drug delivery device comprises a control unit configured to receive a user input to initiate the request and to determine a magnitude of the user input, and causing the drug delivery device to deliver the fixed dose of the drug comprises causing the drug delivery device to deliver a quantity of the drug according to the magnitude of the user input.

19. 1. A patient-controlled analgesia device for administering medication to a patient, comprising: a fingerprint reader for acquiring at least a portion of a fingerprint of a patient; an activation button for requesting a drug delivery device communicatively coupled to the patient-controlled analgesia device to administer a predetermined amount of medication to the patient; one or more sensors for acquiring one or more signals indicative of a condition of the patient; a feedback circuit for indicating the operating status of the patient-controlled analgesia device; one or more processors; When executed by the one or more processors, the one or more processors determining a drug currently being loaded by the drug delivery device; receiving a request to the drug delivery device via the activation button to administer a dose of the medication and a fingerprint of the patient captured by the fingerprint reader; verifying, based on the fingerprint, that the patient is authorized to self-administer the dose of the medication from the drug delivery device; in response to receiving the request and biometric information and verifying that the patient is an authorized user to self-administer the metered dose; obtaining, by one or more sensors associated with the drug delivery device, one or more signals indicative of a condition of the patient; causing the drug delivery device to administer the dose of the drug to the patient after determining that the condition of the patient meets predetermined criteria for allowing the patient to self-administer the drug; a memory containing instructions for performing operations including 1. A patient-controlled analgesia device comprising:

20. The operation further comprises: receiving a second request to the drug delivery device to administer an additional dose of the medication; determining, based on the second request, that the patient is not authorized to self-administer an additional dose of the medication from the drug delivery device; using the feedback circuit to provide sensory information to the patient indicating that no further doses will be administered in response to the second request; and 20. The patient-controlled analgesia device of claim 19, comprising:

Images