Patent Description:
To treat patients, physicians and other medication personnel may use patient care devices ("PCDs"), also referred to herein as patient care units ("PCUs"), which may include various medical devices such as a single or multi-channel infusion pump, a vital signs monitor, a medicant dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe pump module configured to attach to an infusion pump), or other similar devices. PCUs may be utilized to apply intravenous ("IV") infusion therapy to treat various medication complications in patients. IV infusion therapy typically involves infusing medication fluids, such as drugs or nutrients, from a fluid supply, such as a bag, bottle or other container, through the tube of a fluid administration set to a cannula inserted into a patient's blood vessel. Other medications may be ordered by a physician for a patient, such as pills or liquids, to be taken by other delivery routes, such as orally by the patient.

In some cases, a physician may order multiple medications for a single patient, and these are to be administered at particular times of a day or over a number of days resulting in a list of "pending medication orders" for the patient. In some implementations, the administration of multiple medications must occur sequentially and in other cases, there is an overlap of the administration of medications. In yet some implementations, the administration of certain medications must occur at a certain time before or after the administration of another medication or medications.

Since a patient may be associated with a treatment regimen that includes multiple pending medication orders with complex administration rules, it becomes increasingly important to reduce the risk of medication errors when programming and configuring PCUs for the patient. Medication errors may include, for example, incorrect medication, incorrect dosage amount, incorrect administration timing, incorrect delivery route, or incorrect order sequence. One approach for reducing medication errors is to provide barcode labels or radio frequency identification (RFID) tags on medications, which are then scanned for automatic entry into a PCU. However, this only ensures that the PCU is correctly programmed according to the medication label or tag, and does not necessarily verify correctness with a patient treatment regimen, which may be managed by an upstream electronic medical record (EMR) management system. In some situations, such as when treating a patient in an emergency room setting, the patient may not yet be registered into the EMR management system, or the EMR management system may be unavailable. In this case, manual entry of medication orders into PCUs may be unavoidable, which may introduce data entry errors. In some cases, the PCU may have information to automatically administer drugs, but the information may be outdated or superseded by subsequent events which may introduce errors in the administration by the PCU.

<CIT> discloses methods for facilitating safe use of a medical item are provided. In one aspect, a method includes receiving a first identifier for a medical entity located in an institution. The medical entity includes at least one of a patient, medical device, medical location, or medical item. The method also includes receiving a second identifier for a first course of action associated with the medical entity. The method further includes generating, based on a history of the medical entity and the first course of action associated with the medical entity, a second course of action for the medical entity, and providing a notification to a device indicating the second course of action. Systems and machine-readable media are also provided.

<CIT> discloses an automated health care facility for the administration of medication to patients. The automated health care facility can include a plurality of data entry terminals for entry of information such as prescription information identifying a prescription of medication to be provided to a particular patient. A pharmacy, for receiving prescription information from the data entry terminals prepares and dispenses medication in accordance with the prescription. A patient database can be used to store patient data information, and a pharmaceutical database can be used to store information relating to one or more medications such as those dispensed by the pharmacy. An automated medicated infusion device prepares and administers medications to a patient. Information in one or more databases can be accessed to assist in prescribing medication and preventing medication errors.

Accordingly, there is a need for improved systems and methods of order confirmation on medical devices, such as PCUs.

According to various implementations, the disclosure relates to a medication delivery device according to claim <NUM>.

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

In some implementations, the context includes a delivery route for administering the medication with the medication delivery device, and the processor may be configured to filter the one or more medication order candidates based on a correspondence between the delivery route and delivery route information associated with respective medication order candidates. The device may further include a plurality of administration channels; and the processor may be further configured to receive a selection identifying a first channel of the plurality of channels to administer the medication, and the delivery route for the first channel included in the plurality of administration channels is different from another delivery route for a second channel included in the plurality of administration channels.

In some implementations, the processor is configured to receive the 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, or a biometric sensor. In some implementations, the medication delivery device comprises an infusion pump, and wherein the at least one parameter of the medication delivery device includes pumping parameter. Other aspects include corresponding methods, apparatuses, and computer program products for implementation of the system.

According to various implementations, the disclosure relates to a method for providing order confirmation at a medication delivery device, according to claim <NUM>.

Other aspects include corresponding systems, apparatuses, and computer program products for implementation of the method.

