EP4736174A1

EP4736174A1 - Handheld electronic drug-requesting device for use with patient-controlled analgesia

Info

Publication number: EP4736174A1
Application number: EP23748640.2A
Authority: EP
Inventors: Daniel M. Abal; Brendan John Burgess
Original assignee: CareFusion 303 Inc
Current assignee: CareFusion 303 Inc
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2026-05-06
Also published as: CN121399693A; WO2025005933A1; AU2023458219A1

Abstract

A handheld electronic drug-requesting device includes a handle configured to be grasped by a patient's hand, a display embedded into the handle, and a touch-activated control integrated in the handle or the display. The handheld device performs operations that include determining the device is electronically coupled to a drug-delivery device for delivery of a drug to the patient and, in response to determining the device is electronically coupled to the drug-delivery device, receiving information related to a patient profile associated with the patient, presenting a user interface element on the display to the patient including the information related to the patient profile associated with the patient, receiving a patient request to deliver a dose of the drug to the patient via the touch-activated control, and, responsive to the patient request, causing the dose of the drug to be delivered.

Description

HANDHELD ELECTRONIC DRUG-REQUESTING DEVICE FOR USE WITH PATIENT- CONTROLLED ANALGESIA

TECHNICAL FIELD

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

BACKGROUND

[0002] Patient-controlled analgesia (PCA) is a commonly-used method to relieve pain experienced by a patient that can be more convenient for both the clinician and the patient. The method typically involves using a syringe pump programmed to allow for delivery of a predefined amount (e.g., a dose) of analgesia when the patient desires it. Some implementations of PCA include a patient-controlled device (e.g., a PCA wand or a PCA requestor) for the patient to request delivery of the analgesia.

SUMMARY

[0003] There is a growing need for PCA implementations (e.g., including handheld electronic drug-requesting devices) that provide more efficient, intuitive, safe, and better overall treatment experiences to patients. The present disclosure discusses various implementations of devices, systems, and methods for providing patient interactions with drug-requesting devices (e.g., dose-requestors) to improve the patient care experience and/or reduce clinician work (e.g., by minimizing patient intervention). For example, some implementations include providing patients with information about their patient profile (e.g., timing of doses) and information that improves their use of the PCA system (e.g., minimizing and/or otherwise optimizing dose request times based on providing dose-timing information and/or data detected by sensors of the drugrequesting devices to the patient), including feedback to improve drug delivery (e.g., by optimizing dose levels) and to minimize drug diversion and/or mechanical failures (e.g., based on a patient sitting on a tube of a fluid infusion pump). A handheld drug-requesting device according to various implementations described herein can allow for bi-directional patient interactions to obtain feedback about an amount of pain that the user is in while at a same time receive input to cause delivery of a dose of a drug (e.g., an analgesic). For example, the bi-directionality of the feedback provided between the patient and a patient care device that is facilitating PCA delivery and/or delivery of other types of drugs can provide for improved functionality of the device (e.g., by minimizing and/or preventing drug delivery processes that are not safe, authorized, and/or otherwise appropriate). For example, feedback provided by the dose requester to the patient (e.g., when a dose will be available to be delivered) may prevent the amount of drug requests submitted by the patient, thereby reducing computation performed and/or power consumption, since the patient is more informed about when drug delivery is available.

[0004] The handheld electronic drug-requesting further improves patient care feedback mechanisms by facilitating pain feedback after a dose of a drug has been delivered to the patient. In some implementations, patient feedback and/or other patient interactions with the handheld electronic drug-requesting devices (e.g., involuntary movements) can be provided to an artificial intelligence model (e.g., a machine-learning model stored at a server) to improve detections of issues related to the drug delivery. Allowing the patient to provide such inputs directly to the drugrequesting device also allows for a more seamless overall treatment experience by not requiring a clinician to manually assess and/or request information about levels of pain that a patient is experiencing.

[0005] In addition to the improved functional capabilities described above, it is understood that structural aspects of the handheld electronic drug-requesting devices herein, either alone or in conjunction with the improved functional capabilities, contribute to an improved patient experience. For example, the patient can easily request drug boluses while performing other related operations and providing feedback with the handheld electronic drug-requesting device using one hand, and in some cases, as little as a single touch input (e.g., via a patient’s thumb can cause performance of any of the operations described herein). Other technical improvements of implementations described herein will be made apparent to one of skill in the art based on the discussion provided herein.

[0006] According to various aspects, a handheld electronic drug-requesting device is provided. The handheld electronic drug-requesting device includes a handle configured to be grasped by a hand of a patient; a display integrated in the handle; a touch-activated control integrated in the handle or the display; one or more processors; and a memory comprising instructions stored thereon that, when executed by the one or more processors, cause operations comprising: determining the handheld electronic drug-requesting device is electronically coupled to a drug-delivery device for delivery of a drug to the patient; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device; presenting, on the display integrated in the handle, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handle, a patient request to deliver of a dose of the drug to the patient via the touch-activated control integrated in the handle or the display; and responsive to the patient request, causing the dose of the drug to be delivered to the patient. Other aspects include corresponding systems, methods, and computer program products for implementation of the corresponding device and its features.

[0007] According to various aspects, a machine-implemented method comprises determining a handheld electronic drug-requesting device is electronically coupled to a drugdelivery device for delivery of a drug to a patient grasping the handheld electronic drug-requesting device, receiving, by the handheld electronic drug-requesting device, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profde associated with the patient, receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver a dose of the drug to the patient via a touch-activated control of the handheld electronic drug-requesting device, and responsive to the patient request, causing the dose of the drug to be delivered to the patient. Other aspects include corresponding devices, systems, and computer program products for implementation of the corresponding method and its features.

[0008] According to various aspects, a system comprises a drug-delivery device in operable communication with a control unit for controlling drug delivery to a patient via the drugdelivery device, wherein the control unit includes a handheld electronic drug-requesting device, one or more processors, memory, including instructions, which, when executed by the one or more processors, cause performance of operations, comprising: determining a handheld electronic drugrequesting device is electronically coupled to the drug-delivery device for delivery of a drug to the patient, receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device, presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profde associated with the patient, receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drugrequesting device, a patient request to deliver a dose of the drug to the patient via a touch- activated control of the handheld electronic drug-requesting device, responsive to the patient request, causing the dose of the drug to be delivered to the patient. Other aspects include corresponding devices, methods, and computer program products for implementation of the corresponding system and its features.

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a better understanding of the various described implementations, reference should be made to the Description below, in conjunction with the following drawings. Like reference numerals refer to corresponding parts throughout the figures and description.

[0011] FIG. 1 depicts an example of an institutional patient care system of a healthcare organization, according to aspects of the subject technology.

[0012] FIG. 2A depicts an example of an institutional patient care system of a healthcare organization, according to aspects of the subject technology.

[0013] FIG. 2B is a closer view of a portion of the example patient care device shown in FIG. 1 A, according to various aspects of the subject technology.

[0014] FIGS. 3A-3J depict an example handheld electronic drug-requesting device for allowing a patient to request a drug to be delivered, according to aspects of the subject technology. [0015] FIG. 4 depicts an example process for performing PCA operations at a patient care system that includes a handheld electronic drug-requesting device, according to aspects of the subject technology.

[0016] FIG. 5 is a conceptual diagram illustrating an example electronic system for operating an analgesia administration system, according to aspects of the subject technology.

DESCRIPTION

[0017] 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 described implementations. However, it will be apparent to one of ordinary skill in the art that the various described implementations may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the implementations.

