Patent Description:
The invention relates to a method of medication management, a medication dispensing device and a non-transitory computer-readable storage medium as defined in the claims.

The detailed description set forth below is intended as a description of various implementations and is not intended to represent the only implementations in which the subject technology may be practiced. As those skilled in the art would realize, the described implementations may be modified in various different ways, all without departing from the scope of the present disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive.

Automated medication dispensing systems can be used to support decentralized medication management with various features to enhance safety and efficiency. By way of example, such systems may help clinicians accurately dispense medications and may support pharmacy workflows through use of secure authentication and automated tracking of medication inventory and access.

One example of an automated medication dispensing system can employ a computer coupled locally to a medication dispensing device, such as a refrigerator or dispensing cabinet providing a locked container for storing a medication. The local computer can provide a user interface for nurses or other practitioners to access the medication locked in the dispensing device, as well as provide functionality for communicating with a remote server to receive medication orders from the server or provide dispense information to the server to update a database. However, space constraints may make the implementation of a local computer in an automated medication dispensing system impractical, and moreover, the use of a local computer can lead to inefficient queues in cases where multiple nurses need to access the same medication dispensing device to treat multiple patients in a common facility.

<FIG> is a schematic diagram illustrating an example medication management system <NUM>. The medication management system <NUM> includes or otherwise involves medication dispensing devices <NUM>, mobile devices <NUM>, electronic medical record (EMR) terminals <NUM>, a server <NUM>, and a network <NUM>. Each of the medication dispensing devices <NUM> can include a container configured to hold medication, which can be unlocked or otherwise accessed via local or short range communication with mobile devices <NUM>. Each of the mobile devices <NUM> can be configured to communicate with a remote server <NUM> over network <NUM> to receive medication order information and/or to send dispense information to the server <NUM> to allow the server <NUM> to update data.

Each of the mobile devices <NUM> can, for example, be implemented as a smart phone, tablet computer, a wearable device (e.g., a smart watch), or any other appropriate portable communication device capable of running an application (e.g., a mobile app) and communicating with the medication dispensing devices <NUM> via Bluetooth®, near-field communication (NFC), Wi-Fi, or other appropriate short range wireless interface. In <FIG>, a plurality of mobile devices <NUM> and a plurality of medication dispensing devices <NUM> are included in which each mobile device <NUM> is configured to communicate with multiple medication dispensing devices <NUM>, and likewise each medication dispensing device <NUM> is configured to communicate with multiple medical devices <NUM>. This may allow for a flexible framework in which computing devices associated with receiving medication orders and/or unlocking the medication dispensing devices <NUM> can travel with a nurse or other practitioner, rather than being tied to individual medication dispensing devices <NUM>. This can also, for example, allow a nurse or other practitioner to queue medication orders in the mobile device <NUM>, without having to queue up at a local terminal to enter the orders. However, while multiple medication dispensing devices <NUM> and multiple mobile devices <NUM> are included in the example medication management system <NUM> and can be configured to communicate as described above, other implementations are possible. For example, in some implementations only one mobile device <NUM> or any other suitable number of mobile devices can be included. Additionally or alternatively, only one medication dispensing device <NUM> or any other suitable number of dispensing devices can be included. Additionally or alternatively, each mobile device <NUM> can be configured to communicate with only one or any other suitable subset of medication dispensing devices <NUM>. Additionally or alternatively, each medication dispensing device <NUM> can be configured to communicate with only one or any other suitable subset of the mobile devices <NUM>.

When a particular mobile device <NUM> and medication dispensing device <NUM> are in sufficiently close proximity to one another, communication between the mobile device <NUM> and the medication dispensing device <NUM> may be established through the short range wireless interface so that the mobile device <NUM> can provide commands to the medication dispensing device <NUM> to unlock or access medication stored therein. Additionally or alternatively, the communication can allow the mobile device <NUM> to obtain medication dispensing or inventory information from the medication dispensing device <NUM>. The use of short range or local communication between the mobile device <NUM> and medication dispensing device <NUM> may enhance security and safety by constraining the mobile devices <NUM> to only be capable of unlocking or accessing the medication dispensing device <NUM> when in sufficiently close proximity to each other.

