Patient care unit order confirmation

Abstract

The disclosed systems and methods provide patient care unit (PCU) order confirmation. A method can include authorizing a user to operate a medication delivery device. The method can also include retrieving a user history associated with the user in response to the authorizing, where the user history includes one or more dispensing records of pending medications. The method can also include determining one or more medication order candidates for a current administration based on a context that includes the user history. The method can also include presenting a user interface for confirming a medication order from the one or more medication order candidates. The method can also include configuring at least one parameter of the medication delivery device based on the confirmed medication order received from the user interface.

Description

[0001] Cross-reference to related applications

[0002] This application is a non-provisional application filed on May 22, 2020, entitled “PATIENT CARE UNIT ORDER CONFIRMATION”, U.S. Provisional Application Serial No. 63 / 029,300, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to medical devices, and more specifically to methods and systems for confirming medical orders on medical devices. Background Technology

[0004] To treat patients, physicians and other medication administrators may use a patient care device (“PCD”), also referred to herein as a patient care unit (“PCU”), which may include a variety of medical devices such as single or multi-channel infusion pumps, vital signs monitors, medication dispensing devices (e.g., cabinets, cases), medication preparation devices, automated medication dispensing devices, modules coupled to one of the aforementioned devices (e.g., syringe pump modules configured to be attached to an infusion pump), or other similar devices. A PCU may be used to administer intravenous (“IV”) infusion therapy to treat various medication complications in patients. IV infusion therapy typically involves infusing a fluidic drug solution (such as a medication or nutrient) from a fluid supply source (such as a bag, bottle, or other container) through tubing in the fluidic drug device into a cannula inserted into the patient’s blood vessel. Other medications may be ordered by the physician for the patient, such as pills or liquids, and administered via other routes of delivery, such as oral administration by the patient.

[0005] In some cases, a physician may prescribe multiple medications for a patient, and these medications will be administered at specific times of day or over several days, thus forming the patient's "pending medication order" list. In some implementations, the administration of multiple medications must occur sequentially, and in other cases, the administration of medications overlaps. In still other implementations, the administration of certain medications must be performed at specific times before or after the administration of one or more other medications.

[0006] Because patients can be associated with treatment protocols involving multiple pending orders with complex medication administration rules, reducing the risk of medication errors is becoming increasingly important when programming and configuring a PCU for a patient. Medication errors can include, for example, incorrect medication, incorrect dosage, incorrect timing of administration, incorrect route of delivery, or incorrect order of orders. One way to reduce medication errors is to provide barcode markings or radio frequency identification (RFID) tags on medications, which are then scanned to automatically enter the medication into the PCU. However, this only ensures that the PCU is correctly programmed based on the medication markings or tags and does not necessarily verify the correctness of the patient's treatment protocol, which may be managed by an upstream electronic medical record (EMR) management system. In some cases, such as when treating patients in the emergency room, the patient may not yet be registered with an EMR management system, or the EMR management system may be unavailable. In such cases, manually entering medication orders into the PCU may be unavoidable, which can introduce data entry errors. In some cases, the PCU may have information for automatic administration, but this information may be outdated or superseded by subsequent events, which can introduce PCU administration errors.

[0007] Therefore, there is a need to improve the systems and methods for confirming medical orders on medical devices such as PCUs. Summary of the Invention

[0008] According to various embodiments, this disclosure relates to a drug delivery device, comprising: a display; and a processor configured at least in part by instructions stored in a memory to: receive a credential associated with a user; authorize the user to operate the drug delivery device, the authorization being at least in part based on the credential; in response to the authorization, retrieve a user history associated with the user, wherein the user history includes one or more dispensing records for a pending drug; receive user input, unaware of the patient and the medication order, to initiate drug administration; determine one or more medication order candidates for the current administration based on a context including the user history; present a user interface via the display to confirm a medication order from the one or more medication order candidates; and configure at least one parameter of the drug delivery device based on the confirmed medication order received from the user interface.

[0009] In some embodiments, the processor is configured to retrieve one or more medication records from a set of most recent medication records associated with the user. In some embodiments, the processor is configured to transmit a request via a network to a remote database to retrieve user history, the request including the user's identifier. In some embodiments, the context includes the location of a medication delivery device or a care area, and the medication record includes information identifying the medication delivery location or care area, and the processor may be configured to determine one or more medication order candidates, including the processor being configured to identify medication order candidates based on a correspondence between the location of the medication delivery device or care area and the medication delivery location or care area. In some embodiments, the context includes the current time, and the medication record includes the time of administration for the pending medication, and the processor may be configured to determine one or more medication order candidates, including the processor being configured to identify medication order candidates based on a correspondence between the current time and the administration time.

[0010] In some implementations, the context includes a delivery route for administering a drug using a drug delivery device, and the processor can be configured to filter one or more medication order candidates based on a correspondence between the delivery route and delivery route information associated with a corresponding medication order candidate. The device may also include multiple administration channels; and the processor may further be configured to receive a selection of a first channel among the multiple channels for administering the drug, wherein the delivery route of the first channel included in the multiple administration channels differs from another delivery route of a second channel included in the multiple administration channels.

[0011] In some embodiments, the processor is configured to receive a user-associated credential via at least one of the following: a barcode scanner, a radio frequency identification (RFID) reader, a smart card reader, a near-field communication reader, or a biometric sensor. In some embodiments, the drug delivery device includes an infusion pump, and at least one parameter of the drug delivery device includes a pumping parameter. Other aspects include corresponding methods, apparatus, and computer program products for implementing the system.

[0012] According to various embodiments, this disclosure relates to a method for providing prescription confirmation at a drug delivery device, the method comprising: receiving a credential associated with a user; authorizing the user to operate the drug delivery device based at least in part on the received credential; retrieving, in response to the authorization, a user history associated with the user, wherein the user history includes one or more dispensing records for a pending drug; receiving user input, unaware of the patient and the prescription, to initiate drug administration; after receiving the user input, unaware of the patient and the prescription, determining one or more prescription candidates for the current administration based on a context including the user history; presenting a user interface via a display device to confirm the prescription from the one or more prescription candidates; and configuring at least one parameter of the drug delivery device based on the confirmed prescription received from the user interface. Other aspects include corresponding systems, apparatuses, and computer program products for implementing the method.

[0013] Furthermore, the aspects, features, and advantages of the subject matter, as well as the structure and operation of each aspect, will be described in detail below with reference to the accompanying drawings. Attached Figure Description

