JP2018504951A - Systems and methods for drug storage, distribution, and management - Google Patents

Abstract

Various exemplary embodiments relate to methods, devices, and non-transitory machine-readable storage media encoded with instructions executed by a user device that establish a communication session with a patient operating a drug dispenser. Instructions for displaying the instruction information of the input request for the user and instructions for establishing a two-way communication session with the patient via the drug distributor based on the physician user of the user device authorizing the input request Instructions for displaying a dispense user interface (UI) element during an interactive communication session, instructions for receiving a dispense UI element selection from a physician user, and based on the selection, the drug dispenser Including instructions for transmitting a command for dispensing agent.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is a PCT application filed December 3, 2013 claiming priority from US Provisional Patent Application No. 61 / 732,753 filed December 3, 2012 PCT / US2013 / 072878, which is a continuation-in-part of US Patent Application No. 14 / 282,884, filed May 20, 2014, now US Pat. No. 8,922,367. US patent application Ser. No. 14 / 575,477, filed Dec. 18, 2014, which is a continuation-in-part, claims the priority thereof, the entire disclosure of which is hereby incorporated by reference for all purposes. Be incorporated.

  The various exemplary embodiments described herein generally relate to drug storage, distribution, and management.

  Some people are suffering from medical conditions that can lead to emergencies where rapid drug administration is paramount. For example, people who develop allergies when exposed to certain substances can develop anaphylaxis. It is important to treat epinephrine self-injection as soon as possible because of its rapid onset and possible death due to the severity of allergy. Patients with known allergies are commonly prescribed an epinephrine autoinjector to treat sudden anaphylaxis, and the patient constantly carries the autoinjector to respond to emergencies according to the plan. Similarly, patients with other medical conditions that may require emergencies that require immediate treatment may be prescribed appropriate medications or devices to carry.

  In light of the current requirements for administration of epinephrine self-injection and other drugs and various emergency response measures for the device, a brief summary of various exemplary embodiments is presented. In the following summary, some simplifications and omissions may be made, but emphasize and introduce certain aspects of the various exemplary embodiments and do not limit the scope of the invention. A detailed description of the preferred exemplary embodiments is sufficient to enable those skilled in the art to make and use the inventive concepts described in the following sections.

  Various embodiments relate to a non-transitory machine-readable storage medium encoded with instructions to be executed by a user device, wherein the medium is a request input to establish a communication session with a patient operating a drug dispenser. Instructions for displaying the instruction information of the patient, instructions for establishing a two-way communication session with the patient via the drug distributor based on the physician user of the user device approving the input request, and a two-way communication session Instructions for displaying a dispense user interface (UI) element during the period, instructions for receiving a dispense UI element selection from a physician user, and based on the selection, the drug dispenser dispenses a drug to the patient Including instructions for sending a command.

  Various embodiments relate to a method performed by a user device, the method relates to establishing a two-way communication session between a physician user of a user device and a patient via a remote drug dispenser, and a drug dispenser. Based on the selection of the dispense UI element, the remote drug dispenser receives the drug, receiving information describing the drug, displaying a dispense user interface (UI) element indicating the drug for the physician user to select. Sending a command for distribution to the patient.

  Various embodiments relate to a portable communication device for use by a physician user, the portable communication device including a communication interface, a display device, a touch input device, a memory, and a processor in communication with the memory, the processor being a drug dispenser. A communication interface and drug dispenser based on a physician user of a user device that displays instruction information of a request input to establish a communication session with a patient operating the display device and approves the input request Establishes a two-way communication session with the patient via the device, displays the dispense user interface (UI) element via the display device during the two-way communication session, and selects the dispense UI element via the touch input device. User Received via the communication interface based on the selection, and medicament dispenser is an agent to send a command for dispensing to the patient.

  Various embodiments are described in the non-transitory machine-readable storage medium of claim 1 and further include instructions for retrieving drug data describing available drugs via a drug distributor and a dispense UI element. Includes instructions for displaying instruction information of drug data.

  In various embodiments, the medication data includes the expiration date of the medication.

  Various embodiments further include instructions for displaying a second dispense UI element during a two-way communication session, instructions for receiving a second dispense UI element selection from a physician user, and a second Instructions for sending a command for dispensing a second medication to a patient based on the selection of the dispense UI element.

  Various embodiments additionally include instructions for receiving medication information indicating whether the medication is available for dispensing to a patient, the instructions for displaying a dispense user interface (UI) element comprising: Instructions for displaying a dispense UI element as not selectable and instructions for receiving a dispense UI element selection from a physician user when the information indicates that a drug for dispensing to a patient is not available Instructions that are configured to be executed based on drug information indicating that the drug is available for dispensing to a patient.

  Various embodiments may additionally include instructions for receiving a stream of video data from a medication dispenser via a two-way communication session and instructions for displaying video to a physician user based on the stream of video data. Including.

  Various embodiments additionally include instructions for receiving a message input from the physician user and instructions for sending a command for the medication distributor to display the input message to the patient.

  For a better understanding of various exemplary embodiments, reference is made to the following drawings.