In some implementations, the subject technology enables automatic pairing (e.g., when the short range wireless interface is a Bluetooth interface) of a particular mobile device <NUM> to a particular medication dispensing device <NUM>, facilitated by an NFC link established by NFC circuitry provided by the particular mobile device <NUM>, or a badge associated with a clinician. According to various implementations, both the mobile device <NUM> and the medication dispensing device <NUM> may include NFC circuitry such that when within range of each other a connection (e.g., an NFC link) is triggered between the two devices. For example, communication between the two NFC supported devices can occur when the particular mobile device <NUM> is brought in close proximity (e.g., within NFC range corresponding to no more than <NUM> centimeters) with the particular medication dispensing device <NUM>, which activates the respective NFC circuitry on each device allowing for an automated establishment the NFC link. This link is used to quickly provide pairing information so that a secondary wireless connection between the devices may be automatically established using a peer-to-peer pairing process without the need to prompt the clinician to manually select (e.g., from a list) the medication dispensing device, or the need for access credentials to complete the pairing process. The link may be used to transmit other parameters related to the particular medication dispensing device <NUM>. Such other parameters may include, for example, hash information, randomized information, Bluetooth local name, service class identifier, class of device information, etc., that can be utilized as part of an authentication process.

The particular medication dispensing device <NUM> may include active or passive NFC circuitry to enable NFC-related communication between the two devices, and to transmit the pairing information and/or related parameters. When the mobile device <NUM> includes active NFC circuitry, the mobile device may directly receive the pairing information and/or parameters from the medication dispensing device <NUM>. In some implementations, the clinician's badge may be used to initiate the NFC communication. Passive NFC circuitry in the badge may transmit to the medication dispensing device an identifier of the clinician. The medication dispensing device may then send the pairing information (including any related parameters) to a centralized server <NUM> with the identifier, and the server may push the information to the mobile device. In this regard, the mobile device <NUM> receives the information and may automatically initiate and complete the secondary wireless connection using the received information. The server may also perform a check on the clinician's authorization to access the medication dispensing device before providing the information to the mobile device, and/or may provide authentication information to the mobile device which may then be passed over the secondary wireless connection to the medication dispensing device for authentication at the medication dispensing device.

The secondary wireless connection may be a Bluetooth connection. Each of the medication dispensing devices <NUM> may include a Bluetooth low energy (BLE) beacon, or other appropriate wireless transmitter or transceiver, beacon, or interface capable of communicating with the mobile device(s) <NUM>. When the NFC connection is established, the medication dispensing device <NUM> may send over the NFC connection, to the mobile device <NUM>, an address (e.g., a MAC address) of the BLE beacon associated with the medication dispensing device <NUM>. The mobile device <NUM> may then use this address to automatically connect to the BLE beacon of the medication dispensing device <NUM>, automatically, and to begin communications. In some implementations, a pairing PIN code may also be sent over the NFC connection so that the pairing may be securely established between the two devices, without the need to prompt the clinician to manually confirm the PIN code when the pairing process is initiated. After completing the authentication process, the particular mobile device <NUM> and the particular medication dispensing device <NUM> may then be automatically paired, via Bluetooth, based at least in part on the device address of the particular medication dispensing device <NUM> and the other parameters related to the particular medication dispensing device <NUM>.

The foregoing solution speeds up the pairing and connection process by establishing a fast connection between two devices. The NFC link facilitates a pairing process (e.g., via Bluetooth) between the two devices that provides a different communication link (e.g., a Bluetooth connection) which advantageously provides higher network bandwidth, throughput and/or range capabilities to support more sophisticated functionality than the NFC link.

In some implementations, multiple medication dispensing devices <NUM> may be linked, and each dispensing device may be configured to, receive a request or order for a medication, and locate the medication in another linked device. In this regard, the particular mobile device <NUM><NUM> of clinician may automatically connect to one medication dispensing device <NUM> to enter an order for one or more medications, irrespective of where those medications may be stored, and without the need to queue up with other clinicians at a single terminal. In some implementations, the pairing process at a particular medication dispensing device <NUM> may prevent, or lock out, other clinicians from pairing to or accessing medication in the device while the particular mobile device <NUM> of the clinician is paired to the particular medication dispensing device <NUM>. In some implementations, the particular medication dispensing device <NUM> may be configured for multiple pairings, but may restrict access to medication in a single device based on a software queue.

