Handheld electronic drug request device for patient self-controlled analgesia

Abstract

A handheld electronic drug request device includes a handle configured to be held by a patient, a display embedded in the handle, and a touch activation controller integrated in the handle or the display. The handheld device performs operations comprising the steps of: determining that the device is electrically coupled to a drug delivery device for delivering a drug to a patient; and in response to determining that the device is electrically coupled to the drug delivery device, receiving information related to a patient profile associated with the patient; presenting to the patient, on a display, a user interface element including information related to a patient profile associated with the patient; receiving a patient request to deliver a dose of medicament to the patient via the touch activation controller; and causing the dose of medicament to be delivered in response to the patient request.

Description

TECHNICAL FIELD

[0001] The present application relates generally to control of infusion devices. BACKGROUND

[0002] Patient-controlled analgesia (PCA) is a common method of relieving pain experienced by patients that is more convenient for both clinicians and patients. The method generally includes the use of a syringe pump that is programmed to allow delivery of a predetermined amount (e.g., dose) of analgesic agent when needed by the patient. Some implementations of PCA include patient-controlled devices (e.g., PCA sticks) for patient requests to deliver pain medication. SUMMARY

[0003] There is a growing need for PCA implementations (e.g., including handheld electronic medication request devices) that provide more efficient, intuitive, safe, and better overall treatment experiences for patients. The present disclosure discusses various implementations of devices, systems, and methods for providing patient interaction with medication request devices (e.g., dose requesters) to improve patient care experiences 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 means for providing explicit and implicit feedback (e.g., based on data detected by sensors of the medication request device), including feedback that improves medication delivery (e.g., by optimizing dose levels) and minimizes medication delivery and / or mechanical failures (e.g., based on a patient sitting on a tube of a fluid infusion pump). Handheld medication request devices according to various implementations described herein can allow for bidirectional patient interaction to obtain feedback about the level of pain the user is experiencing while receiving input to cause delivery of a dose of medication (e.g., analgesic).

[0004] Handheld electronic medication requests further improve patient care feedback mechanisms by facilitating pain feedback after delivery of a dose of medication to a patient. In some implementations, patient feedback and / or other interactions of the patient with the handheld electronic medication request device (e.g., non-autonomous movements) can be provided to an artificial intelligence model (e.g., a machine learning model stored in a server) to improve detection of issues related to medication delivery. By not requiring a clinician to manually assess and / or request information about the level of pain a patient is experiencing, allowing the patient to directly provide such input to the medication request device also allows for a more seamless overall treatment experience.

[0005] In addition to the improved functional capabilities described above, it should be appreciated that structural aspects of the handheld electronic medication request device herein, whether used alone or in combination with the improved functionality, contribute to improving the patient experience. For example, the patient can easily request a medication bolus while performing other related operations using one hand and providing feedback with the handheld electronic medication request device, and in some cases, with only a single touch input (e.g., any of the operations described herein can be performed via the patient’s thumb). Other technical improvements of the implementations described herein will be apparent to those of skill in the art based on the discussion provided herein.

[0006] According to various aspects, a handheld electronic medication request device is provided. The handheld electronic medication request device includes a handle configured to be handheld by a patient, a display integrated in the handle, a touch-activated controller integrated in the handle or the display, one or more processors, and a memory including instructions that, when executed by the one or more processors, perform operations including determining that the handheld electronic medication request device is electrically coupled to a medication delivery device for delivering medication to the patient, receiving, from the medication delivery device, patient profile related information associated with the patient in response to determining that the handheld electronic medication request device is electrically coupled to the medication delivery device, presenting, on the display integrated in the handle, a user interface element including the patient profile related information associated with the patient, receiving, while presenting the user interface element on the display integrated in the handle, a patient request to deliver a dose of medication to the patient via the touch-activated controller integrated in the handle or the display, and causing the dose of medication to be delivered to the patient in response to the patient request. Other aspects include implementations of corresponding systems, methods, and computer program products for the respective devices and features thereof.

[0007] According to various aspects, a machine-implemented method includes determining that a handheld electronic medication request device is electrically coupled to a medication delivery device for delivering medication to a patient grasping the handheld electronic medication request device; in response to determining that the handheld electronic medication request device is electrically coupled to the medication delivery device, receiving, by the handheld electronic medication request device, patient profile related information associated with the patient from the medication delivery device; presenting a user interface element on a display integrated in the handle, the user interface element including the patient profile related information associated with the patient; while presenting the user interface element on the display integrated in the handheld electronic medication request device, receiving a patient request to deliver a dose of medication to the patient via a touch-activated controller of the handheld electronic medication request device; and in response to the patient request, causing the dose of medication to be delivered to the patient. Other aspects include implementations of corresponding devices, systems, and computer program products for respective methods and features thereof.

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

[0009] It should be appreciated that other configurations of the present subject technology besides those shown and described are possible and contemplated. As can be appreciated, the present subject technology is capable of other and different configurations, and its several details can be modified in various respects, all without departing from the scope of the present subject technology. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature, and not as restrictive. BRIEF DESCRIPTION OF DRAWINGS

[0010] For a better understanding of the various described implementations, reference should be made to the Detailed Description in connection with the accompanying drawings, in which:

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

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

[0013] Figure 2B is an example of a patient care device in accordance with aspects of the subject technology. Figure 1 A close-up view of a portion of the example patient care device shown in A.

[0014] Figures 3A-3J An example of a handheld electronic medication request device for allowing a patient to request delivery of medication is depicted in accordance with aspects of the subject technology.

[0015] Figure 4 An example process for performing a PCA operation in a patient care system including a handheld electronic medication request device is depicted in accordance with aspects of the subject technology.

[0016] Figure 5 is a conceptual diagram showing an example electronic system for operating a pain management system in accordance with aspects of the subject technology. DETAILED 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 can be practiced without these specific details. In some 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] Figure 1 An example of an institutional patient care system 100 for a healthcare organization is depicted in accordance with aspects of the subject technology. In Figure 1In overview, patient care devices 12 ("PCDs") (sometimes generally referred to as "patient care units" ("PCUs") or "medical devices") are connected to a healthcare network 110. The patient care devices can include or be communicably connectable to various ancillary medical devices, such as infusion pumps, vital signs monitors, medication dispensing devices (e.g., cabinets, carts), medication preparation devices, automated dispensing devices, modules coupled with one of the above devices (e.g., a syringe pump module configured to attach to an infusion pump), patient controlled analgesia (PCA) sticks, or other similar devices. Each element of the patient care devices 12 can be connected to the healthcare network 110 through a transmission channel 131. The transmission channel 131 can be any suitable wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some embodiments, the healthcare network 110 also includes computer systems located in various departments throughout a hospital. For example, the 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, the healthcare network 10 can include discrete sub-networks. In the depicted example, the healthcare network 10 includes a device network 140 through which the patient care devices 12 (and other devices) can communicate in accordance with normal operations. In accordance with some embodiments, the devices and support services of the healthcare network 110, or portions thereof, can be cloud-based, e.g., servers and services (e.g., databases, APIs, etc.) located remotely from the hospital and / or distributed across multiple remote locations or regions.

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

[0020] The patient care device 12 can include or incorporate pumps, physiological monitors (e.g., heart rate, blood pressure, electrocardiogram (ECG), electroencephalogram (EEG), pulse oximeter, and other patient monitors), therapy devices, and other medication delivery devices, which can be used in accordance with the teachings set forth herein. In the depicted example, the patient care device 12 includes a control module (also referred to as an interface unit 14) that is connected to one or more functional modules 16, 18, 20, 22. The interface unit 14 includes a central processing unit (CPU) 50 connected to memory, such as memory 58 (e.g., random access memory (RAM)), and one or more interface devices, such as a user interface device 54 (e.g., a display and / or a keyboard), a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. Although not necessary, the interface unit 14 also includes a primary 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, the user interface device 54 is a touch screen for displaying information to the user and allowing the user to input information by touching defined areas of the screen. In addition, or alternatively, the user interface device 54 can include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. The data input device 60 can be a bar code reader capable of scanning and interpreting data printed in bar code format. Alternatively or additionally, the data input device 60 can be any device for inputting encoded data into a computer, such as a device for reading a magnetic strip, a radio frequency identification (RFID) device, whereby the data input device 60 captures digital data encoded in an RFID tag or smart tag (defined below) via radio waves, a PCMCIA smart card, a radio frequency card, a memory stick, a CD, a DVD, or any other analog or digital storage medium. Other examples of data input devices 60 include voice activation or recognition devices or portable personal data assistants (PDAs). Depending on the type of interface device used, the user interface device 54 and the data input device 60 can be the same device. Although the data input device 60 is depicted as being connected to the CPU 50, the data input device 60 can be connected to the CPU 50 via the network connection 52 or the auxiliary interface 62. Figure 1The data input device 60 is shown as being disposed within the interface unit 14, but it should be recognized that the data input device 60 can be integrated within the pharmacy system 34, or located externally and communicate with the pharmacy system 34 through an RS-232 serial interface or any other suitable communication means. The auxiliary interface 62 can be an RS-232 communication interface, however, any other means for communicating with peripheral devices such as printers, patient monitors, infusion pumps or other medical devices can be used without departing from the subject technology. Further, the data input device 60 can be a separate functional module such as the functional modules 16, 18, 20 and 22 and configured to communicate with the interface unit 14 or any other system on the network using suitable programming and communication protocols.

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