[0018] FIG. 1 depicts an example of an institutional patient care system 100 of a healthcare organization, according to aspects of the subject technology. In FIG. 1, a patient care device 12 (“PCD”), sometimes referred to as a “patient care unit” (“PCU”) or “medical device” generally, is connected to a healthcare network 110. The patient care device may include or be communicatively connected to various ancillary medical devices such as an infusion pump, a vital signs monitor, a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (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 patient care device 12 may be connected to healthcare network 110 by a transmission channel 131. Transmission channel 131 may be any suitable wired or wireless transmission channel, for example, an 802.11 wireless local area network (LAN). In some implementations, healthcare network 110 also includes computer systems located in various departments throughout a hospital. For example, healthcare network 110 optionally includes computer systems associated with one or more of: an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers and/or a medical decision support system. As described further below, healthcare network 110 may include discrete subnetworks. In the depicted example, healthcare network 110 includes a device network 140 by which patient care device 12 (and other devices) may communicate, in accordance with normal operations. According to some implementations, the devices and supporting services of healthcare network 110 or a portion thereof may be cloud-based with, for example, the servers and services (e.g., databased, APIs, etc.) located remote from the hospital and/or distributed across multiple remote locations or regions.

[0019] Additionally, institutional patient care system 100 may incorporate a separate information system server 130, the function of which will be described in more detail below. Moreover, although information system server 130 is shown as a separate server, the functions and programming of information system server 130 may be incorporated into another computer, such as, for example, a hospital information system server or cloud-based server, if such is desired by engineers designing the institution's information system. Institutional patient care system 100 may further include one or multiple device terminals 132 for connecting and communicating with information system server 130. Device terminals 132 may include personal computers, personal data assistant, mobile devices such as laptops, tablet computers, augmented reality devices, or smartphones, configured with software for communications with information system server 130 via healthcare network 110. The information system server 130 may receive and provide information about patient and/or their treatment such as measurements from patient monitoring devices (not shown), entries for the patient via one of the device terminals 132, or events from the patient care device 12.

[0020] Patient care device 12 may include or incorporate pumps, physiological monitors (e.g., heart rate, blood pressure, electrocardiogram (ECG), electroencephalogram (EEG), pulse oximeter, and other patient monitors), therapy devices, and other drug delivery devices may be utilized according to the teachings set forth herein. In the depicted example, patient care device 12 comprises a control module, also referred to as interface unit 14, connected to one or more functional modules 16, 18, 20, 22. Interface unit 14 includes a central processing unit (CPU) 50 connected to a memory, for example, memory 58 (e.g., random access memory (RAM)), and one or more interface devices such as 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. Interface unit 14 also, although not necessarily, includes a main non-volatile storage unit (e.g., a disk 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.

[0021] In various implementations, user interface device 54 is a touch screen for displaying information to a user and allowing a user to input information by touching defined areas of the screen. Additionally, or in the alternative, user interface device 54 could include any means for displaying and inputting information, such as a monitor, a printer, a keyboard, softkeys, a mouse, a track ball and/or a light pen. Data input device 60 may be a bar code reader capable of scanning and interpreting data printed in bar coded format. Additionally or in the alternative, data input device 60 can be any device for entering coded data into a computer, such as a device(s) for reading magnetic strips, radio-frequency identification (RFID) devices whereby digital data encoded in RFID tags or smart labels (defined below) are captured by the data input device 60 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage media. Other examples of data input device 60 include a voice activation or recognition device or a portable personal data assistant (PDA). Depending upon the types of interface devices used, user interface device 54 and data input device 60 may be the same device. Although data input device 60 is shown in FIG. 1 to be disposed within interface unit 14, it is recognized that data input device 60 may be integral within pharmacy system 34 or located externally and communicating with pharmacy system 34 through an RS-232 serial interface or any other appropriate communication means. Auxiliary interface 62 may be an RS-232 communications interface, however any other means for communicating with a peripheral device such as a printer, patient monitor, infusion pump or other medical devices may be used without departing from the subject technology. Additionally, data input device 60 may be a separate functional module, such as functional modules 16, 18, 20 and 22, and configured to communicate with interface unit 14, or any other system on the network, using suitable programming and communication protocols.

[0022] Network connection 52 may be a wired or wireless connection, such as by 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 WLANS connection or other wireless connection.

[0023] Functional modules 16, 18, 20, 22 are any devices associated with interface unit 14 for providing care to a patient and/or for monitoring the patient’s condition. As shown in FIG. 1, at least one of functional modules 16, 18, 20, 22 may be an infusion pump module such as an intravenous infusion pump for delivering medication or other fluid 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 or the like. In other examples, functional modules 18, 20 and/or 22 may include devices other than infusion pump modules, including a printer, scanner, bar code reader or any other peripheral input, output, or input/output device.

[0024] Each functional module 16, 18, 20, and 22 communicates directly or indirectly with interface unit 14, with interface unit 14 providing overall monitoring and control of patient care device 12. Functional modules 16, 18, 20, and 22 may be connected physically and electronically in serial fashion to one or both ends of interface unit 14 as shown in FIG. 1. However, it is recognized that there are other means for connecting functional modules with the interface unit that may be utilized without departing from the subject technology. It will also be appreciated that devices such as pumps or patient monitoring devices that provide sufficient programmability and connectivity may be capable of operating as stand-alone devices and may communicate directly with the network without requiring a connection through separate interface unit 14. As described above, additional medical devices or peripheral devices may be connected to patient care device 12 through one or more auxiliary interfaces 62.

[0025] Each of functional modules 16, 18, 20, and 22 may include module-specific components 76, a microprocessor 70, a volatile memory 72 and a nonvolatile memory 74 for storing information. In some implementations, a functional module may include hardware components similar to those of interface unit 14 including, but not limited to, a CPU 50 connected to memory 58, one or more interface devices such as 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. It should be noted that while four functional modules are shown in FIG. 1, any number of devices may be connected directly or indirectly to interface unit 14. The number and type of functional modules described herein are intended to be illustrative, and in no way limit the scope of the subject technology. Module-specific components 76 include any components necessary for operation of a particular module, such as a pumping mechanism for an infusion pump module (e.g., an infusion pump module 22 as shown in FIGS. 2A-2B).

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

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

[0028] Data to and from the various data sources can be converted into networkcompatible data with existing technology, and movement of the information between the medical device and network can be accomplished by a variety of means. For example, patient care device 12 and healthcare network 110 may communicate via automated interaction, manual interaction, or a combination of both automated and manual interaction. Automated interaction may be continuous or intermittent and may occur through network connection 52 (as shown in FIG. 1), or through RS232 links, MIB systems, RF links such as BLUETOOTH, IR links, WLANS, digital cable systems, telephone modems or other wired or wireless communication means. Manual interaction between patient care device 12 and healthcare network 110 involves physically transferring, intermittently or periodically, data between systems using, for example, user interface device 54, coded data input device 60, bar codes, computer disks, portable data assistants, memory cards, or any other media for storing data. The communication means in various aspects is bidirectional with access to data from as many points of the distributed data sources as possible. [0029] FIG. 2A depicts an example of an institutional patient care system of a healthcare organization, according to aspects of the subject technology. Patient care device 200 shown in FIG. 2A is similar or identical to patient care device 12 in FIG. 1, including four fluid infusion pumps 16, 18, 20, and 22 (e.g., which are also referred to as functional modules 16, 18, 20, and 22 in FIG. 1), each of which is in operative engagement with a respective fluid administration set 30, 32, 34, and 36. Fluid supplies 38, 40, 42, and 44, which may take various forms but in this case are shown as bottles, are inverted and suspended above the pumps. Fluid supplies may also take the form of bags or other types of containers. In the depicted example, both patient care device 200 and fluid supplies 38, 40, 42, and 44 are mounted to a roller stand or pole 46. The specific fluid supplies as well as their orientation (e.g., mount location, mount height, mounting type, etc.) within the care area may be generate one or more interaction records. The interaction record for a set for example may be generated in part by detecting a scannable code associated with the set prior to use. Once scanned, the interaction record may be recorded for use as described herein.

[0030] As shown in the example implementation of FIG. 2 A, each administration set 30, 32, 34, and 36 is connected between a respective fluid supply 38, 40, 42, and 44 and a patient 48 so that patient 48 may receive the fluids in all the fluid supplies. The administration set may be identified either actively by, for example, scanning by a clinician or passively by, for example, wireless or optical detection of the administration set. As with the fluid supply, once identified, an interaction record may be generated identifying the administration set and one or more of the clinician, programming module, pump, administration set positioning (e.g., administration location (e.g., left forearm, right upper-arm, etc.).

[0031] Each of fluid infusion pump 16, 18, 20, and 22 is used to infuse each of the fluids of the fluid supplies into patient 48. Fluid infusion pumps 22, 24, 26, and 28 are flow control devices that will act on the respective tube or fluid conduit of the fluid administration set to move the fluid from the fluid supply through the conduit to patient 48. Because individual pumps are used, each can be individually set to the pumping or operating parameters required for infusing the particular medical fluid from the respective fluid supply into the patient at the particular rate prescribed for that fluid by the clinician. The activities performed by the pump or clinician to infuse the particular medical fluid may be associated with one or interaction which may be recorded and processed as described. [0032] FIG. 2B is a closer view of a portion of the example patient care device shown in FIG. 1A, according to various aspects of the subject technology. FIG. 2B shows two functional modules 18 and 20 (e.g., infusion pumps, syringe pump modules, and/or drug-delivery devices) mounted at either side of a main frame control unit 14, and the displays and control keys of each, with the main frame infusion controller being capable of programming both infusion pumps. In accordance with some implementations, the patient care unit 12 includes functional syringe pump module 18 and function infusion pump module 20, which are two different types of drug-delivery devices that can be controlled by patient care unit 12. The infusion device includes a door 5a and a handle 5b that operates to lock the door in a closed position for operation and to unlock and open the door for access to the internal pumping and sensing mechanisms and to load administration sets for the pump. When the door 5a is open, the tube can be connected with the pump module 20. When the door 5a is closed, the tube is brought into operating engagement with the pumping mechanism, the upstream and downstream pressure sensors, and the other equipment of the pump. A display 5c, such as an LED display, is located in plain view on the door in this embodiment and may be used to visually communicate various information relevant to the pump module 20, such as alert indications (e.g., alarm messages). Control keys 5e to 5h may exist for programming and controlling operations of the infusion pump as desired. In some implementations, the control keys may be presented as interactive elements on the display 5c (e.g., touchscreen display). The main frame and/or functional module may also include audio alert equipment in the form of a speaker (not shown).

[0033] The main frame control unit 14 of the patient care device 12 includes a display 6a for visually communicating various information, such as the operating parameters of a connected pump and alert indications and alert messages, and control keys 6b and 6c for selecting and/or setting control parameters and/or options for controlling the patient care device 12 and connected modules. The main frame control unit 14 may also include a speaker to provide audible alerts. In some implementations, the display 6a may be implemented as a touchscreen display. In such implementations, the control keys 6b may be omitted or reduced in number by providing corresponding interactive elements via a graphical user interface presented via the display 6a. In some implementations, each control key 6b (or 6c) may select a corresponding option displayed in display 6a. [0034] The main frame control unit 14 may include a communications system (not shown) with which the main frame control unit 14 may communicate with external equipment such as a medical facility server or other computer and with a portable processor, such as a handheld communication device or a laptop-type of computer, or other information device that a clinician may have to transfer information as well as to download drug libraries to a functional module 16, 18, 20, 22 (e.g., fluid infusion pump 20). In some implementations, the main frame infusion controller may communicate (e.g., through a wired connection or wirelessly) with drug-requesting device 300, which is described in more detail below with respect to FIGS. 3A-3F. The communication module may be used to transfer access and interaction information for clinicians encountering the main frame infusion controller or device coupled therewith (e.g., fluid infusion pump module 22 or bar code scanner). The communications system may include one or more of a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH™ system, or other wired or wireless system. The bar code scanner and communications system may alternatively be included integrally with the infusion pump 20, such as in cases where a main frame infusion controller is not used, or in addition to one with the main frame control unit 14. Further, information input devices need not be hard-wired to medical instruments, information may be transferred through a wireless connection as well. Additionally, other types of modules may be connected to the pump modules or to the main frame infusion controller such as a syringe pump module, patient controlled analgesic module, end tidal CO2 (ETCO2) monitoring module, oximeter monitoring module, or the like.

[0035] For the purpose of this disclosure, interface unit 14 and/or information server 130 may include software and associated algorithms for implementing the various features described herein. This hardware, software, and associated algorithms are collectively referred to herein as the patient care system. In some implementations, interface unit 14 operates the patient care system in that the internal processing and decision control for approval of a dose request made by drug-delivery device 300. In some implementations, the dose request may be forwarded from interface unit 14 to the information server 130 for approval. In some implementations, on the interface unit 14 receiving the dose request, the interface unit may process and approve the dose request based on obtaining patient profile information from the server 130 (e.g., from an EMR system).

[0036] During operation of the patient care system, when a connected drug-delivery device

300 is actuated, interface unit 14 (including, e.g., microprocessor 50) receives a dose request signal via a patient dose request cord 303. If interface unit 14 determines (e.g., in connection with profde data obtained from an internal database or via server 130) that there are no limitations in administering a requested bolus dose of medication, interface unit 14 may then send a signal to a connected pump controller to instruct a pump unit associated with the request to administer the requested bolus dose. The interface unit 14 also provides for the coordination of activities between the functional units, such as the pump and an ETCO2 unit. For example, a clinician may set up the patient care device 12 to provide PC A administration and the ETCO2 unit to monitor the ETCO2 parameters of aPCA patient. Optionally, one or more additional monitors, such as a pulse oximetry unit, may be communicatively connected to the patient care system and set up to monitor blood oxygen saturation and pulse rate. The clinician may specify a minimum and/or maximum value for ETCO2, respiration rate, and/or other monitored parameters which thereby effectively sets a range of acceptable values for those parameters. If the patient's ETCO2 parameter is outside the selected acceptable range, such as in the case where it becomes less than the minimum or greater than the maximum levels set by the clinician, the ETCO2 monitor may send a trigger signal to the interface unit 14. In response, interface unit 14 may activate a visual and/or auditory alarm (e.g., via a display in device 300, as described below), suspend operation of the pump, adjust the flow rate of the pump, and/or perform another predetermined function. For example, in response to an out-of-range ETCO2 measurement in a patient 48, interface unit 14 may cease all further administration of analgesics until after the unacceptably low or high ETCO2 value and/or respiration rate situation is resolved, such as by clinician intervention or patient change. Alternatively, interface unit 14 may simply lock-out the drug-delivery device 300 so that the patient cannot obtain further self-administrations. Thus, after appropriate values have been set up, the patient control system provides communication and coordination between the interface unit, pump, and the ETCO2 unit ensure greater safety and decreased risk of injuries from respiratory depression.

[0037] In some implementations, rather than interface unit 14 suspending operation of the pump in response to only an out-of-range signal from the ETCO2 unit or from another functional module, interface unit 14 may include program instructions for monitoring the changes in the CO2 concentration data or other data generated by the ETCO2 unit and to make decisions on whether to interfere with the patient's control of the pump module based upon the changes, such as the rate of change, in the monitored data. [0038] Typically, medical fluid administration sets have more parts than are shown in FIGS. 1-2B. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. These other devices have not been included in the drawings so as to preserve clarity of illustration. For example, patient care device 200 may include a patient- controlled analgesia (PCA) device (e.g., drug-requesting device 300) that allows patient 48 to selfadminister medication (e.g., analgesics). Refer to FIGS. 3A-4 and the related description below on how drug-requesting device 300 can be operated in conjunction with components and devices of patient care system 100, including patient care device 200.

[0039] FIGS. 3A-3J depict an example handheld electronic drug-requesting device 300 for allowing a patient to request a drug to be delivered, according to aspects of the subject technology. The illustrations and example patient interactions shown in FIGS. 3A-3 J illustrate the capabilities of the handheld device for improving patients’ experiences. As will be discussed in more detail below, drug-requesting device 300 can be used to provide indications (e.g., via user interface elements and/or audio indications) related to a patient profile of the patient, which may be helpful to patient 48 for determining when to request a dose of a drug to be delivered via drug-requesting device 300. As described herein, a patient profile may include any medical characteristics and/or patient-specific information about patient 48, such a patient diagnosis, treatment prescription, demographics, physiological parameters (e.g., weight, BMI, resting heart rate, blood pressure, etc.), scheduling information (e.g., related to physical activities that the patient will perform as part of a physical therapy program).

[0040] A patient 48 may use the drug-requesting device 300 to provide feedback regarding an amount of pain the patient is experiencing or the location of the pain so that the system (or remote clinician) may assess whether the pain is congruent with the medication provided, and to request and/or self-administer a dose of pain medication when approved by the system and/or clinician. The patient 48 can easily perform operations with drug-requesting device 300 using one hand, and in some cases, as little as a single touch input (e.g., via a patient’s thumb can cause performance of any of the operations described herein).

[0041] Aspects of the drug-requesting device 300 are described herein with reference to FIGS. 1, 2A, and 2B, and the associated components and/or processes described herein. Drugrequesting device 300 is in operable connection with one or more of fluid infusion pumps 16, 18, 20, and 22 (e.g., through an operable connection to patient care device 12, and/or another component of the patient care system 100). In some implementations, drug-requesting device 300 physically connects (e.g., via electrical wiring) to a component of the patient care device 12, such as the main frame control unit 14. In some implementations, drug-requesting device 300 wirelessly connects to the patient care system 100 (e.g., through network 110 via an API interface of information system server 130 that is in electronic communication with the patient care device 12). In some implementations, drug-requesting device 300 operably couples with one or more fluid infusion pumps of the patient care system via a decision control module that is compatible with the patient care system 100.

[0042] FIGS. 3A and 3B illustrate several different perspective views of drug-requesting device 300, according to various aspects of the subject technology. Drug-requesting device 300 includes a housing 301 that forms a handle 302 configured (e.g., arranged, shaped) for a hand of patient 48 to grasp the handle 302 (e.g., based on a length of an outer perimeter of the handle 302). In some implementations, handle 302 is an elongate member of housing 301 having a grip-sized outer perimeter along a major dimension of the elongate member. Drug-requesting device 300 also includes a display 304 embedded into housing 301 (e.g., integrated in the handle 302 above the grip area), in accordance with various implementations. Display 304 can be a circular touchscreen display (e.g., a display with a touch-activated control). Display 304 may be integrated into, or otherwise arranged on housing 301 of drug-requesting device 300, and display 304 may be positioned adjacent or within handle 302 such that it faces towards patient 48 while they are using drug-requesting device 300 (e.g., by being located on an upper end of handle 302 above a grip section of handle 302). Display 304 can present user interfaces to patient 48 related to drug delivery. For example, in FIG. 3A, display 304 displays a user interface indicating that drugrequesting device 300 is electronically coupled to a drug-delivery device (e.g., one or more of fluid infusion pumps 16, 18, 20, and 22). In some implementations, an indication that drug-requesting device 300 is electronically coupled to a drug-delivery device can include information about one or more drugs available to be delivered via the electronic coupling (e.g., based on drug libraries stored at patient care device 12).

[0043] In some implementations, drug-requesting device 300 is physically connected to the interface unit 14 or one or more components of the patient care system 100 (e.g., a syringe pump module) by a request cord 303. In some implementations, drug-requesting device 300 may form a wireless connection with patient care system 100 (e.g., a syringe pump module) and/or a component thereof.

[0044] According to various implementations, when the patient 48 requests drug delivery via device 300, an electronic communication is sent to a component of patient care system 100 (e.g., control unit 14). The component of patient care system 100 may verify the drug request, for example, by verifying that a device identifier of drug-requesting device 300 corresponds to patient 48. The component may then provide a signal to one or more of fluid infusion pumps 16, 18, 20, and 22 to cause delivery of the dose of the drug to patient 48.

[0045] The drug-requesting device 300 may include a touch-sensitive surface on the display 304, and/or a depressible mechanical button located under the display 304. In some implementations, there is a depressible mechanical button within the same user interaction area as (e.g., co-located with) the touchscreen display (e.g., the display can be an upper portion of abutton itself, or include a peripheral button integrated into some portion of the display or a perimeter area). In some implementations, drug-requesting device 300 performs a first operation based on a first user input directed to the touch-sensitive surface of the display 304, and drug-requesting device 300 performs a second operation based on a second user input directed to a depressible mechanical button located under (e.g., co-located with) the touchscreen of the display 304. For example, a first user input directed to the touchscreen can cause a display of information pertaining to the patient profile or drug available for delivery, and a second user input directed to the depressible mechanical button can cause a drug request to occur. In some implementations, the touchscreen of display 304 is configured to receive different types of patient interactions (e.g., based on respective locations of the touchscreen where patient 48 performs touch inputs).

[0046] In some implementations, the drug-requesting device 300 includes a camera 306, which may be located near display 304 to allow the camera to capture image data of patient 48 while they are using drug-requesting device 300. In some implementations, camera 306 facilitates detection of interactions and/or actions by patient 48 and/or another person in proximity to drugrequesting device 300. In some implementations, system software associated with drug-requesting device 300 may employ image recognition and/or a machine learning algorithm which may receive images from the camera and recognize actions performed by the patient (e.g., based on a trained model) based on those images. In some implementations, the algorithm may distinguish between voluntary and involuntary actions. For example, camera 306 may detect eye movements of patient 48 and map predetermined eye movements to user inputs (e.g., for requesting delivering of a dose of a drug), and/or map eye movements to a current state and/or condition of the patient that may be provided to the system as feedback before or after drug delivery.

[0047] In some implementations, camera 306 can activate automatically, without explicit user input, based on a determination related to the current state of patient 48 and/or an interaction with drug-requesting device 300. For example, in conjunction with a dose of a drug being available for delivery to patient 48 via one or more infusion pumps of patient care device 12, drug-requesting device 300 may determine, via imaging data collected by camera 306, whether patient 48 is in a state that would allow them to provide touch-based inputs (e.g., via a touch-activated surface of display 304 or by way of a button 312a). Responsive to determining that patient 48 is not in a state that allows them to provide touch -based inputs, drug-requesting device 300 may cause camera 306 to begin obtaining imaging data of patient 48 for the purpose of detecting a different type of user input (e.g., based on a head movement, an eye movement, etc.).

[0048] In some implementations, drug-requesting device 300 includes a grip sensor (e.g., a pressure sensor, piezoelectric sensor, accelerometer, or the like disposed along a portion of the handle 302), that can detect a patient 48 grasping handle 302 (e.g., via one or more pressure sensors disposed along a major dimension of the handle 302). For example, the grip sensor of the drugrequesting device 300 may detect an amount of grip pressure being applied by patient 48 at the grip sensor, and based on the amount of grip pressure, the drug-requesting device 300 may cause a pain assessment and/or alert to be presented to patient 48 based on a threshold grip pressure being applied by patient 48 (e.g., indicating that patient 48 is in pain). Patient 48 may then use the grip sensor to provide user inputs to drug-requesting device 300. For example, on detecting an even higher predetermined threshold pressure by grip pressure may cause a drug delivery request to be registered by the device 300. In some implementations, data from the grip sensor may be used to determine if a hand of patient 48 is grasping handle 302 while they request delivery of the drug. In some implementations, by detecting whether patient 48 is grasping handle 302 when the drug request is received, drug diversion is reduced by ensuring that the unauthorized drug requests are not being performed by other people that are in the same room as patient 48. [0049] In some implementations, drug-requesting device 300 includes peripheral buttons 312a and 312b, which can allow patient 48 to provide additional and/or alternative user inputs for performing operations described herein. In some implementations, a user input directed to peripheral button 312a may cause more information about the patient’s profde to be displayed, and a user input directed to peripheral button 312b may cause a drug-delivery request to occur.

[0050] In some implementations, drug-requesting device 300 includes a speaker 308 and a microphone 310 for audio interactions with the patient, which may allow for patient 48 to interact with drug -requesting device 300 while patient 48 is unable to interact via the touchscreen of display 304 or button(s) 312 (e.g., because of abnormal levels of pain). Further, the audio features provided by speaker 308 and microphone 310 can be used in conjunction with presenting user interfaces at display 304. In some implementations, patient 48 can provide a user input at display 304 that causes microphone 310 to be activated, and patient 48 can provide vocal user inputs (e.g., which may be provided to a clinician). In some implementations, an audio signal can be provided in conjunction (e.g., simultaneously) with a user interface being presented (e.g., as part of an alert). For example, based on detecting an indication that drug diversion is occurring, the patient care system may provide an alert user interface to patient 48 via a user interface element displayed on display 304 indicating that patient 48 is no longer able to cause a dose of a drug to be delivered, and audio can be provided via speaker 308 with the same or similar information to draw the attention of patient 48 to the alert user interface. Providing such dynamic interactions enhances patient treatment by ensuring that patient 48 is alerted of high priority information (e.g., that drug delivery will be halted to mitigate a drug diversion attempt).

[0051] In some implementations, drug-requesting device 300 includes one or more sensors that are not visible from the outer surface of drug-requesting device 300. In some implementations, drug-requesting device 300 includes an accelerometer (not shown) within housing 301 for detecting movement by patient 48. Patient care system 100 can detect, via the accelerometer, a movement by patient 48 after initiation of delivery of the dose of the drug. In this regard, patient care system 100 can be configured to execute instructions for mapping accelerometer measurements to predetermined movements and, based on determining a movement by patient 48 matches a predetermined movement, determine that patient 48 is experiencing an adverse patient interaction (e.g., an involuntary movement) to the drug delivery. In some implementations, the patient-interaction information is based on a voluntary patient interaction with drug-requesting device 300 (e.g., alerting a clinician, administering a dose of a drug, performing a pain assessment, etc.). For example, patient 48 may be able to provide a user input to a pain assessment by performing a hand gesture (e.g., a hand rotation) while gripping the handle, which can be detected by the accelerometer. In some implementations, data collected by one or more sensors of drugrequesting device 300, including the accelerometer, can be provided to a machine-learning model, as described below with respect to process 400 which may be remote from drug-requesting device 300 (e.g., at the information system server 130). As described previously, one or more sensors external to drug-requesting device 300 can be used in conjunction with any of the operations described herein. For example, an SpO2 sensor may be attached to a fingertip of patient 48, and drug-requesting device 300 may use data from the external SpO2 sensor to determine a state of patient 48.

[0052] In some implementations, one or both of the camera 306 and the display 304 may be used to establish a connection between the drug-requesting device 300 and the patient care device 200 (or component thereof) that will administer the requested drug. For example, the camera 306 may be used to scan a barcode of a patient, clinician, or device to associate the patient, clinician, or device with the drug-requesting device 300. Once scanned, the drug-requesting device 300 may send a message including an identifier for itself and the associated patient, clinician, or device to create the association. In some implementations, the display 304 may be configured to present a barcode or other encoded information to identify the drug-requesting device 300. This information may be scanned by, for example, an EMR barcode scanner to create an association between the drug-requesting device 300 and a patient, clinician, or administration device.

[0053] FIG. 3C depicts drug-requesting device 300 displaying a user interface that includes several user interface elements for facilitating the patient’s experience with drug-requesting device 300. According to various implementations, the patient care system monitors how much medication a patient 48 has been provided over the course of a treatment. Total dosage amounts may be stored in an EMR database 137 for each medication provided to the patient. The database may further include patient data based on medical information for the patient (e.g., medication orders, medication limits, demographics, physiological measurements, lab values, etc.) and pharmacokinetics of the medication provided, and the system may monitor medication administration in view of the patient data to determine when it is acceptable for a patient to receive another dose of the medication and/or the amount that may be dosed. In this manner, information pertaining to when the patient can receive a further dose of a medication may be communicated via display 304 of the drug-delivery device 300, thereby relieving the burden on clinicians to manage patient requests.

[0054] In the depicted example, a user interface element 314 displayed on display 304 provides an indication that a dose of a particular drug (e.g., Drug A) is available for delivery to patient 48 (e.g., in response to a patient request) and that the patient may request the dose be delivered immediately to the patient via an interaction with drug-requesting device 300. Another user interface element 316 may indicate a location of the touchscreen of display 304 that patient 48 can provide a user input to in order to cause delivery of a drug to patient 48 (e.g., via a fluid infusion pump). In some implementations, the patient care system displays via the user interface of display 304 a time when a next dose is going to be available to be delivered after patient 48 requests delivery of the dose currently available. For example, user interface element 318 may indicate a countdown including an amount of time before patient 48 will be able to request delivery of another dose of the drug (and/or a different drug).

[0055] In some implementations, the patient care system 100 may determine and provide, via the user interface, information related to a physical activity that patient 48 is scheduled to partake, or is required to undertake before another dose may be delivered, which may be based on scheduling information related to the patient’s patient profile (e.g., received from the information system server 130). In some implementations, patient care system 100 can provide user interfaces to display 304 that include information also being presented at the display 6a of interface unit 14, for example, mirroring the display 6a. In some implementations, patient care system 100 is configured such that a first user input directed to the location on the touchscreen of user interface element 316 causes delivery of a dose of a drug, and a second user input directed to user interface element 318 can cause different information from the patient profile of patient 48 to be displayed.

[0056] FIG. 3D shows patient 48 performing a gesture 320 directed to the user interface shown displayed on display 304 of drug-requesting device 300 in FIG. 3C. The patient care system detects and maps gestures to predetermined gestures to determine actions performed by the patient. The gesture 320 performed by patient 48 may be a touch gesture directed to display 304 (which may be a touch-sensitive display), and/or the gesture 320 may be a press gesture to depress a mechanical button that is co-located with the display 304 of the drug-requesting device 300. In some implementations, patient 48 may perform gestures directed to other inputs of the drugrequesting device 300, such as press gesture directed to one of peripheral buttons 312a and 312b. In some implementations, patient 48 can provide audio input, and/or eye movements, to cause the drug request to occur. In some implementations, other interactions detected by one or more sensors of the drug-requesting device may cause interactions with drug-requesting device 300 while the user interface is displayed. For example, a voice input detected by microphone 310 may cause actuation of drug delivery without the any additional inputs provided by the patient. In some implementations, usage data, such as gesture 320 can be collected by drug-requesting device 300 and provided to another component of patient care system 100. For example, data related to gesture 320 can be provided by patient care system 100 to a machine-learning model stored at information system server 130, which may be used to determine whether any aspect of gesture 320 indicates that drug-diversion may be occurring (e.g., gesture 320 may not match other similar gestures performed by patient 48).

[0057] FIG. 3E illustrates another user interface being presented by display 304 of drugrequesting device 300, which includes a confirmation user interface element 322 indicating that the dose of the drug was successfully delivered. In some implementations, other information can be presented in conjunction with confirmation user interface element 322. For example, a user interface element similar to user interface element 318 may be presented in conjunction with confirmation user interface element 322, allowing patient 48 to know when another dose will be available to be delivered after patient 48 has successfully delivered the current dose. In some implementations, a reminder user interface element can be presented in conjunction with the confirmation user interface element, where the reminder user interface element reminds patient 48 when they are recommended to cause delivery of another dose of the drug based on information from the patient profile related to an activity that patient 48 is scheduled to perform (e.g., physical therapy, preparation for an operation).

[0058] In some implementations, patient care system 100 may provide for display via display 304 a countdown interface or element showing a duration of time until the next dose of medication will be available for request. That is, after a medication is provided by the associated pump(s), the patient care system may determine based on pharmacokinetics of the medication provided, patient profile (including, e.g., patient weight, BMI, demographics, etc.), current measured physiological data (e.g., from a connected sensor), and other available information when a next administration of the medication would be safe for the patient. In some implementations, the time duration may be based on a medication order for the medication (e.g., provided and/or entered by a clinician to the EMR system). The interval between dosages may be displayed in units of time (e.g., fifteen minutes before, ten minutes before, five minutes before) and/or may include a real-time countdown before the activity. In this way, drug-requesting device 300 can provide patient 48 with relevant information that they may wish to know prior to experience any sedation or other mental effects caused by delivery of the dose of the drug.

[0059] FIG. 3F shows another user interface being presented at display 304, the user interface including a prompt for patient 48 to perform a pain assessment. In some implementations, drug-requesting device 300 can provide alternative means for patient 48 to provide user inputs related to the pain assessment (e.g., to account for sedation, acute pain, or any other effects that limit the ability of patient 48 to provide user inputs to the touchscreen of display 304). For example, camera 306 may be activated by patient care system 100 after patient 48 causes delivery of the drug, and can obtain image data of patient 48 to determine a state that patient 48 is in after a dose of a drug has been delivered. In the example shown, patient 48 is instructed (e.g., via display 304 or by an audio prompt provided by speaker 308) to perform eye movements to provide the pain assessment, and the eye movements may be provided to adjust the indication of the level of pain experienced by patient 48 that is shown in by the pain assessment indicator. For example, a magnitude of an eye movement in a particular direction may be processed and detected by the patient care system based on images received from the camera. The patient care system may cause the indicator of the pain assessment user interface to move on the display 304 with and/or a distance that corresponds to the magnitude of the detected eye movement, which may occur in real-time as patient 48 is performing the eye movement. In this regard, patient 48 may visualize the resulting input that will be provided based on the eye movement, and the patient care system may, based on the imaging data, detect a number of times that patient 48 blinks, and move the indicator a predefined discrete amount within the pain assessment user interface element based on the number of blinks. In this way, drug-requesting device 300 provides convenient interactions for patients with limited mobility, or temporary incapacity based on a medical situation (e.g., an abnormal amount of pain being experienced by patient 48). [0060] In some implementations, camera 306 can also be used to collect biometric data, which may be used to authorize patient 48 as the appropriate recipient of the dose of the drug. For example, the camera may be used to authenticate patient 48 based on facial recognition. In some implementations, one or more other sensors of drug-requesting device 300, and/or sensors physically separate from but in electronic communication with drug-requesting device 300 may be used to verify the identity of patient 48. For example, a fingertip scanner and/or a card scanner attached to drug-requesting device 300, or another device that is physically separate from drugrequesting device 300, but in electronic communication with patient care system 100 may be used to verify the identity of patient 48 as part of a dose request, in accordance with some implementations.

[0061] In some implementations, data collected via the pain assessment can be provided to a machine-learning model (e.g., stored at information system server 130), which can be used to determine that a level of pain currently being experienced by patient 48 does not correspond to an expected pain value, based on an amount of the drug that was delivered to patient 48 (e.g., an indication that patient 48 is still experiencing high levels of pain after delivery of a dose of analgesic that should have reduced an amount of pain that patient 48 is experiencing). In some implementations, another user interface can be presented to patient 48 (and/or a clinician associated with patient care system 100) to indicate that drug delivery will become unavailable (e.g., based on the patient care system determining that drug diversion is or may be occurring).

[0062] FIGS. 3G-3J show additional examples of user interfaces that can be provided at display 304 of drug-requesting device 300. Specifically, FIGS. 3G-3I show distinct pain assessment user interfaces that can be provided to patient 48 via display 304 by the patient care system 100. In some implementations, different pain assessment user interfaces are provided to patient 48 based on respective circumstances for the pain assessment being initiated. In some implementations, a machine-learning model is used to determine which type of pain assessment to present to patient 48 (e.g., based on a level of accuracy of respective responses to the type of pain assessment). In some implementations, patient 48 can manually toggle between pain assessment types (e.g., by providing a user input to peripheral button 312a).

[0063] FIG. 3G shows a pain assessment user interface that includes a sliding scale user interface element that patient 48 can interact with to indicate a level of pain that patient 48 is experiencing along the sliding scale. In some implementations, patient 48 can indicate a level along the sliding scale without providing a user input to the touchscreen of display 304. For example, the device 300 may include an accelerometer which measures movements of the device. In this regard, accelerometer data is sent to the patient care system which can then detect a hand gesture by patient 48 based on the data. In this regard, an amount of pain may be indicated by measuring an amount of rotational and/or translational movement of the user’s hand in a particular direction while the scale user interface element is presented. That is, a greater magnitude of translational and/or rotational movement detected by the accelerometer can indicate a higher level of pain being experienced by patient 48. In some implementations, the patent care system may determine a level of pain by matching accelerometer readings with predetermine patterns consistent with pain. In some implementations, a user input can include a facial movement (e.g., a head movement and/or an eye movement) detected by camera 306, as shown in FIG. 3F. Facial images obtained by the camera, real time changes to the images, and motion of the images may be matched against predetermined facial patterns to determine whether the patient is experiencing a level of pain.

[0064] FIG. 3H shows a pain assessment user interface that includes a depiction of a human body and can be used to allow patient 48 to indicate which part of their own body they are experiencing pain. In some implementations, camera 306 can be used for patient 48 to indicate a location of pain. For example, camera 306 may be activated in conjunction with the pain assessment user interface being presented, and imaging data, obtained by the camera 306, of patient 48 touching a particular body part (e.g., touching a can be used to determine that patient 48 is experiencing pain at the particular body part). In some implementations, a speaker 308 can sequentially list body parts, and patient 48 can provide a user input (e.g., via a voice command detected by microphone 310) to indicate whether a listed body part is in pain. For example, patient 48 may depress button 312 (or a touch element on a touchscreen 304) when a body part is audibly identified that is experiencing pain, which can be provided from drug-requesting device 300 to another device of the patient care system 100 to determine an aspect of drug delivery (e.g., a type of PCA to make available to the patient 48 based on the location where the pain is being experienced, or a time period for making another dose of a drug available for delivery to the patient 48). For example, a pain assessment indicating a body part where pain relief should have been received based on a previous drug delivery may indicate that drug diversion is occurring and therefore a particular drug should not be made available via patient request at the drug-delivery device 300. In some implementations, the indication provided by patient 48 that they are experiencing pain at a particular body part can be input to a machine-learning model to determine whether a dose delivered to patient 48 in response to a drug request (or another aspect of treatment of patient 48) was effective.

[0065] FIG. 31 shows a pain assessment user interface that includes selectable yes and no checkbox user interface elements for patient 48 to provide a binary selection in response to a question relevant for a pain assessment. In some implementations, the patient care system may present symbols on the display 304, which can then be selected to indicate the patient’s response to questions or requests. By touching the symbols on the screen to indicate the appropriate negative or positive response, the patient may provide feedback which may be logged and used to determine, for example, when a dose becomes available for administration or to determine the amount of a dose. Drug-requesting device 300 can provide sequential binary selections to patient 48 as part of a single pain assessment.

[0066] In some implementations, the questions may be used to assess whether the patient is attempting diversion. For example, the patent care system may obtain answers regarding pain assessments (e.g., based on gripping the handle or via accelerometer readings, eye movements, etc.) or other extra-sensory data (e.g., from ETCO2, SPO2, etc.) and determine that the answers are consistent with diversion activities. In some implementations, as shown in FIG. 3J, an alert interface may be provided to indicate that drug delivery will be halted (e.g., based on an indication that drug diversion is occurring, and/or that patient 48 is not in a stable condition). In some implementations, an alert user interface may include user inputs for requesting assistance from a clinician (e.g., to mitigate an emergency and/or otherwise critical condition).

[0067] FIG. 4 depicts an example process 400 for performing PCA operations at a patient care system that includes a handheld electronic drug-requesting device (e.g., drug-requesting device 300), according to aspects of the subject technology. For explanatory purposes, the various blocks of example process 400 are described herein with reference to FIGS. 1-3, and the associated components and/or processes described herein. The one or more blocks of process 400 may be implemented, for example, by one or more computing devices including, for example, infusion control module 114 (also referred to herein as interface unit 14), information system server 130, one or more of functional modules 16, 18, 20, and 22, drug-requesting device 300, and/or client computing device 32. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some implementations, one or more of the blocks may be implemented apart from other blocks, and by one or more different processors or devices. Further, for explanatory purposes, to the extent that the blocks of example process 400 are described as occurring in serial, or linearly, in some implementations, multiple blocks of example process 400 may occur in parallel (e.g., blocks 406 and 408 may occur in parallel). The blocks of example process 400 need not be performed in the order shown, and one or more blocks of the example process 400 need not be performed, in according with some implementations.

[0068] In the depicted example, a drug-requesting device 300 is provided (402). According to various implementations, drug-requesting device 300 includes a handle, a display, a touch-activated control, one or more processors and memory. While the description of example process 400 focuses the operations performed, it is understood that drug-requesting device 300 can include some or all of the structural features and components described with respect to FIGS. 3 A to 3 J above.

[0069] According to some implementations, the patient care system 100 and/or a component within patient care system 100 (e.g., patient care device 12, one or more functional modules 16, 18, 20, and 22) determines whether drug-requesting device 300 is electronically coupled to a drug-delivery device (e.g., one or more of fluid infusion pumps 16, 18, 20, and 22) for delivering a drug to a patient (404). For example, drug-requesting device 300 (or an associated algorithm) may perform a polling operation to determine that the infusion pump of patient care system 100 is in proximity to patient 48. In some implementations, the drug-requesting device 300 transmits an identifier to the patient care system as part of a device authentication process (e.g., a secure handshake). In some implementations, determining whether drug-requesting device 300 is electronically coupled to one or more drug-delivery devices includes and/or is based on determining that patient 48 is authorized to received delivery of the dose of the drug, which may be based on information from the patient’s patient profile. In some implementations, the determination that patient 48 is authorized to the receive delivery of the drug includes detecting biometric data about patient 48 via one or more sensors located at or otherwise in electronic communication with the drug-requesting device 300 (e.g., camera 306). Data including the biometric information may be provided to another component of patient care system 100 (e.g., information system server 130).

[0070] In response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, drug-requesting device 300 receives information related to a patient profde associated with 48 from the drug-delivery device (406). For example, the patient care system 100 (e.g., interface unit 14) may query a database or may otherwise access information about the patient profde from the external database 137 (e.g., via an operation performed at the patient care device 12). The patient profde may include, for example, information from information system server 130 indicating a schedule of when doses of one or more drugs will be available to be delivered to patient 48.

[0071] The depicted example 400 continues with drug-requesting device 300 presenting a user interface element on the display 304 to the patient including the information related to the patient profde associated with the patient (408). In some implementations, the user interface element(s) displayed on display 304 may be rendered by a local process within device 300. In some implementations, the user interface element(s) are rendered by one or more components of patient care system 100 (e.g., interface unit 14 or an associated server) and provided to the device 300 for presentation on display 304. In accordance with previously-described processing, for example by an algorithm, the user interface element may display profde information concurrently with a second user interface for providing a patient request to deliver a dose of a drug, as discussed with respect to operation 410. Similarly, the user interface element may be configured to include an amount of time before patient 48 will be able to cause another dose of the drug to be delivered (e.g., a distinct dose of the same or a different drug). For example, the user interface displayed at display 304 of drug-requesting device 300 in FIG. 3C includes a user interface element 316 indicating a location on display 304 where patient 48 can provide a touch input to actuate a drug request. And the user interface includes another user interface element 318 indicating when another dose will be available to be delivered (e.g., based on patient-specific information in the patient profile).

[0072] In some implementations, the same or a different user interface may present information related to the patient profile that includes a reminder to administer a particular dose of medication at least a predefined amount of time before a scheduled physical activity (e.g., as part of a physical therapy program for the patient) is scheduled to occur. That is, a separate user interface may be displayed with the reminder, at a different time than a patient request can be received (e.g., at a time when patient 48 is not currently able to request a dose to be delivered). For example, a separate user interface may be presented fifteen minutes before a dose is available to be delivered, and may indicate that patient 48 should consider requesting a dose within the next thirty minutes.

[0073] The example process 400 continues with drug-requesting device 300 receiving, concurrently with the user interface element being presented on display 304, a patient request to deliver a dose of the drug to patient 48 via a touch-activated control (e.g., the touchscreen of display 304) (410). In some implementations, the device 300 is configured to detect when the handle is grasped by patient 48. In some implementations, the request to deliver the dose will only be received by the device 300 after a grasping of the handle is detected. In some implementations, the patient request can be detected without the handle of the drug-requesting device being grasped by the patient. For example, patient 48 may be temporarily unable to hold drug-requesting device 300, and may still request the delivery of a dose of the drug (e.g., using a voice command).

[0074] In some implementations, the patient request is provided as a user input selected from a group consisting of (i) an audio input (e.g., vocalizations identified (e.g., via an Al model) as being performed by patient 48), and (ii) a visually-detectable input (e.g., a facial -movement- based input detected via pupillometry sensors configured to monitor the patient’s eye movements and/or identify patient 48 via pupil features). In some implementations, based on a determination that there is a dose available to be delivered to patient 48, drug-requesting device 300 can access information about patient 48 (e.g., via one or more sensors of drug-requesting device 300, such as camera 306, and/or information from the patient profile of patient 48) to determine how to provide an indication to patient 48 about the availability of the dose. For example, based on determining patient 48 is not in a state where they can cause doses to be delivered, drug-requesting device 300 may provide an audial indication to patient 48 (e.g., via speaker 308), and the audio prompt may indicate that patient 48 can provide the request via different means than a touch input.

[0075] Responsive to the patient request, drug-requesting device 300 causes the dose of the drug to be delivered to patient 48 (e.g., via a drug-delivery device that is operably connected to drug-requesting device 300 (e.g., physically and/or electronically connected) (412). According to various implementations, the device 300 causing the dose to be delivered includes the device 300 sending the request to a processing component of the patient care system, which then processes the request in accordance with the various implementations described herein and signals the infusion device to deliver the dose. In some implementations, the patient 48 is not required to grasp the handle of drug-requesting device in order to cause delivery of a dose of the drug (e.g., when the patient is immobilized by a particular health condition the patient 48 is experiencing).

[0076] In some implementations, before or after causing the dose of the drug to be delivered, one or more cameras (e.g., camera 306) of drug-requesting device 300 obtain image data. Drug-requesting device 300 may use the imaging data to confirm, based on the imaging data captured by the camera, that patient 48 is in fact the person actuating the drug request, and/or that patient 48 is authorized to self-administer the dose of the drug from the drug-delivery device (e.g., based on comparing the biometric information to information from the patient’s drug-delivery profile). Drug-requesting device 300 may use the imaging data to perform a pain assessment of patient 48 (e.g., determining a level of pain that patient 48 is in based on shifting of the patient’s body, such as clenching fists, rubbing or holding the painful area, etc.). And the patient control unit may use the imaging data to detect a pain-indicating user input (e.g., eye movements) directed to one or more patient-interactable affordances presented within a pain-assessment user interface. In some implementations, one or more of the operations can be performed using a sensor of the one or more sensors different from the camera can be used, additionally, or alternatively, to the imaging data from the camera.

[0077] In some implementations, after the dose of the drug has been caused to be delivered to patient 48 via the drug-delivery device, drug-requesting device 300 presents a confirmation user interface element to patient 48 indicating that the dose of the drug has been successfully delivered (e.g., a user interface indicating a type of medication and an amount of the dose of medication, such as confirmation user interface element 322 shown in FIG. 3E). In some implementations, before or after the dose of the drug has been delivered, drug-requesting device 300 presents (e.g., via display 304) a pain-assessment user interface, the pain-assessment user interface including selectable user interface elements for allowing patient 48 to perform a pain assessment (e.g., the pain assessment user interface shown in FIGS. 3E and 3F). [0078] In some implementations, patient care system 100 can determine whether patient 48 is interacting with any other electronic devices that can be used to supplement and/or replace operability of drug-requesting device 300. For example, in accordance with patient care system 100 determining that patient 48 is using an augmented-reality device in operable communication with patient care system 100, any of the operations of process 400 described above can optionally be implemented at the augmented-reality device. In this way, the intuitive and efficient means of interaction provided by operations, user interfaces, and other aspects of process 400 can be provided to patient 48 regardless (e.g., agnostic to) physical hardware being used by patient 48 to cause the operations to be performed.

[0079] In some implementations, patient care system 100 can determine a subset of operations that are capable of being performed more effectively by a different electronic device in operable communication with patient care system 100, and may offload that subset of operations to respective different electronic device that are in operable communication with patient care system 100. For example, patient care system 100 may determine that a sensor connected to a fingertip of patient 48 is more accurate and/or efficient for detecting a specific biometric signal of patient 48, and/or that an eye-tracking sensor of an augmented-reality system is more capable of detecting eye movements performed by patient 48, and that subset of operations may be offloaded to the different devices, while another subset of operations (e.g., detecting touch inputs at the touchscreen of display 304) would be more efficient or intuitive to be performed at drug-requesting device 300.

[0080] As described previously, a machine-learning model may be used to analyze interactions by patient 48 with drug-requesting device 300 and/or determine whether a request for a bolus of a drug should be authorized and delivered. The machine-learning model may be trained and implemented at a different electronic device of patient care system 100 (e.g., information system server 130). In some implementations, the machine-learning model may be configured to determine if a particular interaction by patient 48 indicates that drug diversion may be occurring within patient care system 100. For example, in some implementations, the patient care system 100 may collect usage data associated with a plurality of handheld electronic devices 300 for delivered doses of the drug across a patient population (e.g., within a care center), determine drug response times and/or motion patterns based on patients in the population receiving a similar dose associated with the request, compare the patient’s response to the dose (e.g., based on accelerometer, image, and/or physiological sensor data), and determine drug diversion may be occurring when the patient response is inconsistent with a mean or average response time and/or motion pattern based on the population (e.g., is outside a tolerance). In some implementations, one or more sensors located at or in electronic communication with drug-requesting device 300 (e.g., imaging data obtained by camera 306, motion data and/or orientations data detected by an accelerometer of drug-requesting device 300) can be provided as usage data to the machinelearning model. Certain usage data of patient 48 may not be provided in conjunction with usage data of the other patients in the patient population (e.g., based on data privacy laws). In some implementations, the usage data is provided in a way that anonymizes the protected health information (PHI) of patient 48 and other patients within the patient population.

[0081] According to various implementations, the usage data of the patient 48 is input into the machine-learning model, and the machine-learning model can be used to determine, based on the usage data, that a particular drug request actuated at drug-requesting device 300 does not conform to the patient population. In some implementations, the drug-requesting device 300 provides, responsive to determining that the patient request does not conform to the patient population, an alert (e.g., to a device associated with a caregiver of patient 48) indicating that the machine-learning model is detecting a drug diversion attempt based on an aspect of the patient request. In some implementations, the machine-learning model can be further trained based on an input provided by patient 48 responsive to the alert (e.g., when displayed at the drug-requesting device 300). The module may, based on the additional input, determine that drug-diversion was in fact not occurring, and that patient 48 actuated the drug requesting and the dose of the drug was successfully delivered to patient 48. As described previously, drug-requesting device 300 can collect pain assessment information from patient 48 via one or more sensors (e.g., as shown in FIG. 3F). Drug-requesting device 300 can determine, based on inputting the pain assessment information to the machine-learning model, that a level of pain of patient 48 does not correspond to an expected pain value based on an amount of a drug delivered to patient 48. The pain assessment indications may be provided to the machine-learning model where the pain assessment indications are used in conjunction with the usage data to determine if the machine-learning model is detecting the drug diversion attempt. Drug diversion may be ruled out, for example, when pain assessment indicates a reduction in pain that is expected for the patient based on the collected patient information and pharmacokinetic profde of the drug. [0082] In some implementations, in accordance with applying the usage data to the machine-learning model, the machine-learning model can determine that a dosage amount configured to be delivered to patient 48 is too high. Based on the determination, one or more components of patient care system 100 can lower the dosage amount configured to be delivered to patient 48. For example, a low than typical number of drug requests may indicate that patient 48 is avoiding using the dose-requester when they are or should be experiencing pain may indicate that the dosage amount is too high for a drug tolerance of patient 48 for the drug.

[0083] Many of the above-described operations of example process 400, and related features and applications, may also be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium), and may be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) 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. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0084] The term “software” is meant to include, where appropriate, firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while remaining distinct software aspects of the subject disclosure. In some implementations, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software aspect described here is within the scope of the subject disclosure. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

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

[0086] FIG. 5 is a conceptual diagram illustrating an example electronic system 500 for operating an analgesia administration system, according to aspects of the subject technology. Electronic system 500 may be a computing device for execution of software associated with one or more portions or steps of process 400 of FIG. 1, or components and processes provided by FIGS. 1-3, including but not limited to information system server 130, computing hardware within patient care device 12, or administration set 32. Electronic system 500 may be representative, in combination with the disclosure regarding 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, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or any other sort of computer-related electronic device having network connectivity.

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

[0088] Bus 508 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 500. For instance, bus 508 communicatively connects processing unit(s) 512 with ROM 510, system memory 504, and permanent storage device 502. [0089] From these various memory units, processing unit(s) 512 retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The processing unit(s) can be a single processor or a multi-core processor in different implementations.

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

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

[0092] Bus 508 also connects to input and output device interfaces 514 and 506. Input device interface 514 enables the user to communicate information and select commands to the electronic system. Input devices used with input device interface 514 include, e.g., alphanumeric keyboards and pointing devices (also called “cursor control devices”). Output device interfaces 506 enables, e.g., the display of images generated by the electronic system 500. Output devices used with output device interface 506 include, e.g., printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.

[0093] Also, as shown in FIG. 5, bus 508 also couples electronic system 500 to a network (not shown) through network interfaces 516. Network interfaces 516 may include, e.g., a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interfaces 516 may also include hardware (e.g., Ethernet hardware) for connecting the computer to a part of a network of computers such as a local area network (“LAN”), a wide area network (“WAN”), wireless LAN, or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system 500 can be used in conjunction with the subject disclosure.

[0094] These functions described above can be implemented in computer software, firmware, or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.

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

[0096] While the above discussion primarily refers to microprocessor or multi-core processors that execute 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 that are stored on the circuit itself.

[0097] As used in this specification and any claims of this application, the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0098] To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; e.g., feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; e.g., by sending web pages to a web browser on a user’s client device in response to requests received from the web browser.

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