Further aspects of the subject technology, features, and advantages, as well as the structure and operation of various aspects of the subject technology are described in detail below with reference to accompanying drawings.

Various objects, features, and advantages of the present disclosure can be more fully appreciated with reference to the following detailed description when considered in connection with the following drawings, in which like reference numerals identify like elements. The following drawings are for the purpose of illustration only and are not intended to be limiting of this disclosure, the scope of which is set forth in the claims that follow.

While aspects of the subject technology are described herein with reference to illustrative examples for particular applications, it should be understood that the subject technology is not limited to those particular applications. Those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and aspects within the scope thereof and additional fields in which the subject technology would be of significant utility.

To avoid medication errors and ensure the highest quality of care, healthcare best practices may encourage automated monitoring of the devices and intelligent parameter limits for inputs provided to the devices to ensure the correct administration of medication orders. Since patient care units, or PCUs, are centrally positioned in the healthcare device chain, PCUs may be ideally positioned to provide medication order confirmation prior to administration. After a clinician is authorized to control a PCU, the PCU may retrieve remote data from a healthcare server or database that includes the clinician's user history, such as dispensing records. The dispensing records may include pending records for pending medications. The PCU may assemble a context from the remote data and other local data, and determine, using the context, a next medication order for administration. A user interface may be presented on the PCU to confirm the next medication order. After confirmation, the PCU may be automatically programmed with the correct parameters for administration, such as pumping parameters for an infusion pump.

By enabling the PCU to provide order confirmation, several separate confirmation steps may be consolidated at the PCU, thereby streamlining patient care and avoiding further steps that may introduce mistakes and errors. For example, scanning of individual medications may be avoided and the PCU may be directly programmed and configured based on the next medication order. In addition, scanning of an identifier tag attached to the patient may be avoided by using a patient ID associated with the PCU, or by using geolocation to determine the correct patient for the next administration. All of the data may be consolidated and displayed at the PCU, and the clinician only needs to confirm that everything is correct to continue with administration.

Referring now in more detail to the drawings for purposes of illustration of implementations of the invention, wherein like reference numerals designate corresponding or like elements among the several views, there is shown in <FIG> a partial block diagram of a system in accordance with certain aspects of the invention. The patient care unit (PCU) in the example shown in <FIG> is an infusion pump system <NUM>, which is connected to a patient <NUM> to infuse medication fluid from an IV fluid container <NUM>, such as a bag, to patient <NUM> through a fluid administration set <NUM>. The pump system includes an infusion pump <NUM> located at the left side of a controller <NUM> and an auto identification module <NUM> or "auto ID module" located to the right side of the controller. The identification module in this case includes a tethered <NUM> bar code reader <NUM>.

The controller <NUM> is connected with a server <NUM>, which may take the form of any server or servers in a health care facility. The box <NUM> identified as "server" may be a single server or it may comprise multiple servers or computers and memory for data storage. Server <NUM> may be in communication with database <NUM>, which may store patient identification data as well as pending medication orders for patients admitted to the health care facility. It may also store clinician identification data and other data, such as user history <NUM> associated with a particular user or clinician. User history <NUM> may include dispensing records <NUM>, which may include a record for each medication dispensed by the association clinician. For example, when the clinician uses automated dispensing machine ("ADM") <NUM> to retrieve a medication, an associated record may be created in pending records <NUM>. Pending records <NUM> may be associated with open or pending medication orders, whereas closed records <NUM> may be associated with medication orders that have already been administered. While pending records <NUM> and closed records <NUM> are shown as separate record sets, it should be understood that both record sets may be stored in a single table with record fields that identify which records are pending or closed.

The "server" identified by numeral <NUM> may also include, for purposes of convenience of discussion and illustration, a server of the company that provides the infusion pump system <NUM> and establishes communication protocols between that infusion pump system and health care facility servers. The server <NUM> electronically receives medication order entries <NUM> from one or more sources, such as the pharmacy information system (PIS), laptop computers, physician order entry devices, personal digital assistants ("PDA"), and other devices. Medication order entries <NUM> may also be entered into the server by the pharmacy. Dispensing records <NUM> may each be associated with a corresponding medication order entry <NUM>. The controller <NUM> may be in communication with the server <NUM> by any wired or wireless means and the server may be in communication with other devices by wired or wireless means.