[0023] The functional modules 16, 18, 20, 22 are any devices associated with the interface unit 14 for providing care to a patient and / or for monitoring the condition of a patient. As Figure 1 shown, at least one of the functional modules 16, 18, 20, 22 can be an infusion pump module such as an intravenous infusion pump for delivering medication or other fluids to a patient. For example, the functional module 16 can be an infusion pump module. Each of the functional modules 16, 18, 20 and 22 can be any patient treatment or monitoring device including, but not limited to, an infusion pump, 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, among others. In other examples, the functional modules 18, 20 and / or 22 can include devices other than an infusion pump module including a printer, a scanner, a bar code reader or any other peripheral input, output or input / output device.

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

[0025] Each of the functional modules 16, 18, 20, and 22 can include module-specific components 76, a microprocessor 70, volatile memory 72 for storing information, and non-volatile memory 74. In some embodiments, the functional modules can include hardware components similar to those of the interface unit 14, including but not limited to a CPU 50 connected to memory 58, one or more interface devices such as user interface devices 54, encoded data input devices 60, network connections 52, and auxiliary interfaces 62 for communicating with additional modules or devices. It should be noted that while the functional modules are shown as separate from the interface unit 14, the functional modules can be integrated into the interface unit 14 in some embodiments. Figure 1 While four functional modules are shown in FIG. 1, any number of devices can be connected directly or indirectly to the interface unit 14. The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. The module-specific components 76 include any components required for the particular module to operate, such as a pumping mechanism for an infusion pump module (e.g., an infusion pump module 22 as shown in FIG. 2). Figures 2A-2B As shown, the module-specific components 76 of the infusion pump module 22 include a pump 78, a motor 80, a reservoir 82, a user interface 84, and a display 86. The module-specific components 76 of the patient monitor module 16 include a sensor 88, a user interface 90, and a display 92. The module-specific components 76 of the medication administration module 18 include a user interface 94 and a display 96. The module-specific components 76 of the patient identification module 20 include a user interface 98 and a display 100.

[0026] According to various embodiments, while each functional module can be capable of operating independently (e.g., as described with respect to the interface unit 14 and its hardware components), the interface unit 14 is configured to monitor and control the overall operation of the patient care device 12. For example, the interface unit 14 can 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 can be equipped with a network interface module (NIM) allowing the medical device to participate as a node in a network. While the subject technology will be described for clarity in an Ethernet environment using Internet Protocol (IP), it will be understood that the concepts of the subject technology are equally applicable to other network environments and that such environments are intended to be within the scope of the subject technology.

[0028] Data to and from various data sources can be converted to network compatible data using existing technology, and information movement between medical devices and the network can be accomplished by various means. For example, patient care device 12 and health care network 10 can communicate through automatic interaction, manual interaction, or a combination of automatic and manual interaction. Automatic interaction can be continuous or intermittent, and can occur through network connection 52 (as shown), or through RS232 links, MIB systems, RF links such as Bluetooth, IR links, WLAN, digital cable systems, telephone modems, or other wired or wireless communication means. Manual interaction between patient care device 12 and health care network 10 includes the physical transfer of data between systems intermittently or periodically using, for example, user interface device 54, encoded data input device 60, bar codes, computer disks, portable data assistants, memory cards, or any other medium for storing data. In various aspects, the communication means is bidirectional, and data can be accessed from as many distributed data source points as possible. Figure 1

[0029] Figure 2A An example of an institutional patient care system for a health care organization is depicted in accordance with aspects of the subject technology. Figure 2A Patient care device 200 shown is similar or identical to patient care device 12 in Figure 1 , including four fluid infusion pumps 16, 18, 20, and 22 (also referred to as functional modules 16, 18, 20, and 22 in Figure 1 ), each in operable engagement with a respective fluid administration set 30, 32, 34, and 36. Fluid supplies 38, 40, 42, and 44 can take various forms, but are shown in this case as bottles, which are inverted and hung above the pumps. Fluid supplies can 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 on a rolling stand or pole 46. The particular fluid supply and its orientation (e.g., mounting location, mounting height, mounting type, etc.) within the care area can generate one or more interaction records. For example, an interaction record for a device can be generated in part by detecting a scannable code associated with the device prior to use. Once scanned, the interaction record can be logged for use as described herein.

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

[0031] Each of the fluid infusion pumps 16, 18, 20, and 22 is used to infuse each of the fluids in the fluid supplies into the patient 48. The fluid infusion pumps 22, 24, 26, and 28 are flow control devices that will act on the respective tubing or fluid conduit of the administration device to deliver fluid from the fluid supply through the conduit to the patient 48. Because separate pumps are used, each pump can be individually set to the pumping or operating parameters required to infuse 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 in connection with the infusion of a particular medical fluid can be associated with one or more interactions that can be logged and processed as described.

[0032] Figure 2B FIG. 1 shows an example patient care device in accordance with aspects of the subject technology. Figure 1 A close-up view of a portion of the example patient care device shown in FIG. 1. Figure 2B Two functional infusion pump modules 18 and 20 (e.g., infusion pumps, medication delivery devices) mounted on either side of a main rack control unit 14 are shown, along with a display and control keys for each module, where the main rack infusion controller is capable of programming both infusion pumps. The infusion device includes a door 5a and handle 5b for locking the door in the closed position for operation, and unlocking and opening the door for access to the internal pumping and sensing mechanisms, and loading of administration devices for the pumps. When the door 5a is open, tubing can be connected with the pump module 20. When the door 5a is closed, the tubing is in operative engagement with the pumping mechanism, upstream and downstream pressure sensors, and other devices of the pump. In this embodiment, a display 5c, such as an LED display, is located in the planar view on the door, and can be used to visually communicate various information related to the pump module 20, such as alarm indications (e.g., alert messages). Control keys 5e-5h can be present for programming and controlling the operation of the infusion pumps as needed. In some embodiments, the control keys can be presented as interaction elements on the display 5c (e.g., a touch screen display). The main rack and / or functional modules can also include audio alarm devices in the form of a speaker (not shown).

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

[0034] The main rack control unit 14 can include a communication system (not shown) by which the main rack control unit 14 can communicate with external devices, such as a medical facility server or other computer, and portable processors, such as a hand-held communication device or laptop computer, or other information devices through which a clinician can have to transmit information and download drug libraries to functional modules 16, 18, 20, 22 (e.g., the fluid infusion pump 20). In some embodiments, the main rack infusion controller can communicate with the medication request device 300 (e.g., through a wired connection or a wireless connection), which will be described in more detail below with reference to FIG. 3. The communication module can be used to transmit access and interaction information for a clinician encountering a device coupled with the main rack infusion controller (e.g., the fluid infusion pump module 22 or the bar code scanner). The communication system can 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 the communication system can alternatively be included integrally with the infusion pump 20, such as in situations where the main rack infusion controller is not used, or in addition to use with the main rack control unit 14. Further, the information input device need not be hard-wired to the medical appliance, information can also be transmitted through a wireless connection. Further, other types of modules, such as syringe pump modules, patient controlled analgesia modules, end-tidal CO2 (EtCO2) monitoring modules, oximeter monitoring modules, etc. can be connected to the pump modules or the main rack infusion controller. Figures 3A-3F

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

[0036] During operation of the patient care system, when a connected drug delivery device 300 is activated, the interface unit 14 (including, e.g., microprocessor 50) receives a dose request signal over the patient dose request line 303. If the interface unit 14 determines (e.g., in conjunction with profile data obtained from an internal database or via the server 130) that there are no restrictions on administering the requested bolus dose of the drug, the interface unit 14 can send a signal to the connected pump controller to instruct the pump unit associated with the request to administer the requested bolus dose. The interface unit 14 also provides coordination of activities between functional units such as the pump and the ETCO2 unit. For example, a clinician can set the patient care device 12 to provide PCA dosing and set the ETCO2 unit to monitor the ETCO2 parameter of a PCA patient. Optionally, one or more additional monitors, such as a pulse oximetry unit, can be communicably connected to the patient care system and set to monitor blood oxygen saturation and pulse rate. The clinician can specify minimum and / or maximum values for the ETCO2, respiratory rate, and / or other monitored parameters, effectively setting a range of acceptable values for these parameters. If the patient's ETCO2 parameter is outside the selected acceptable range, such as where it becomes less than the minimum level set by the clinician or greater than the maximum level set by the clinician, the ETCO2 monitor can send a trigger signal to the interface unit 14. In response, the interface unit 14 can activate a visual and / or audible alarm (e.g., via a display in the 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 the patient 48, the interface unit 14 can stop all further dosing of analgesic until the unacceptable low or high ETCO2 value and / or respiratory rate condition is resolved, such as by clinician intervention or patient change. Alternatively, the interface unit 14 can simply lock the drug delivery device 300 so that the patient cannot obtain further self-dosing. Thus, after appropriate values have been set, the patient control system provides communication and coordination between the interface unit, the pump, and the ETCO2 unit 94 to ensure greater safety and reduce the risk of harm from respiratory depression.

[0037] In some embodiments, the interface unit 14 can include program instructions for monitoring changes in the CO2 concentration data or other data produced by the ETCO2 unit and deciding whether to interfere with patient control of the pump module based on monitoring changes in the data, such as rate of change, rather than simply suspending operation of the pump in response to an out-of-range signal from the ETCO2 unit 94 or from another functional module.