[00100] The computing system can include clients and servers. A client and server 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 transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

[00101] Those of skill in the art would appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in varying ways for each particular application. 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 subject technology.

[00102] Illustration of Subject Technology as Clauses:

[00103] Various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.) for convenience. These are provided as examples, and do not limit the subject technology. Identifications of the figures and reference numbers are provided below merely as examples and for illustrative purposes, and the clauses are not limited by those identifications.

[00104] Clause 1. A handheld electronic drug-requesting device, comprising: a handle configured to be grasped by a hand of a patient; a display embedded into the handle; a touch- activated control integrated in the handle or the display; one or more processors; and memory, comprising instructions, which, when executed by the one or more processors, cause operations comprising: determining the handheld electronic drug-requesting device is electronically coupled to a drug-delivery device for delivery of a drug to the patient; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver of a dose of the drug to the patient via the touch-activated control; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

[00105] Clause 2. The handheld electronic drug-requesting device of Clause 1, wherein the user interface element including the information related to the patient profile is presented concurrently with a second user interface element for providing the patient request to deliver the dose of the drug, and the information related to the patient profile includes an amount of time before the patient will be able to cause another dose of the drug to be delivered.

[00106] Clause 3. The handheld electronic drug-requesting device of one of Claim 1 or Claim 2, wherein: the information related to the patient profile includes a reminder to administer a particular dose of medication at least a predefined amount of time before a scheduled physical activity is scheduled to occur.