[0014] The various objects, features, and advantages of this disclosure can be more fully understood when considered in conjunction with the following drawings and with reference to the following detailed description, wherein similar reference numerals identify similar elements. The following drawings are for illustrative purposes only and are not intended to limit the scope of this disclosure, which is set forth in the following claims.

[0015] Figure 1 This is a partial block diagram of a system based on various aspects of the subject matter, including a patient care unit (PCU) with infusion equipment and associated controllers connected to a healthcare facility server to confirm medication orders when a clinician is identified by an infusion pump or controller, and also showing the interaction between an automated dispensing machine and the server.

[0016] Figure 2 This illustrates the use of connections to various aspects of the technology according to this subject matter. Figure 1 The diagram illustrates the automatic identification module of the controller associated with the infusion pump to authorize clinicians to use certain methods.

[0017] Figure 3 This is a display illustrating various aspects of the technology according to this subject matter. Figure 2 A diagram of an example user interface on an infusion pump or controller.

[0018] Figure 4 An example process for providing medical order confirmation in a patient care unit (PCU) on a medical device is described, based on various aspects of the technology in this subject matter.

[0019] Figure 5This is a conceptual diagram illustrating an example electronic system for providing confirmation of medical orders in a Patient Care Unit (PCU) according to various aspects of the technology in this subject matter. Detailed Implementation

[0020] While this document describes various aspects of the subject matter with reference to illustrative examples of specific applications, it should be understood that the subject matter is not limited to those specific applications. Those skilled in the art who have access to the teachings provided herein will recognize additional modifications, applications, and aspects within its scope, as well as additional areas where the subject matter will have significant practical value.

[0021] To avoid medication errors and ensure the highest quality of care, best practices in healthcare can encourage automated monitoring of devices and intelligent parameter constraints on the inputs provided to these devices to ensure the correct execution of medication orders. Since the Patient Care Unit (PCU) is positioned at the center of the healthcare device chain, it can ideally be positioned to provide medication order confirmation before administration. After a clinician is authorized to control the PCU, it can retrieve remote data from a healthcare server or database that includes the clinician's user history, such as dispensing records. Dispensing records may include pending records for medications. The PCU can assemble a context based on remote data and other local data and use this context to determine the next medication order for administration. A user interface can be presented on the PCU to confirm the next medication order. After confirmation, the PCU can be automatically programmed with the correct medication administration parameters, such as the pumping parameters for the infusion pump.

[0022] By enabling the PCU to provide prescription confirmation, several separate confirmation steps can be consolidated at the PCU, simplifying patient care and avoiding additional steps that could introduce errors and inconsistencies. For example, scanning individual medications can be avoided, and the PCU can be programmed and configured directly based on the next medication order. Furthermore, scanning the identifier tag attached to the patient can be avoided by using the patient ID associated with the PCU, or by using geolocation to determine the correct patient for the next medication administration. All data can be consolidated and displayed at the PCU, allowing clinicians to proceed with medication administration simply by confirming everything is correct.

[0023] For the purpose of illustrating embodiments of the invention, reference will now be made in more detail to the accompanying drawings, wherein similar reference numerals designate corresponding or similar elements in several views. Figure 1 A partial block diagram of a system according to a specific aspect of the present invention is shown. Figure 1In the example shown, the patient care unit (PCU) is an infusion pump system 20 connected to the patient 22 to infuse medication fluid from an IV fluid container 24 (such as a bag) to the patient 22 via a fluid administration device 26. The pump system includes an infusion pump 28 located to the left of the controller 30 and an automatic identification module 32, or "automatic ID module," located to the right of the controller. In this case, the identification module includes a barcode reader 34 attached to a tether 33.

[0024] Controller 30 connects to server 35, which can take the form of any one or more servers within a healthcare facility. The box 35, identified as a “server,” can be a single server or may include multiple servers or computers and storage for data storage. Server 35 can communicate with database 60, which can store patient identification data and pending medication orders for patients admitted to the healthcare facility. It can also store clinician identification data and other data, such as user history 70 associated with a specific user or clinician. User history 70 may include dispensing records 80, which may include records of each medication dispensed by the associated clinician. For example, when a clinician retrieves a medication using an automated dispensing machine (“ADM”) 37, an associated record may be created in pending record 82. Pending record 82 may be associated with open or pending medication orders, while closed record 84 may be associated with medication orders that have already been administered. Although pending record 82 and closed record 84 are displayed as separate record sets, it should be understood that these two record sets can be stored in a single table, with record fields identifying which records are pending or closed.

[0025] For ease of discussion and illustration, the “server” identified by the numeral 35 may also include a server of a company that provides the infusion pump system 20 and establishes a communication protocol between the infusion pump system and the healthcare facility server. Server 35 receives medication order entries 36 electronically from one or more sources, such as pharmacy information systems (PIS), laptops, prescription input devices, personal digital assistants (“PDAs”), and other devices. Medication order entries 36 may also be entered into the server by the pharmacy. Dispensing records 80 may each be associated with a corresponding medication order entry 36. Controller 30 may communicate with server 35 via any wired or wireless means, and the server may communicate with other devices via wired or wireless means.

[0026] An automated medication dispensing machine (“ADM”) 37 is also shown, and it typically includes medications for nearby patients. The ADM has a device called a medication processor 50. Figure 5The dispensing processor (as shown) can require clinicians to identify the medication before allowing its withdrawal. The dispensing processor can allow only specific clinicians to remove specific items from the ADM. The ADM can also contain “controlled items,” which, for the purposes of this article, can be any item the healthcare facility hosting the ADM wishes to track. This can include narcotics, but can also include items of much lower sensitivity.