An automated dispensing machine ("ADM") <NUM> is also shown and typically includes medications for the patients in the vicinity. The ADM has a processor, termed a dispensing processor <NUM> (shown in <FIG>), and may require clinician identification before permitting any medications to be withdrawn. The dispensing processor may permit only certain clinicians to remove certain items from the ADM. The ADM may also contain "controlled items" which, for the purposes herein, may be any item desired to be tracked by the healthcare facility in which the ADM is located. This may include narcotics but also may include items of much less sensitivity.

<FIG> is a diagram showing a means of authorizing a clinician through the use of an auto identification module connected to a controller associated with the infusion pump of <FIG>, according to various aspects of the subject technology. Upon initial power up of the controller <NUM>, the controller <NUM> may prompt the clinician to login. The clinician may have an identification <NUM> that can be scanned by an embedded code reader <NUM> or a tethered <NUM> code scanner <NUM>. As shown in <FIG>, the reader <NUM> and the scanner <NUM> form parts of an automated identification module <NUM> that can be attached to a PCU. The code reader <NUM> and/or code scanner <NUM> may include a radio frequency identification (RFID) reading element(s), smart card reading element(s), near-field communication reading element(s), or biometric sensing element(s) to process (e.g., collect, verify, authenticate) credentials provided by the clinician. The automated identification module <NUM> may communicate by wired or wireless means with the controller <NUM>. In one case, the controller <NUM> includes a communications interface ("CI Board") containing a processor, programming, and a substantial memory. The CI Board is in contact with the automated identification module <NUM>. Upon receiving a clinician credential, the CI Board may send a message to the controller <NUM> indicating that a clinician is requesting to login. The message may include the clinician credential received. In some implementations, the automated identification module <NUM> may validate and/or verify the credential and include a result of the validation or verification in the message provided to the controller <NUM>. In some implementations, the functions of the CI Board are all performed by a processor of controller <NUM> and/or by other components within controller <NUM>. A processor of controller <NUM> may then verify whether the clinician is authorized to control infusion pump system <NUM>. For example, in some implementations, infusion pump system <NUM> may be assigned to a specific patient identifier, and a lookup may be performed to verify whether the clinician is authorized to provide care for a patient associated with the specific patient identifier.

Upon a successful authorization of the clinician's credentials, display 42A of infusion pump <NUM> and/or display 42B of controller <NUM> may show a user interface for confirming a next medication order. As discussed below in conjunction with <FIG>, the next medication order may be intelligently selected based on a context, which includes the user history <NUM> associated with the clinician. The user interface may show the next medication order pre-selected on the user interface and ask for confirmation prior to programming and configuring infusion pump <NUM>.

As used herein, the term "medication" is meant to be understood in a broad sense as pertaining to medical care. "Medication" would include oral medications and infusions of medications, but is also meant to include physical therapy, taking vital signs, preparation for surgery, and other medical care. Also, "administer" is meant to be understood in a broad sense as providing medical care. "Administer" is meant to cover the dispensing of medications, such as oral medications, as well as performing infusions on a patient and other provisions of medical care. The illustrative controller <NUM> discussed herein and shown in the drawings as a separate unit may actually be a part of an infusion pump or other medical instrument. The order of identifying individuals or medications or performing steps is provided as implementations. The identifications may be performed in different orders in certain healthcare facilities, the orders presented here are implementations.

<FIG> is a diagram showing example user interfaces displayed on the infusion pump or controller of <FIG>, according to various aspects of the subject technology. With respect to <FIG>, display 342A, display 342B, and display 342C may correspond to display 42A or display 42B from <FIG> and <FIG>. In some implementations, display 342A-342C may be shown on a remote device, such as a tablet, smartphone, laptop, or desktop computer.

Display 342A may be shown after startup of controller <NUM>. As shown in display 342A, the user interface displays no information regarding any patients or orders and waits for a clinician to successfully login before displaying any information. Assuming that the clinician is successfully authenticated using the procedures described above, the user interface may transition to display 342B.

As shown in display 342B, a next medication order for administration is already preselected and shown to the clinician, with various details of the medication order indicated including the associated clinician, the associated patient, the administration time, the location, and the medication order including information such as medication name, administration route, drug concentration, and pumping parameters such as volume to be infused ("VTBI") and infusion rate over time. If everything appears correct, the clinician may simply indicate the "confirm order" option, and the infusion pump <NUM> may be programmed according to the pumping parameters in the indicated order. Example steps for preselection of a medication order are described in further detail below in conjunction with <FIG>.