For example, multiple clinicians may connect to a first medication dispensing device <NUM> using the previously-described wireless pairing process, and enter orders simultaneously for various medications. A first and second requested medication may be available at the first medication dispensing device, while a third requested medication is available at a second medication dispensing device. The system may require a second clinician who placed an order for the second requested medication to wait for a first clinician who placed an order for the first requested medication to retrieve the first requested medication before the second clinician is provided access to the first medication dispensing device. However, a third clinician may be able to place an order for the third medication and the second medication dispensing device while the others access the first medication dispensing device.

Each mobile device <NUM> can, for example, employ secure authentication such as biometric authentication, passcode authentication, and/or other credentials to avoid unauthorized access, for example, by somebody other than an authorized nurse or other practitioner in possession of the mobile device <NUM>. Some examples of biometric authentication include fingerprint authentication, facial recognition, and iris authentication. Some examples of passcode authentication include pincodes, passwords, and other knowledge based authentication factors. As described previously, this information may be passed by the NFC link, or over the Bluetooth connection during the pairing process to authenticate the clinician to the respective medication dispensing device <NUM>.

Each medication dispensing device <NUM> may, for example, be implemented as a refrigerator, automated dispensing cabinet, or a combination thereof, which contains one or more containers configured to store a medication therein. The dispensing device(s) <NUM> may also, for example, include a locking mechanism or other appropriate access control mechanism for allowing access to the container or dispensing of the medication only when appropriate commands are received from the mobile devices <NUM> via the BLE beacon or other local communication interface.

The mobile device(s) <NUM> can each also include a network interface for communicating with a remote server <NUM> over a network <NUM>, such as the internet or another appropriate data network. The mobile device(s) <NUM> can include an application or other appropriate programming that configures the mobile device(s) <NUM> to receive medication order information from the server <NUM> associated with medications to be accessed from the dispensing devices <NUM>. Additionally or alternatively, the mobile device(s) <NUM> can be configured to provide commands to the medication dispensing device(s) <NUM> to unlock a container to access a medication stored therein. Additionally or alternatively, the mobile device(s) <NUM> can be configured to provide medication dispensing information to the server <NUM>, in which the medication dispensing information is associated with medication dispensing event(s) involving the medication dispensing device <NUM>.

The mobile device(s) <NUM> can, for example, include one or more input devices and/or output devices, which can provide a user interface for receiving inputs from a user and/or providing outputs to a user associated with medication. For example, the user interface can output a notification upon receipt of a new medication order from the server <NUM> (e.g., a push notification), and/or the user interface provide for input to select particular patients or medication, or to initiate unlocking or access of a container in the medication dispensing device <NUM>. Examples of input devices include touchscreens, touchpads, microphones, buttons, and any other devices that allow for interaction from a user to input information or provide commands through the mobile device. Examples of output devices include display, speakers, haptic vibrations, and other appropriate devices that allow for interaction with a user to communicate information to the user. Examples of user interfaces that can be provided in the mobile devices <NUM> are shown in <FIG> below.

The server <NUM> may, for example, be implemented as a physical and/or cloud based server operated on one or several computing devices that can coordinate with the mobile devices <NUM> to provide medication order information and/or receive medication dispensing information. Additionally or alternatively, the server <NUM> can coordinate with EMR terminals <NUM> other appropriate devices to receive medication orders from a doctor or other medical practitioner capable of prescribing medications. The server <NUM> can be configured to receive a medication order input into a patient's EMR or other electronic record through the EMR terminal(s) <NUM>, and coordinate with an application running on the mobile devices <NUM> to provide the medication order information to the appropriate nurses or practitioners. Additionally or alternatively, the server <NUM> can be configured to update or maintain a pharmacy information system (PIS) or other medication related data based on dispense information received from the mobile devices <NUM>.