[0027] Figure 2 This illustrates the use of connections to various aspects of the technology according to this subject matter. Figure 1 The diagram illustrates the means by which the controller associated with the infusion pump authorizes the clinician through an automatic identification module. Upon initial power-up of the controller 30, the controller 30 may prompt the clinician to log in. The clinician may possess an identification 39 that can be scanned by an embedded code reader 40 or a code scanner 34 with a tether 33. Figure 2 As shown, reader 40 and scanner 34 constitute part of an automatic identification module 32 that can be attached to the PCU. The barcode reader 40 and / or barcode scanner 34 may include one or more radio frequency identification (RFID) reading elements, one or more smart card reading elements, one or more near-field communication reading elements, or one or more biometric identification sensing elements to process (e.g., collect, verify, authenticate) credentials provided by clinicians. The automatic identification module 32 can communicate with the controller 30 via wired or wireless means. In one embodiment, the controller 30 includes a communication interface (“CI board”) containing a processor, programming, and substantial memory. The CI board contacts the automatic identification module 32. Upon receiving a clinician credential, the CI board may send a message to the controller 30 indicating that the clinician is requesting login. This message may include the received clinician credential. In some embodiments, the automatic identification module 32 may verify and / or validate the credential and include the result of the verification or validation in a message provided to the controller 30. In some embodiments, the functionality of the CI board is performed entirely by the processor of the controller 30 and / or other components within the controller 30. The processor of controller 30 can then verify whether the clinician is authorized to control infusion pump system 20. For example, in some embodiments, infusion pump system 20 can be assigned to a specific patient identifier, and a lookup can be performed to verify whether the clinician is authorized to provide care to a patient associated with that specific patient identifier.

[0028] After successful authorization of the clinician's credentials, the display 42A of the infusion pump 28 and / or the display 42B of the controller 30 can display a user interface to confirm the next medication order. (See below for details.) Figure 3The discussed approach allows for the intelligent selection of the next medication order based on context, including the user history 70 associated with the clinician. The user interface can display the pre-selected next medication order and request confirmation before the infusion pump 28 is programmed and configured.

[0029] As used herein, the term "medication" is intended to be understood in a broad sense in relation to medical care. "Medication" includes oral medications and medication infusions, but also aims to include physical therapy, recording vital signs, surgical preparation, and other medical care. Furthermore, "administer" is intended to be understood in a broad sense as the delivery of medical care. "Administer" means covering the delivery of medications such as oral medications, as well as the supply of intravenous fluids and other medical care to a patient. The exemplary controller 30 discussed herein and shown as a separate unit in the accompanying drawings may actually be part of an infusion pump or other medical device. Medical orders identifying an individual or medication or a procedure of administration are provided as an implementation. In a particular healthcare facility, this identification may be carried out according to different medical orders; the orders shown here are implementation examples.

[0030] Figure 3 This is a display illustrating various aspects of the technology according to this subject matter. Figure 2 A diagram of an example user interface on an infusion pump or controller. About Figure 3 Displays 342A, 342B, and 342C can correspond to Figure 1 and Figure 2 The display 342A or display 42B is included. In some implementations, the displays 342A-342C can be displayed on a remote device, such as a tablet, smartphone, laptop, or desktop computer.

[0031] Display 342A can be shown after controller 30 is started. As shown on display 342A, the user interface does not display any information about the patient or medical orders and waits for the clinician to successfully log in before displaying any information. Assuming the clinician is successfully authenticated using the above procedure, the user interface can switch to display 342B.

[0032] As shown on display 342B, the next medication order for drug administration has been pre-selected and displayed to the clinician. Details of the indicated medication order include: the associated clinician, the associated patient, the time and location of administration, and information such as the drug name, route of administration, drug concentration, and pump parameters such as the infusion volume to be infused (“VTBI”) and its infusion rate over time. If everything appears correct, the clinician can simply select the “Confirm Order” option and program the infusion pump 28 according to the pump parameters in the indicated order. The following is in conjunction with… Figure 4 Provide a more detailed description of example steps for pre-selected medication orders.

[0033] If the pre-selected next medication order is not the desired order, the user interface can include controls to receive input for selecting a different order. Figure 3 In B, the user interface includes a "Select Different Prescription" control element for receiving this input. Once activated, the control element causes the user interface to transition to display 342C. Display 342C shows a list of candidate prescriptions. This prescription can be associated with a selection control element that can interact with to receive a selection of the desired medication prescription. The list of candidate prescriptions can be narrowed down based on contextual information detected or accessible by the system. The following is in conjunction with... Figure 4 A further detailed description of the example steps for narrowing down medical orders is provided.

[0034] Figure 4 An example process 400 for providing physician order confirmation in a patient care unit (PCU) on a medical device, based on various aspects of the techniques described herein, is presented. For illustrative purposes, reference is made to... Figure 1 A-3 describes the various blocks of example process 400, as well as the components and / or processes described herein. One or more blocks of process 400 may be implemented, for example, by one or more computing devices described herein, such as a PCU, a module coupled to a PCU, or a server in a medical facility (e.g., server 35). In some embodiments, one or more blocks may be implemented separately from other blocks and may be implemented by one or more different processors or devices. Also for illustrative purposes, the blocks of example process 400 are described as occurring serially or linearly. However, multiple blocks of example process 400 may occur in parallel. Furthermore, the blocks of example process 400 do not need to be executed in the order shown and / or one or more blocks of example process 400 do not need to be executed.

[0035] In the illustrated example flowchart, a medical device or PCU (such as infusion pump system 20) can authorize a user (such as a clinician) to operate infusion pump system 20 (411). As described above, the user can use a badge with a barcode, RFID tag, or other identifier as authorization credentials. Infusion pump system 20 can receive the credentials using a corresponding reader, such as a barcode reader 34 with a tether 33. By communicating with server 35 and / or database 60, infusion pump system 20 can verify that the credentials are authorized.

[0036] Processing 400 may, in response to authorization, continue retrieving the user's associated user history, which includes one or more pending medication records (412). Reference Figure 1This could correspond to the infusion pump system 20 querying database 60 to retrieve user history 70 associated with a user, where user history 70 includes dispensing records 80 with pending records 82. For example, user history 70 could be associated with a user ID that matches a previously authorized clinician ID. In another example, user history 70 could be associated with another user ID, such as a supervisor who authorized access based on the authorized clinician ID. Figure 1 As shown, when an associated user retrieves medication from a dispensing device such as ADM 37, each pending record 82 can be created, and each record 82 can reference an associated medication order entry 36, which may be provided by the pharmacy, as described above. In some cases, pending records 82 may include a large number of records. In this case, instead of retrieving all pending records 82, only the most recent set of dispensing records may be retrieved, for example, up to a fixed number or based on a time deadline. The time deadline can be dynamically assessed based on information associated with the authorized user. For example, an attendance system may include the authorized user's shift start time. The shift start time may represent the earliest time of the current day that can be associated with a dispensing event related to the authorized user.