[0038] Generally, medical fluid administration devices have a Figures 1-2Bmore components are shown. Many have check valves, drip chambers, valved ports, connectors, and other devices known to those skilled in the art. In order to maintain the clarity of the illustrations, these other devices have not been included in the drawings. For example, the patient care device 200 can include a patient controlled analgesia (PCA) device (e.g., a drug request device 300) that allows the patient 48 to self-administer medication (e.g., a pain reliever). Referring to Figures 3A-4 and the related description below regarding how the drug request device 300 can be operated in conjunction with the components and devices of the patient care system 100, including the patient care device 200.

[0039] Figures 3A-3J An example handheld electronic drug request device 300 for allowing a patient to request delivery of medication is depicted in accordance with aspects of the subject technology. Figures 3A-3J The illustrations shown in FIGS. 1-3 and the example patient interactions described below illustrate the ability of the handheld device to improve the patient experience. As will be discussed in greater detail below, the drug request device 300 can be used to provide indications related to the patient profile of the patient (e.g., via user interface elements and / or audio indications), which can assist the patient 48 in determining when to request delivery of a dose of medication via the drug request device 300. As described herein, the patient profile can include any medical characteristics about the patient 48 and / or patient-specific information, such as 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 be performing as part of a physical therapy plan).

[0040] The patient 48 can use the drug request device 300 to provide feedback regarding the degree of pain or the location of the pain that the patient is experiencing so that the system (or a remote clinician) can assess whether the pain is consistent with the medication provided and request and / or self-administer a dose of pain medication when approved by the system and / or clinician. The patient 48 can easily operate the drug request device 300 with one hand and, in some cases, with a simple single touch input (e.g., any of the operations described herein can be performed via the patient’s thumb).

[0041] Reference is made herein to Figure 1 , Figure 2A and Figure 2BAspects of a medication request device 300 are described, along with related components and / or processes described herein. The medication request device 300 is operably connected (e.g., through operable connection with another component of the patient care device 12 and / or the patient care system 100) with one or more of the fluid infusion pumps 16, 18, 20, and 22. In some implementations, the medication request device 300 is physically connected (e.g., via a wire) to a component of the patient care device 12, such as the main rack control unit 14. In some implementations, the medication request device 300 is wirelessly connected to the patient care system 100 (e.g., over the network 110, via an API interface of the information system server 130 in electronic communication with the patient care device 12). In some implementations, the medication request device 300 is operably coupled with one or more fluid infusion pumps of the patient care system via a decision control module compatible with the patient care system 100.

[0042] Figure 3A and 3B Several different perspective views of a medication request device 300 are shown, in accordance with aspects of the subject technology. The medication request device 300 includes a housing 301 forming a handle 302 that is configured (e.g., arranged, shaped) to be grasped by a hand of the patient 48 (e.g., based on a length of a perimeter of the handle 302). In some implementations, the handle 302 is an elongated member of the housing 301 having a perimeter of a grip dimension along a major dimension of the elongated member. According to various implementations, the medication request device 300 further includes a display 304 embedded in the housing 301 (e.g., integrated in the handle 302 above a grip area). The display 304 can be a circular touch screen display (e.g., a display having touch activated controls). The display 304 can be integrated or otherwise arranged on the housing 301 of the medication request device 300, and the display 304 can be located near or within the handle 302 such that the display 304 faces the patient 48 when the patient 48 uses the medication request device 300 (e.g., through an upper end of the handle 302 located above a grip portion of the handle 302). The display 304 can present a user interface to the patient 48 related to medication delivery. For example, in Figure 3A the display 304 displays a user interface indicating that the medication request device 300 is electronically coupled to a medication delivery device (e.g., one or more of the fluid infusion pumps 16, 18, 20, and 22). In some implementations, the indication that the medication request device 300 is electronically coupled to a medication delivery device can include information about one or more medications available for delivery via the electronic coupling (e.g., based on a medication library stored in the patient care device 12).

[0043] In some embodiments, the medication request device 300 is physically connected to the interface unit 14 or one or more components of the patient care system 100 via the request line 303. In some embodiments, the medication request device 300 can form a wireless connection with the patient care system 100 and / or components thereof.

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

[0045] The medication request device 300 can include a touch-sensitive surface on the display 304 and / or a pressable mechanical button located beneath the display 304. In some embodiments, the pressable mechanical button is present within the same user interaction area as (e.g., co-located with) the touch screen display (e.g., the display can be the upper portion of the button itself, or include a peripheral button integrated into some portion or peripheral area of the display). In some embodiments, the medication request device 300 performs a first operation based on a first user input to the touch-sensitive surface of the display 304, and the medication request device 300 performs a second operation based on a second user input to the pressable mechanical button located beneath (e.g., co-located with) the touch screen of the display 304. For example, the first user input to the touch screen can cause information about a patient profile or medication that can be used for delivery to be displayed, and the second user input to the pressable mechanical button can cause a medication request to appear. In some embodiments, the touch screen of the display 304 is configured to receive different types of patient interactions (e.g., based on the respective location of the touch screen that the patient 48 performs a touch input).

[0046] In some embodiments, the medication request device 300 includes a camera 306, which can be located proximate to the display 304 to allow the camera to capture image data of the patient 48 while the patient 48 is using the medication request device 200. In some embodiments, the camera 306 facilitates detection of interactions and / or actions of the patient 48 and / or another person in proximity to the medication request device 300. In some embodiments, system software associated with the medication request device 300 can employ image recognition and / or machine learning algorithms that can receive images from the camera and identify actions performed by the patient based on those images (e.g., based on a trained model). In some embodiments, the algorithm can distinguish between autonomous and non-autonomous actions. For example, the camera 306 can detect eye movement of the patient 48 and map predetermined eye movements to user inputs (e.g., for requesting delivery of a dose of medication), and / or map eye movements to the current state and / or condition of the patient, which can be provided as feedback to the system before or after delivery of the medication.

[0047] In some embodiments, the camera 306 can be automatically activated without explicit user input based on determinations related to the current state of the patient 48 and / or interactions with the medication request device 300. For example, in connection with a dose of medication available for delivery to the patient 48 via one or more infusion pumps of the patient care device 12, the medication request device 300 can determine, via imaging data collected by the camera 306, whether the patient 48 is in a state that allows them to provide touch-based inputs (e.g., via a touch-activated surface of the display 304 or by the button 312a). In response to determining that the patient 48 is not in a state that allows them to provide touch-based inputs, the medication request device 300 can cause the camera 306 to begin acquiring imaging data of the patient 48 for the purpose of detecting different types of user inputs (e.g., based on head movement, eye movement, etc.).

[0048] In some embodiments, the medication delivery device 300 includes a grip sensor (e.g., a pressure sensor, a piezoelectric sensor, an accelerometer, etc. disposed along a portion of the handle 302) that can detect that the patient 48 is gripping the 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 medication request device 300 can detect an amount of gripping pressure applied by the patient 48 at the grip sensor, and based on the amount of gripping pressure, the medication request device 300 can present a pain assessment and / or an alert to the patient 48 based on a threshold gripping pressure applied by the patient 48 (e.g., indicative of pain by the patient 48). The patient 48 can then use the grip sensor to provide user input to the medication request device 300. For example, upon detecting an even higher predetermined threshold pressure by the gripping pressure, the medication delivery request can be caused to be logged by the device 300. In some embodiments, data from the grip sensor can be used to determine whether the patient 48's hand is gripping the handle 302 when the patient 48 requests delivery of medication. In some embodiments, by detecting whether the patient 48 is gripping the handle 302 when a medication request is received, medication abuse is reduced by ensuring that others in the same room as the patient 48 do not execute an unauthorized medication request.

[0049] In some embodiments, the medication request device 300 includes peripheral buttons 312a and 312b that can allow the patient 48 to provide additional and / or alternative user input to perform the operations described herein. In some embodiments, user input to the peripheral button 312a can cause more information about the patient's profile to be displayed, while user input to the peripheral button 312b can cause a medication delivery request to appear.

[0050] In some embodiments, the medication request device 300 includes a speaker 308 and a microphone 310 for providing audio interaction with the patient, which can allow the patient 48 to interact with the medication request device 300 when the patient 48 is unable to interact via a touchscreen of the display 304 or one or more buttons 312 (e.g., due to an abnormal degree of pain). Further, the audio features provided by the speaker 308 and the microphone 310 can be used in conjunction with presenting a user interface on the display 304. In some embodiments, the patient 48 can provide user input at the display 304 that causes the microphone 310 to be activated, and the patient 48 can provide a voice user input (e.g., which can be provided to a clinician). In some embodiments, an audio signal can be provided in conjunction with (e.g., simultaneously with) presenting a user interface (e.g., as part of an alert). For example, based on detecting an indication that drug abuse is occurring, the patient care system can provide an alert user interface to the patient 48 via a user interface element displayed on the display 304 that indicates that the patient 48 is no longer able to cause delivery of a dose of medication, and can provide audio via the speaker 308 with the same or similar information to draw the attention of the patient 48 to the alert user interface. Providing such dynamic interaction enhances patient treatment by ensuring that high-priority information is alerted to the patient 48 (e.g., that medication delivery will be stopped to mitigate a drug abuse attempt).

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