<FIG> is flow diagram illustrating an example method <NUM> for medication management. The method <NUM> may, for example, be implemented using the medication management system <NUM> shown in <FIG>. <FIG> are examples of user interfaces 300a-300d that may, for example, be implemented in a mobile device in connection with the method <NUM>.

As shown in <FIG>, at <NUM>, a new medication order can be generated at an EMR terminal <NUM> based on a doctor or other appropriate medical professional (e.g., an MD) ordering medication for a patient in an EMR or other appropriate electronic record. The medication order can include information identifying a medication (or drug) to be provided to a particular patient. At <NUM>, the EMR. terminal <NUM> sends the medication order otherwise sends information regarding the medication order to server <NUM> over a network (e.g., network <NUM>).

At <NUM>, the server <NUM> receives the medication order or otherwise receives information regarding medication order. At <NUM>, the server <NUM> sends the medication order or otherwise sends information regarding the medication order to a mobile device <NUM> over a network, e.g., through a mobile application running on the mobile device.

At <NUM>, the mobile device receives a notification of the new medical order from the server <NUM>. At this stage, the mobile device <NUM>, can, for example, present a notification (e.g., a push notification) of the new medication order through a user interface, such as is shown in the example display interface 300a shown in <FIG>. Alternatively, the notification need not be presented, and the user can simply see the medication order information when the user chooses to open or otherwise access the application on the mobile device <NUM>.

At <NUM>, upon a user (e.g., a nurse or practitioner) accessing the application, the mobile device <NUM> can present all available medication orders, or patients having outstanding medication orders, or otherwise present information regarding the same through an appropriate user interface. An example of a display interface 300b showing a listing of several patients having corresponding medication orders is shown in <FIG>. The user interface can also provide for the user to select the desired patient and/or medication for a patient, e.g., through user input to an appropriate input device. Examples of display interfaces 300b and 300c showing selection of a patient, and medications for a particular patient, are shown in <FIG> respectively.

At <NUM>, the mobile device <NUM> selects a medication corresponding to the medication order based on received user input. For example, the medication may be selected upon the user selecting the appropriate patients and their appropriate medication(s), and selecting "dispense" as shown in the display interface 300c in <FIG>. Upon selection of the medication, the mobile device <NUM> can automatically connect, as described above, to a medication dispensing device <NUM> within sufficiently close proximity to the mobile device <NUM>, and communicate the selection to the medication dispensing device <NUM> or otherwise communicate an indication of the medication order, and send a command or otherwise initiate dispensing of the medication from the medication dispensing device <NUM>. Although not shown in <FIG>, as described above, the mobile device <NUM> can establish a connection to an appropriate medication dispensing device <NUM>, e.g., via a Bluetooth pairing, before or after the medication order is received or selected. If the connected medication dispensing device does not currently store the requested medication corresponding to the medication order then the connected medication dispensing device may inform the mobile device (and the clinician) of the location of another medication dispensing device where the medication can be retrieved.

At <NUM>, the medication dispensing device <NUM> (identified as containing the medication) unlocks an appropriate container containing the medication corresponding to the medication order, or otherwise dispenses the medication housed within the medication dispensing device <NUM>. The medication dispensing device <NUM> may be configured to only unlock the container or otherwise dispense the medication when the mobile device <NUM> is identified as being within a range of or paired with the medication dispensing device <NUM> (e.g., as described above), and the clinician appropriately authenticated to the device. The dispense device <NUM> can be configured to unlock the container or otherwise dispense the medication upon receipt of a command or other appropriate communication from the mobile device <NUM> over the short range wireless interface. If the medication dispensing device <NUM> contains multiple containers or compartments corresponding to multiple medications, the medication dispensing device <NUM> can, for example, be configured to unlock only the container or containers containing the selected medication or medications corresponding to the medication order.

At <NUM>, the mobile device <NUM> can close the medication dispensing transaction, for example, based on confirmation or other user input from the user. An example of a display interface 300d providing for a user to close the transaction after the desired medication is retrieved is shown in <FIG>.

At <NUM>, after unlocking the container the medication dispensing device <NUM> locks the container from which the medication was dispensed and retrieved by the user. The container can, for example, lock upon the mobile device <NUM> closing the transaction and sending a command or other communication to the medication dispensing device <NUM> indicating that the dispense transaction has been completed. Additionally or alternatively, the container can lock again automatically, e.g., after a fixed period of time for security.