If the preselected next medication order is not the desired order, the user interface may include a control element to receive an input to select a different order. 3B, the user interface includes a "select different order" control element to receive this input. Once activated, the control element may cause a transition of the user interface to present display 342C. In display 342C, a list of candidate orders are shown. The orders may be associated with a selection control element that can be interacted with to receive a selection for a desired medication order. The list of candidate orders may be narrowed based on contextual information detected or accessible by the system. Example steps for narrowing orders are described in further detail below in conjunction with <FIG>.

<FIG> depicts an example process <NUM> for providing patient care unit (PCU) order confirmation on a medical device, according to various aspects of the subject technology. For explanatory purposes, the various blocks of example process <NUM> are described herein with reference to FIGS. 1A-<NUM>, and the components and/or processes described herein. The one or more of the blocks of process <NUM> may be implemented, for example, by one or more of computing devices described here, such as a PCU, module coupled with a PCU, or a server of the healthcare facility (e.g., server <NUM>). In some implementations, one or more of the blocks may be implemented apart from other blocks, and by one or more different processors or devices. Further for explanatory purposes, the blocks of example process <NUM> are described as occurring in serial, or linearly. However, multiple blocks of example process <NUM> may occur in parallel. In addition, the blocks of example process <NUM> need not be performed in the order shown and/or one or more of the blocks of example process <NUM> need not be performed.

In the depicted example flow diagram, a medical device or PCU, such as infusion pump system <NUM>, may authorize a user, such as a clinician, to operate the infusion pump system <NUM> (<NUM>). As described above, the user may use a badge with a barcode, RFID tag, or other identifier as a credential for authorization. Infusion pump system <NUM> may use a corresponding reader, such as tethered <NUM> code reader <NUM>, to receive the credential. By communicating with server <NUM> and/or database <NUM>, infusion pump system <NUM> may verify that the credential is authorized.

Process <NUM> may continue with retrieving, in response to the authorizing, a user history associated with the user, wherein the user history includes one or more pending medication dispensing records (<NUM>). Referring to <FIG>, this may correspond to infusion pump system <NUM> querying database <NUM> to retrieve a user history <NUM> associated with the user, wherein the user history <NUM> includes dispensing records <NUM> with pending records <NUM>. For example, the user history <NUM> may be associated with a user ID that matches the previously authorized clinician ID. In another example, user history <NUM> may be associated with another user ID, e.g. a supervisor, that is authorized according to access privileges granted by the authorized clinician ID. As shown in <FIG>, each of pending records <NUM> may be created when the associated user retrieves medication from a dispensing device, such as ADM <NUM>, and each record may reference an associated medication order entry <NUM>, which may be provided by a pharmacy, as described above. In some cases, pending records <NUM> may include a large number of records. In this case, rather than retrieving all of pending records <NUM>, only a most recent set of dispensing records may be retrieved, e.g. up to a fixed number or according to a time cutoff. The time cutoff may be dynamically assessed based on information associated with the authorized user. For example, a time and attendance system may include a shift start time for the authorized user. The shift start time may represent the earliest moment in the current day that could be associated with a dispense event related to the authorized user.

According to various implementations, process (in some implementations, optionally) receives a patient and order agnostic user input to begin administration of a medication (<NUM>). For the purposes of this disclosure, a "patient and order agnostic user input" means an input that does not include any information identifying a patient or an order. In this regard, the system may receive information about a medication being administered but does not know to what patient that medication is being administered or whether the medication is currently associated with an order.

Process <NUM> may continue with determining, based on the patient and order user input (if available) and a context that includes the user history, one or more medication order candidates for present administration (<NUM>). When receiving patient and order agnostic user input, the system does not currently know to what patient to which the medication delivery device is designated for or associated with, and has not currently associated an order with the patient or a medication being programmed in the device. Accordingly, the system performs an order correlation independent and before the patient or medication is identified to the system. Instead, the pending records <NUM> in the retrieved user history <NUM>, and various other factors may be considered for determining the medication order candidates. The factors in the context can be used to narrow the medication order candidates to a list of most likely next medication orders, for example by assigning a relevance weighting to each medication order candidate, wherein each of the factors in the context may contribute a weighted value for each medication order candidate. After the weighting, the list of medication order candidates can be narrowed or pruned using one or more factors, such as falling below a weighting threshold, or meeting a maximum number of candidates (e.g. by including <NUM> candidates with the highest weight values).