[0052] Figure 3C The medication request device 300 is depicted displaying a user interface that includes a plurality of user interface elements for facilitating the patient’s experience with the medication request device 300. According to various embodiments, the patient care system monitors how much medication has been provided to the patient 48 over the course of treatment. For each medication provided to the patient, the total dose can be stored in the EMR database 137. The database can also include patient data based on the patient’s medical information (e.g., medication orders, medication restrictions, demographics, physiologic measurements, lab values, etc.) and pharmacokinetics of the provided medications, and the system can monitor medication dosing according to the patient data to determine when the patient is due for another dose of medication and / or the amount that can be administered. In this way, information regarding when the patient can be due for a further dose of medication can be communicated via the display 304 of the medication delivery device 300, thereby alleviating the burden on the clinician to manage patient requests.

[0053] In the depicted example, a user interface element 314 displayed on the display 304 provides an indication that a dose of a particular medication (e.g., medication A) can be used for delivery to the patient 48 (e.g., in response to a patient request) and that the patient can request immediate delivery of that dose to the patient via interaction with the medication request device 300. Another user interface element 316 can indicate a location of the touchscreen of the display 304 to which the patient 48 can provide user input in order to cause delivery of the medication to the patient 48 (e.g., via a fluid infusion pump). In some embodiments, the patient care system displays via the user interface of the display 304 the time until the next dose will be available for delivery after the patient 48 requests delivery of a currently available dose. For example, a user interface element 318 can indicate a countdown including an amount of time until the patient 48 can request delivery of another dose of medication (and / or a different medication).

[0054] In some embodiments, the patient care system 100 can determine and provide information related to physical activity that the patient 48 is scheduled to participate in or needs to perform prior to another dose being delivered via the user interface, which can be based on scheduled information related to the patient's patient profile (e.g., information received from the information system server 130). In some embodiments, the patient care system 100 can provide a user interface to the display 304 that includes information that is also presented on the display 6a of the interface unit 14 (e.g., a mirrored display 6a). In some embodiments, the patient care system 100 is configured such that a first user input to the user interface element 316 for a location on the touchscreen causes delivery of a dose of medication, while a second user input to the user interface element 318 can cause display of different information from the patient profile of the patient 48.

[0055] Figure 3D The patient 48 is shown performing physical activity in response to the information provided by the patient care system 100. The patient 48 is shown performing physical activity in response to the information provided by the patient care system 100. Figure 3CA gesture 320 of a user interface displayed on the display 304 of the traditional medicine request device 300. The patient care system detects the gesture and maps the gesture to a predetermined gesture to determine an action performed by the patient. The gesture 320 performed by the patient 48 can be a touch gesture directed at the display 304 (which can be a touch-sensitive display), and / or the gesture 320 can be a press gesture of a mechanical button co-located with the display 304 of the medicine request device 300. In some embodiments, the patient 48 can perform gestures of other inputs to the medicine request device 300, such as a press gesture directed at one of the peripheral buttons 312a and 312b. In some embodiments, the patient 48 can provide audio input and / or eye movement to cause the occurrence of a medicine request. In some embodiments, other interactions detected by one or more sensors of the medicine request device can cause an interaction with the medicine request device 300 when a user interface is displayed. For example, a voice input detected by the microphone 310 can cause the initiation of a medicine delivery without any additional input provided by the patient. In some embodiments, usage data such as the gesture 320 can be collected by the medicine request device 300 and provided to another component of the patient care system 100. For example, data related to the gesture 320 can be provided by the patient care system 100 to a machine learning model stored at the information system server 130, which can be used to determine whether any aspect of the gesture 320 indicates that medicine abuse can be occurring (e.g., the gesture 320 can not match other similar gestures performed by the patient 48).

[0056] Figure 3E Another user interface presented by the display 304 of the medicine request device 300 is shown, which includes a confirmation user interface element 322 indicating that the dose of medicine has been successfully delivered. In some embodiments, other information can be presented in conjunction with the confirmation user interface element 322. For example, a user interface element similar to the user interface element 318 can be presented in conjunction with the confirmation user interface element 322, allowing the patient 48 to know when another dose is available for delivery after the patient 48 has successfully delivered the current dose. In some embodiments, a reminder user interface element can be presented in conjunction with the confirmation user interface element, where the reminder user interface element reminds the patient 48 when they are advised to perform delivery of another dose of medicine based on information from the patient profile related to an activity (e.g., physical therapy, surgical preparation) that the patient 48 is scheduled to perform.

[0057] In some embodiments, the patient care system 100 can provide, via the display 304, a display countdown interface or element showing the duration until the next dose of medication is available for request. That is, after a medication is provided by the associated pump(s), the patient care system can determine when it is safe for the patient to be dosed again based on the pharmacokinetics of the medication provided, the patient profile (including, for example, patient weight, BMI, demographics, etc.), currently measured physiological data (e.g., from connected sensors), and other available information. In some embodiments, the duration can be based on the dosing orders for the medication (e.g., provided and / or entered by a clinician into the EMR system). The interval between doses can be displayed in time units (e.g., 15 minutes before, 10 minutes before, 5 minutes before) and / or can include a real-time countdown before activity. In this way, the medication request device 300 can provide relevant information to the patient 48 that they can wish to know before experiencing any sedation or other mental effects caused by the delivery of that dose of medication.

[0058] Figure 3FAnother user interface presented on display 304 is shown, which includes a prompt for a pain assessment of patient 48. In some embodiments, medication request device 300 can provide alternative ways for patient 48 to provide user input 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 input to the touchscreen of display 304). For example, camera 306 can be activated by patient care system 100 after patient 48 causes medication to be delivered, and image data of patient 48 can be obtained to determine a state of patient 48 after a dose of medication has been delivered. In the example shown, patient 48 is instructed (e.g., via an audio prompt provided via display 304 or by speaker 308) to perform an eye movement to provide a pain assessment, and can provide an eye movement to adjust an indication of the level of pain experienced by patient 48 that is displayed in an indicator of the pain assessment user interface. For example, the patient care system can process and detect the amplitude of an eye movement in a particular direction based on images received from the camera. The patient care system can cause the indicator of the pain assessment user interface to move on display 304 a distance and / or corresponding to the amplitude of the detected eye movement, which can occur in real-time as patient 48 performs the eye movement. In this regard, this can occur in real-time as patient 48 performs the eye movement. In this regard, patient 48 can visualize the result input that will be provided based on the eye movement, and the patient care system can detect the number of times patient 48 blinks based on the imaging data, and move the indicator within the pain assessment user interface element a predetermined discrete amount based on the number of blinks. In this way, medication request device 300 provides a convenient interaction for patients who are incapacitated or temporarily lose the ability to act based on the medical condition (e.g., the level of pain experienced by patient 48).

[0059] In some embodiments, camera 306 can also be used to collect biometric data that can be used to authorize patient 48 as an appropriate recipient of the dose of medication. For example, the camera can be used to authenticate patient 48 based on facial recognition. In some embodiments, one or more other sensors of medication request device 300, and / or sensors that are physically separate from medication request device 300 but in electronic communication with medication request device 300, can be used to verify the identity of patient 48. For example, according to some embodiments, a finger scan and / or a card scanner attached to medication request device 300, or another device that is physically separate from medication request device 300 but in electronic communication with patient care system 100, can be used to verify the identity of patient 48 as part of a dose request.

[0060] In some embodiments, data collected via pain assessments can be provided to a machine learning model (e.g., stored in the information system server 130) that can be used to determine that the degree of pain that the patient 48 is currently experiencing does not align with an expected pain value based on the amount of medication delivered to the patient 48 (e.g., an indication that the patient 48 is still experiencing a high level of pain after delivery of a dose of analgesic that should have lessened the degree of pain experienced by the patient 48). In some embodiments, another user interface can be presented to the patient 48 (and / or a clinician associated with the patient care system 100) to indicate that medication delivery will become unavailable (e.g., based on a determination by the patient care system that medication misuse is occurring or likely to occur).

[0061] Figures 3G-3J An additional example of a user interface that can be provided on the display 304 of the medication request device 300 is shown. In particular, Figures 3G-3I A different pain assessment user interface that can be provided to the patient 48 by the patient care system 100 via the display 304 is shown. In some embodiments, different pain assessment user interfaces are provided to the patient 48 based on the respective circumstances of the pain assessment being initiated. In some embodiments, a machine learning model is used to determine which type of pain assessment to present to the patient 48 (e.g., based on the accuracy of respective responses to the type of pain assessment). In some embodiments, the patient 48 can manually switch between pain assessment types (e.g., by providing user input to the peripheral button 312a).

[0062] Figure 3G A pain assessment user interface is shown that includes a sliding scale user interface element that the patient 48 can interact with to indicate the degree of pain experienced by the patient 48 along the sliding scale. In some embodiments, the patient 48 can indicate the degree along the sliding scale without having to provide user input to the touchscreen of the display 304. For example, the device 300 can include an accelerometer that measures device motion. In this regard, accelerometer data is sent to the patient care system, which can then detect gestures by the patient 48 based on the data. In this regard, the degree of pain can be indicated by measuring the amount of rotational and / or translational movement of the user’s hand in a particular direction when the scale user interface element is presented. That is, greater amplitude translational and / or rotational motion detected by the accelerometer can indicate a higher degree of pain being experienced by the patient 48. In some embodiments, the patient care system can determine the level of pain by matching accelerometer readings to predetermined patterns that are consistent with pain. In some embodiments, user input can include facial movements (e.g., head movements and / or eye movements) detected by the camera 306, as described in more detail below. Figure 3FThe facial image obtained by the camera, real-time changes in the image, and motion of the image can be matched against predetermined facial patterns to determine whether the patient is experiencing a certain degree of pain.