[00107] Clause 4. The handheld electronic drug-requesting device of any one of Clauses 1 through 3, wherein the patient request is provided as a user input selected from a group consisting of: (i) an audio input, and (ii) a visually-detectable input.

[00108] Clause 5. The handheld electronic drug-requesting device of any one of Clauses 1 through 4 , further comprising one or more sensors configured to detect a state of the patient, wherein the operations further comprise: responsive to a first detection that the patient is in a first state indicative that the patient is stable and capable of providing inputs at the touch-activated control, providing a user interface element responsive to user inputs for requesting delivery of the dose of the drug; and responsive to a second detection that the patient is in a second state indicative that the patient is incapable of providing the inputs at the touch-activated control, providing an alternative means, distinct from the user interface element, for allowing the user patient to request delivery of the dose of the drug.

[00109] Clause 6. The handheld electronic drug-requesting device of Clause 5, wherein the one or more sensors include a camera located on a patient-facing portion of the handheld electronic drug-requesting device, and the handheld electronic drug-requesting device further comprises instructions for performing, based on imaging data captured by the camera, an operation from the group consisting of: confirming, based on the imaging data captured by the camera, that the patient is authorized to self-administer the dose of the drug from the drug-delivery device; performing a pain assessment of the patient; and detecting a pain-indicating user input directed to one or more patient-interactable affordances presented within a pain-assessment user interface.