[0037] According to various implementation schemes, the system (optionally in some implementations) receives user input that is unaware of the patient and order to initiate drug administration (413). For the purposes of this disclosure, “patient and order agnostic user input” means: input that does not include any information identifying the patient or order. In this respect, the system may receive information about the drug being administered, but may not know which patient the drug is being administered to or whether the drug is currently associated with an order.

[0038] Processing 400 can continue to determine one or more medication order candidates for the current administration based on user input (if available) of the patient and the medication order, as well as context including user history (414). When user input of unknown patient and medication order is received, the system currently does not know which patient the medication delivery device is designated for or associated with, and there is currently no medication order associated with a patient or a medication being programmed into the device. Therefore, the system performs medication order association independently before the patient or medication is identified to the system. Instead, pending records 82 in the retrieved user history 70, along with various other factors, can be considered to determine medication order candidates. Factors in the context can be used to narrow down the medication order candidates to a list of the most likely next medication order—for example, by assigning a relevance weight to each medication order candidate, where each factor in the context contributes a weighted value to each medication order candidate. After weighting, one or more factors can be used to narrow down or eliminate the list of medication order candidates, such as falling below a weighting threshold or meeting a maximum number of candidates (e.g., by including the 3 candidates with the highest weighted values).

[0039] In some implementations, the context may include the location of the medical device and / or a defined care area. For example, the infusion pump system 20 may be pre-programmed with a deployment location and / or care area, or may otherwise include location tracking components, such as a Global Positioning System (GPS) sensor or a radio triangulation sensor, to determine the current location.

[0040] In some implementations, the context includes the location of the medication delivery device or the care area. For example, a medication dispensing record may include information identifying the dispensing location or medication dispensing care area. In this regard, the system can identify medication order candidates to determine one or more medication order candidates by identifying a correspondence between the location of the medication delivery device or care area and the dispensing location or medication dispensing care area. This correspondence may include, but is not limited to, differences or satisfaction of one or more thresholds (e.g., the number of matching features), or it may be configurable. The correspondence may also be a dynamic correspondence based on medication, patient, care area, etc.

[0041] By querying patient data at the current location via server 35, potential patients can be limited to those located at, near, or within the designated care area of ​​the medical device. Therefore, medication order candidates can be narrowed down to orders specifically targeting patients at the location of the medical device or within its designated care area.

[0042] In some implementations, the context may include the current time and the administration time for the medication order. For example, medication orders with an administration time closer to the current time may be preferred as medication order candidates. The context may also include the dispensing time for the medication order, which can be compared to the current time. For example, the most recently dispensed medication order may be favored because the most recently dispensed item may be the most urgent for the clinician. The earliest dispensed medication order may also be favored because the earliest dispensed item may be the first dispensed in the drug sequence. If rules are defined for the sequential administration of multiple medication orders, these rules may also be considered when selecting and weighting medication orders.

[0043] In some implementations, the context may include the patient associated with the medical device. For example, if the medical device is configured to care for only a specific patient, medication order candidates may be restricted to that specific patient.

[0044] In some implementations, the context may include the route of delivery for the medication order. For example, the infusion pump system 20 may only accept medication orders intended for intravenous infusion, rather than other routes such as oral administration.

[0045] In some implementations, context can exclude positive patient identification, such as when a patient has just been admitted to the emergency room and there is no patient EMR available yet. In this case, medication order candidates can still be determined based on the other contextual factors mentioned above. Similarly, when other factors are missing or unavailable, the remaining factors in the context can still be used to determine medication order candidates.

[0046] According to some embodiments, the context includes the delivery route for delivering the drug using a drug delivery device, and the system can filter one or more medication order candidates based on a correspondence between the delivery route and delivery route information associated with the corresponding medication order candidate. As previously mentioned, the correspondence may include, but is not limited to, differences or satisfaction of one or more thresholds (e.g., the number of matching features), or may be configurable. Furthermore, in some embodiments, the drug delivery device may include multiple administration channels. In this regard, the system may be configured to receive a selection of a first channel among multiple channels for administering the drug, and the delivery route of the first channel included in the multiple administration channels may differ from another delivery route of a second channel included in the multiple administration channels.

[0047] Process 400 can continue to present the user interface for confirming a medication order from one or more medication order candidates (415). For example, after narrowing down the medication order candidates, if only one order candidate remains, that order can be selected for confirmation. However, if multiple medication order candidates still remain, the most likely next order can be pre-selected, such as... Figure 3 As shown in the user interface of display 342B, other medication order candidates can still be selected using the selection user interface shown in display 342C. For example, the most likely next medication order can be selected by choosing the candidate with the highest weighting.

[0048] For example, the selection list in display 342C can be sorted in a weighted order, where prescription #1 is determined as the most likely next medication prescription, and prescription #3 is determined as the least likely next medication prescription. For example, John Doe could be located in room 215, while Robert Grant could be located in room 226. Since the medical device is in room 215, John Doe's medication prescription is listed first. Furthermore, the current time could be 11:00 AM, indicating that heparin administration has already occurred, while aminophylline administration is 20 minutes away. Therefore, the prescription with the closest administration time is preferred and listed as prescription #1.

[0049] In some implementation schemes, users can execute medication dispensing events and thus associate these events with the system. The user then associates with the pump via credentials. Medication order information from the dispensing device can be provided and confirmed at the pump before the user enters any order-specific information.

[0050] Processing 400 can continue configuring at least one parameter (416) of the medical device based on the confirmed medication order received from the user interface. Thus, after a clinician confirms a pre-selected order on display 342B or selects a different order on display 342C, the pumping parameters for the confirmed order can be programmed into the infusion pump 28, including, for example, VTBI and infusion rate. Once medication administration is complete, the medical device can send a notification to server 35 to move the associated record in pending records 82 to closed records 84.