An exemplary medicine storage case is illustrated. FIG. 4 illustrates a block diagram of exemplary components of a medication storage case. FIG. 3 shows an example schematic diagram of example components of a medication storage case. 1 illustrates an exemplary sleeve containing a drug. FIG. 6 illustrates a cross-sectional view of an exemplary drug storage case and includes an exemplary actuator for selectively holding and releasing a sleeve. Fig. 4 illustrates an exemplary method for contacting emergency services through a medication storage case. FIG. 4 illustrates an exemplary method for accessing a medication in response to a remote instruction. 1 illustrates an example network environment for a drug storage case. FIG. 3 shows an example hardware diagram of a physician device or control center device. FIG. 4 illustrates an example user interface for authenticating a physician user. FIG. 4 illustrates an example user interface for displaying a home screen. FIG. FIG. 4 illustrates an example user interface for displaying an input communication request indication. FIG. FIG. 4 illustrates an example user interface for display during a communication session. FIG. 4 illustrates an example user interface for displaying patient video and sending test messages. Figure 4 illustrates an alternative user interface for displaying patient videos. FIG. 4 illustrates an example user interface for displaying a dispense button for dispensing medication to a patient. FIG. 6 illustrates an alternative user interface for displaying a dispense button for dispensing medication to a patient. FIG. 4 illustrates an example user interface for displaying a log of a previous communication session. FIG. 4 illustrates an example user interface for receiving a physician note regarding a communication session. Fig. 4 illustrates an exemplary method for communicating with a medication storage case.

  While often effective, emergency responses where patients always carry drugs are not the perfect solution. There are many situations in which patients do not have access to appropriate medications to deal with emergencies. For example, if the patient's condition is still undiagnosed, there is no urgent opportunity to prescribe medications or devices in advance. As another example, if the patient is a child, or supervision or guidance is required for the use of a drug or device, it may not be available because it may not actually carry the patient prescription. In addition, there may be no appropriate administrator for administration. Except for these special circumstances, the patient may simply have forgotten the prescription or may not have the prescribed medication or device in an emergency. For at least these reasons, there is a need for alternative or additional solutions to provide properly prescribed drugs or devices in an emergency.

  As described in more detail below, various embodiments provide limited access to stored medication until instructions are received from a remote operator, such as a doctor at the time of the call, allowing local patients or other users to A drug storage case that releases the drug to be used is included. In order to properly and reliably determine whether and when the remote operator dispenses medication from the storage case, the storage case additionally has two-way communication capabilities with the remote operator. This communication allows the remote operator to obtain sufficient information about the patient and the situation to determine whether the medication should be dispensed.

  The description and drawings described herein illustrate various principles. Those skilled in the art can devise these principles and devise various arrangements that fall within the scope of this disclosure, even if not explicitly described or shown in the specification. As used herein, the term “or” means non-exclusive “or” (ie, “or”), and unless otherwise indicated (eg, “or another” or “or selective”). ")". Moreover, the various embodiments described herein are not mutually exclusive and can be combined to form additional embodiments that incorporate the principles described herein. It will be apparent that the methods and devices described herein can be used to dispense drugs, medical devices, and combinations thereof. Thus, it will be understood that the term “agent” as used herein refers to both a drug and a medical device. Further, it will be appreciated that the various devices described herein can be used to control access to materials, devices, and other items outside the medical field.

  Referring now to the drawings in which like numerals refer to like components or steps, the broad aspects of the various exemplary embodiments will be described.

  FIG. 1 illustrates an exemplary medicine storage case 100. Various embodiments of the medication storage case are disclosed herein, and the example case 100 may also be referred to as a medical management system. As illustrated, the storage case 100 includes a case main body 110 and a door 120 coupled to the case main body 110 by hinges 122a and 122b. Case body 110 includes an interior region 140 that is accessible by an opening on the front surface of case body 110. In various embodiments, the storage case 100 can be attached to a wall or other structure. As such, the storage case may also include enough fixed hardware to complete the attachment. For example, the back surface of the case body 110 may include a recess that receives a bolt head of a bolt that is screwed to the wall. As another example, the fixed hardware can include a separate mounting structure that is attached to the wall with screws, and the back surface of the case body 110 has hooks, clips, or other structures. It is attached. Various other types of fixed hardware for attaching the containment case 100 to the structure will be apparent. In various embodiments, the backside surface, bottom surface, or other surface of the case body can include connectors for power, network, and telephone connections.

  A lower ledge 142 is formed at the bottom of the case body, on which the drug 130 dispensed before being removed by the user remains. Before being dispensed, medication 130 is held in another area of interior area 140, which is inaccessible to local users or accessible with difficulty. For example, the medication 130 may be held in a portion of the interior region 140 that is hidden behind the front surface of the storage case 110 over the opening and lower ledge 142. In various embodiments, the storage case 100 is configured to store and dispense a plurality of medications that may differ from each other. For example, in some implementations, the storage case can dispense both adult and child epinephrine autoinjectors and can be held inside various packaging, such as product boxes.

  To hold the drug before dispensing, the storage case 100 may include a drug lock (not shown) or other lockable holding structure (not shown) such as a door. Alternatively, the illustrated door 120 can be locked closed. Various exemplary drug locks and other retention structures are described in more detail below. Although a particular holding structure has been used, in various embodiments, the holding structure can be electrically moved from locked to unlocked by an actuator (not shown) controlled by a processor (not shown). Can operate according to instructions received from a remote site to an unlocked holding structure. For example, upon receiving an unlock signal, such as an internet packet containing distribution instructions, the processor can send an access signal to the actuator, which can then cause the holding structure to be unlocked. Once the holding structure is unlocked, the drug can be freely moved from the device, i.e., the user manually operates an unlocked holding structure (e.g., opening an unlocked door). You can freely access the drug.

  Storage case 100 also includes a plurality of input / output devices for communicating with local users. As shown, the storage case includes a “Go” button 111 and a “Stop” button 112. When the Go button 111 is pressed, the storage case 100 can initiate a two-way communication session with a remote site via a communication unit (not shown). The communication session may include audio communication through the microphone 114 and the speaker 115, and the local user and the remote operator may have a conversation. The Stop button 112 may be configured to terminate a call performed by the storage case 100 when the local user presses the Go button 112 or to stop all processing.

  A display 113 may also be provided for various purposes. For example, the display may facilitate video feeds between remote sites and local users with a camera (not shown) as part of an interactive communication session. Alternatively, display 113 can show various information to the local user, for example, medication usage instructions or status updates regarding actions currently performed by storage case 100 or a remote operator. As such, the displayed information can be stored locally or received from a remote site or other location. In various embodiments, the information displayed on the display 113 is controlled by a remote operator such as a physician. In some implementations, the display 113 includes touch screen input. In this embodiment, display 113 may include soft buttons instead of or in addition to Go button 111 and Stop button 112. The touch screen display 113 can also be used to provide a management interface that can be accessed by entering a password, swiping a key card or any other authentication process, with information recorded by an authorized user. Or access internal compartments and replace dispensed or expired medications.

  The status of storage case 100 may be communicated in alternative or additional ways. For example, as shown, the storage case 100 includes a plurality of status lights 116. The status light may display system information such as power on or boot status, or process flow information such as whether a call has been made or medication has been dispensed. Various other uses for the status light 116 are apparent.

  In various embodiments, the electronics that control the operation of the storage case may always be powered from a battery, power supply, or other power source. In other embodiments, a power saving feature that reduces power consumption may be implemented. For example, the electronic device of the storage case 100 may be turned off or enter a “sleep” mode while not in use. When activated by a local user, these electronic devices turn on or wake up and perform related functions. For example, the electronic device may be configured to turn on or wake up when the door 120 is opened and the Go button is pressed or a separate “Power” button is pressed. The characteristics of saving various other powers are obvious.

  Once the medication is dispensed, the storage case 100 can be refilled with additional medication by the service staff. In some implementations, refilling can be performed after opening the case 100, but in other embodiments, the service staff does not open the case and directly into the case through the front open product access area. Can be refilled. Various alternative methods for refilling that do not require special service access (eg, opening the case) can be utilized, such as a slot in the top of the case, as described below with respect to FIG. To fill the drug.

  FIG. 2 illustrates an example block diagram 200 of example components of a medication storage case. In various embodiments, the block diagram illustrates various electronic and mechanical components of the example storage case 100 of FIG.

  As shown, block diagram 200 includes an electronic subsystem 210, a mechanical subsystem 240, and various additional components 250-266. The electronic subsystem 210 includes a processor 212 and various supporting electronics components 214-232. The processor 212 may include any virtual device that can coordinate the functions described herein, such as a microprocessor, a field programmable gate array (FPGA), or an application specific integrated circuit. (ASIC). In various embodiments, the processor 212 is an ARM architecture microprocessor.

  The processor 212 accesses various forms of memory / data storage, including an SD card interface 216 and on-board program and data memories 224, 226. Program memory 224 stores software instructions for causing the processor to perform various methods described herein, such as the exemplary methods described with respect to FIGS. For example, the program memory 224 may include an operating system such as a Linux kernel including appropriate device drivers, a real-time transport protocol (RTP) stack instruction, a session initiation protocol (SIP) stack instruction, a direct access arrangement (DAA) stack. Instructions and instructions for providing a Qt graphical user interface (GUI) may be stored. In addition, the program memory 224 may store event handler instructions for responding to incoming events, such as door open / close, watchdog reset, factory reset, firmware update, entry into manufacturing mode, Status / reporting, and failure notification. Program memory 224 may store a variety of audio components, including Advanced Linux Sound Architecture (ALSA) libraries, software codec instructions, and echo / noise cancellation algorithms.

  Data memory 226 may be used by the processor to store various data, including storage case usage, log data for location information, or log of temperature information. Various other data stored in the data memory 226 or SD or other memory card will be apparent from the specification of the present application. Alternatively or additionally, the SD or other memory card 216 may be used to store boot-up instructions, firmware images, activity logs, predetermined information and messages, and other information.

  The electronic subsystem 212 includes an audio interface 214 such as an audio codec and allows the processor to send and receive audio data via various audio devices such as speakers 250, headsets 252, or microphones 254. Similarly, the electronic subsystem 210 includes a touch screen interface 218 for outputting video data to the touch screen device 256 and receiving touch input. The electronic subsystem 210 includes a general purpose input / output (GPIO) interface 220 for various other input / output devices such as status LEDs 258 or push buttons 260.

  The processor 212 may access various external devices. For example, to connect to other devices over the Internet or other network, the electronic subsystem 210 communicates with various physical media interfaces (such as Ethernet or WiFi 262) such as Ethernet (registered trademark) or WiFi (registered trademark) 262. PHY). In addition, the electronic subsystem 210 includes a conventional regular telephone system (POTS) interface 228 to allow establishment of a telephone call over the landline 264. To allow system debugging and other maintenance, the electronic subsystem 210 includes an RS-232 serial interface 232 and a device including a universal asynchronous receiver / transmitter (UART) can be attached to process data and instructions. Communicate with.

  The electronic subsystem 210 may also include an enclosure I / O interface 230 for communicating with the mechanical subsystem 240. In various embodiments, the enclosure I / O interface 230 may simply use the GPIO interface 220. Mechanical subsystem 240 includes two devices. A device that detects that the door has opened, such as a switch, button, proximity sensor, or motion detector, may be arranged to send a signal to the enclosure I / O interface 230 when the door is opened. In various embodiments, this signal can be used to power on or wake up the electronic subsystem 210. A drug lock / unlock mechanism 244, such as a solenoid interface or other actuator interface, receives access signals from the processor 212 via the enclosure I / O interface 244. Upon receipt of the signal, the drug lock / unlock mechanism 244 dispenses the drug as detailed below.

  FIG. 3 illustrates an example schematic 300 of an example component of a medication storage case. In various embodiments, the overview diagram 300 may describe various systems of the example storage case 100 and may illustrate a more detailed embodiment of the block diagram 200 of FIG.

  As shown, the system is located around a processor 310 described below, which can be a microprocessor, FPGA, ASIC, or any other device capable of performing the described functions. The processor 310 may include a number of on-board memories, and may further access other forms of memory such as the SD card connector 311 and EEPROM 314, DDR3 memory 315, and NAND flash memory 316. The processor 310 may communicate with the SD card connector 311 via a secure digital input output (SDIO) bus. Various data and instructions can be stored in these memory devices. Further, it will be apparent that fewer or additional memory devices may be used, as well as different types of memory devices than those shown here.

  The processor may also use other devices that do not belong to the described subsystem. For example, in various embodiments, the system 300 may continue to log usage based on the date and time reported by the real-time clock chip 312. In some implementations, the processor 310 may monitor and record the temperature of the drug or surrounding area as reported by the temperature sensor 313. In some implementations, the temperature sensor 313 can be used by the processor 310 or other chip (not shown) to control the temperature at which the drug is exposed. For example, the storage case may be equipped with a fan or other device for controlling the internal temperature. The processor 310 may be configured in an embodiment that controls a fan when the temperature sensor 313 reports a temperature or a time-lapse temperature that is above a predetermined threshold. This feature can be particularly useful in embodiments where the storage case is portable or exposed to an inconsistent climate. Further, as described above, processor 310 may provide a debug or maintenance interface to other devices via RS232 transceiver 317 and connector 318.

  As described, in various embodiments, the system 300 turns on or wakes up upon detecting that the door has been opened. To provide this functionality, the module 320 that detects that the door has opened includes one or more proximity sensors 322 that detect that the door has moved from a closed state. Such information may be sent to the processor via one or more GPIO lines. In various alternative embodiments, proximity sensor 322 may be replaced with other devices such as a dedicated power button or any one of go-stop buttons 341.

  The audio interaction unit 330 communicates with the processor 330 to facilitate audio communication. That is, the audio interaction unit 330 includes an audio codec 332 that communicates data with the processor 310 via a multi-channel audio serial port (McASP) and an integrated circuit (12C) bus. Next, the audio codec 332 outputs the audio data received from the processor 310 through the headset 334 and the speaker 336, and digitizes the analog audio data received via the microphone 338. As will be appreciated, the processor may simply act as a pass-through for the audio data, allowing data exchange between the audio interaction unit and the connection unit 350. In other embodiments, the audio interaction unit 330 may be directly connected to the connection unit 350, in which case the data may be transmitted to a remote location without the processor 310 handling the data. For example, the audio interaction unit 330 can transmit and receive analog audio data via an RJ-11 connector. In some implementations, the direct connection may be selectively enabled or disabled by the processor 310.

  For interaction with additional types of local users, the system 300 includes a user interface unit 340 that includes various input / output devices. For example, the user interface unit 340 may include Go and Stop buttons 341 that can be used to initiate or interrupt system operation for connecting to a remote site. As such, the Go and Stop buttons 341 may provide signals to the processor 310 via one or more GPIO channels. Similarly, the processor may be configured to illuminate the status and activity LED 343 by sending a signal over one or more GPIO channels.

  User interface unit 340 also includes an LCD display 345 and an integrated touch screen 357. The processor 310 transmits video data such as predetermined instructions stored in the memory devices 311, 314, 315 and 316 or information received via the connection module 350 to the LCD display 345 via a display interface. Can be output. The processor 310 also receives any input received from the touch screen 347 via the touch screen interface. In various embodiments, the use of the system in dim conditions may also be assisted by providing a backlight driver 349 that controls the backlight of the LCD display 345, Go-Stop button 341, or other components. The processor may send indication information indicating the desired backlight intensity to the backlight driver 349 via the pulse width modulation channel.

  The processor 310 is provided with the ability to communicate with remote devices via the connection module 350. As shown, the connection module 350 is provided with three communication channels. Less or more communication channels may be supported. As a first channel, the connection module includes an Ethernet® PHY chip 351 that enables wired network communication via an Ethernet® connector 353 such as an RJ-45 connection. The processor 310 may transmit data with an Ethernet PHY chip via a media independent interface (MII). To provide a second network channel, the connection module 350 includes a WiFi module 355 that includes an antenna and a WiFi PHY chip. The processor 310 transmits data using the WiFi (registered trademark) module 355 via the SDIO bus. The third channel provided in the connection module 350 is a terrestrial communication line POTS connection. As such, the connection module 350 includes a voice direct access arrangement (DAA) chipset 357 that communicates with a telephone line via an RJ-11 connector 359. The processor 310 may communicate with the audio DA chipset 357 via the SPI bus and McASP.

  The processor 310 communicates with the drug device distribution circuit 360 to release the drug. In particular, the processor 310 may communicate with one or more solenoid interfaces 362, 364 or other interfaces to release medication. In various embodiments, the processor 310 communicates with each of the solenoid interfaces 362, 364 via respective general purpose IO channels.

  In some implementations, the various electronics circuits may include self-diagnostic functions or feedback capabilities. For example, self-diagnosis or feedback methods may be employed to monitor solenoid loop conditions, monitor battery degradation, and other key functions. The method for implementing this capability is clear.

  Some devices that may be used to implement the example system 300 may be omitted. For example, when implementing the system, a telephone line translator may be located between the voice DA chipset 357 and the RJ-11 connector, and a magnet may be the Ethernet® PHY chip 351 and the Ethernet® connector 353. It can be located between. Furthermore, additional lines for communication can be placed between the various chips. For example, in addition to displaying data on the LCD display 345, the processor 310 may additionally transmit various signals such as an enable signal or a read / write signal. It is clear that there are details that are omitted in various further implementations.

  As described, the drug can be dispensed with or without packaging. In some implementations, the retention and release of the drug may include a separate sleeve, case, or other containing and holding drug, and other for locking the drug and engaging other holding structures in the storage case. It can be assisted by other devices that provide structural features. FIG. 4 illustrates an exemplary sleeve 400 for holding a drug. The sleeve 400 can be virtually formed from any material. In some implementations, the sleeve 400 is formed from acrylonitrile butadiene styrene (ABS) resin or other material, which withstands drop forces or absorbs shocks, and is a monolith of any drug that is retained within the sleeve 400. It is strong enough to maintain its sex. The sleeve includes a hollow sleeve body 410, at least one opening 420 near at least one end, and a rail 430 extending from the top surface of the body 410. The opening is sized to receive a box package for the drug. For example, a standard commercial box package containing two epinephrine autoinjector pens can be inserted through the opening 420 and received within the body 410. Rails 430 are provided to lock the drug or engage other retaining structures of the containment case, an exemplary form of which is described below with reference to FIG.

  Obviously, the sleeve 400 is one example and various alternative structures may be used. For example, the sleeve may not include the opening 420, but instead may include a hinged engagement between two parts of the body, and the sleeve may open. As another example, rail 430 may be replaced with a circular loop, magnet, or other structure or material suitable for use to engage a particular holding structure. Further, the body 410 can be formed in different shapes. For example, if the drug is dispensed without a package, the body 410 may instead be a round sleeve or other shape that is a structure containing the drug. In some implementations, the body 410 can be omitted and the rail 430 or other engagement structure can be directly attached to the drug or drug package by an adhesive, screw, or other mounting means, or the drug or It can be formed integrally with the package. Various additional variations are apparent.

  FIG. 5 illustrates a cross-sectional view 500 as seen from the side of the example drug containment case 110 of FIG. 1 and includes an example actuator that selectively holds and releases the sleeve. The case body 110 includes a front side surface and a back side surface that form an internal region 140 therebetween.

  The sleeve 400 holding the drug 130 is suspended in the inner region 140 by the sleeve rail 430. As shown, the hook 510 is received under the rail 430 so that the sleeve 400 hangs from the hook 510. The hook 510 is properly held at the pivot point 512. For example, a rod, pin, or other structure may be inserted into the hook 510 at the pivot point 512, and the hook may rotate clockwise or counterclockwise as seen from the perspective view of FIG. Depending on the mass of the sleeve 400 and the drug 130, the hook tends to rotate clockwise. As shown, the rail 430 slides down from the hook 510 when the hook 510 is rotated sufficiently far clockwise. If not supported by the hook 510, the sleeve 400 falls and reaches the lower ledge to be collected by the user. A sufficient force spring is disposed between the head of the hook 510 and the case body 110 in order to resist the force of the sleeve 400 falling from the hook 510. As such, the hook holds the sleeve 400 in the air if no other external forces act on the hook 510.

  An actuator including a solenoid 562 and a solenoid controller 362 is provided to release a holding structure (eg, hook 510 and spring 514). As described above, the solenoid controller 362 receives an access signal from the processor and, in response, provides sufficient current to the solenoid 562 to move the solenoid cylinder forward (right side in the perspective view of FIG. 5), A third force is applied to the hook 512. The force of solenoid 562 applied along with the downward force of sleeve 400 and drug 130 is sufficient to force spring 514 to move in the opposite direction, so hook 510 rotates to release sleeve 400.

  The arrangement of FIG. 5 is an example of a retention structure and actuator for dispensing medication and it will be appreciated that many other configurations are possible. For example, the sleeve 400 can be hung directly by a solenoid cylinder and operates to disengage the sleeve 400 when the solenoid controller 362 is activated. In this embodiment, the components of solenoid 562 function as both a holding structure and an actuator. Similarly, in some implementations, the solenoid cylinder can be configured in contact with or together with another non-pivoting structure to move linearly and disengage from the sleeve 400. In another embodiment, instead of suspending sleeve 400 or drug 130, sleeve 400 or drug 130 may be positioned along a movable platform. When activated, the platform can be retracted or swiveled so that the sleeve 400 or drug 130 is no longer supported and falls to the lower ledge 142.

  Various arrangements may use actuators rather than solenoids. For example, a servo motor or stepping motor can be used to control the angular position of the hook 510 or platform, or another holding structure can be connected to one or more coupled structures (eg, a wound cable attached to the structure). Can be used to recede linearly through. As another example, if the holding structure is an electromagnetic magnet, the actuator may be a controller configured to turn off power to the magnet, thus releasing the sleeve 400 or drug 130. Various other types of actuators are apparent.

  In addition, various other holding structures and actuator arrangements are available that dispense the drug without dropping it to an area accessible to the user. For example, the drug 130 may be locked to the containment case by a ring or clamp placed around the drug 130 and may be opened by a suitable actuator. As another example, the drug 130 may be placed behind a locked door, for example, a second door behind the first door 120, Go in the embodiment behind the first door 120. Controls such as buttons 111 are not housed on the back side of the first door, i.e., in a locked drawer. The actuator of this embodiment can function to unlock the door or drawer, allowing the user to open the door or drawer and access the medication. Thus, in some implementations, the actuator actively releases the drug 130 so that the user can remove the drug 130 directly after release, while in other embodiments the actuator passively removes the drug 130. As a result, the user can manually move the holding structure to access the drug 130.

  FIG. 6 illustrates an example method 600 for contacting emergency services through a medication storage case. Method 600 may be performed by a processor, such as processor 212 or processor 310 of storage case 100, and may be encoded as a program instruction for execution by the processor.

  Method 600 begins at step 610 and proceeds to step 620 where the processor receives instruction information that the Go button has been pressed. The pressing of the button can be detected by a physical Go button such as button 111 or a soft Go button that can be displayed on a touch screen display such as display 113. In various embodiments, step 620 comprises the step of receiving and recognizing event handler events.

  Next, in step 630, the processor initiates a landline call for emergency dispatch. For example, if the storage case is located in the United States, the processor is configured to make the telephone call a 911 emergency service. During or after connecting to the emergency dispatch, the processor transmits a set of predetermined information to the emergency dispatch via a landline call. For example, the processor may send information indicating that the call is from a medication storage case, so there is no need to establish a voice session with the local user, ie the location of the storage case is pre-programmed or determined by GPS or other means. May be. Various additional or alternative information to be sent to the emergency dispatch is obvious. The information may be transmitted in any form, such as voice audio generated by a computer, fax data, or data encoded in an analog telephone signal.

  Next, in step 650, the processor initiates a voice over IP (VOIP) call to the control center rather than an emergency dispatch. For example, the control center may be operated by the same operator that provides, maintains, or is associated with a containment case or medication contained therein. Again, the storage case may also send various predetermined information such as the location of the storage case or identification information. Next, in step 660, the processor transfers the audio data between the audio codec and the VOIP channel, allowing the local user to contact the control center operator. As shown below, the control center operator can forward the call to the physician, and then the local user can contact the physician. In step 670, the processor determines whether to end the VOIP call. For example, the processor may determine whether the Stop button has been pressed or the VOIP call has been closed from the other end. If not, method 600 loops back to step 660 and continues to transfer the audio data to the remote site. Otherwise, the processor proceeds to step 680 and closes the VOIP channel and the method ends at step 690.

  Method 600 is an example of the operation of a drug containment case according to the systems and methods described herein, and various alternative methods may be used. For example, step 670 may be performed with an event handler that closes the call and indication information for the event. In some implementations, a call to an emergency dispatch may not occur, but in other embodiments, only a call to 911 is performed and the emergency dispatch remotely controls the dispensing of drugs or Transfer to a doctor or other operator implemented in the same way. In other embodiments, the various steps of the method are performed in parallel. For example, step 620 can be divided into two threads, the first thread involves steps 630, 640, and the second thread involves steps 650-680. In this embodiment, two calls are executed simultaneously. Various other variations are apparent.

  FIG. 7 illustrates an example method 700 that can access a medication in response to a remote instruction. Method 700 may be performed by a processor in storage case 100, such as processor 212 or processor 310, and may be encoded as a program instruction for execution by the processor.

  The method begins at step 710 and proceeds to step 720, where the processor receives an unlock signal that functions as a distribution instruction. For example, the processor may receive a packet containing instructions for dispensing medication. In step 730, the processor determines the index of the medication to be dispensed by instruction. In particular, if the storage case is an embodiment that can dispense multiple different drugs and dosages, the available drugs can be indexed. For example, an adult epinephrine autoinjector set may be indexed to “0” and a child epinephrine autoinjector set may be indexed to “1”. The instruction received at step 720 may directly identify an index to the appropriate drug, or may identify only the drug to be dispensed, in which case the processor identifies the index of the identified drug, eg, a lookup Can be determined by table. In embodiments where only a single type of drug can be dispensed, step 730 may be omitted.

  In step 740, the processor sends an access signal to the actuator corresponding to the appropriate medication. Again, this step may include correlating the index or drug with the actuator, eg, by a look-up table. Upon receipt of the access signal, the actuator releases the drug for removal by the user. In various alternative embodiments, a single actuator can control the release of multiple drugs, in which the processor can simply send an index or other identification information of the desired drug to the actuator, And determine the appropriate action to dispense the requested medication.

  After dispensing the medication, the processor records and places video instructions for the medication, or receives the instructions over the network interface. In step 750, the processor outputs the instruction to the display device so that the instruction is displayed as an image to any physician or other remote operator. Method 700 proceeds to end at step 760.

  FIG. 8 illustrates an example network environment 800 for a drug storage case. As described in detail above, the operation of storage case 100 is controlled by a remote device, such as control center device 820 or physician device 830, at least in part via the Internet 810 or other network. Control center device 820 or physician device 830 may be any virtual user device such as a terminal, personal computer, tablet, mobile phone, or other device.

  As described, when activated by the user, the storage case 100 initiates a VOIP call to a remote site such as a control center 820 or emergency dispatch (not shown). The control center 820 may transfer the VOIP call to the physician who is in the field or placed on the call immediately, that is, during the call. In some implementations, the control center 820 can simply operate as an electronic device and automatically transfer the call to an available physician device 830. In this embodiment, the control center 820 can be hosted in a cloud computing environment.

  The control center 820 or physician device 830 provides the ability of a remote operator to remotely release one or more medications in the storage case 100, in addition to assisting an audio VOIP call. For example, the doctor device 830 executes a mobile application to communicate audio data between the doctor and the storage case, and prepares the following two buttons for the doctor. A button for dispensing an adult epinephrine autoinjector and a button for dispensing a child epinephrine autoinjector. The button may cause the physician device to generate an emission signal, such as a distribution instruction packet, and be sent to the storage case 100 via the control center 820 or directly via the Internet 810 without the control center 820. Similar functions can be provided in the control center 820.

  Various variations and additional features are apparent. For example, the control center 820 or physician device 830 can be further configured to support the storage case 100 and a unidirectional or bidirectional video feed. In another embodiment, the control center 820 or the physician device 830 may allow the remote operator to select and transmit text or graphics to be displayed on the storage case 100 display device. In addition, the control center 820 or physician device 830 can interface with other devices (not shown), such as a patient record storage location, allowing the remote operator to access the patient's medical history.

  In some implementations, the management system may communicate with the storage case 100 via the Internet 810 or other network. For example, a separate server, personal computer, table, laptop, cloud virtual machine, or control center 820 itself can communicate with the storage case, providing functions such as list management, call recording & logging, and other management functions Can be implemented.

  FIG. 9 illustrates an example hardware diagram 900 for a physician device or a control center device. In various embodiments, the example hardware diagram 900 may also describe at least a portion of a storage case. As shown, the hardware 200 includes a processor 920, a memory 930, a user interface 940, a network interface 950, and a storage 960 that are interconnected by one or more system buses 910. It will be appreciated that FIG. 9 is constructed in several ways from an abstract one, and the actual configuration of the components of hardware 900 is more complex than that shown.

  The processor 920 may execute any instructions stored in the memory 930 or the storage 960, or may be any hardware device that can process data. As such, processor 920 may include a microprocessor, field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other similar device.

  The memory 930 may include various memories such as, for example, L1, L2, or L3 cache or system memory. As such, the memory 930 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory device.

  User interface 940 may include one or more devices for enabling communication with a user, such as an administrator. For example, the user interface 940 may include a display, a mouse, and a keyboard for receiving user commands. In some implementations, the user interface 240 can include a command line interface or a graphical user interface that can be communicated to the remote terminal via the network interface 950.

  The network interface 950 may include one or more devices for enabling communication with other hardware devices. For example, the network interface 950 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. Furthermore, the network interface 950 may implement a TCP / IP stack to communicate according to the TCP / IP protocol. Various alternative or additional hardware or configurations for the network interface 950 are apparent.

  Storage 960 may include one or more machine-readable storage media such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, or similar storage media. In various embodiments, the storage 960 may store instructions executed by the processor 920 or data that the processor 920 processes. For example, the storage 960 includes Linux (registered trademark), Microsoft (registered trademark) Windows (registered trademark) OS, Apple (registered trademark) OSX (registered trademark), Apple (registered trademark) iOS (registered trademark), or Google ( A base operating system (OS) 961 such as a registered Android OS can be stored. Storage 960 also includes instructions for determining an application 962 for communicating with one or more storage cases. As part of storage case application 962, storage 960 instructs VOIP instruction 963 to communicate audio or video data with the storage case and the user of hardware 900 to release the medication from the storage case. Release instructions 964 to be stored.

  It will be apparent that various information described as being stored in the storage 960 may additionally or alternatively be stored in the memory 930. For example, operating system 961 and wall unit application 962 may be at least partially copied to memory 930 for execution on processor 920. In this regard, the memory 930 may be considered as being a “storage device” and the storage 960 may be considered as a “memory”. Various other arrangements are apparent. Further, both memory 930 and storage 960 may be considered “non-transitory machine-readable media”. As used herein, the term “non-transitory” will be understood to include all forms of storage except temporary signals, and includes both volatile and non-volatile memory.

  Although the illustrated hardware each includes one of the components described, various components may overlap in various embodiments. For example, the processor 920 may be a plurality of microprocessors, configured to perform the methods described herein independently, or to perform the steps or subroutines of the methods described herein. Configured, the plurality of processors cooperate to accomplish the functions described herein.

  Exemplary hardware and functions for the physician's device that have been described, an exemplary user interface for the physician's device, and related functions are described with reference to FIGS. As will be appreciated, various interfaces may be generated by the storage case application 962 and displayed via the user interface 940. Various variations are apparent.

  FIG. 10 illustrates an example user interface 1000 for authenticating a physician user. As shown, the interface includes fields 1010, 1020 for receiving a username and password, respectively. Selecting any one of fields 1010, 1020 may provide an interface for the user to enter alphanumeric values, for example, a soft keyboard interface provided by the operating system. The interface also includes a login button 1030 configured to enter a username and password. When the login button 1030 is selected, the input authentication information is compared with the authentication information stored locally and the authentication information stored locally, for example, for another authentication for authentication of a control center device or the like. It can be validated by sending it to the server. Upon receiving an indication or determination that the user has been authenticated, the application proceeds to the home screen.

  FIG. 11 illustrates an example user interface 1100 for showing a home screen. The home screen interface 1100 includes a home button 1110 (displayed as already selected) for accessing the home screen, a call log button 1120 for accessing the call log, and a setting menu. A navigation bar including a setting button 1130 may be displayed. While the home screen interface 1100 (and potentially other interfaces after login) is displayed, the application may listen for incoming calls. In particular, the control center or drug storage case may send a request to the physician device to establish a communication session.

  FIG. 12 illustrates an example user interface 1200 for displaying an input communication request indication. When the physician device receives the entered request, the entered request interface 1200 may be displayed, for example, to establish a communication session from a control center device or medication storage case. The input request interface 1200 includes medicine storage case instruction information 1210 corresponding to the input request. The user also has two buttons, which are an answer button 1220 for approving the input request and a negative button 1230 for denying the input request. Selecting the deny button 1230 may return the application to the home screen or to another screen that was displayed before the incoming request was received. When answer button 1220 is selected, the application may display an active communication session screen.

  FIG. 13 illustrates an example user interface 1300 for display during a communication session. While the active session interface 1300 is displayed, the application may provide at least an audio communication session via the device hardware. That is, the user can communicate with the medicine storage case called in the VOIP session by the speaker and the microphone of the doctor device. The active session interface 1300 includes a menu 1310 that includes a plurality of buttons. As described in more detail below, menu 1310 includes buttons for toggling the video stream, muting the microphone, holding the call, accessing the text message interface, and accessing the distribution interface. Can be included. The active session interface 1300 further includes an end call button 1320 to end the active session and return to the home screen or return to another screen that was displayed before the incoming request was received.

  FIG. 14 illustrates an example user interface 1400 for displaying patient videos and sending test messages. As shown in the figure, when the video button of the menu 1310 is selected, the video stream 1410 is subsequently displayed. Video stream 1410 may be received from a connected medication storage case or control center device. For example, when the video button is pressed, the application may begin to display video data that has already been transmitted from the connected storage case, or may send instructions to the storage case to transmit the video data. Further, as shown in the figure, when the hold button of the menu 1310 is selected as shown in the figure, the communication is held, and no other communication is transmitted / received until the hold is released.

  Menu 1310 indicates that text message interface elements 1420, 1430 are shown when a text message button is further selected. As shown, interface 1400 includes a text area 1420 for receiving an input text message. When the text area 1420 is selected, the user can display an interface element for inputting text using, for example, an OS soft keyboard. Interface 1400 also includes a send button 1430. Selecting the send button 1430 may cause the application to send a text message to the calling storage case, and upon receiving the text message, the message may be displayed to the patient, for example, via an LCD screen.

  FIG. 15 illustrates an alternative user interface 1500 for displaying patient video. For example, an alternative user interface 1500 may be displayed when a video feed is activated and the physician rotates the phone 90 degrees. The application can access the operating system, determine the current orientation of the physician device, and switch to the alternate interface 1500 when the device is held approximately laterally. As shown, the alternative interface displays the video stream on a full screen 1510. Obviously, various alternative arrangements are possible. For example, a menu similar to menu 1310 may be displayed in video area 1510. The application may return to the previous interface, interface 1400, when the physician device is rotated back approximately vertically.

  FIG. 16 illustrates an example user interface 1600 for displaying a dispense button for dispensing medication to a patient. As shown, menu 1310 indicates that a distribution button has been selected. As a result, a plurality of distribution interface elements 1610, 1620, 1630 are displayed as part of the interface 1600. The interface 1600 includes two dispensing buttons 1610, 1620 that correspond to available medications for dispensing from a connected medication storage case. There may be fewer or additional buttons in various embodiments. In some embodiments, the connected storage case may send information to the physician device that identifies other information, such as an expiration date, as well as available medications. Interface 1600 may then display corresponding buttons 1610, 1620. Although not shown, in some alternative embodiments, interface 1600 may additionally include a field for receiving a physician signature. For example, in some situations there may be a rule that requires a doctor's signature for any prescription. When the signature input or distribution button is pressed, the physician device stores or transmits the signature image, text, or other display method to the control center.

  As shown, the interface 1600 identifies two available medications for dispensing from a connected storage case. The first button 1610 indicates that a “Jr. Epipen” drug with an expiration date of 20 December 2015 is available. The second button 1620 indicates that a “Sr. Epipen” drug with an expiration date of February 15, 2015 is available. Selecting either button 1610, 1620 causes the physician device to send instructions to the connected storage case and dispense the corresponding medication. For example, a connected storage case may transmit an index or other instruction information for each drug along with available drugs. Next, when a button is selected, the application may send instructions including instruction information corresponding to the selected medication. The interface 1600 also includes a cancel button 1630 that returns to the previous interface that does not include the dispensing elements 1610, 1620, 1630.

  FIG. 17 illustrates an alternative user interface 1700 for displaying a dispense button for dispensing medication to a patient. In some implementations, button 1720 may indicate that selection is not possible if the corresponding medication is not available. As shown, the connected storage cases cannot dispense “Sr Epipen” medication by displaying that button 1720 is not selectable. The application can determine that the drug is not available, for example, if the drug is expected to be available by the application but is not reported as available from the connected storage case, or the storage case is clearly May report drug not available. In various alternative embodiments, the interface 1700 may simply omit displaying all buttons for unavailable drugs.

  FIG. 18 illustrates an example user interface 1800 for displaying a log of previous communication sessions. Call history interface 1800 may be made accessible by selecting call history button 1120 in the navigation menu. As shown, the call history interface displays a plurality of inputs 1810, 1820, 1830, 1840 that identify all previous input requests or, alternatively, all allowed input requests. Upon selecting inputs 1810, 1820, 1830, 1840, the application may display an interface to display or enter additional information for the call.

  FIG. 19 illustrates an example user interface 1900 for receiving physician notes regarding a communication session. The annotation interface 1900 may be made accessible by selecting the inputs 1810, 1820, 1830, 1840 from the call history interface 1800. As shown, interface 1900 includes a call field 1910 and a text field 1920 for receiving physician notes. When selected, text field 1920 may provide an interface element, such as an OS soft keyboard, for entering text to the physician. The interface 1900 additionally includes a send button 1930 for sending the text in the text field 1920 to a command center device with storage for storing call records. When the cancel button 1940 is selected, the application returns to the previous screen such as the call history interface 1800, for example. Although not shown, in some alternative embodiments, interface 1600 may additionally or alternatively include a field for receiving a physician's signature. For example, in some situations, there may be rules that require a doctor's signature for any prescription. When the enter signature or send button 1930 is pressed, the physician device stores or sends the signature image, text, or other display method to the control center.

  FIG. 20 illustrates an exemplary method 2000 for communicating with a medication storage case. Method 2000 may be performed by a component of a physician device, such as physician device 900. The method begins at step 2005 and proceeds to step 2010 where the device receives the entered request and establishes a communication session. Based on the received request, the instruction information of the request input by the device in step 2015 is displayed on the interface 1200, for example. In step 2020, the device determines whether the physician user has granted the request. If not, in step 2025 the device sends a disallow message to the control center or drug storage case. The control center or drug storage case continues to send a request and attempt to establish a communication session to attempt to connect to another physician device. The method ends at step 2055.

  However, if the physician approves the entered request at step 2020, the method proceeds to step 2030 and the device establishes a two-way communication session with the drug dispenser. Next, in step 2035, the device displays one or more distribution buttons. For example, as described above, a button is displayed for the user request. Next, in step 2040, the device determines whether the physician has pressed the dispense button. If not, the method skips to step 2050. If the physician presses the dispense button, in step 2045, the device sends instructions for dispensing the corresponding medication to the user. In step 2050, the device determines whether the session has been terminated, for example by a local user or a user of a remote medication dispenser. If not, the method loops back to step 2040 and continues checking the physician's choice of dispense button. Alternatively, the method ends at step 2055.

  Various modifications to the above-described method are apparent in terms of additional functionality for the physician devices described herein. For example, the method 2000 includes additional steps for interpreting input data describing available medications, calling hold muting or holding, sending a text message, and displaying a video stream. It is possible. Various additional variations are apparent.

  In accordance with the foregoing description, various exemplary embodiments allow a physician to quickly access and prescribe medication at a remote location. For example, an agent that can establish an audio or video communication session and provide a physician device application that can send dispensing instructions to a remote medication dispenser, enabling a competent human resource to understand or handle an emergency situation and to help or handle the situation Can be effectively provided. Various other advantageous effects are evident from the foregoing description.

  From the foregoing description, it will be apparent that various exemplary embodiments of the invention may be implemented in hardware and / or firmware. Moreover, various exemplary embodiments can be implemented as instructions recorded on a machine-readable storage medium and read and executed by at least one processor to perform the operations described in detail herein. . A machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal or laptop computer, server, or other computing device. Accordingly, machine-readable storage media may include read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and similar storage media.

  Those skilled in the art will appreciate that any block diagram described herein has been conceptually illustrated to implement the principles of the invention. Similarly, it will be understood that any flowchart, flowchart, state transition diagram, pseudocode, etc. represents various processes, which can be substantially represented in machine-readable media, such as a computer Or executed by the computer or processor, whether or not the processor is explicitly indicated.

  Although various exemplary embodiments have been described with particular reference to that particular exemplary embodiment, the invention is capable of other embodiments and its details are capable of modifications in various obvious respects. Will be understood. It will be apparent to those skilled in the art that various modifications and variations are possible within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and drawings are used for reference only and are not intended to limit the invention in any way, but are defined only by the claims.

Claims (20)

A non-transitory machine readable storage medium encoded with instructions to be executed by a user device, the non-transitory machine readable storage medium comprising:
Instructions for displaying instruction information of a request input to establish a communication session with a patient operating a drug dispenser;
Instructions for establishing an interactive communication session with the patient via the medication dispenser based on a physician user of the user device that approves the input request;
Instructions for displaying a dispense user interface (UI) element during the interactive communication session;
Instructions for receiving a selection of dispense UI elements from the physician user;
A non-transitory machine-readable storage medium that includes instructions for the medication dispenser to send a command to dispense medication to the patient based on the selection. The non-transitory machine-readable storage medium of claim 1.
Instructions for searching through the drug distributor for drug data describing available drugs;
A non-transitory machine-readable storage medium further comprising instructions for displaying drug data instruction information on the dispense UI element.   The non-transitory machine-readable storage medium according to claim 2, wherein the drug data includes an expiration date of the drug. The non-transitory machine-readable storage medium of claim 1.
Instructions for displaying a second dispense UI element during the two-way communication session;
Instructions for receiving a selection of the second dispense UI element from the physician user;
A non-transitory machine readable storage medium further comprising instructions for the medication dispenser to send a command to dispense a second medication to the patient based on the selection of the second dispense UI element. The non-transitory machine-readable storage medium of claim 1.
Further comprising instructions for receiving medication information indicating whether the medication is available for dispensing to the patient;
The instruction to display a dispense user interface (UI) element displays the dispense UI element as not selectable when the drug information indicates that the drug for dispensing to the patient is not available Including instructions for
Instructions for receiving a selection of the dispense UI element from the physician user are configured to be executed based on the medication information indicating that the medication is available for dispensing to the patient. A temporary machine-readable storage medium. The non-transitory machine-readable storage medium of claim 1.
Instructions for receiving a stream of video data from the drug dispenser via the interactive communication session;
A non-transitory machine-readable storage medium further comprising instructions for displaying video to the physician user based on the stream of video data. The non-transitory machine-readable storage medium of claim 1.
Instructions for receiving a message input from the physician user;
A non-transitory machine readable storage medium further comprising instructions for sending a command for the medication dispenser to display an input message to the patient. A method performed by a user device, the method comprising:
Establishing a two-way communication session between a physician user of the user device and a patient via a remote drug dispenser;
Receiving information describing a medication relating to the medication dispenser;
Displaying a dispensing user interface (UI) element indicating the medication for selection by the physician user;
A method comprising the step of the remote medication dispenser sending a command to dispense the medication to the patient based on selection of a dispense UI element. The method of claim 8, wherein
The received medication information includes an expiration date, and the method includes displaying the expiration date by the dispensing UI element. 9. The method of claim 8, wherein the received information additionally describes a second medication relating to the medication distributor;
Displaying a second dispense UI element indicative of the second drug for the drug dispenser;
The method further comprising the step of transmitting a command for the remote medication dispenser to dispense the second medication to the patient based on the selection of the second dispense UI element. The method of claim 8, wherein
The received information indicates whether the medication is available for dispensing from the remote medication dispenser;
Displaying information indicating that the drug cannot be dispensed based on received information indicating that the drug cannot be dispensed; and
Disabling selection of the dispense UI element based on received information indicating that the drug cannot be dispensed. The method of claim 8, wherein
Receiving a stream of video data from the remote drug dispenser;
Displaying the video to the physician user based on the stream of video data. The method of claim 8, wherein
Receiving a message input by the physician user;
The method further comprising the step of sending a command for the remote medication dispenser to display the entered message to the patient. A portable communication device used by a physician user, the portable communication device comprising:
A communication interface;
A display device;
A touch input device;
Memory,
A processor in communication with the memory, the processor comprising:
In order to establish a communication session with the patient operating the drug dispenser, display instruction information of the input request via the display device;
Establishing a two-way communication session with the patient via the communication interface and the medication dispenser based on a user device of a physician user approving the input request;
Displaying a dispense user interface (UI) element via the display device during the interactive communication session;
Receiving a selection of the physician user's dispense UI element via the touch input device;
A portable communication device configured to send, via the communication interface, a command for dispensing the medication to the patient based on the selection. 15. The portable communication device of claim 14, wherein the processor is
A portable communication device further configured to receive medication data describing available medication from the medication dispenser and to display medication data instruction information at the dispense UI element via the display device. The portable communication device of claim 15, wherein
The portable communication device, wherein the medication data includes an expiration date of the medication. The portable communication device according to claim 14, wherein the processor 1s includes:
Displaying a second dispense UI element via the display device during the interactive communication session;
Receiving a selection of the second dispense UI element from the physician user via the touch input device;
A portable communication device, further configured to send a command for dispensing a second medication to the patient based on selection of the second dispense UI element via the communication interface. The portable communication device of claim 14, wherein
The processor 1s is further configured to receive medication information indicating whether the medication for dispensing to the patient is available;
During display of a dispense user interface (UI) element, the processor is configured to display a dispense UI element that cannot be selected if the drug information indicates that the drug is not available for dispensing to the patient. Composed of
The portable communication device configured to accept a selection of the dispense UI element from the physician user based on the medication information indicating that the medication for dispensing to the patient is available . The portable communication device of claim 14, wherein
The processor is
Receiving a stream of video data from the drug dispenser via the interactive communication session;
A portable communication device further configured to display video to the physician user via the display device based on a stream of video data. The portable communication device of claim 14, wherein
The processor is
Receiving a message entered by the physician user;
A portable communication device, wherein the medication dispenser is further configured to send a command to display the entered message to the patient.

Images