[00110] Clause 7. The handheld electronic drug-requesting device of any one of Clauses 1 through 6, further comprising instructions for: after the dose of the drug has been caused to be delivered to the patient via the drug-delivery device: presenting a confirmation user interface element to the patient indicating that the dose of the drug has been successfully delivered.

[00111] Clause 8. The handheld electronic drug-requesting device of any one of Clauses 1 through 7, wherein the display includes a touch- sensitive surface configured to receive touch inputs, and the display is configured to detect (i) a first user input directed to the touch-sensitive surface, and (ii) a second user input directed to a depressible mechanical button located under the touch-sensitive surface of the display.

[00112] Clause 9. The handheld electronic drug-requesting device of any one of Clauses 1 through 8, further comprising: an elongate structure configured to be gripped by a hand of the patient while a thumb of the patient interacts with one or more of the touch-activated control and a depressible mechanical button.

[00113] Clause 10. The handheld electronic drug-requesting device of Clause 9, wherein the handle comprises a sensor configured to detect a grip pressure being applied by the hand of the patient, and further comprising instructions for: receiving, from the sensor, sensor data based on the grip pressure being applied by the hand of the patient; and causing a pain assessment of the patient to be performed based on the grip pressure being applied by the hand of the patient. [00114] Clause 11. The handheld electronic drug-requesting device of any one of Clauses 1 through 10, further comprising: presenting, via the display, a pain-assessment user interface, the pain-assessment user interface including selectable user interface elements for allowing the patient to perform a pain assessment.