[0051] Many aspects of the above-described example processing 400, along with its related features and applications, can also be implemented as software processing, specified as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium), and capable of automatic execution (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause the one or more processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard disk drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted via wireless or wired connections.

[0052] The term "software" refers, where appropriate, to firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processor processing. Furthermore, in some embodiments, the multiple software aspects disclosed herein may be implemented as sub-parts of a larger program while maintaining the distinct software aspects disclosed herein. In some embodiments, the multiple software aspects may also be implemented as separate programs. Finally, any combination of separate programs that jointly implement the software aspects described herein is within the scope of this disclosure. In some embodiments, when a software program is installed to operate on one or more electronic systems, one or more specific machine implementations define the operations that execute and run the software program.

[0053] Computer programs (also referred to as programs, software, software programs, scripts, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or processing languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored as part of a file containing other programs or data (e.g., one or more scripts stored in a markup language file), in a single file dedicated to the program in question, or in multiple coordinating files (e.g., a file storing one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communication network.

[0054] Figure 5 This is a conceptual diagram illustrating an example electronic system 500 for providing confirmation of medical orders in a Patient Care Unit (PCU) according to various aspects of the subject matter. The electronic system 500 may be software associated with performing one or more parts or steps of processing 400, or software related to... Figure 1-4The computing device that provides the components and processing associated software. (Regarding...) Figure 1-4 In combination with the above disclosure, electronic system 500 may represent the infusion pump system 20, infusion pump 28, or controller 30 described above. In this respect, electronic system 500 may be a microcomputer, personal computer, or mobile device such as a smartphone, tablet, laptop, PDA, augmented reality device, wearable device (such as a watch, bracelet, or glasses, or a combination thereof), or other touchscreen or television having one or more processors embedded therein or coupled thereto, or any other type of computer-related electronic device with network connectivity.

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

[0056] Bus 508 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 500. For example, bus 508 communicatively connects one or more processing units 512 to ROM 510, system memory 504, and permanent storage device 502.

[0057] One or more processing units 512 retrieve instructions to be executed and data to be processed from these different memory units in order to perform the processing disclosed in this subject matter. In different embodiments, the one or more processing units may be a single-processor or a multi-core processor.

[0058] ROM 510 stores static data and instructions required by one or more processing units 512 and other modules of the electronic system. On the other hand, permanent storage device 502 is a read-write memory device. This device is a non-volatile memory cell that can store instructions and data even when the electronic system 500 is powered off. Some embodiments disclosed in this subject matter use mass storage devices (such as magnetic disks or optical disks and their corresponding disk drives) as permanent storage device 502.

[0059] Some embodiments use removable storage devices (such as floppy disks, flash drives, and their corresponding disk drives) as permanent storage device 502. Like permanent storage device 502, system memory 504 is a read-write memory device. However, unlike storage device 502, system memory 504 is volatile read-write memory, such as random access memory. System memory 504 stores some instructions and data required by the processor during operation. In some embodiments, the processing of this disclosure is stored in system memory 504, permanent storage device 502, and / or ROM 510. One or more processing units 512 retrieve instructions to be executed and data to be processed from these different memory units to perform the processing of some embodiments.

[0060] Bus 508 is also connected to input and output device interfaces 514 and 506. Input device interface 514 enables users to communicate information and select commands to the electronic system. Input devices used with input device interface 514 include, for example, alphanumeric keypads and pointing devices (also referred to as "cursor control devices"). Output device interface 506 enables, for example, the display of images generated by electronic system 500. Output devices used with output device interface 506 include, for example, printers and display devices such as cathode ray tube (CRT) or liquid crystal display (LCD). Some implementations include devices such as touchscreens that function as both input and output devices.

[0061] In addition, bus 508 couples electronic system 500 to a network (not shown) via network interface 516. Network interface 516 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interface 516 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a part of a computer network, such as a local area network (“LAN”), wide area network (“WAN”), wireless LAN or intranet, or a network of networks, such as the Internet. Any or all components of electronic system 500 may be used in conjunction with this subject matter.

[0062] These functions can be implemented in computer software, firmware, or hardware. These technologies can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. Processing and logic flows can be executed by one or more programmable processors and one or more programmable logic circuits. General-purpose and special-purpose computing devices and storage devices can be interconnected through communication networks.

[0063] Some implementations include electronic components, such as microprocessors, storage devices, and memories, that store computer program instructions in a machine-readable or computer-readable medium (which may alternatively be referred to as a computer-readable storage medium, machine-readable medium, or machine-readable storage medium). Some examples of such computer-readable media include RAM, ROM, read-only optical disc (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), read-only digital versatile optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state drives, read-only and recordable... Optical discs, high-density optical discs, any other optical or magnetic media, and floppy disks. Computer-readable media may store computer programs executable by at least one processing unit and include a set of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as code generated by a compiler, and files containing higher-level code executed by a computer, electronic component, or microprocessor using an interpreter.

[0064] While the above discussion primarily concerns microprocessors or multi-core processors that execute software, some implementations are executed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions stored on the circuit itself.

[0065] As used in this specification and any claim of this application, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical devices. These terms do not include people or groups of people. For the purposes of this specification, the terms "display" or "shown" mean displayed on an electronic device. As used in this specification and any claim of this application, the terms "computer-readable medium" and "computer-readable media" are limited entirely to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or any other transient signals.

[0066] To provide interaction with the user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including acoustic, voice, or tactile input. Furthermore, the computer can interact with the user by sending and receiving files to and from the device used by the user; for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

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

[0068] A computing system may include clients and servers. Clients and servers are typically geographically separated but can interact via a communication network. The relationship between clients and servers arises from computer programs running on their respective computers, and a client-server relationship exists between them. In some implementations, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to a user interacting with the client device and to receive user input from that user). Data generated at the client device (e.g., the result of user interaction) can be received from the client device at the server.

[0069] Those skilled in the art will understand that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability between hardware and software, the functionality of the various illustrative blocks, modules, elements, components, methods, and algorithms has been generally described above. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Skilled technicians can implement the described functionality in different ways for each specific application. Various components and blocks can be arranged in different ways (e.g., in different orders, or partitioned in different ways), all without departing from the scope of the subject matter.

[0070] It should be understood that the specific order or hierarchy of steps in the disclosed process is illustrative of the example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some of these steps may be performed simultaneously. The claims accompanying the method present the elements of various steps in a sample order, but this does not imply limitation to the presented specific order or hierarchy.

[0071] This subject matter technology is described in the form of clauses:

[0072] For convenience, examples of various aspects of this disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided by way of example and do not limit the subject matter. The identification of figures and reference numbers is provided for illustrative purposes only, and these clauses are not limited by these identifications.

[0073] Clause 1. A drug delivery device, comprising: a display; and a processor configured at least in part by instructions stored in a memory to: receive a credential associated with a user; authorize the user to operate the drug delivery device, the authorization being at least in part based on the credential; in response to the authorization, retrieve a user history associated with the user, wherein the user history includes one or more dispensing records for a pending drug; receive user input, unaware of the patient and the prescription, to initiate drug administration; determine one or more prescription candidates for the current administration based on a context including the user history; present a user interface via the display to confirm a prescription from the one or more prescription candidates; and configure at least one parameter of the drug delivery device based on the confirmed prescription received from the user interface.

[0074] Clause 2. The drug delivery device according to Clause 1, wherein the processor is configured to retrieve one or more dispensing records from a set of the most recent dispensing records associated with the user.

[0075] Clause 3. A drug delivery device according to any of the preceding clauses, wherein the processor is configured to transmit a request via a network to a remote database to retrieve user history, the request including the user's identifier.

[0076] Clause 4. A medication delivery device according to any of the preceding clauses, wherein the context includes the location or care area of ​​the medication delivery device, and wherein the medication dispensing record includes information identifying the medication dispensing location or medication dispensing care area, and wherein the processor is further configured to determine one or more medication order candidates, including that the processor is configured to identify medication order candidates based on a correspondence between the location or care area of ​​the medication delivery device and the medication dispensing location or medication dispensing care area.

[0077] Clause 5. A drug delivery device according to any of the preceding clauses, wherein the context includes the current time, and wherein the dispensing record includes the administration time for the drug to be determined, and wherein the processor is further configured to determine one or more medication order candidates, including that the processor is configured to identify the medication order candidates based on the correspondence between the current time and the administration time.

[0078] Clause 6. A drug delivery device according to any of the preceding clauses, wherein the context includes a delivery route for administering a drug using the drug delivery device, and wherein the processor is further configured to filter one or more drug order candidates based on a correspondence between the delivery route and delivery route information associated with the corresponding drug order candidate.

[0079] Clause 7. The drug delivery device according to Clause 6 further includes: a plurality of administration channels; and wherein the processor is further configured to receive a selection of a first channel among the plurality of channels for administering the drug, and wherein the delivery path of the first channel included in the plurality of administration channels is different from another delivery path of the second channel included in the plurality of administration channels.

[0080] Clause 8. A drug delivery device according to any of the preceding clauses, wherein the processor is configured to receive a credential associated with a user via at least one of the following: a barcode scanner, a radio frequency identification (RFID) reader, a smart card reader, a near-field communication reader, or a biometric sensor.

[0081] Clause 9. A drug delivery device according to any of the preceding clauses, wherein the drug delivery device includes an infusion pump, and wherein at least one parameter of the drug delivery device includes a pumping parameter.

[0082] Clause 10. A method for providing prescription confirmation at a drug delivery device, the method comprising: receiving a credential associated with a user; authorizing the user to operate the drug delivery device based at least in part on the received credential; retrieving, in response to the authorization, a user history associated with the user, wherein the user history includes one or more dispensing records for a pending drug; receiving user input via the drug delivery device, unaware of the patient and the prescription, to initiate drug administration; after receiving the user input, unaware of the patient and the prescription, determining one or more prescription candidates for the current administration based on a context including the user history; presenting a user interface via a display device for the drug delivery device to confirm the prescription from the one or more prescription candidates; and configuring at least one parameter of the drug delivery device based on the confirmed prescription received from the user interface.

[0083] Clause 11. The method according to Clause 10, wherein retrieving one or more medication records is retrieved from a set of the most recent medication records associated with the user.

[0084] Clause 12, the method described pursuant to Clause 10 or Clause 11, further comprises: transmitting a request over a network to a remote database to retrieve user history, the request including an identifier associated with the user.

[0085] Clause 13. The method according to any one of Clauses 10 to 12, wherein the context includes the location of the medication delivery device or the care area, and wherein the medication record includes information identifying the medication location or medication care area, and wherein the method further includes: identifying medication order candidates based on the correspondence between the location of the medication delivery device or the care area and the medication location or medication care area.

[0086] Clause 14. The method according to any one of Clauses 10 to 13, wherein the context includes the current time, and wherein the dispensing record includes the time of administration for the pending medication, the method further comprising: identifying medication order candidates based on the correspondence between the current time and the administration time.

[0087] Clause 15. The method according to any one of Clauses 10 to 14, wherein the context includes a delivery route for administering a drug using a drug delivery device, the method further comprising: filtering one or more drug order candidates based on a correspondence between the delivery route and delivery route information associated with a corresponding drug order candidate.

[0088] Clause 16. The method according to Clause 15 further includes: receiving a selection of a first channel among a plurality of channels for administering the drug, wherein the delivery pathway included in the first channel of the plurality of channels is different from another delivery pathway included in a second channel of the plurality of channels.

[0089] Clause 17. The method described in any one of Clauses 10 to 16, wherein authorizing a user comprises: receiving a credential associated with the user via at least one of a barcode scanner, a radio frequency identification (RFID) reader, a smart card reader, a near field communication reader, and a biometric sensor.

[0090] Clause 18. The method according to any one of Clauses 10 to 17, wherein the drug delivery device includes an infusion pump, and wherein at least one parameter of the drug delivery device includes a pumping parameter.

[0091] Clause 19. A non-transitory storage medium including instructions that, when read by one or more processors, cause one or more processors to perform a method comprising the steps of: receiving a credential associated with a user; authorizing the user to operate a drug delivery device based at least in part on the received credential; retrieving a user history associated with the user in response to the authorization, wherein the user history includes one or more dispensing records for a pending drug; receiving user input via the drug delivery device to initiate drug administration without knowing the patient and the prescription; after receiving the user input without knowing the patient and the prescription, determining one or more prescription candidates for the current administration based on a context including the user history; presenting a user interface via a display device for the drug delivery device to confirm the prescription from the one or more prescription candidates; and configuring at least one parameter of the drug delivery device based on the confirmed prescription received from the user interface.

[0092] Clause 20. The non-transitory storage medium as described in Clause 19, wherein the context includes the location of a medication delivery device or a care area, and wherein the medication record includes information identifying the medication delivery location or medication care area, and wherein the method further includes: identifying medication order candidates based on a correspondence between the location of the medication delivery device or the care area and the medication delivery location or medication care area.

[0093] Also considered:

[0094] It should be understood that the specific order or hierarchy of steps in the disclosed process is illustrative of the example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some of these steps may be performed simultaneously. The claims accompanying the method present the elements of various steps in a sample order, but this does not imply limitation to the presented specific order or hierarchy.

[0095] The preceding description is provided to enable those skilled in the art to practice the various aspects described herein. The preceding 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 are given the full scope consistent with the language of the claims, wherein, unless specifically stated otherwise, reference to an element in the singular does not mean “one and only one,” but rather “one or more.” Unless otherwise specifically 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 this disclosure.

[0096] The term "website" as used herein can include any aspect of a website, including one or more web pages, one or more servers used to host or store content related to those web pages, 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 imply any specific tangible or intangible modification to the subject, but are intended to be used interchangeably. For example, a processor configured to monitor and control operations or components may also mean a processor programmed to monitor and control operations or an operable processor to monitor and control operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code or an operable processor to execute code.

[0097] As used herein, the term "automatic" can include actions performed by a computer or machine without user intervention; for example, instructions that respond to a predicate action via a computer, machine, or other initiation mechanism. The word "example" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as preferentially superior to other aspects or designs.

[0098] Phrases such as "aspect" do not imply that the aspect is necessary to the subject matter technology, or that the aspect is applicable to all configurations of the subject matter technology. Disclosures relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. Phrases such as "aspect" may refer to one or more aspects, or vice versa. Phrases such as "implementation" do not imply that the implementation is necessary to the subject matter technology, or that the implementation is applicable to all configurations of the subject matter technology. Disclosures relating to an implementation may apply to all implementations, or one or more implementations. An implementation may provide one or more examples. Phrases such as "implementation" may refer to one or more implementations, or vice versa. Phrases such as "configuration" do not imply that such a configuration is necessary to the subject matter technology, or that such a configuration is applicable to all configurations of the subject matter technology. Disclosures relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. Phrases such as "configuration" may refer to one or more configurations, or vice versa.

[0099] 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 that includes data fields and / or other control elements for receiving input signals or providing electronic information, and / or providing information to the user in response to any received input signals. Control elements may include dial pads, buttons, icons, selectable areas, or other perceptible markings presented via the UI, which initiate data exchange with the device presenting the UI when interacted with (e.g., click, touch, select, etc.). The UI may use, in whole or in part, technologies such as Hypertext Markup Language (HTML), Flash, etc. TM JAVA TM .NET TM The implementation may use C, C++, web services, or rich site summaries (RSS) technologies. In some implementations, the UI may be included in a separate client (e.g., a thick client, a fat client) configured to communicate (e.g., send or receive data) according to one or more of the described aspects. Communication may be between medical devices or servers with which they communicate, or from medical devices or servers.

[0100] As used herein, the term "determine" or "determined" encompasses a wide variety of actions. For example, "determined" can include calculations, operations, processing, derivations, generation, retrieval, lookups (e.g., searching in tables, databases, or other data structures), and determinations via hardware components without user intervention. Furthermore, "determined" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), and so on via hardware components without user intervention. "Determined" can also include parsing, selecting, picking, and building via hardware components without user intervention.

[0101] As used herein, the term “provide” or “provide” encompasses a wide variety of actions. For example, “providing” can include storing a value at a location on a storage device for later retrieval, transmitting a value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, etc. “Providing” can also include encoding, decoding, encrypting, decrypting, acknowledging, verifying, etc., via hardware components.

[0102] As used herein, the term "message" encompasses a variety of formats used to convey (e.g., transmit or receive) information. A message may include summaries of machine-readable information such as XML documents, fixed-field messages, comma-separated messages, etc. In some implementations, a message may include signals of one or more representations used to transmit information. Although stated in the singular, it is understood that a message may consist of multiple parts, be transmitted, stored, received, etc.

[0103] As used herein, the term "selectively" or "selective" can cover a wide variety of actions. For example, "selective" processing may include determining an option from a plurality of options. "Selective" processing may include one or more of the following: dynamically determined input, pre-configured input, or user-initiated input for making the determination. In some implementations, n input switches may be included to provide selectivity functionality, where n is the number of inputs used for making the selection.

[0104] As used herein, the term "correspondence" or "corresponding to" encompasses a structural, functional, quantitative, and / or qualitative association or relationship between two or more objects, datasets, information, and / or similar entities, preferably wherein the correspondence or relationship can be used to translate two or more objects, information, and / or similar entities to appear identical or equivalent. Correspondence can be evaluated using one or more of the following: thresholds, value ranges, fuzzy logic, pattern matching, machine learning evaluation models, or combinations thereof.

[0105] In any implementation, the generated or detected data may be forwarded to a “remote” device or location, where “remote” means a location or device other than the location or device where the program is executed. For example, a remote location could be another location in the same city (e.g., an office, laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Therefore, when an item is indicated as being “remote” to another item, it means that the two items may be in the same room but separated, or at least in different rooms or different buildings, and may be at least one mile, ten miles, or at least one hundred miles apart. “Transmitting” information refers to the transmission of data representing that information as electrical signals via an appropriate communication channel (e.g., a private or public network). “Forwarding” an item refers to any means of moving that item from one location to another, whether by physical transmission or other means (if possible), at least in the case of data, including the physical transmission of the medium carrying or conveying the data. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet, or include email transmissions and information recorded on websites, etc.

[0106] Elements known or subsequently known to those skilled in the art throughout the various aspects described herein are all structural and functional equivalents expressly incorporated herein by reference and intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be exclusive to the public, whether or not it is expressly stated in the claims. No claim element shall be interpreted in accordance with 35 U.S.SC §112 unless the element is expressly stated using the phrase “means for…” or, in the case of a method claim, using the phrase “steps for…”. Furthermore, where the terms “comprising,” “having,” etc., are used in the specification or claims, such terms are intended to encompass in a manner similar to the term “comprising” (as is interpreted when “comprising” is used as a transition word in a claim).

Claims

1. A drug delivery device, comprising: monitor; as well as A processor, configured at least in part by instructions stored in memory, as follows: Receive credentials associated with the user; An authorized user operates the drug delivery device, the authorization being at least in part based on the credentials; In response to the authorization, retrieve the user history associated with the user, wherein the user history includes one or more dispensing records for the pending medication; It receives user input without knowing the patient or doctor's orders so that the drug delivery device can initiate drug administration without identifying the patient or doctor's orders. as well as In situations where it is unknown which patient the drug delivery device is administering the drug to and the drug label is unknown: Based on the context including the user history, one or more medication order candidates for the current administration are determined, wherein each medication order candidate includes an order identifying the corresponding medication for the corresponding patient, and is selected based on the correspondence between the location of the medication delivery device or care area and the medication location or care area in the corresponding medication record; A user interface is presented via the display to confirm medication orders from one or more medication order candidates; as well as Receive the confirmed medication order from one or more medication order candidates; and Configure at least one parameter of the drug delivery device based on the confirmed medication order received from the user interface.

2. The drug delivery device according to claim 1, wherein, The processor is configured to retrieve one or more medication records from the set of most recent medication records associated with the user.

3. The drug delivery device according to claim 1, wherein, The processor is configured to transmit a request via a network to a remote database to retrieve the user's history, the request including the user's identifier.

4. The drug delivery device according to claim 1, wherein, The context includes the location of the drug delivery device or the care area, and The medication dispensing record includes information identifying the location or area where medication is dispensed, and The processor is further configured to determine the one or more medication order candidates, including that the processor is configured to identify the medication order candidates based on the correspondence between the location of the drug delivery device or the care area and the medication dispensing location or medication dispensing care area.

5. The drug delivery device according to claim 1, wherein, The context includes the current time, and The medication dispensing record includes the time of administration for the pending medication, and The processor is further configured to determine the one or more medication order candidates, including that the processor is configured to identify the medication order candidates based on the correspondence between the current time and the administration time.

6. The drug delivery device according to claim 1, wherein, The context includes the delivery route for administering the drug using the drug delivery device, and The processor is further configured to filter the one or more medication order candidates based on the correspondence between the delivery route and the delivery route information associated with the corresponding medication order candidate.

7. The drug delivery device according to claim 6, further comprising: Multiple application channels; as well as The processor is further configured to receive a selection of a first channel among the plurality of channels used for drug administration, and The delivery path of the first channel included in the plurality of application channels is different from the delivery path of the second channel included in the plurality of application channels.

8. The drug delivery device according to claim 1, wherein, The processor is configured to receive credentials associated with the user via at least one of the following: a barcode scanner, a radio frequency identification (RFID) reader, a smart card reader, a near-field communication reader, or a biometric sensor.

9. The drug delivery device according to claim 1, wherein, The drug delivery device includes an infusion pump, and at least one parameter of the drug delivery device includes a pumping parameter.

10. A method for providing prescription confirmation at a drug delivery device, the method comprising: Receive credentials associated with the user; The user is authorized to operate the drug delivery device, at least in part, based on the received credentials; In response to the authorization, retrieve the user history associated with the user, wherein the user history includes one or more dispensing records for the pending medication; The drug delivery device receives user input without knowing the patient or doctor's orders so that the drug delivery device can initiate drug administration without identifying the patient or doctor's orders. as well as In situations where it is unknown which patient the drug delivery device is administering the drug to and the drug label is unknown: After receiving user input that does not know the patient and the prescription, one or more medication prescription candidates for the current administration are determined based on the context including the user's history, wherein each medication prescription candidate includes a prescription that identifies the corresponding drug for the corresponding patient, and is selected based on the correspondence between the location of the medication delivery device or care area and the medication location or medication care area in the corresponding medication record; A user interface is presented via a display device for the drug delivery device to confirm a medication order from one or more medication order candidates; as well as Receive the confirmed medication order from one or more medication order candidates; and Configure at least one parameter of the drug delivery device based on the confirmed medication order received from the user interface.

11. The method according to claim 10, wherein, The one or more medication records are retrieved from the set of most recent medication records associated with the user.

12. The method of claim 10, further comprising: A request is transmitted over a network to a remote database to retrieve the user's history, the request including an identifier associated with the user.

13. The method according to claim 10, wherein, The context includes the location of the medication delivery device or the care area, and the medication record includes information identifying the medication location or the medication care area, and the method further includes: Candidate medication orders are identified based on the correspondence between the location of the drug delivery device or the nursing area and the medication dispensing location or the medication dispensing nursing area.

14. The method of claim 10, wherein, The context includes the current time, and The medication dispensing record includes the administration time for the drug to be determined, and the method further includes: Candidate medication orders are identified based on the correspondence between the current time and the administration time.

15. The method according to claim 10, wherein, The context includes a delivery route for administering a drug using the drug delivery device, and the method further includes: The one or more medication order candidates are filtered based on the correspondence between the delivery route and the delivery route information associated with the corresponding medication order candidate.

16. The method of claim 15, further comprising: The receiving identifier indicates the selection of a first channel among a plurality of channels for administering the drug, wherein the delivery pathway of the first channel included in the plurality of channels is different from another delivery pathway of the second channel included in the plurality of channels.

17. The method according to claim 10, wherein, Authorizing the user includes: The credential associated with the user is received via at least one of the following: a barcode scanner, a radio frequency identification (RFID) reader, a smart card reader, a near-field communication reader, and a biometric sensor.

18. The method according to claim 10, wherein, The drug delivery device includes an infusion pump, and at least one parameter of the drug delivery device includes a pumping parameter.

19. A non-transitory storage medium comprising instructions, which, when read by one or more processors, cause the one or more processors to perform a method comprising the following steps: Receive credentials associated with the user; The user is authorized to operate the drug delivery device, at least in part, based on the received credentials; In response to the authorization, retrieve the user history associated with the user, wherein the user history includes one or more dispensing records for the pending medication; The drug delivery device receives user input without knowing the patient or doctor's orders so that the drug delivery device can initiate drug administration without identifying the patient or doctor's orders. as well as In situations where it is unknown which patient the drug delivery device is administering the drug to and the drug label is unknown: After receiving user input that does not know the patient and the prescription, one or more medication prescription candidates for the current administration are determined based on the context including the user's history, wherein each medication prescription candidate includes a prescription that identifies the corresponding drug for the corresponding patient, and is selected based on the correspondence between the location of the medication delivery device or care area and the medication location or medication care area in the corresponding medication record; A user interface is presented via a display device for the drug delivery device to confirm a medication order from one or more medication order candidates; as well as Receive the confirmed medication order from one or more medication order candidates; and Configure at least one parameter of the drug delivery device based on the confirmed medication order received from the user interface.

20. The non-transitory storage medium according to claim 19, wherein, The context includes the location of the medication delivery device or the care area, and the medication record includes information identifying the medication location or the medication care area, and the method further includes: Candidate medication orders are identified based on the correspondence between the location of the drug delivery device or the nursing area and the medication dispensing location or the medication dispensing nursing area.

Images