At <NUM>, the mobile device <NUM> sends dispense information to the server <NUM> over the network. The dispense information can, for example, be sent upon closing the transaction (e.g., upon a nurse selecting "yes" in the display interface 300d shown in <FIG>). The dispense information can, for example, include an amount and/or type of medication dispensed, a time of the dispense event, or other information associated with the medication dispense event. The dispense information can, for example, be based on monitoring performed automatically by the medication dispensing device <NUM>.

At <NUM>, the server <NUM> receives the dispense information from the mobile device <NUM>. At <NUM>, the server <NUM> updates a pharmacy information system (PIS) included in or otherwise coupled to the server <NUM><NUM>, based on the dispense information associated with the dispense event.

<FIG> is a block diagram illustrating an example computer system <NUM> with which any one or more of the mobile device(s) <NUM>, the EMR terminal(s) <NUM>, or the server(s) <NUM><NUM> may be implemented.

Computer system <NUM> includes a bus <NUM> or other communication mechanism for communicating information, and a processor <NUM> coupled with bus <NUM> for processing information. By way of example, the computer system <NUM> may be implemented with one or more processors <NUM>. Processor <NUM> may be a general-purpose microprocessor, a micro control module, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a control module, a state machine, gated logic, discrete hardware components, or any other suitable entity that can perform calculations or other manipulations of information.

Computer system <NUM> can include, in addition to hardware, a code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them stored in an included memory <NUM>, such as a Random Access Memory (RAM), a flash memory, a Read Only Memory (ROM), a Programmable Read-Only Memory- (PROM), an Erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-ROM, a DVD, or any other suitable storage device, coupled to bus <NUM> for storing information and instructions to be executed by processor <NUM>. The processor <NUM> and the memory <NUM> can be supplemented by, or incorporated in, a special purpose logic circuitry.

The instructions may be stored in the memory <NUM> and implemented in one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, the computer system <NUM>, and according to any method well known to those skilled in the art, including, but not limited to, computer languages such as data-oriented languages (e.g., SQL, dBase), system languages (e.g., C, Objective-C, C++, Assembly), architectural languages (e.g., Java,. NET), and application languages (e.g., PUP, Ruby, Perl, Python). Instructions may also be implemented in computer languages such as array languages, aspect-oriented languages, assembly languages, authoring languages, command line interface languages, compiled languages, concurrent languages, curly-bracket languages, dataflow languages, data-structured languages, declarative languages, esoteric languages, extension languages, fourth-generation languages, functional languages, interactive mode languages, interpreted languages, iterative languages, list-based languages, little languages, logic-based languages, machine languages, macro languages, metaprogramming languages, multiparadigm languages, numerical analysis, non-English-based languages, object-oriented class-based languages, object-oriented prototype-based languages, off-side rule languages, procedural languages, reflective languages, rule-based languages, scripting languages, stack-based languages, synchronous languages, syntax handling languages, visual languages, wirth languages, and xml-based languages. Memory <NUM> may also be used for storing temporary variable or other intermediate information during execution of instructions to be executed by processor <NUM>.

A computer program as discussed herein does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code).

Computer system <NUM> further includes a data storage device <NUM>, such as a magnetic disk or optical disk, coupled to bus <NUM> for storing information and instructions. Computer system <NUM> may be coupled via input/output module <NUM> to various devices. Input/output module <NUM> can be any input/output module. Exemplary input/output modules <NUM> include data ports such as USB ports. Input/output module <NUM> is configured to connect to a communications module <NUM>. Exemplary communications modules <NUM> include networking interface cards, such as Ethernet cards and modems. In certain aspects, input/output module <NUM> is configured to connect to a plurality of devices, such as an input device <NUM> and/or an output device <NUM>. Examples of input devices <NUM> include a keyboard and a pointing device, e.g., a mouse or a trackball, by which a user can provide input to the computer system <NUM>. Other kinds of input devices <NUM> can be used to provide for interaction with a user as well, such as a tactile input device, visual input device, audio input device, or brain-computer interface device. For example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, tactile, or brain wave input. Examples of output devices <NUM> include display devices, such as an LCD (liquid crystal display) monitor, for displaying information to the user.