[00115] Clause 12. The handheld electronic drug-requesting device of any one of Clauses 1 through 11, further comprising: an accelerometer for detecting movement by the patient; and instructions for: detecting, via the accelerometer, a movement by the patient after initiation of delivery of the dose of the drug; and based on determining that the movement by the patient corresponds to an adverse patient interaction, based on an interaction by the patient detected by one or more sensors of the handheld electronic drug-requesting device, providing patientinteraction information to another electronic device.

[00116] Clause 13. The handheld electronic drug-requesting device of any one of Clauses 1 through 12, further comprising instructions for: collecting usage data associated with a plurality of handheld electronic devices for delivered doses of the drug across a patient population; inputting the usage data to a machine-learning model; determining, based on inputting the usage data to the machine-learning model, that the patient request does not conform to the patient population; and presenting, responsive to determining that the patient request does not conform to the patient population, an alert to the display or to a device associated with a caregiver of the patient indicating that the machine-learning model is detecting a drug diversion attempt based on an aspect of the patient request.

[00117] Clause 14. The handheld electronic drug-requesting device of Clause 13, further comprising instructions for: collecting pain assessment information from the patient via one or more sensors; determining, based on inputting the pain assessment information to the machinelearning model, that a level of pain of the patient does not correspond to an expected pain value based on an amount of a drug delivered to the patient; and causing pain assessment indications to be provided to the machine-learning model, wherein the pain assessment indications are used in conjunction with the usage data to determine if the machine-learning model is detecting the drug diversion attempt. [00118] Clause 15. The handheld electronic drug-requesting device of Clause 14, further comprising instructions for: in accordance with applying the usage data to the machine-learning model, determining that a dosage amount configured to be delivered to the patient is too high; and lowering the dosage amount configured to be delivered to the patient.