[0063] Figure 3H A pain assessment user interface is shown that includes a depiction of a human body and can be used to allow the patient 48 to indicate which part of their body is experiencing pain. In some embodiments, the camera 306 can be used for the patient 48 to indicate the location of the pain. For example, the camera 306 can be activated in conjunction with the pain assessment user interface being presented and imaging data of the patient 48 touching a particular body part obtained by the camera 306 (e.g., touching a can be used to determine that the patient 48 is experiencing pain at a particular body part). In some embodiments, the speaker 308 can sequentially list body parts and the patient 48 can provide user input (e.g., voice commands detected via the microphone 310) to indicate whether the listed body part is in pain. For example, when the body part experiencing pain is audibly identified, the patient 48 can press the button 312 (or a touch element on the touchscreen 304), which can be provided from the medication request device 300 to another device of the patient care system 100 to determine an aspect of medication delivery (e.g., a type of PCA available to the patient 48 based on the location of the body part experiencing pain, or a time period in which another dose of medication can be used for delivery to the patient 48). For example, a pain assessment based on the location of the body part that should have received pain relief based on previous medication delivery can indicate that medication abuse is occurring and, therefore, a particular medication should not be provided at the medication delivery device 300 through a patient request. In some embodiments, the indication provided by the 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 the patient 48 in response to a medication request (or another aspect of the treatment of the patient 48) was effective.

[0064] Figure 3I A pain assessment user interface is shown that includes selectable “yes” and “no” checkbox user interface elements for the patient 48 to provide a binary choice in response to a question related to the pain assessment. In some embodiments, the patient care system can present symbols on the display 304 that can then be selected to indicate the patient’s response to a question or request. By touching the symbols on the screen to indicate the appropriate negative or positive response, the patient can provide feedback that can be recorded and used to determine, for example, when a dose is available for administration or to determine the amount of the dose. The medication request device 300 can provide the patient 48 with successive binary choices as part of a single pain assessment.

[0065] In some implementations, a question can be used to assess whether the patient is attempting to divert attention. For example, the patient care system can obtain an answer regarding the pain assessment (e.g., based on holding a handle or through accelerometer readings, eye movement, etc.) or other extrasensory data (e.g., from ETCO2, SPO2, etc.) and determine that the answer is consistent with misuse activity. In some implementations, as shown in Figure 3J an alarm interface can be provided to indicate that drug delivery will be stopped (e.g., based on an indication that drug misuse is occurring and / or that the patient 48 is not in a stable state). In some implementations, the alarm user interface can include user input for requesting assistance from a clinician (e.g., to mitigate an emergency and / or other critical situation).

[0066] Figure 4 An example process 400 for performing PCA operations in a patient care system including a handheld electronic drug request device (e.g., the drug request device 300) is depicted in accordance with aspects of the subject technology. For purposes of explanation, reference is made to the Figure 1 -3 description of the example process 400, as well as related components and / or processes described herein. One or more blocks of the process 400 can be implemented, for example, by one or more computing devices including, for example, the infusion control module 114 (also referred to herein as the interface unit 14), the information system server 130, one or more of the functional modules 16, 18, 20, and 22, the drug request device 300, and / or the client computing device 32. In some implementations, one or more blocks can be implemented based on one or more machine learning algorithms. In some implementations, one or more blocks can be implemented separately from other blocks and by one or more different processors or devices. Moreover, for purposes of explanation, to the extent that the blocks of the example process 400 are described as occurring serially or linearly, in some implementations, multiple blocks of the example process 400 can occur in parallel (e.g., blocks 406 and 408 can occur in parallel). According to some implementations, the blocks of the 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.

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

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

[0069] In response to determining that the handheld electronic medication request device is electrically coupled to a medication delivery device, the medication request device 300 receives patient profile related information associated with the 48 from the medication delivery device (406). For example, the patient care system 100 (e.g., the interface unit 14) can query a database, or can otherwise access information about a patient profile from the external database 137 (e.g., via an operation performed at the patient care device 12). The patient profile can include, for example, information from the information system server 130 that indicates a schedule of when a dose of one or more medications will be available for delivery to the patient 48.