According to one aspect of the present disclosure, method <NUM> or any portion thereof can be implemented using a computer system <NUM> in response to processor <NUM> executing one or more sequences of one or more instructions contained in memory- <NUM>. Such instructions may be read into memory <NUM> from another machine-readable medium, such as data storage device <NUM>. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in memory <NUM>. In alternative aspects, hard-wired circuitry may be used in place of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuitry and software.

Various aspects of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The communication network (e.g., network <NUM>) can include, for example, any one or more of a LAN, a WAN, the Internet, and the like. Further, the communication network can include, but is not limited to, for example, any one or more of the following network topologies, including a bus network, a star network, a ring network, a mesh network, a star-bus network, tree or hierarchical network, or the like. The communications modules can be, for example, modems or Ethernet cards.

Computer system <NUM> can include clients and servers. Any one or more of the mobile devices <NUM> and/or EMR terminals <NUM> can, for example, be configured as a client to the server <NUM>. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship with each other. Computer system <NUM> can be, for example, and without limitation, a desktop computer, laptop computer, or tablet computer. Computer system <NUM> can also be embedded in another device, for example, and without limitation, a mobile telephone, a PDA, a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and/or a television set top box.

The term "machine-readable storage medium" or "computer readable medium" as used herein refers to any medium or media that participates in providing instructions to processor <NUM> for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as data storage device <NUM>. Volatile media include dynamic memory, such as memory <NUM>. Transmission media include coaxial cables, copper wire, and fiber optics, including the wires that include bus <NUM>. Common forms of machine-readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH EPROM, any other memory chip or cartridge, or any other medium from which a computer can read. The machine-readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The computer readable medium can be non-transitory.

A phrase "at least one of" preceding a series of items, with the terms "and" or "or" to separate any of the items, modifies the list as a whole, rather than each member of the list. The phrase "at least one of' does not require selection of at least one item; rather, the phrase allows a meaning that includes at least one of any one of the items, and/or at least one of any combination of the items, and/or at least one of each of the items. By way of example, each of the phrases "at least one of A, B, and C" or "at least one of A, B, or C" refers to only A, only B, or only C; any combination of A, B, and C; and/or at least one of each of A, B, and C.

It is understood that the specific order or hierarchy of steps, operations, or processes disclosed is an illustration of exemplary approaches. Unless explicitly stated otherwise, it is understood that the specific order or hierarchy of steps, operations, or processes may be performed in different order. Some of the steps, operations, or processes may be performed simultaneously. The accompanying method claims, if any, present elements of the various steps, operations or processes in a sample order, and are not meant to be limited to the specific order or hierarchy presented. These may be performed in serial, linearly, in parallel or in different order. It should be understood that the described instructions, operations, and systems can generally be integrated together in a single software/hardware product or packaged into multiple software/hardware products.

The disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the principles described herein may be applied to other aspects.

Claim 1:
A method of medication management, the method comprising:
receiving, at a mobile device (<NUM>), via a network interface from a server (<NUM>), information regarding a medication order;
establishing a first near-field communication, NFC, connection between the mobile device (<NUM>) and a medication dispensing device (<NUM>);
receiving at the mobile device (<NUM>), over the first NFC connection, pairing information from the medication dispensing device (<NUM>) for the mobile device (<NUM>) to connect to the medication dispensing device (<NUM>);
automatically establishing a short range wireless connection, different than first the NFC connection, to wirelessly connect the mobile device (<NUM>) to the medication dispensing device (<NUM>) using a peer-to-peer pairing process with the pairing information that was received over the first NFC connection;
sending, from the mobile device (<NUM>) via the short range wireless interface, a medication request including the medication order to the medication dispensing device (<NUM>) to initiate dispensing of a medication corresponding to the medication order, the medication request causing the medication dispensing device (<NUM>) to provide access to a medication corresponding to the medication order; and
sending, with the mobile device (<NUM>) via the network interface, dispense information to the server (<NUM>), the dispense information corresponding to the medication provided by the medication dispensing device (<NUM>).