[00119] Clause 16. The handheld electronic drug-requesting device of any one of Clauses 1 through 15, further comprising instructions for: based on an interaction by the patient detected by one or more sensors of the handheld electronic drug-requesting device, providing patientinteraction information to another electronic device.

[00120] Clause 17. The handheld electronic drug-requesting device of any of Clauses 1 through 16, further comprising instructions for: detecting that the handle is grasped by a hand of the patient, and authorizing the drug request by the patient based on the handle being grasped by the hand of the patient.

[00121] Clause 18. A machine-implemented method, comprising: determining a handheld electronic drug-requesting device is electronically coupled to a drug-delivery device for delivery of a drug to a patient grasping the handheld electronic drug-requesting device; receiving, by the handheld electronic drug-requesting device, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profile associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profde associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver a dose of the drug to the patient via a touch-activated control of the handheld electronic drug-requesting device; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

[00122] Clause 19. A system, comprising: a drug-delivery device in operable communication with a control unit for controlling drug delivery to a patient via the drug-delivery device, wherein the control unit includes a handheld electronic drug-requesting device; one or more processors; and memory, including instructions, which, when executed by the one or more processors, cause performance of operations, comprising: determining a handheld electronic drug- requesting device is electronically coupled to the drug-delivery device for delivery of a drug to the patient; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drugrequesting device, a patient request to deliver a dose of the drug to the patient via a touch- activated control of the handheld electronic drug-requesting device; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