[0070] Continuing with the depicted example 400, the medication request device 300 presents user interface elements to the patient on a display 304, including patient profile information associated with the patient (408). In some embodiments, one or more user interface elements displayed on the display 304 may be presented by a local process within the device 300. In some embodiments, the one or more user interface elements are presented by one or more components of the patient care system 100 (e.g., interface unit 14 or an associated server) and provided to the device 300 for presentation on the display 304. According to the previously described process (e.g., by algorithm), the user interface elements may simultaneously display profile information with a second user interface for providing a patient request for delivery of a dose of medication, as discussed with respect to operation 410. Similarly, the user interface elements may be configured to include a timeframe prior to the patient 48 being able to cause delivery of another dose of medication (e.g., a different dose of the same or different medication). For example, in Figure 3C The user interface displayed on the display 304 of the medication request device 300 includes a user interface element 316 that indicates where the patient 48 can provide touch input on the display 304 to initiate a medication request. The user interface also includes another user interface element 318 that indicates when another dose will be available for delivery (e.g., based on patient-specific information in the patient's profile).

[0071] In some implementations, the same or different user interfaces may present information related to a patient profile, including reminders to administer a specific dose of medication at least a predetermined time before a planned physical activity (e.g., as part of a patient's physical therapy plan) is scheduled to occur. That is, a separate user interface with reminders may be displayed at a different time than when the patient's request is received (e.g., when the patient 48 is currently unable to request a dose). For example, a separate user interface may be presented 15 minutes before a dose becomes available, instructing the patient 48 to consider requesting a dose within the next 30 minutes.

[0072] The example process 400 continues while the user interface element is rendered on the display 304, with the medication request device 300 receiving a patient request to deliver a dose of medication to the patient 48 via touch activation of a controller (e.g., a touchscreen of the display 304) (410). In some embodiments, the device 300 is configured to detect when the patient 48 is grasping the handle. In some embodiments, the request to deliver the dose will only be received by the device 300 after detection of grasping the handle. In some embodiments, the patient request can be detected without the patient grasping the handle of the medication request device. For example, the patient 48 can be temporarily unable to hold the medication request device 300 and can still request delivery of a dose of medication (e.g., using a voice command).

[0073] In some embodiments, the patient request is provided as user input selected from (i) an audio input (e.g., a vocalization recognized (e.g., via an AI model) as being performed by the patient 48), and (ii) a visually detectable input (e.g., a facial movement-based input detected via a pupil measurement sensor configured to monitor eye movement of the patient and / or identify the patient 48 via pupil features). In some embodiments, based on the determination that a dose is available for delivery to the patient 48, the medication request device 300 can access information about the patient 48 (e.g., via one or more sensors of the medication request device 300 such as the camera 306 and / or information from a patient profile of the patient 48) to determine how to provide an indication to the patient 48 about the availability of the dose. For example, based on a determination that the patient 48 is not in a state where they can have a dose delivered, the medication request device 300 can provide an audio indication to the patient 48 (e.g., via the speaker 308), and the audio prompt can indicate that the patient 48 can provide a request via a means other than touch input.

[0074] In response to the patient request, the medication request device 300 causes the dose of medication to be delivered to the patient 48 (e.g., via a medication delivery device operably connected to the medication request device 200 (e.g., physically and / or electronically) (412). According to various embodiments, the device 300 causing the dose to be delivered includes the device 300 sending a request to a processing component of a patient care system, which then processes the request according to various embodiments described herein and sends a signal to an infusion device to deliver the dose. In some embodiments, the patient 48 does not need to grasp the handle of the medication request device to cause delivery of the dose of medication (e.g., when the patient 48 is unable to move due to a particular health condition that the patient 48 is experiencing).

[0075] In some embodiments, one or more cameras of the medication request device 300 (e.g., the camera 306) acquire image data prior to or after the dose of medication is caused to be delivered. The medication request device 300 can use the imaging data captured by the camera to confirm that the patient 48 is in fact the person who initiated the medication request, and / or that the patient 48 is authorized to self-administer the dose of medication from the medication delivery device (e.g., based on comparing biometric information to information from the patient's medication delivery profile). The medication request device 300 can use the imaging data to perform a pain assessment of the patient 48 (e.g., determine the degree of pain of the patient 48 based on movement of the patient's body, such as clenching a fist, rubbing or holding a painful area, etc.). And the patient control unit can use the imaging data to detect a pain-indicating user input (e.g., eye movement) directed to one or more patient-interactive controls presented within the pain assessment user interface. In some embodiments, additionally or alternatively, one or more of the operations can be performed using one of the one or more sensors that can be used as an alternative or in addition to imaging data from the camera.

[0076] In some embodiments, after the dose of medication has been caused to be delivered to the patient 48 via the medication delivery device, the medication request device 300 presents a confirmation user interface element to the patient 48 indicating that the dose of medication has been successfully delivered (e.g., such as the confirmation user interface element 322 shown indicating the type of medication and the amount of the dose of medication). In some embodiments, prior to or after the dose of medication has been delivered, the medication request device 300 presents (e.g., via the display 304) a pain assessment user interface including optional user interface elements for allowing the patient 48 to perform a pain assessment (e.g., such as the pain assessment user interface shown). Figure 3E Figure 3E and 3F the pain assessment user interface shown).

[0077] In some embodiments, the patient care system 100 can determine whether the patient 48 is interacting with any other electronic device that can be used to supplement and / or replace the operability of the medication request device 300. For example, in accordance with the patient care system 100 determining that the patient 48 is using an augmented reality device in operable communication with the patient care system 100, any of the operations of the above-described process 400 can optionally be implemented at the augmented reality device. In this way, the intuitive and effective means of interaction provided by the operations, user interfaces, and other aspects of the process 400 can be provided to the patient 48 regardless of (e.g., unknowingly) what physical hardware the patient 48 is using to cause the operations to be performed.

[0078] ​In some embodiments, the patient care system 100 can determine a subset of operations that can be more efficiently performed by different electronic devices in operable communication with the patient care system 200, and can offload the subset of operations to the respective different electronic devices in operable communication with the patient care system 100. For example, the patient care system 100 can determine that a sensor connected to a fingertip of the patient 48 is more accurate and / or more efficient for detecting a particular biometric signal of the patient 48, and / or that an eye tracking sensor of an augmented reality system is more capable of detecting eye movements performed by the patient 48, and a subset of the operations can be offloaded to the different device, while another subset of the operations (e.g., detecting touch inputs at a touchscreen of the display 304) are more efficient or intuitive to perform at the medication request device 300.

[0079] As previously described, a machine learning model can be used to analyze interactions of the patient 48 with the medication request device 300 and / or determine whether a request for a medication bolus should be authorized and delivered. The machine learning model can be trained and implemented on different electronic devices of the patient care system 100 (e.g., the information system server 130). In some embodiments, the machine learning model can be configured to determine whether a particular interaction of the patient 48 indicates that drug misuse can be occurring within the patient care system 100. For example, in some embodiments, the patient care system 100 can collect usage data of delivered medication doses associated with a plurality of handheld electronic devices 300 across a population of patients (e.g., within a care center), determine medication reaction times and / or movement patterns based on patients in the population receiving similar doses 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 that drug misuse can be occurring when the patient’s response is inconsistent with (e.g., outside of a tolerance of) the population-based mean or average response time and / or movement pattern. In some embodiments, one or more sensors located at or in electronic communication with the medication request device 300 (e.g., imaging data obtained by the camera 306, movement data and / or directional data detected by an accelerometer of the medication request device 300) can be provided as usage data to the machine learning model. Certain usage data of the patient 48 can not be provided together with usage data of other patients in the population of patients (e.g., based on data privacy laws). In some embodiments, the usage data is provided in a manner that anonymizes protected health information (PHI) of the patient 48 and the other patients in the population of patients.

[0080] According to various implementations, patient 48's usage data is fed into a machine learning model, which can be used to determine, based on the usage data, that a specific medication request initiated at the medication request device 300 is not in the patient population. In some implementations, in response to determining that the patient request is not in the patient population, the medication request device 300 provides an alert (e.g., to a device associated with the caregiver of patient 48) indicating that the machine learning model is detecting a drug abuse attempt based on one aspect of the patient request. In some implementations, the machine learning model can be further trained based on input provided by patient 48 in response to the alert (e.g., when displayed on the medication request device 300). The module can determine, based on additional input, that drug abuse has not actually occurred, that patient 48 initiated a medication request, and that a dose of medication has been successfully delivered to patient 48. As described above, the medication request device 300 can collect pain assessment information from patient 48 via one or more sensors (e.g., such as...). Figure 3F (As shown). The medication request device 300 can determine, based on pain assessment information input into a machine learning model, that the level of pain in patient 48 does not correspond to the expected pain value based on the amount of medication delivered to patient 48. Pain assessment indicators can be provided to the machine learning model, whereby the pain assessment indicators are combined with usage data to determine whether the machine learning model is detecting an attempt at medication abuse. For example, when the pain assessment indicates that the patient's expected pain relief is based on the collected patient information and the pharmacokinetic characteristics of the medication, medication abuse can be ruled out.

[0081] In some implementations, by applying usage data to a machine learning model, the model can determine that the dose configured to be delivered to patient 48 is too high. Based on this determination, one or more components of the patient care system 100 can reduce the dose configured to be delivered to patient 48. For example, a dose request below the typical amount may instruct patient 48 to avoid using the dose requester when they are experiencing or should be experiencing pain, or may indicate that the dose is too high for patient 48's tolerance to the drug.

[0082] Many of the operations described above and in connection with the example process 400, as well as related features and applications, can 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 when executed by one or more processing units (for example, one or more processors, cores of processors, or other processing units), cause the one or more processing units to perform the actions indicated in the instructions. The computer readable medium can be a machine readable storage medium such as one or more memory devices including, but not limited to, optical discs, flash drives, RAM chips, hard drives, EPROMs and the like. The computer readable medium does not include a carrier wave or electronic signals propagating through space.

[0083] The term "software" refers to, in appropriate cases, 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 embodiments, aspects of the subject disclosure can be implemented as sub-parts of a larger program while maintaining a tendency of the subject disclosure to be modularized. In some embodiments, aspects of the subject disclosure can also be implemented in a computing system that is implemented as a suitably programmed computer or a suitably programmed network device. Finally, in some embodiments, aspects of the subject disclosure can be implemented as a combination of two or more separate programs, sub-programs, or code portions. In some embodiments, the software program, when installed to operate on one or more electronic systems, defines one or more specific machine implementations that execute and perform the operations of the software program.

[0084] 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 file 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 code portions). 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 networks.

[0085] Figure 5 FIG. 5 is a conceptual diagram illustrating an example electronic system 500 for operating an analgesic dosing system, in accordance with aspects of the subject technology. The electronic system 500 can be for performing the operations described above in connection with the example system 100, and the like. Figure 1a software computing device associated with one or more portions or steps of the process 400, or by Figure 1 - components and processes provided by FIG. 3, including but not limited to the information system server 130, computing hardware within the patient care device 12, or the administration device 32. In conjunction with the disclosure regarding Figures 1-4 In this regard, the electronic system 500 can be a personal computer or a mobile device, such as a smartphone, tablet, notebook, PDA, augmented reality device, wearable device such as a watch or band or glasses or combination thereof, or other touchscreen or television with one or more processors embedded or coupled thereto, or any other kind of computer-related electronic device with network connectivity.

[0086] The electronic system 500 can include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, the electronic system 500 includes a bus 508, 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, the electronic system 500 can include or be integrated with other computing devices or circuitry for operation of the various components and processes described above.

[0087] The bus 508 collectively represents all system, peripheral, and chipset buses that communicatively connect the various internals of the electronic system 500. For instance, the bus 508 communicably connects the processing unit(s) 512 with the ROM 510, the system memory 504, and the permanent storage device 502.

[0088] The one or more processing units 512 retrieve instructions to execute and data to process from these different storage units, to execute the processes of the subject disclosure. In different implementations, the one or more processing units can be a single processor or multiple cores.

[0089] The ROM 510 stores static data and instructions that are needed by the one or more processing units 512 and other modules of the electronic system. On the other hand, the permanent storage device 502 is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the 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 the permanent storage device 502.

[0090] 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 as 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, one or more processing units— 512 retrieve instructions to execute and data to process in order to execute the processes of some implementations.

[0091] Bus 508 also connects to input and output devices 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, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). Output device interface 506 enables, for example, the display of images generated by the electronic system 500. Output devices used with output device interface 506 include, for example, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.

[0092] Furthermore, as will be appreciated, various embodiments can be used with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as computers found in hand-held devices, embedded computer systems, and distributed computing environments, to name a few. Figure 5 As shown, bus 508 also couples electronic system 500 to a network (not shown) through network interface 516. Network interface 516 can include, for example, a wireless access point (such as Bluetooth or WiFi) or a radio circuit for connecting to a wireless access point. Network interface 516 can also include hardware for connecting a computer to a portion of a computer network, such as a local area network (“LAN”), a wide area network (“WAN”), a 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.

[0093] The 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.