In some implementations, the context may include a location and/or defined care area of the medical device. For example, infusion pump system <NUM> may be preprogrammed with a deployment location and/or care area, or otherwise include location tracking components, such as global positioning system (GPS) sensors or radio triangulation sensors to determine a current location.

In some implementations, the context includes a location or care area of the medication delivery device. For example, a dispensing record may include information identifying a dispensing location or dispensing care area. In this regard, the system may determine one or more medication order candidates by identifying a medication order candidate based on a correspondence between the location or care area of the medication delivery device and the dispensing location or dispensing care area. Such correspondence may include, but is not limited to, a difference or meeting one or more thresholds (e.g. number of matching characteristics), or may be configurable. Correspondence may also be dynamic based on medication, patient, care area, and the like.

By querying server <NUM> for patient data at the current location, the possible patients can be limited to those located at the current location of the medical device, near the current location of the medical device, or within a defined care area of the medical device. Accordingly, the medication order candidates can be narrowed to orders specifically for the patients within the location or defined care area of the medical device.

In some implementations, the context may include a current time and an administration time of the medication order. For example, medication orders with an administration time that are closer to the current time may be favored for selection as medication order candidates. The context may also include a dispensing time of the medication order, which may be compared to the current time. For example, a most recently dispensed medication order may be favored for selection, since the latest dispensed item may be the most urgent for the clinician. A least recently dispensed medication order may also be favored for selection, since the oldest dispensed item may be the first to dispense in a sequence of medications. If rules are defined for ordered administration of multiple medication orders, then these rules may also be factored when selecting and weighting medication orders.

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

In some implementations, the context may include a delivery route for the medication orders. For example, infusion pump system <NUM> may only accept medication orders intended for IV delivery, rather than other routes such as oral administration.

In some implementations, the context may exclude a positive identification of the patient, for example when the patient is newly admitted into an emergency room setting and no EMRs exist yet for the patient. In this case, the medication order candidates can still be determined based on the other context factors described above. In a similar fashion, when other factors are missing or unavailable, then the other remaining factors in the context may still be used to determine the medication order candidates.

According to some implementations, context includes a delivery route for administering the medication with the medication delivery device, and the system may filter the one or more medication order candidates based on a correspondence between the delivery route and delivery route information associated with respective medication order candidates. As described previously, correspondence may include, but is not limited to, a difference or meeting one or more thresholds (e.g. number of matching characteristics), or may be configurable. Additionally, in some implementations, the medication delivery device may include a plurality of administration channels. In this regard, the system may be configured to receive a selection identifying a first channel of the plurality of channels to administer the medication, and the delivery route for the first channel included in the plurality of administration channels may be different from another delivery route for a second channel included in the plurality of administration channels.

Process <NUM> may continue with presenting a user interface for confirming a medication order from the one or more medication order candidates (<NUM>). For example, after narrowing the medication order candidates, if only a single medication order candidate remains, then that order may be selected for confirmation. However, if multiple medication order candidates remain, the most likely next order may be preselected, as shown in the user interface of display 342B of <FIG>, wherein the other medication order candidates can still be selected using the selection user interface shown in display 342C. The most likely next order may be selected by, for example, selecting the candidate with the highest weighting.

For example, the selection list in display 342C may be sorted in order of weighting, wherein order #<NUM> is determined to be the most likely next medication order and order #<NUM> is determined to be the least likely next medication order. For example, John Doe may be located at room <NUM>, whereas Robert Grant may be located at room <NUM>. Since the medical device is in room <NUM>, the medication orders for John Doe are listed first. Additionally, the current time may be <NUM>:<NUM> AM, which indicates that the administration of Heparin is now due, whereas the administration of Aminophylline is still <NUM> minutes in the future. Thus, the order that has the closest administration time is preferred and listed as order #<NUM>.

According to some implementations, the user may perform a dispense event, and thus be associated with the dispense event by the system. The user then associates with the pump via a credential. Order information from the dispense may be provided and confirmed at the pump before the user enters any order specific information.