[00123] Clause 20. A non-transitory computer-readable storage medium comprising instructions, which, when executed by one or more processors of a handheld electronic drugrequesting device in operable communication with a drug-delivery device, cause performance of operations, comprising: determining a handheld electronic drug-requesting device is electronically coupled to the drug-delivery device for delivery of a drug to a patient grasping the handheld electronic drug-requesting device; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profile associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profde associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver a dose of the drug to the patient via a touch-activated control of the handheld electronic drug-requesting device; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

[00124] Further Consideration:

[00125] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration 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 meant to be limited to the specific order or hierarchy presented.

[00126] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (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.

[00127] The term website, as used herein, may include any aspect of a website, including one or more web pages, one or more servers used to host or store web related content, etc. Accordingly, the term website may be used interchangeably with the terms web page and server. The predicate words “configured to,” “operable to,” and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. For example, a processor configured to monitor and control an operation, or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.

[00128] The term automatic, as used herein, may include performance by a computer or machine without user intervention; for example, by instructions responsive to a predicate action by the computer or machine or other initiation mechanism. The word “example” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[00129] A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. A disclosure relating to an embodiment may apply to all implementations, or one or more implementations. An embodiment may provide one or more examples. A phrase such as an “embodiment” may refer to one or more implementations and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to 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.

[00130] 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, a database, or another data structure), ascertaining and the like via a hardware element without user intervention. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element without user intervention. “Determining” may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention.

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

[00132] As used herein, the term “message” encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine- readable aggregation of information such as an XML document, fixed field message, comma separated message, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.

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

[00134] As user herein, the terms “correspond” or “corresponding” encompasses a structural, functional, quantitative and/or qualitative correlation or relationship between two or more objects, data sets, information and/or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information and/or the like so to appear to be the same or equal. Correspondence may be assessed using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning assessment model, or combinations thereof.

Claims

What is claimed is:

1. A handheld electronic drug-requesting device, comprising: a handle configured to be grasped by a hand of a patient; a display integrated in the handle; a touch-activated control integrated in the handle or the display; one or more processors; and memory, comprising instructions, which, when executed by the one or more processors, cause operations comprising: determining the handheld electronic drug-requesting device is electronically coupled to a drug-delivery device for delivery of a drug to the patient; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profile associated with the patient from the drug-delivery device; presenting, on the display integrated in the handle, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handle, a patient request to deliver of a dose of the drug to the patient via the touch-activated control integrated in the handle or the display; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

2. The handheld electronic drug-requesting device of Claim 1, wherein: the user interface element including the information related to the patient profile is presented concurrently with a second user interface element for providing the patient request to deliver the dose of the drug, and the information related to the patient profile includes an amount of time before the patient will be able to cause another dose of the drug to be delivered.

3. The handheld electronic drug-requesting device of one of Claim 1 or Claim 2, wherein: the information related to the patient profile includes a reminder to administer a particular dose of medication at least a predefined amount of time before a scheduled physical activity is scheduled to occur.

4. The handheld electronic drug-requesting device of any one of Claims 1 through 3, wherein the patient request is provided as a user input selected from a group consisting of: (i) an audio input, and (ii) a visually-detectable input.

5. The handheld electronic drug-requesting device of any one of Claims 1 through 4 , further comprising one or more sensors configured to detect a state of the patient, wherein the operations further comprise: responsive to a first detection that the patient is in a first state indicative that the patient is stable and capable of providing inputs at the touch-activated control, providing a user interface element responsive to user inputs for requesting delivery of the dose of the drug; and responsive to a second detection that the patient is in a second state indicative that the patient is incapable of providing the inputs at the touch-activated control, providing an alternative means, distinct from the user interface element, for allowing the user patient to request delivery of the dose of the drug.

6. The handheld electronic drug-requesting device of Claim 5, wherein the one or more sensors include a camera located on a patient-facing portion of the handheld electronic drugrequesting device, and the handheld electronic drug-requesting device further comprises instructions for performing, based on imaging data captured by the camera, an operation from the group consisting of: confirming, based on the imaging data captured by the camera, that the patient is authorized to self-administer the dose of the drug from the drug-delivery device; performing a pain assessment of the patient; and detecting a pain-indicating user input directed to one or more patient-interactable affordances presented within a pain-assessment user interface.

7. The handheld electronic drug-requesting device of any one of Claims 1 through 6, further comprising instructions for: after the dose of the drug has been caused to be delivered to the patient via the drugdelivery device: presenting a confirmation user interface element to the patient indicating that the dose of the drug has been successfully delivered.

8. The handheld electronic drug-requesting device of any one of Claims 1 through 7, wherein the display includes a touch-sensitive surface configured to receive touch inputs, and the display is configured to detect (i) a first user input directed to the touch-sensitive surface, and (ii) a second user input directed to a depressible mechanical button located under the touch-sensitive surface of the display.

9. The handheld electronic drug-requesting device of any one of Claims 1 through 8, further comprising: an elongate structure configured to be gripped by a hand of the patient while a thumb of the patient interacts with one or more of the touch-activated control and a depressible mechanical button.

10. The handheld electronic drug-requesting device of Claim 9, wherein the handle comprises a sensor configured to detect a grip pressure being applied by the hand of the patient, and further comprising instructions for: receiving, from the sensor, sensor data based on the grip pressure being applied by the hand of the patient; and causing a pain assessment of the patient to be performed based on the grip pressure being applied by the hand of the patient.

11. The handheld electronic drug-requesting device of any one of Claims 1 through 10, further comprising: presenting, via the display, a pain-assessment user interface, the pain-assessment user interface including selectable user interface elements for allowing the patient to perform a pain assessment.

12. The handheld electronic drug-requesting device of any one of Claims 1 through 11, further comprising: an accelerometer for detecting movement by the patient; and instructions for: detecting, via the accelerometer, a movement by the patient after initiation of delivery of the dose of the drug; and based on determining that the movement by the patient corresponds to an adverse patient interaction from an interaction by the patient detected by the accelerometer, providing patient-interaction information to another electronic device.

13. The handheld electronic drug-requesting device of any one of Claims 1 through 12, further comprising instructions for: collecting usage data associated with a plurality of handheld electronic devices for delivered doses of the drug across a patient population; inputting the usage data to a machine-learning model; determining, based on inputting the usage data to the machine-learning model, that the patient request does not conform to the patient population; and presenting, responsive to determining that the patient request does not conform to the patient population, an alert to the display or to a device associated with a caregiver of the patient indicating that the machine-learning model is detecting a drug diversion attempt based on an aspect of the patient request.

14. The handheld electronic drug-requesting device of Claim 13, further comprising instructions for: collecting pain assessment information from the patient via one or more sensors; determining, based on inputting the pain assessment information to the machine-learning model, that a level of pain of the patient does not correspond to an expected pain value based on an amount of a drug delivered to the patient; and causing pain assessment indications to be provided to the machine-learning model, wherein the pain assessment indications are used in conjunction with the usage data to determine if the machine-learning model is detecting the drug diversion attempt.

15. The handheld electronic drug-requesting device of Claim 14, further comprising instructions for: in accordance with applying the usage data to the machine-learning model, determining that a dosage amount configured to be delivered to the patient is too high; and lowering the dosage amount configured to be delivered to the patient.

16. The handheld electronic drug-requesting device of any one of Claims 1 through 15, further comprising instructions for: based on an interaction by the patient detected by one or more sensors of the handheld electronic drug-requesting device, providing patient-interaction information to another electronic device.

17. The handheld electronic drug-requesting device of any one of claims 1 through 16, further comprising instructions for: detecting that the handle is being grasped by a hand of the patient; and authorizing the drug request by the patient based on detecting the handle being grasped by the hand of the patient.

18. A machine-implemented method, comprising: determining a handheld electronic drug-requesting device is electronically coupled to a drug-delivery device for delivery of a drug to a patient grasping the handheld electronic drug-requesting device; receiving, by the handheld electronic drug-requesting device, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver a dose of the drug to the patient via a touch-activated control of the handheld electronic drug-requesting device; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

19. A system, comprising: a drug-delivery device in operable communication with a control unit for controlling drug delivery to a patient via the drug-delivery device, wherein the control unit includes a handheld electronic drug-requesting device; one or more processors; and memory, including instructions, which, when executed by the one or more processors, cause performance of operations, comprising: determining a handheld electronic drug-requesting device is electronically coupled to the drug-delivery device for delivery of a drug to the patient; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver a dose of the drug to the patient via a touch-activated control of the handheld electronic drug-requesting device; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.

20. A non-transitory computer-readable storage medium comprising instructions which, when executed by one or more processors of a handheld electronic drug-requesting device in operable communication with a drug-delivery device, cause performance of operations, comprising: determining a handheld electronic drug-requesting device is electronically coupled to the drug-delivery device for delivery of a drug to a patient grasping the handheld electronic drug-requesting device; receiving, in response to determining the handheld electronic drug-requesting device is electronically coupled to the drug-delivery device, information related to a patient profde associated with the patient from the drug-delivery device; presenting, on a display integrated in the handheld electronic drug-requesting device, a user interface element including the information related to the patient profile associated with the patient; receiving, concurrently with the user interface element being presented on the display integrated in the handheld electronic drug-requesting device, a patient request to deliver a dose of the drug to the patient via a touch-activated control of the handheld electronic drug-requesting device; and responsive to the patient request, causing the dose of the drug to be delivered to the patient.