[0094] Some embodiments 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 a computer-readable medium 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 DVD (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 medium can store the computer program instructions so as to replace, add, or modify the electronic component (e.g.,

[0095] Although the above discussion primarily refers to microprocessor or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself.

[0096] 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 personal or group computers. For purposes of this specification, the terms“display” or“displaying” mean 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.

[0097] 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; for example, 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; for example, by sending web pages to a web browser on a user’s client device in response to requests received from the web browser.

[0098] 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 inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0099] The computing system can include clients and servers. A client and server are generally remote from each other and typically 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 embodiments, 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.

[0100] Those skilled in the art will appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or combinations of both. To illustrate the 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 can be implemented in varying ways for each particular application. Various components and blocks can be differentially arranged from that shown without departing from the scope of the subject technology.

[0101] The subject technology is described as clauses:

[0102] For convenience, the various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the subject technology. The identification of the above-identified examples of aspects of the disclosure is not a limitation of the subject technology. The clauses are provided as examples and illustrative purposes only and are not limiting of the subject technology.

[0103] Clause 1. A handheld electronic medication request device. The handheld electronic medication request device comprises: a handle configured to be handheld by a patient; a display integrated in the handle; a touch-activated controller integrated in the handle or the display; one or more processors; and a memory comprising instructions that, when executed by the one or more processors, perform operations comprising: determining that the handheld electronic medication request device is electrically coupled to a medication delivery device for delivering medication to the patient; in response to determining that the handheld electronic medication request device is electrically coupled to the medication delivery device, receiving patient profile related information associated with the patient from the medication delivery device; presenting a user interface element on the display integrated in the handheld electronic medication request device, the user interface element comprising the patient profile related information associated with the patient; while presenting the user interface element on the display integrated in the handheld electronic medication request device, receiving a patient request to deliver a dose of medication to the patient via the touch-activated controller; and in response to the patient request, causing the dose of medication to be delivered to the patient.

[0104] Clause 2. The handheld electronic medication request device of clause 1, wherein the user interface element comprising the patient profile related information is presented concurrently with a second user interface element for providing the patient request to deliver the dose of medication, and the information related to the patient profile comprises an amount of time before the patient can cause another dose of medication to be delivered.

[0105] Clause 3. The handheld electronic medication request device of one of claim 1 or claim 2, wherein: the patient profile-related information comprises a reminder to administer a particular dose of medication at least a predetermined amount of time before a scheduled physical activity plan occurs.

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

[0107] Clause 5. The handheld electronic medication request device of any one of clauses 1-4, further comprising one or more sensors configured to detect a patient state, wherein the operations further comprise: responsive to a first detection that the patient is in a first state, the first state indicating that the patient is stable and able to provide input at the touch-activated controller, providing a user interface element responsive to the user input for requesting delivery of the dose of medication; and responsive to a second detection that the patient is in a second state, the second state indicating that the patient is unable to provide input at the touch-activated controller, providing an alternative to the user interface element for allowing the user patient to request delivery of the dose of medication.

[0108] Clause 6. The handheld electronic medication request device of clause 5, wherein the one or more sensors comprise a camera positioned on a patient-facing portion of the handheld electronic medication request device, and the handheld electronic medication request device further comprises instructions for performing operations from the group consisting of: confirming, based on imaging data captured by the camera, that the patient is authorized to self-administer the dose of medication from the medication delivery device; performing a pain assessment on the patient; and detecting a pain-indicating user input directed to one or more patient-interactive controls presented within a pain assessment user interface, based on imaging data captured by the camera.

[0109] Clause 7. The handheld electronic medication request device of any one of clauses 1-6, further comprising instructions for: after the dose of medication has been caused to be delivered to the patient via the medication delivery device: presenting a confirmation user interface element to the patient to indicate that the dose of medication has been successfully delivered.

[0110] Clause 8. The handheld electronic medication request device of any one of clauses 1-7, wherein the display comprises 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 positioned beneath the touch-sensitive surface of the display.

[0111] Clause 9. The handheld electronic medication request device of any one of clauses 1-8, further comprising: an elongated structure configured to be held by a patient’s hand when the patient’s thumb interacts with one or more of the touch-activated controls and the depressible mechanical button.

[0112] Clause 10. The handheld electronic medication request device of clause 9, wherein the handle comprises a sensor configured to detect a grip pressure applied by the patient’s hand, and further comprising instructions for: receiving, from the sensor, sensor data based on the grip pressure applied by the patient’s hand; and performing a pain assessment of the patient based on the grip pressure applied by the patient’s hand.

[0113] Clause 11. The handheld electronic medication request device of any one of clauses 1-10, further comprising: presenting, via the display, a pain assessment user interface comprising selectable user interface elements for allowing the patient to perform a pain assessment.

[0114] Clause 12. The handheld electronic medication request device of any one of clauses 1-11, further comprising: an accelerometer for detecting patient motion; and instructions for: detecting, via the accelerometer, motion of the patient after initiating delivery of the dose of medication; and based on patient interaction detected by one or more sensors of the handheld electronic medication request device, providing patient interaction information to another electronic device based on a determination that the motion of the patient corresponds to an adverse patient interaction.

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

[0116] Clause 14. The handheld electronic medication request device of clause 13, further comprising instructions for: collecting, via one or more sensors, pain assessment information from the patient; based on inputting the pain assessment information into the machine learning model, determining that a degree of pain of the patient does not correspond to an expected pain value based on an amount of medication delivered to the patient; and causing a pain assessment indication to be provided to the machine learning model, wherein the pain assessment indication is used in conjunction with the usage data to determine whether the machine learning model is detecting a medication abuse attempt.

[0117] Clause 15. The handheld electronic medication request device of clause 14, further comprising instructions to: determine that a dose configured to be delivered to the patient is too high in accordance with applying the usage data to a machine learning model; and reduce the dose configured to be delivered to the patient.

[0118] Clause 16. The handheld electronic medication request device of any of clauses 1-15, further comprising instructions to: provide patient interaction information to another electronic device based on interactions of the patient detected by one or more sensors of the handheld electronic medication request device.

[0119] Clause 17. The handheld electronic medication request device of any of clauses 1-16, further comprising instructions to: detect whether the handle is being handheld by the patient, and authorize a medication request by the patient based on the handle being handheld by the patient.

[0120] Clause 18. A machine-implemented method comprising: determining that a handheld electronic medication request device is electrically coupled to a medication delivery device for delivering medication to a patient grasping the handheld electronic medication request device; in response to determining that the handheld electronic medication request device is electrically coupled to the medication delivery device, receiving, by the handheld electronic medication request device, patient profile related information associated with the patient from the medication delivery device; presenting a user interface element on a display integrated in the handheld electronic medication request device, the user interface element comprising the patient profile related information associated with the patient; while presenting the user interface element on the display integrated in the handheld electronic medication request device, receiving a patient request to deliver a dose of medication to the patient via a touch-activated controller of the handheld electronic medication request device; and in response to the patient request, causing the dose of medication to be delivered to the patient.

[0121] Clause 19. A system comprising: a medication delivery device in operable communication with a control unit for controlling delivery of medication to a patient via the medication delivery device, wherein the control unit comprises a handheld electronic medication request device; one or more processors; and a memory comprising instructions that, when executed by the one or more processors, cause performance of operations comprising: determining that the handheld electronic medication request device is electrically coupled to a medication delivery device for delivering medication to the patient; receiving, from the medication delivery device, patient profile related information associated with the patient in response to determining that the handheld electronic medication request device is electrically coupled to the medication delivery device; presenting a user interface element on a display integrated in the handheld electronic medication request device, the user interface element comprising the patient profile related information associated with the patient; receiving a patient request to deliver a dose of medication to a patient via a touch-activated controller of the handheld electronic medication request device while presenting the user interface element on the display integrated in the handheld electronic medication request device; and causing the dose of medication to be delivered to the patient in response to the patient request.

[0122] Clause 20. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of a handheld electronic medication request device in operable communication with a medication delivery device, cause performance of operations comprising: determining that the handheld electronic medication request device is electrically coupled to a medication delivery device for delivering medication to a patient grasping the handheld electronic medication request device; receiving, from the medication delivery device, patient profile related information associated with the patient in response to determining that the handheld electronic medication request device is electrically coupled to the medication delivery device; presenting a user interface element on a display integrated in the handheld electronic medication request device, the user interface element comprising the patient profile related information associated with the patient; receiving a patient request to deliver a dose of medication to a patient via a touch-activated controller of the handheld electronic medication request device while presenting the user interface element on the display integrated in the handheld electronic medication request device; and causing the dose of medication to be delivered to the patient in response to the patient request.

[0123] Further considered:

[0124] It should be understood that the particular order or hierarchy of steps in the processes disclosed is an example that can be re-arranged, and that the particular order or hierarchy of steps is not a limitation. Some of the steps can be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not necessarily limited to the specific order or hierarchy presented.

[0125] The foregoing description is intended to enable any person skilled in the art to practice the various aspects described herein. The foregoing description provides various examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but should be given the full scope consistent with the language of the claims, wherein, unless specifically stated otherwise, reference to elements in the singular form is not intended to mean “one and only one,” but rather “one or more.” Unless otherwise stated, the term “some” means one or more. Masculine pronouns (e.g., his) include feminine and neuter pronouns (e.g., her and its), and vice versa. Titles and subtitles (if any) are used for convenience only and do not limit the invention described herein.

[0126] As used herein, the term "website" can 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. Therefore, the term "website" can be used interchangeably with the terms web page and server. The predicates "configured as," "operable as," and "programmed as" do not refer to any specific tangible or intangible modification of the subject matter, but are intended to be used interchangeably. For example, a processor or component configured to monitor and control operations can also refer to a processor programmed to monitor and control operations, or a processor operable to monitor and control operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code or operable to execute code.

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

[0128] Phrases such as “aspect” do not imply that a particular aspect is essential to the subject technology or that the subject technology has all the aspects. A disclosure related to one aspect can apply to all or one or more aspects. An aspect can provide one or more examples. Phrases such as “aspect” can refer to one or more aspects, and vice versa. Phrases such as “embodiment” do not mean that the embodiment is essential to the subject technology or that the embodiment applies to all configurations of the subject technology. A disclosure related to one embodiment can apply to all or one or more embodiments. An embodiment can provide one or more examples. Phrases such as “embodiment” can refer to one or more embodiments, and vice versa. Phrases such as “configuration” do not imply that the configuration is essential to the subject technology or that the configuration applies to all configurations of the subject technology. A disclosure related to one configuration can apply to all or one or more configurations. A configuration can provide one or more examples. Phrases such as “configuration” can refer to one or more configurations, and vice versa.

[0129] As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” can include calculating, computing, processing, deriving, generating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like via a hardware element based on input. Also, “determining” can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element based on input. “Determining” can include resolving, selecting, choosing, establishing and the like via a hardware element based on input.

[0130] As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” can include storing values in locations of a storage device for subsequent retrieval, sending values directly to a receiving party via at least one wired or wireless communication medium, sending or storing references to values, and the like via a hardware element. “Providing” can also include encoding, decoding, encrypting, decrypting, verifying, authenticating and the like via a hardware element.

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

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

[0133] As used herein, the term "correspond" or "corresponding" encompasses a structural, functional, quantitative, and / or qualitative association or relationship between two or more objects, data sets, information, and / or the like, preferably wherein the correspondence or relationship can be used to transform one or more of the two or more objects, data sets, information, and / or the like to appear to be the same or equal. The correspondence relationship can be assessed using one or more of a threshold, a range of values, fuzzy logic, pattern matching, a machine learning assessment model, or combinations thereof.

Claims

1. A handheld electronic drug request device, comprising: The handle is configured to be held by the patient. A display integrated into the controller; Touch-activated controllers integrated into gamepads or displays; One or more processors; and The memory includes instructions that, when executed by the one or more processors, perform operations including the following steps: It is determined that the handheld electronic drug request device is electrically coupled to a drug delivery device for delivering drugs to a patient; In response to determining that the handheld electronic drug request device is electrically coupled to the drug delivery device, patient profile information associated with the patient is received from the drug delivery device; User interface elements are displayed on a display integrated into the handle, the user interface elements including patient profile information associated with the patient; While displaying the user interface elements on a monitor integrated into the handheld device, the system receives a patient request to deliver a specific dose of medication to the patient via a touch-activated controller integrated into the handheld device or monitor; and In response to the patient's request, a certain dose of the drug is delivered to the patient.

2. The handheld electronic drug request device according to claim 1, wherein: The user interface element, including information related to the patient's file, and a second user interface element for providing the patient's request to deliver the prescribed dose of medication are presented simultaneously. The patient record information includes the amount of time before the patient is able to receive another dose of medication.

3. The handheld electronic drug request device according to claim 1 or claim 2, wherein: The patient record information includes reminders to administer a specific dose of medication at least for a predetermined time period prior to the scheduled physical activity.

4. The handheld electronic drug request device according to any one of claims 1 to 3, wherein, The patient request is provided as user input, which is selected from the group consisting of (i) audio input and (ii) visually detectable input.

5. The handheld electronic medication request device according to any one of claims 1 to 4, further comprising one or more sensors configured to detect patient status, wherein the operation further comprises: In response to a first detection that the patient is in a first state, indicating that the patient is stable and able to provide input at a touch-activated controller, a user interface element is provided in response to the user input for requesting delivery of the given dose of medication; as well as In response to a second detection that the patient is in a second state, indicating that the patient cannot provide input at the touch-activated controller, an alternative to the user interface elements is provided to allow the patient to request delivery of the specified dose of medication.

6. The handheld electronic drug request device according to claim 5, wherein, The one or more sensors include a camera located on the patient-facing portion of the handheld electronic medication request device, and the handheld electronic medication request device also includes instructions for performing operations from the group consisting of the following steps based on imaging data captured by the camera: Based on the imaging data captured by the camera, it is confirmed that the patient is authorized to administer the prescribed dose of medication to themselves from the drug delivery device; Perform a pain assessment on the patient; as well as Detect pain indication user input in response to one or more patient-interactive controls presented within the pain assessment user interface.

7. The handheld electronic drug request device according to any one of claims 1 to 6, further comprising instructions for the following steps: After the drug has been delivered to the patient via the drug delivery device: A confirmation user interface element is presented to the patient to indicate that the prescribed dose of medication has been successfully delivered.

8. The handheld electronic drug request device according to any one of claims 1 to 7, wherein, The display includes a touch-sensitive surface configured to receive touch input, and the display is configured to detect (i) a first user input to the touch-sensitive surface, and (ii) a second user input to a pressable mechanical button located below the touch-sensitive surface of the display.

9. The handheld electronic drug request device according to any one of claims 1 to 8, further comprising: An elongated structure configured to be held by the patient's hand when the patient's thumb interacts with one or more of the touch-activated controller and pressable mechanical buttons.

10. The handheld electronic drug request device according to claim 9, wherein, The handle includes a sensor configured to detect gripping pressure applied by the patient's hand, and also includes instructions for the following steps: Receive sensor data based on the gripping pressure applied by the patient's hand from the sensor; and This results in the patient's pain assessment being performed based on the gripping pressure applied by the patient's hand.

11. The handheld electronic drug request device according to any one of claims 1 to 10, further comprising: A pain assessment user interface is presented via the display, the pain assessment user interface including optional user interface elements for allowing the patient to perform a pain assessment.

12. The handheld electronic drug request device according to any one of claims 1 to 11, further comprising: An accelerometer used to detect patient movement; as well as Instructions for the following steps: After initiating the delivery of the specified dose of medication, the patient's movement is detected via the accelerometer; as well as Based on the patient's interactions detected by the accelerometer, which determine that the patient's movements correspond to unfavorable patient interactions, patient interaction information is provided to another electronic device.

13. The handheld electronic drug request device according to any one of claims 1 to 12, further comprising instructions for the following steps: Collect usage data on drug delivery dosages associated with multiple handheld electronic devices across patient populations; The usage data is then input into the machine learning model; Based on inputting the usage data into the machine learning model, it is determined that the patient request does not conform to the patient population; and In response to determining that the patient request does not conform to the patient population, an alert is presented to the display or a device associated with the patient's caregiver to indicate that the machine learning model has detected a drug abuse attempt based on one aspect of the patient request.

14. The handheld electronic drug request device of claim 13, further comprising instructions for the following steps: Pain assessment information is collected from the patient via one or more sensors; Based on inputting the pain assessment information into the machine learning model, it is determined that the patient's pain level does not correspond to the expected pain value based on the amount of medication delivered to the patient; and This causes pain assessment indicators to be provided to the machine learning model, wherein, The pain assessment indicators are combined with the usage data to determine whether the machine learning model is detecting a substance abuse attempt.

15. The handheld electronic drug request device of claim 14, further comprising instructions for the following steps: Based on applying the usage data to the machine learning model, it was determined that the dose configured to be delivered to the patient was too high; and Reduce the dose configured to be delivered to the patient.

16. The handheld electronic drug request device according to any one of claims 1 to 15, further comprising instructions for the following steps: Based on the patient's interactions detected by one or more sensors of the handheld electronic drug request device, patient interaction information is provided to another electronic device.

17. The handheld electronic drug request device according to any one of claims 1 to 16, further comprising instructions for the following operations: Detecting whether the handle is being held by the patient, and Based on the detection that the handle is being held by the patient, the patient's medication request is authorized.

18. A machine-implemented method, comprising: It is determined that the handheld electronic drug request device is electrically coupled to a drug delivery device for delivering medication to a patient holding the handheld electronic drug request device; In response to determining that the handheld electronic drug request device is electrically coupled to the drug delivery device, the handheld electronic drug request device receives patient profile information associated with the patient from the drug delivery device; User interface elements, including patient profile information associated with the patient, are displayed on a display integrated into the handheld electronic drug request device. While displaying the user interface elements on a screen integrated into a handheld electronic medication delivery device, the system receives a patient request to deliver a dose of medication to the patient via a touch-activated controller of the handheld electronic medication delivery device; and In response to the patient's request, a certain dose of the drug is delivered to the patient.

19. A system comprising: A drug delivery device operatively communicating with a control unit, the control unit being used to control the delivery of a drug to a patient via the drug delivery device, wherein the control unit includes a handheld electronic drug request device; One or more processors; and The memory includes instructions that, when executed by the one or more processors, cause operations including the following steps to be performed: It is determined that the handheld electronic drug request device is electrically coupled to a drug delivery device for delivering medication to the patient; In response to determining that the handheld electronic drug request device is electrically coupled to the drug delivery device, patient profile information associated with the patient is received from the drug delivery device; User interface elements, including patient profile information associated with the patient, are displayed on a display integrated into the handheld electronic drug request device. While displaying the user interface elements on a screen integrated into a handheld electronic medication delivery device, the system receives a patient request to deliver a dose of medication to the patient via a touch-activated controller of the handheld electronic medication delivery device; and In response to the patient's request, a certain dose of the drug is delivered to the patient.

20. A non-transient computer-readable storage medium comprising instructions that, when executed by one or more processors of a handheld electronic drug request device operatively in communication with a drug delivery device, cause to perform operations including the following steps: It is determined that the handheld electronic drug request device is electrically coupled to the drug delivery device for delivering medication to a patient holding the handheld electronic drug request device; In response to determining that the handheld electronic drug request device is electrically coupled to the drug delivery device, patient profile information associated with the patient is received from the drug delivery device; User interface elements, including patient profile information associated with the patient, are displayed on a display integrated into the handheld electronic drug request device. While displaying the user interface elements on a screen integrated into a handheld electronic medication delivery device, the system receives a patient request to deliver a dose of medication to the patient via a touch-activated controller of the handheld electronic medication delivery device; and In response to the patient's request, a certain dose of the drug is delivered to the patient.

Images