Process <NUM> may continue with configuring at least one parameter of the medical device based on the confirmed medication order received from the user interface (<NUM>). Thus, after the clinician confirms the pre-selected order in display 342B or selects a different order in display 342C, the pumping parameters of the confirmed order may be programmed into infusion pump <NUM>, including e.g. VTBI and infusion rate. Once the administration is completed, then the medical device may send a notification to server <NUM> to cause the associated record in pending records <NUM> to be moved to closed records <NUM>.

Many aspects of the above-described example process <NUM>, and related features and applications, may also be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium), and may be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

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

<FIG> is a conceptual diagram illustrating an example electronic system <NUM> for providing patient care unit (PCU) order confirmation, according to various aspects of the subject technology. Electronic system <NUM> may be a computing device for execution of software associated with one or more portions or steps of process <NUM>, or components and processes provided by <FIG>. Electronic system <NUM> may be representative, in combination with the disclosure regarding <FIG>, of the infusion pump system <NUM>, the infusion pump <NUM>, or the controller <NUM> described above. In this regard, electronic system <NUM> may be a microcomputer, personal computer or a mobile device such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or any other sort of computer-related electronic device having network connectivity.

Electronic system <NUM> may include various types of computer readable media and interfaces for various other types of computer readable media. In the depicted example, electronic system <NUM> includes a bus <NUM>, processing unit(s) <NUM>, a system memory <NUM>, a read-only memory (ROM) <NUM>, a permanent storage device <NUM>, an input device interface <NUM>, an output device interface <NUM>, and one or more network interfaces <NUM>. In some implementations, electronic system <NUM> may include or be integrated with other computing devices or circuitry for operation of the various components and processes previously described.

Bus <NUM> collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system <NUM>. For instance, bus <NUM> communicatively connects processing unit(s) <NUM> with ROM <NUM>, system memory <NUM>, and permanent storage device <NUM>.

From these various memory units, processing unit(s) <NUM> retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The processing unit(s) can be a single processor or a multi-core processor in different implementations.

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

Some implementations use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as permanent storage device <NUM>. Like permanent storage device <NUM>, system memory <NUM> is a read-and-write memory device. However, unlike storage device <NUM>, system memory <NUM> is a volatile read-and-write memory, such a random access memory. System memory <NUM> 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 <NUM>, permanent storage device <NUM>, and/or ROM <NUM>. From these various memory units, processing unit(s) <NUM> retrieves instructions to execute and data to process in order to execute the processes of some implementations.

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

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

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

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

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

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.

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

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.

A client and server are generally remote from each other and may interact through a communication network. In some implementations, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device).

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

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

The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more. Headings and subheadings, if any, are used for convenience only and do not limit this disclosure.

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

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

A phrase such as an "implementation" does not imply that such implementation is essential to the subject technology or that such implementation applies to all configurations of the subject technology. A disclosure relating to an implementation may apply to all implementations, or one or more implementations. An implementation may provide one or more examples. A phrase such as an "implementation" may refer to one or more implementations and vice versa. A phrase such as a "configuration" may refer to one or more configurations and vice versa.

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

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

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

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

As used herein, the term "selectively" or "selective" may encompass a wide variety of actions. For example, a "selective" process may include determining one option from multiple options. A "selective" process may include one or more of: dynamically determined inputs, preconfigured inputs, or user-initiated inputs for making the determination. In some implementations, an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.

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

Claim 1:
A medication 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 medication delivery device, said authorization based at least in part on the credential;
retrieve, in response to the authorizing, a user history associated with the user, wherein the user history includes one or more dispensing records for medications retrieved from one or more dispensing devices by the user during a period of time;
receive a patient and order agnostic user input, to begin an administration of a medication by the medication delivery device, without information identifying the medication or a patient or an order; and
without knowing to what patient the medication is being administered by the medication delivery device, and without knowing an identification of the medication:
determine, based on a context that includes the user history, one or more candidate medication orders, each candidate medication order comprising an order identifying a respective medication for a respective patient, and selected based on a correspondence between a location or care area of the medication delivery device and a dispensing location or a dispensing care area in a respective dispensing record;
present, via the display, a user interface for confirming a medication order from the one or more candidate medication orders; and
receive a confirmed medication order of the one or more candidate medication orders; and
configure at least one parameter of the medication delivery device based on the confirmed medication order received from the user interface.