TWI678678B - System and method for medicament storage, dispensing, and administration - Google Patents

Abstract

Various exemplary embodiments relate to a method, device, and non-transitory machine-readable storage medium encoded with instructions for execution by a user device, the medium including: an indication for displaying an incoming request to communicate with An instruction to operate a patient of a medicine dispenser to establish a communication session; an instruction to establish a two-way communication session with the patient via the medicine dispenser based on an approval request from a physician user of the user device ; An instruction to display a user interface (UI) element for allocation during the two-way communication session; an instruction to receive a selection of the assigned UI element from the physician user; and a method for transmitting the selection based on the selection A medication dispenser orders an order to dispense a medication to the patient.

Description

System and method for drug storage, distribution and management [Cross Reference of Related Applications]

This patent application is a part of a co-pending U.S. Patent Application No. 14 / 282,884 filed on May 20, 2014; a continuation of U.S. Patent Application No. 14 / 282,884; Part of the PCT Application No. PCT / US2013 / 072878 continues the application; PCT Application No. PCT / US2013 / 072878 claims the priority of US Provisional Patent Application No. 61 / 732,753 filed on December 3, 2012; the The entire text of these applications is incorporated herein for all purposes.

The various illustrative embodiments disclosed herein relate generally to the storage, distribution, and management of drugs.

Some people suffer from conditions that can lead to an emergency. In an emergency, the immediate administration of a medicine is the most important. For example, exposure to an allergen in a person with severe allergies can trigger an allergic reaction. Due to its potential for acute attacks and concomitant death (depending on the severity of the allergy), it is important to administer the treatment as quickly as possible (such as the administration of a certain amount of adrenaline). One of the epinephrine autoinjectors is usually prescribed for patients with known allergies to treat sudden allergic reactions, and it is recommended that patients carry an autoinjector with them so that they can be used in emergency situations. Similarly, patients with other conditions that can cause Patients who need immediate treatment (emergency) prescribe an appropriate medicine or device to carry with them.

Given the current need for various emergency plans to manage epinephrine and other drugs and devices, this article presents a brief overview of one of the various exemplary embodiments. Some simplifications and omissions may be made to the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments without limiting the scope of the invention. Subsequent paragraphs will be followed by a detailed description sufficient to allow one of ordinary skill to make and use one of the preferred exemplary embodiments of the present invention.

Various embodiments relate to a non-transitory machine-readable storage medium encoded with instructions for execution by a user device, the medium including: displaying an indication of an incoming request to interact with a medicine dispenser An instruction for a patient to establish a communication session; an instruction for establishing a two-way communication session with the patient via the medicine dispenser based on the approval of an incoming request by a physician user of the user device; Displaying an instruction to dispense a user interface (UI) element during a communication session; an instruction to receive a selection of the distribution UI element from the physician user; and to transmit based on the selection to cause the medicine dispenser to load a medicine An order assigned to the patient.

Various embodiments relate to a method performed by a user device, the method comprising: establishing a two-way communication session between a physician user and a patient of the user device via a remote medicine dispenser; receiving Describes information about a medicine associated with the medicine dispenser; display indicates that one of the medicines assigns a user interface (UI) element for the physician user to select; and transmits the remote medicine based on the selection of the assigned UI element The dispenser orders the medicine to one of the patients.

Various embodiments relate to a portable communication device for use by a physician user. The portable communication device includes a communication interface, a display device, a touch input device, a memory, and communication with the memory. A processor configured to: display an instruction of an incoming request via the display device to establish a communication session with a patient operating a medicine dispenser; based on one of the user devices Physician user approval The incoming request establishes a two-way communication session with the patient via the communication interface and the medicine dispenser; displays a distribution user interface (UI) element via the display device during the two-way communication session; and via the touch The input device receives a selection of the dispensing UI element from the physician user; and transmits a command for the medicine dispenser to dispense a medicine to the patient via the communication interface and based on the selection.

Various embodiments describe the non-transitory machine-readable storage medium as described in the technical solution 1, further comprising: an instruction for retrieving medicine information describing medicines obtainable through the medicine dispenser; and for displaying and distributing The UI element is associated with an instruction indicated by the drug profile.

Various embodiments are described herein, wherein the drug profile includes an expiration date for one of the drugs.

In addition, various embodiments include: an instruction to display a second assigned UI element during the two-way communication session; an instruction to receive a selection of one of the second assigned UI elements from the physician user; and an instruction based on the This selection of the second distribution UI element transmits an instruction that causes the medicine dispenser to dispense a second medicine to the patient.

In addition, various embodiments include instructions for receiving drug information indicating whether the drug is available for distribution to the patient, wherein the instructions for displaying a distribution user interface (UI) component include instructions for when the drug information The instruction indicating that the medicine is not available for distribution to the patient displays the assigned UI element as non-selectable, and the instruction for receiving a selection of one of the assigned UI elements from the physician user is configured to be based on the indication of the medicine It can be used for the drug information assigned to the patient.

In addition, various embodiments include: an instruction for receiving a stream of video data from the medicine dispenser via the two-way communication session; and an instruction for displaying a video to the physician user based on the video data stream.

In addition, various embodiments include: an instruction for receiving a message entry item from the physician user; and for transmitting the medicine dispenser to display the input message to the patient One of the command instructions.

100‧‧‧Medicine storage box

110‧‧‧Box

111‧‧‧Start button

112‧‧‧Stop button

113‧‧‧Display

114‧‧‧ Microphone

115‧‧‧Speaker

116‧‧‧Status Light

120‧‧‧ gate

122a‧‧‧ hinge

122b‧‧‧ hinge

130‧‧‧ drugs

140‧‧‧internal area

142‧‧‧Lower flange

200‧‧‧block diagram

210‧‧‧Electronics Subsystem

212‧‧‧Processor

214‧‧‧Supports electronic components / audio interface

216‧‧‧Supports electronic components / SD card interface / memory card

218‧‧‧Supports electronic components / touch screen interface

220‧‧‧ Supports electronic components / General Purpose Input / Output (GPIO) interface

222‧‧‧Supports electronic components

224‧‧‧Supports electronic components / program memory

226‧‧‧Supports electronic components / data memory

228‧‧‧Supports Electronic Component / Polyphone System (POTS) interface

230‧‧‧Supports electronic components / closed I / O interface

232‧‧‧Supports electronic components / RS-232 serial interface

240‧‧‧ mechanical subsystem

244‧‧‧Medication lock / unlock mechanism

250‧‧‧components / speakers

252‧‧‧Component / Headphone

254‧‧‧component / microphone

256‧‧‧component / touch screen device

258‧‧‧Component / Status LED

260‧‧‧component / button

262‧‧‧Component / Ethernet / WiFi

264‧‧‧component / landline

266‧‧‧components

300‧‧‧Schematic / System

310‧‧‧ processor

311‧‧‧SD card connector / memory device

312‧‧‧Real-time clock chip

313‧‧‧Temperature sensor

314‧‧‧EEPROM / Memory Device

315‧‧‧DDR3 memory / memory device

316‧‧‧Anti-Flash Memory / Memory Device

317‧‧‧RS232 Transceiver

318‧‧‧ connector

320‧‧‧ Door Opening Detection Module

322‧‧‧proximity sensor

330‧‧‧Audio Interactive Unit

332‧‧‧Audio codec

334‧‧‧Headphone

336‧‧‧Speaker

338‧‧‧Microphone

340‧‧‧user interface unit

341‧‧‧Start and stop buttons

343‧‧‧Status and activity LED

345‧‧‧LCD display

347‧‧‧Touch screen

349‧‧‧ backlight driver

350‧‧‧connection unit / connection module

351‧‧‧Ethernet PHY Chip

353‧‧‧Ethernet connector

355‧‧‧WiFi Module

357‧‧‧ Voice Direct Access Configuration (DAA) chipset

359‧‧‧RJ-11 connector

360‧‧‧Medicine device distribution circuit

362‧‧‧Solenoid valve interface / solenoid valve controller

364‧‧‧Solenoid valve interface

400‧‧‧ Cover

410‧‧‧hollow envelope body

420‧‧‧ opening

430‧‧‧ track

500‧‧‧ cross section

510‧‧‧ hook

512‧‧‧ Pivot Point

514‧‧‧Spring

562‧‧‧Solenoid valve

600‧‧‧ Method

610‧‧‧step

620‧‧‧step

630‧‧‧step

640‧‧‧step

650‧‧‧step

660‧‧‧step

670‧‧‧step

680‧‧‧step

690‧‧‧step

700‧‧‧ Method

710‧‧‧step

720‧‧‧step

730‧‧‧step

740‧‧‧step

750‧‧‧step

760‧‧‧step

800‧‧‧ network environment

810‧‧‧Internet

820‧‧‧Control Center Device / Control Center

830‧‧‧Physician device

900‧‧‧ Hardware Picture / Physician's Device / Hardware

910‧‧‧System Bus

920‧‧‧ processor

930‧‧‧Memory

940‧‧‧user interface

950‧‧‧Interface

960‧‧‧Storage

961‧‧‧operating system (OS)

962‧‧‧Storage Box App / Closet App

963‧‧‧ Voice over Internet Protocol (VOIP) Instruction

964‧‧‧ release instruction

1000‧‧‧ user interface

1010‧‧‧ Field

1020‧‧‧field

1030‧‧‧Login button

1100‧‧‧user interface / home screen interface

1110‧‧‧Home button

1120‧‧‧Call History Button / Call History Button

1130‧‧‧set button

1200‧‧‧user interface / incoming request interface

1210‧‧‧Instructions

1220‧‧‧ Answer button

1230‧‧‧Reject button

1300‧‧‧user interface / active session interface

1310‧‧‧Menu

1320‧‧‧End call button

1400‧‧‧user interface

1410‧‧‧ Video Stream

1420‧‧‧Text message interface component / text area

1430‧‧‧Text message interface component / Send button

1500‧‧‧user interface

1510‧‧‧Video Area / Full Screen

1600‧‧‧user interface

1610‧‧‧Assign interface components / Assign button

1620‧‧‧Assign interface components / Assign button

1630‧‧‧Assign interface components / cancel button

1700‧‧‧user interface

1720‧‧‧ button

1800‧‧‧user interface / call history interface

1810‧‧‧ credited to the project

1820‧‧‧ credited to the project

1830‧‧‧ credited to the project

1840‧‧‧ credited to the project

1900‧‧‧user interface / annotation interface

1910‧‧‧Call details

1920‧‧‧ text field

1930‧‧‧Send button

1940‧‧‧Cancel button

2000‧‧‧ Method

2005‧‧‧step

2010‧‧‧Steps

2015‧‧‧steps

2020‧‧‧step

2025‧‧‧step

2030‧‧‧step

2035‧‧‧step

2040‧‧‧step

2045‧‧‧step

2050‧‧‧step

2055‧‧‧step

Refer to the accompanying drawings to better understand various exemplary embodiments, wherein: FIG. 1 illustrates an exemplary drug storage box; FIG. 2 illustrates a block diagram of an exemplary component of a drug storage box; and FIG. 3 illustrates An exemplary schematic diagram of an exemplary component of a drug storage box; FIG. 4 illustrates an exemplary envelope for holding a drug; FIG. 5 illustrates a cross-section of an exemplary drug storage box, including An exemplary actuator for holding and releasing a sleeve; FIG. 6 illustrates an exemplary method for contacting emergency services via a medication storage box; and FIG. 7 illustrates permission for access in response to a remote command An exemplary method of a medicine; FIG. 8 illustrates an exemplary network environment of a medicine storage box; FIG. 9 illustrates an exemplary hardware diagram of a physician device or a control center device; An exemplary user interface for a physician user; FIG. 11 illustrates an exemplary user interface for presenting a home screen; FIG. 12 illustrates an exemplary user interface for displaying an instruction for an incoming communication request User interface; Figure 13 shows a An exemplary user interface displayed during a session; FIG. 14 illustrates an exemplary user interface for displaying patient videos and transmitting text messages; FIG. 15 illustrates an alternative user interface for displaying patient videos; FIG. 16 illustrates an exemplary user interface for displaying a dispensing button for dispensing a drug to a patient; FIG. 17 illustrates an alternative user interface for displaying a dispensing button for dispensing a drug to a patient User interface; FIG. 18 illustrates an exemplary user interface for displaying a record of a previous communication session; FIG. 19 illustrates an exemplary user interface for receiving physician notes related to a communication session; and FIG. 20 illustrates an exemplary method for communicating with a medication storage tank.

Although an emergency plan for a patient to carry medicines with them is usually effective, it is not a satisfactory solution. In many cases, a patient cannot obtain appropriate medicines to respond to an emergency. For example, if the condition has not been diagnosed, emergency medicines or devices cannot be prescribed in advance. As another example, if the patient is a child or otherwise requires supervision or instruction in the use of medicines or devices, the patient cannot actually carry the place and is therefore not available. In addition, appropriate supervisors of management cannot be provided. Except in special cases such as these, patients are prone to forget the prescription or otherwise unable to use the portable prescription medicine or device immediately in an emergency. For at least these reasons, an alternative or complementary solution is needed to provide appropriate prescription drugs or devices in emergency situations.

As will be explained in more detail below, various embodiments include a medication storage box that restricts access to a stored medication until a command is received from a remote operator (such as a call physician) to release the medication to a local patient or otherwise User use. To enable the remote operator to properly determine whether and when to appropriately dispense a medication from the storage box, the storage box additionally facilitates two-way communication with the remote operator. Through this communication, the remote operator can obtain information about the patient and circumstances sufficient to determine whether the drug should be dispensed.

The descriptions and diagrams presented herein illustrate various principles. It should be understood that those skilled in the art will be able to contemplate various configurations, and although such configurations are not explicitly described or shown herein, such configurations embody these principles and are included within the scope of the present invention. As used herein, the term "or" is used herein unless otherwise indicated (such as "otherwise" or "or alternatively") Means a non-exclusive or (ie, or). In addition, the various embodiments described herein are not necessarily mutually exclusive, but may be combined to produce additional embodiments that incorporate the principles described herein. It should be understood that the methods and devices described herein can be used to dispense drugs, medical devices, and combinations thereof. Accordingly, the term "drug" as used herein will be understood to encompass both pharmaceuticals and medical devices. In addition, it should be understood that the various devices described herein can be used to provide controlled access to materials, devices, and other items outside the medical field.

Reference is now made to the drawings, in which the same element symbols refer to the same components or steps, to reveal the broad aspects of various exemplary embodiments.

FIG. 1 illustrates an exemplary medicine storage box 100. Various embodiments of the drug storage case disclosed herein, including the exemplary case 100, may also refer to a medical management system. As shown in the figure, the storage box 100 includes a box body 110 and a door 120 attached to the box body 110 by hinges 122a, 122b. The box 110 includes an inner region 140 accessible through an opening in a front surface of the box 110. In various embodiments, the storage tank 100 may be mounted to a wall or other structure. Therefore, the storage box may also contain fixing hardware sufficient to achieve this installation. For example, the rear surface of the case 110 may include a recess for receiving a bolt head of a bolt that has been screwed into a wall. As another example, fixing the hardware may include a separate mounting structure that is fixed to the wall by screws and the rear surface of the box 110 is hooked, clipped, or otherwise attached to one of them. I will appreciate various other types of fixing hardware used to secure the storage box 100 to a structure. In various embodiments, the rear surface, bottom surface, or other surface of the cabinet may include connectors such as electrical, network, and telephone connections.

A bottom flange 142 is formed on the bottom of the case to dispense the medicine 130 before it is removed by the user. Before the medicine 130 is dispensed, the medicine 130 is held in another area of the inner area 140 that is inaccessible or inaccessible to the end user. For example, the medicine 130 may be held in a portion of the inner region 140, which is located above the opening and the lower flange 142 and hidden behind the front surface of the storage box 110. In various embodiments, the storage tank 100 is configured to store and dispense multiple drugs that may be different from each other. For example, in some embodiments, the storage tank Able to dispense adult and child formulas that can be contained in an adrenaline autoinjector in various packages, such as a product box.

To hold the medication prior to dispensing, the storage box 100 may include a medication lock (not shown) or other lockable retention structure, such as a door (not shown). Alternatively, the illustrated door 120 may be locked in a closed position. Various exemplary drug locks and other retention structures will be described in more detail below. Regardless of the particular retaining structure used, in various embodiments, the retaining structure can be electronically moved from a locked state to an actuator (not shown) controlled by a processor (not shown). In an unlocked state, the processor is operable to unlock the holding structure according to an instruction received from a remote site. For example, upon receiving an unlock signal (such as an Internet packet containing an allocation instruction), the processor may transmit an access signal to the actuator, which in turn unlocks the holding structure. Once the holding structure is in the unlocked state, the drug can be freely removed from the device or the user can manually operate the unlocked holding structure (eg, open an unlock door) to release the drug.

The storage box 100 also includes a plurality of input / output devices for communicating with a local user. As shown in the figure, the storage box includes a "start" button 111 and a "stop" button 112. Once the start button 111 is pressed, the storage box 100 can start a two-way communication session with a remote site via a communication unit (not shown). The communication session may involve audio communication via a microphone 114 and a speaker 115 so that the local user and the remote operator can talk. Once a local user presses the stop button 112, the stop button 112 may be configured to end the call or suspend any procedure performed by the storage box 100.

A display 113 may also be provided for various purposes. For example, a display can facilitate a video feed between a remote site and a local user as part of a two-way communication session and combined with a camera (not shown). Alternatively, the display 113 may display various information to the local user, such as a medication use instruction or status update regarding the current action performed by the storage box 100 or a remote operator. Therefore, the displayed information can be stored locally or remotely. 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 embodiments, the display 113 includes a touch screen input. In these embodiments, the display 113 may include soft buttons instead of the start button 111 and the stop button 112, or may include soft buttons in addition to the start button 111 and the stop button 112. A 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 to provide access to recorded information or internal partitions to an authorized user. Replace any dispensed or expired medication.

The status of the storage box 100 may be transmitted in an alternative or additional manner. For example, as shown in the figure, the storage tank 100 includes a plurality of status lights 116. Status lights can convey system information (such as power-on or on status) or process flow information (such as whether a call has been made or whether a medication has been dispensed). I will understand various other uses of the status light 116.

In various embodiments, the electronics controlling the operation of the storage box may be continuously powered by a battery, a power supply, or other power source. Other embodiments may implement power saving features that reduce energy consumption. For example, during periods of non-use, the electronics of storage box 100 may be switched off or placed in a "sleep" mode. Once activated by a local user, these electronic devices can be powered on or awakened to perform associated functions. For example, opening the door 120, pressing the start button, or pressing a separate "power" button can be configured to turn on or wake up the electronics. I will understand various other power saving features.

Once a medication has been dispensed, the storage tank 100 can be reloaded with other medications by service personnel. Although in some embodiments, reloading can be achieved by opening the box 100, in other embodiments, the service personnel can directly reload the box through the front opening product access area instead of opening the box. Various alternative reloading methods that do not require special service access (eg, open the box) can be used (such as, for example) to load a drug through a slot in the top of the box, as described below with respect to FIG.

FIG. 2 illustrates an exemplary block diagram 200 of an exemplary component of a medication storage tank. in In various embodiments, the block diagram represents various electronic and mechanical components of the exemplary storage tank 100 of FIG. 1.

As shown in the figure, the block diagram 200 includes an electronic device subsystem 210, a mechanical subsystem 240, and many additional components 250-266. The electronic device subsystem 210 includes a processor 212 and various supporting electronic components 214 to 232. The processor 212 may actually include any device capable of coordinating the functions described herein, such as, for example, a microprocessor, a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In various embodiments, the processor 212 is an ARM-based microprocessor.

The processor 212 provides access to various forms of memory / data storage (which includes an SD card interface 216, a built-in program memory 224, and a data memory 226). The program memory 224 stores software instructions for instructing the processor to perform various methods described herein, such as the exemplary methods described with respect to FIGS. 6-7. For example, program memory 224 may store an operating system (such as a Linux kernel with an appropriate device driver), real-time transfer protocol (RTP) stacking instructions, session initiation protocol (SIP) stacking instructions, and direct access configuration (DAA) Stacking instructions and instructions for providing a Qt graphical user interface (GUI). In addition, the program memory 224 may store event handler instructions for responding to incoming events such as door opening / closing, monitor reset, factory reset, firmware upgrade, input manufacturing mode, status / report, and failure notification. The program memory 224 may also store various audio components, such as the Advanced Linux Sound Architecture (ALSA) library, software codec instructions, and echo / noise cancellation algorithms.

The data memory 226 may be used by the processor to store various data, such as one of log data, location information, or temperature information about the use of the storage box. Various other data stored in the data memory 226 or on an SD card or other memory card will be understood in view of the present invention. Alternatively or in addition, an SD card or other memory card 216 may be used to store boot commands, firmware images, activity records, predefined information and messages, and other information.

The electronics subsystem 212 includes an audio interface 214, such as an audio codec, for the processor to receive and output audio through various audio devices, such as a speaker 250, a headset 252, or a microphone 254. Similarly, the electronic device subsystem 210 includes a touch screen interface 218 for outputting video data to a touch screen device 256 and receiving touch input from the touch screen device 256. The electronics subsystem 210 provides a general-purpose input / output (GPIO) interface 220 to various other input / output devices, such as status LEDs 258 or buttons 260.

The processor 212 may also be connected to various external devices. For example, to connect to other devices via the Internet or other networks, the electronic device subsystem 210 includes a physical network interface (PHY) that communicates through various media, such as Ethernet or WiFi 262. In addition, the electronic device subsystem 210 includes a general telephone system (POTS) interface 228 capable of establishing a telephone call via a landline communication line 264. To achieve system debugging and other maintenance, the electronic device subsystem 210 includes an RS-232 serial interface 232. A device with a universal asynchronous transceiver (UART) can be attached to the RS-232 serial interface 232 to communicate with the processor Exchange of information and instructions.

The electronics subsystem 210 may also include a closed I / O interface 230 for communicating with the mechanical subsystem 240. In various embodiments, the closed I / O interface 230 may utilize only the GPIO interface 220. The mechanical subsystem 240 includes two devices. A door opening detection device (such as a switch, button, proximity sensor, or motion detector) may be positioned to send a signal to the closed I / O interface 230 when the door is opened. In various embodiments, this signal can be used to power up or wake up the electronic device subsystem 210. A medication lock / unlock mechanism 244 (such as a solenoid valve interface or other actuator interface) receives an access signal from the processor 212 via the closed I / O interface 230. Upon receiving this signal, the drug lock / unlock mechanism 244 causes a drug to be dispensed, as explained in more detail below.

FIG. 3 illustrates an exemplary schematic diagram 300 of an exemplary component of a medicine storage tank. In various embodiments, the schematic diagram 300 may describe various systems of the exemplary storage tank 100 and may be plotted A more detailed embodiment of the block diagram 200 of FIG. 2 is shown.

As shown in the figure, the system is configured around a processor 310. As described above, the processor 310 may be a microprocessor, FPGA, ASIC, or any other device capable of performing the described functions. The processor 310 may include some built-in memories and may be connected to other forms of memory, such as an SD card connector 311, an EEPROM 314, a DDR3 memory 315, and an inverse and flash memory 316. The processor 310 can 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. In addition, it should be understood that fewer or additional memory devices may be utilized and memory device types other than those shown.

The processor may also utilize other devices that are not part of a separately described subsystem. For example, in various embodiments, the system 300 may maintain a usage record based on a date and time reported by an instant clock chip 312. In some embodiments, the processor 310 may store or monitor the temperature of a drug or an environmental area reported by a temperature sensor 313. In some embodiments, a temperature sensor 313 can be used by the processor 310 or other wafers (not shown) to adjust the temperature to which the drug is exposed. For example, a storage tank may have a fan or other device to control an internal temperature. In these embodiments, the processor 310 may be configured to control the fans in response to the temperature sensor 313 reporting a temperature or hourly temperature reading above a predetermined threshold. Such features may be particularly useful in embodiments where the storage box is portable or otherwise subject to an inconsistent climate. In addition, as described above, the processor 310 may provide a debugging or repair interface to other devices via an RS232 transceiver 317 and a connector 318.

As explained herein, in various embodiments, the system 300 may be powered on or woken up in response to detecting that a door has been opened. To provide this function, a door opening detection module 320 includes one or more proximity sensors 322 for detecting that the door has been moved away from the closed position. This information can be transmitted to the processor via one or more GPIO lines. In various alternative embodiments, other devices (such as a dedicated power button or one of the start and stop buttons 341) may be used To replace the proximity sensor 322.

To facilitate audio communication, an audio interactive unit 330 communicates with the processor 310. That is, the audio interactive unit 330 includes an audio codec 332 that exchanges data with the processor 310 via a multi-channel audio serial port (McASP) and an internal integrated circuit (I2C) bus. The audio codec 332 then presents the audio data received from the processor 310 through a headset 334 and a speaker 336 and digitizes the analog audio data received via a microphone 338. It should be understood that the processor can only serve as one of the audio data transmission devices to enable data to be exchanged between the audio interactive unit and a connection unit 350. In other embodiments, the audio interactive unit 330 may be directly connected to the connection unit 350 to thereby allow the data to be transferred to a remote location without the processor 310 disposing of the data. For example, the audio interactive unit 330 can transmit and receive analog audio data through an RJ-11 connector. In some embodiments, this direct connection may be selectively enabled or disabled by the processor 310.

For additional types of local user interactions, the system 300 includes a user interface unit 340 that includes various input and output devices. For example, the user interface unit 340 may include a start and stop button 341 for starting and interrupting the operation of the system connected to a remote site. Thus, the start and stop buttons 341 can provide signals to the processor 310 via one or more GPIO channels. Similarly, the processor may be configured to light up the status and activity LED 343 by transmitting signals through one or more GPIO channels.

The user interface unit 340 also includes an LCD display 345 and an integrated touch screen 347. The processor 310 may output video data (such as predefined commands stored in the memory devices 311, 314, 315, 316 or information received via the connection module 350) to a LCD display 345 via a display interface. The processor 310 also receives any input received by the touch screen 347 through the touch screen interface. Various embodiments may also facilitate the use of the system in low light conditions by providing a backlight driver 349 (which is used to control the backlight of the LCD display 345), start and stop buttons 341, or other components. The processor can transmit an indication of the intensity of the desired backlight to a backlight driver via a pulse width modulation channel 349.

The processor 310 is capable of communicating with a remote device via the connection module 350. As shown in the figure, the connection module 350 provides three communication channels. It should be understood that fewer or additional communication channels may be supported. As a first channel, the connection module includes an Ethernet PHY chip 351 that implements wired network communication via an Ethernet connector 353 (such as an RJ-45 connection). The processor 310 may transfer data to and from the Ethernet PHY chip through a media independent interface (MII). To provide a second network channel, the connection module 350 includes a WiFi module 355, which includes an antenna and a WiFi PHY chip. The processor 310 can transfer data to and from the WiFi module 355 via an SDIO bus. The third channel provided by the connection module 350 is a land communication line POTS connection. Thus, the connection module 350 includes a voice direct access configuration (DAA) chipset 357 that communicates with a telephone line via an RJ-11 connector 359. The processor 310 can communicate with the voice DAA chipset 357 via an SPI bus and a McASP.

To achieve drug release, the processor 310 communicates with a drug device dispensing circuit 360. Specifically, the processor 310 may communicate with one or more solenoid valve interfaces 362, 364 or other interfaces for implementing the distribution of a drug. In various embodiments, the processor 310 communicates with each of the solenoid valve interfaces 362, 364 via a general-purpose IO channel.

In some embodiments, various electronic circuits may include self-diagnostic or feedback capabilities. For example, self-diagnostics or feedback methods can be used to monitor the status of solenoid valve loops, monitor battery degradation, or monitor other key functions. I will understand the methods used to implement these capabilities.

It should be appreciated that some devices that may be used in the exemplary system 300 may be omitted. For example, when implementing the system, a telephone line translator can be positioned between the voice DAA chipset 357 and the RJ-11 connector or an electromagnetic switch can be provided between the Ethernet PHY chip 351 and the Ethernet connector 353 between. In addition, additional communication lines can be provided between the various chips. For example, in addition to transmitting the display data to the LCD display 345, the processor 310 may also transmit various signals (such as an enable or read / write signal) to the LCD display 345. I will understand already Various additional implementation details are omitted.

As mentioned herein, drugs can be dispensed with or without encapsulation. In some embodiments, the retention and release of the drug may be facilitated by a separate envelope, case, or other device that holds or holds the drug and provides other structural features that engage the drug lock or other holding structure of the storage case. FIG. 4 illustrates an exemplary envelope 400 for containing a medicament. The envelope 400 may be made of virtually any material; in some embodiments, the envelope 400 is made of acrylonitrile-butadiene-styrene (ABS) plastic or strong enough to withstand or absorb the descent force to be contained within the envelope 400 Any drug remains intact as other materials are formed. The envelope includes a hollow envelope body 410, at least one opening 420 near at least one end, and a track 430 extending from an upper surface of the body 410. The opening is sized to receive a box of medicine. For example, a standard commercial packaging box containing one of the two epinephrine injection needles may be inserted through the opening 420 and received within the body 410. The track 430 is provided to engage a medication lock or other retaining structure of the storage case, and an example of the storage case will be described below with respect to FIG. 5.

It should be understood that the envelope 400 is an example and various alternative structures may be used. For example, the envelope may not include an opening 420, but instead may include a hinged joint between two parts of the body so that the envelope can be opened. As another example, the track 430 may be replaced with a circle, magnet, or other structure or material suitable for engaging a particular holding structure used. In addition, a body 410 having a different shape may be formed. For example, if an unencapsulated drug is dispensed, the body 410 may be replaced by a circular envelope or other shape that is structured to hold the drug. In some embodiments, the body 410 may be omitted, and the track 430 or other engaging structure may be directly attached to the drug or drug package or may be integrally formed with the drug or package via an adhesive, screws, or other attachment members. I will understand various additional modifications.

FIG. 5 illustrates a cross-section 500 of the exemplary drug storage case 110 of FIG. 1, which includes an exemplary actuator for selectively retaining and releasing a sleeve, viewed from a side. The cabinet 110 provides a front surface and a rear surface to form an inner region 140 between the front surface and the rear surface.

The envelope 400 containing the drug 130 is suspended within the inner region 140 by the envelope track 430. As shown in the figure, a hook 510 may be received under the track 430 such that the envelope 400 is suspended from the hook 510. One of the pivot points 512 of the hook 510 is held in place. For example, a rod, pin, or other structure may be inserted through the pivot point 512 of the hook 510, which when viewed from the perspective of FIG. 5 allows the hook to rotate clockwise or counterclockwise. The weight of the envelope 400 and the medicine 130 tends to force the hook to rotate clockwise; as can be seen in the figure, once the hook 510 rotates far enough clockwise, the rail 430 will slide off the hook 510. When the envelope 400 is no longer supported by the hook 510, the envelope 400 will fall and land on the lower flange for the user to retrieve. A spring having sufficient strength is disposed between the top portion of the hook 510 and the case 110 to offset the downward force of the envelope 400 on the hook 510. Thus, when no other external force acts on the hook 510, the hook keeps the envelope 400 hanging.

An actuator including a solenoid valve 562 and a solenoid valve controller 362 is provided to realize the release of the holding structure (such as the hook 510 and the spring 514). As described above, the solenoid valve controller 362 receives an access signal from the processor and responsively sends a current through the solenoid valve 562 to move the solenoid valve cylinder forward (from the perspective of FIG. 5 to the right) A third force is applied to the hook 510. The force of the solenoid valve 562 and the downward force of the envelope 400 and the medicine 130 are high enough to offset the force of the spring 514 and thereby cause the hook 510 to rotate and release the envelope 400.

It should be understood that the configuration of FIG. 5 is only one example of a holding structure and an actuator for dispensing a drug and many additional configurations are possible. For example, the envelope 400 may be directly suspended from a solenoid valve cylinder that is moved away from the envelope 400 after being activated by the solenoid valve controller 362. In this embodiment, the components of the solenoid valve 562 can serve as both a holding structure and an actuator. Similarly, in some embodiments, the solenoid valve cylinder may be in contact with or formed with another non-pivoting structure that is linearly moved to disengage the envelope 400. As another alternative, instead of suspending the envelope 400 or the medicine 130, the envelope 400 or the medicine 130 may be separately placed on a movable platform. Once activated, the platform can be retracted or pivoted such that The envelope 400 or drug 130 is no longer supported and drops to the lower flange 142.

It should also be understood that various configurations may use actuators instead of solenoid valves. For example, a servo motor or stepper motor can be used to control the angular position of the hook 510 or a platform or can be used to linearly retract via one or more link structures (e.g., by winding a cable attached to the structure) Back to another holding structure. As another example, when the holding structure is an electromagnet, the actuator may be a controller that is adapted to cut off power to the magnet, thereby releasing the envelope 400 or the drug 130. I will understand various other types of actuators.

Further various other holding structures and actuator configurations can be utilized that deliver the drug without lowering it to a user-accessible area. For example, a drug 130 may be locked to the storage tank by a ring or clamp that is positioned around the drug 130 and can be opened by a suitable actuator. As another example, the medicine 130 may be stored behind a locked door (such as a second door behind the first door 120), and the control member (such as the start button 111) may not be placed behind the first door In one embodiment, it is stored behind the first door 120 or in a locked drawer. In these embodiments, the actuator may be used to unlock the door or drawer to allow a user to open the door or drawer and get the medication. Therefore, in some embodiments, the actuator realizes the active release of the drug 130, so that the user can directly extract the drug 130 after release, while in other embodiments, the actuator achieves the passive release of the drug 130, so that the user The holding structure can be moved manually to obtain the medicine 130.

FIG. 6 illustrates an exemplary method 600 for contacting emergency services via a medication storage tank. The method 600 may be executed by one of the processors of the storage box 100, such as the processor 212 or the processor 310, and may be encoded as program instructions for execution by this processor.

The method 600 begins at step 610 and proceeds to step 620, where the processor receives an indication that the start button has been pressed. This button press can be detected via a physical start button (such as button 111) or via a soft start button (such as a button that can be displayed on a touch screen display (such as display 113)). In various embodiments, step 620 consists of The processor receives and identifies an event component at an event handler.

Next, in step 630, the processor initiates a landline call to an emergency dispatch. For example, when the storage bin is located in the United States, the processor may be configured to call 911 emergency services by phone. During or after connection 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 transmit a call from an instruction in a medicine storage box, an instruction that has not established a voice session with the local user, or a location of a storage box that may be pre-programmed or determined via GPS or other means. I will understand the various additional or alternative information to be transmitted to emergency dispatch. Information may be transmitted in any form, such as, for example, computer-displayed voice audio, facsimile data, or data that is otherwise encoded based on an analog telephone signal.

Next, in step 650, the processor turns on to a control center instead of emergency dispatching a Voice over IP (VOIP) call. For example, the control center may be operated by the same entity that provides, maintains, or otherwise is associated with a storage box or a medicine contained within the storage box. In addition, the storage box can transmit various predefined information, such as the location of the storage box or an identifier. Next, in step 660, the processor causes the audio data to be exchanged between the audio codec and the VOIP channel, so that the local user can talk with the operator of the control center. As will be described below, the control center operator can transfer the call to a physician, after which the local user can talk to 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 whether the VOIP call has been turned off from the other end. If the stop button is not pressed or the VOIP call is not closed from the other end, the method 600 loops back to step 660 to continue exchanging audio data with the far site. Otherwise, the processor proceeds to close the VOIP channel in step 680 and the method ends in step 690.

It should be understood that method 600 is an example of the operation of a drug storage tank according to one of the systems and methods described herein, and various alternative methods may be used. For example, step 670 may be completed through an event handler and an event that a call will be closed is detected. In some embodiments, emergency dispatch may not be called over the phone, while in other embodiments, when emergency dispatch is equipped beyond When controlling the distribution of medicines or transferring calls to one of the physicians or other entities equipped, they can call 911 only. In other embodiments, various steps of the method are performed in parallel. For example, step 620 may be divided into two threads: a first thread having one of steps 630 and 640 and a second thread having one of steps 650 to 680. In these embodiments, two telephone calls can be made simultaneously. I will understand various other modifications.

FIG. 7 illustrates an exemplary method 700 for allowing a medication to be obtained in response to a remote command. The method 700 may be executed by one of the processors of the storage box 100, such as the processor 212 or the processor 310, and may be encoded as program instructions for execution by this processor.

The method starts at step 710 and proceeds to step 720, where the processor receives an unlock signal serving as one of the allocation instructions. For example, the processor may receive a packet containing an instruction to dispense a medication. In step 730, the processor determines the indication of the medication to be dispensed from the instruction. In particular, in embodiments where the storage tank is capable of dispensing multiple different drugs and doses, the available drugs may be labeled. For example, an adult epinephrine syringe set may be labeled as "0" and a child epinephrine syringe set may be labeled as "1." The instruction received in step 720 may directly specify the label of the appropriate drug or may specify only the drug to be dispensed, in which case the processor determines the label of the identified drug through, for example, a lookup table. In embodiments where only a single type of drug can be dispensed, step 730 can be omitted.

In step 740, the processor sends an access signal to an actuator associated with the appropriate medication. In addition, this step may include associating a label or medication with the actuator through, for example, a lookup table. Upon receiving the access signal, the actuator releases the drug for extraction by a user. In various alternative embodiments, a single actuator may control the release of multiple drugs; in these embodiments, the processor may send only the label or other identification of the desired drug to the actuator, which in turn determines Take appropriate action to dispense the requested medication.

After the medication is dispensed, the processor determines the stored video instructions for the medication or receives such instructions via a network interface. In step 750, the processor outputs via the display device Instructions to use video to enhance any physician or other remote operator's instructions. The method 700 then proceeds to end in step 760.

FIG. 8 illustrates an exemplary network environment 800 of a medicine storage box. As explained in detail above, the operation of the storage box 100 may be at least partially controlled by a remote device, such as a control center device 820 or a physician device 830, via the Internet 810 or other networks. The control center device 820 or the physician device 830 may be virtually any user device, such as a terminal, personal computer, tablet computer, mobile phone, or other device.

As explained herein, once the storage box 100 is activated by a user, the storage box 100 opens to a VOIP call at a remote site, such as a control center 820 or an emergency dispatch (not shown). The control center 820 may transfer the VOIP call to an on-site or standby physician immediately or at some time during the call. In some embodiments, the control center 820 may only act as an electronic dispatcher that automatically forwards calls to one of the available physician devices 830. In these embodiments, the control center 820 may be controlled in a cloud computing environment.

In addition to facilitating audio VOIP calls, the control center 820 or physician device 830 can also provide remote operators with the ability to remotely release one or more drugs in the storage box 100. For example, the physician device 830 may run a mobile application that causes audio data to be transmitted between the physician and the storage box and presents the following two buttons to the physician: a button that dispenses an adult formula adrenaline syringe and a child formula adrenal One of the syringe buttons. These buttons may cause the physician device to generate a release signal, such as a distribution instruction packet, and transmit the release signal to the storage box 100 via the control center 820 or directly through the Internet 810 (bypassing the control center 820). Similar functions may be provided at the control center 820.

I will understand various modifications and additional features. For example, the control center 820 or the physician device 830 may be further configured to support one-way or two-way video feed with one of the storage boxes 100. As another alternative, the control center 820 or the physician device 830 may enable a remote operator to select or transmit text or graphics displayed on one of the display devices of the storage box 100. In addition, the control center 820 or physician device 830 may interact with other devices (not shown) such as a patient record (Repository) interface to enable remote operators to obtain a medical history of one of the patients.

In some embodiments, a management system may also communicate with the storage box 100 via the Internet 810 or other networks. For example, a separate server, personal computer, tablet, laptop, cloud virtual machine, or control center 820 itself can communicate with the storage box to perform functions such as inventory management, call recording and depositing, and other management functions.

FIG. 9 illustrates an exemplary hardware diagram 900 of a physician device or control center device. In various embodiments, the exemplary hardware diagram 900 may also describe at least a portion of a storage case. As shown in the figure, the hardware 900 includes a processor 920, a memory 930, a user interface 940, a network interface 950, and a memory 960 interconnected via one or more system buses 910. It should be understood that, in some aspects, FIG. 9 constitutes an abstract concept and the actual organization of the components of the hardware 900 may be more complicated than what is depicted.

The processor 920 may be any hardware device capable of executing instructions stored in the memory 930 or the storage 960 or otherwise processing data. Therefore, the processor 920 may include a microprocessor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other similar devices.

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

The user interface 940 may include one or more devices for enabling communication with a user, such as a manager. For example, the user interface 940 may include a display for receiving user commands, a mouse, and a keyboard. In some embodiments, the user interface 940 may include a command line interface or a graphical user interface that can be presented to a 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 protocol configured to communicate in accordance with an Ethernet protocol. A network interface card (NIC). In addition, the network interface 950 may implement a TCP / IP stack to communicate according to the TCP / IP protocol. I will understand the various alternative or additional hardware or configurations of the web interface 950.

The memory 960 may include one or more machine-readable storage media, such as read-only memory (ROM), random access memory (RAM), disk storage media, optical storage media, flash memory devices, or similar storage media. In various embodiments, the memory 960 may store instructions executed by the processor 920 or data operable by the processor 920. For example, the storage 960 may store a basic operating system (OS) 961, such as Linux, MICROSOFT WINDOWS OS, APPLE OS X, APPLE iOS, or GOOGLE ANDROID OS. The storage 960 also includes instructions for defining an application 962 that communicates with one or more storage bins. The storage 960 may store a VOIP instruction 963 for communicating audio or video data with the storage box and a release instruction 964 for instructing the storage box to release a medicine under the command of a user of the hardware 900 as a storage box application 962 section.

It should be understood that various information described as stored in the memory 960 may be additionally or alternatively stored in the memory 930. For example, the operating system 961 and the closet application 962 may be at least partially copied to the memory 930 for execution by the processor 920. In this aspect, the memory 930 may also be considered to constitute a “storage device” and the memory 960 may be considered to be a “memory”. I will understand various other configurations. In addition, 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 exclude temporary signals, but includes all forms of storage, including both volatile and non-volatile memory.

Although the hardware 900 is shown as including one of each of the described components, the various components may be repeated in various embodiments. For example, the processor 920 may include multiple microprocessors that are configured to independently perform the methods described herein or are configured to perform the steps or subroutines of the methods described herein such that the multiple processors Collaborate to achieve the functions described in this article.

After the exemplary hardware and functions of a physician device have been described, the exemplary user interface and associated functions of the physician device will now be described with respect to FIGS. 10 to 20. It should be understood that various interfaces may be generated by the storage box application 962 and displayed via the user interface 940. I will understand the various modifications.

FIG. 10 illustrates an exemplary user interface 1000 for identifying a physician user. As shown in the figure, the interface includes fields 1010 and 1020 for receiving a username and password, respectively. Once one of the fields 1010, 1020 is selected, the user may be provided with an interface for entering a text value, such as, for example, a soft keyboard interface provided by the operating system. The interface also includes a login button 1030 to confirm the input of a username and password. Once the login button 1030 is selected, it can be verified by comparing the entered credentials with locally stored credentials or by transmitting the entered credentials to another server (such as, for example, a control center device) for authentication These entered credentials. Once receiving an instruction or determining that the user is authenticated, the application may proceed to a home screen.

FIG. 11 illustrates an exemplary user interface 1100 for presenting a home screen. The home screen interface 1100 may present a navigation bar, which includes a home screen button 1110 (shown as selected) for accessing a home screen, a call log button 1120 for accessing a call log, and Take a setting button 1130 from one of the setting menus. When on the home screen interface 1100 (and possibly when on other interfaces after login), the application can receive incoming calls. Specifically, the control center or medication storage box may transmit the request to the physician device to establish a communication session.

FIG. 12 illustrates an exemplary user interface 1200 for displaying an instruction for an incoming communication request. The incoming request interface 1200 may be displayed in response to the physician device receiving an incoming request from, for example, a control center device or a medication storage box to establish a communication session. The incoming request interface 1200 includes an indication 1210 of one of the medication storage bins associated with the incoming request. The following two buttons are also presented to the user: one answer button 1220 for approving an incoming request and one reject button 1230 for one rejecting an incoming request. Once the reject button 1230 is selected, then The application can return to the home screen or to another screen that was previously displayed before receiving an incoming request. Once the answer button 1220 is selected, the application can display an active communication session screen.

FIG. 13 illustrates an exemplary user interface 1300 for displaying during a communication session. When the current conversation interface 1300 is displayed, the application can also provide at least one audio communication session through the device hardware. In other words, the user can communicate with the calling medicine storage box via the speaker and the microphone of the physician's device via a VOIP session. The active conversation interface 1300 includes a menu 1310 including a plurality of buttons. As will be explained in more detail below, the menu 1310 may include buttons for switching a video stream, muting the microphone, pausing a call, accessing a text message interface, and accessing a distribution interface. In addition, the active session interface 1300 includes an end call button 1320, which is used to end an active session and return to the main screen or to another screen previously displayed before receiving an incoming request.

FIG. 14 illustrates an exemplary user interface 1400 for displaying patient videos and transmitting text messages. As shown in the figure, the video button on menu 1310 has been selected and therefore a video stream 1410 is displayed. The video stream 1410 can be received from a connected medicine storage box or from a control center device. For example, once the video button is pressed, the application can begin to visualize the video data that has been transmitted by the connected storage box or can send a command to the storage box to begin transmitting this video data. As further illustrated in the figure, the pause button of menu 1310 has also been shown to be selected to indicate that communication has been suspended and will not receive or transmit communications until the suspension is cancelled.

Menu 1310 further shows that the text message button has been selected to cause the text message interface elements 1420, 1430 to be displayed. As shown in the figure, the interface 1400 includes a text area 1420 for receiving an input text message. Once the text area 1420 is selected, the user can be presented with an interface element that will be used to enter text, such as, for example, an OS soft keyboard. The interface 1400 also includes a send button 1430. Once the send button 1430 is selected, the application can send a text message to the call box, and once the call box receives the text message Information, the message can be displayed to the patient via, for example, an LCD screen.

FIG. 15 illustrates an alternative user interface 1500 for displaying patient video. For example, when the video feed is activated and the physician rotates the phone 90 degrees, the alternative user interface 1500 may be displayed. The application can access the operating system to determine the current orientation of one of the physician's devices, and if the device remains approximately horizontal, then switch to the alternate interface 1500. As shown in the figure, the alternative interface presents the video stream in full screen 1510. It should be understood that various alternative configurations are possible. For example, a menu similar to the menu 1310 may be displayed on the video area 1510. When the physician device is rotated in the reverse direction to a substantially vertical orientation, the application may transition back to a previous interface, such as interface 1400.

FIG. 16 illustrates an exemplary user interface 1600 for displaying a dispensing button for dispensing a medication to a patient. As shown in the figure, menu 1310 indicates that the assign button has been selected. Accordingly, a plurality of distribution interface elements 1610, 1620, 1630 are displayed as part of the interface 1600. Interface 1600 includes two dispensing buttons 1610, 1620 associated with medications that can be dispensed from a connected medication storage tank. It should be understood that in various embodiments, fewer or additional buttons may be included. In some embodiments, the connected storage box may transmit information to the physician device to identify available medications and other information such as expiration dates. Then, the interface 1600 can display the corresponding buttons 1610 and 1620. Although not shown in the figures, in some alternative embodiments, the interface 1600 may additionally include a field for receiving a physician signature. For example, some countries may have a requirement that any prescription requires a physician's signature. Once the signature is entered or the assign button is pressed, the physician device may store an image, text or other representation of the signature or transmit an image, text or other representation of the signature to the control center.

As shown in the figure, interface 1600 identifies two drugs that can be dispensed from a connected storage tank. The first button 1610 indicates: "Jr. Epipen" medicine with an expiration date of December 20, 2015 is available. The second button 1620 indicates that "Sr. Pipen" medicine with an expiration date of February 15, 2015 can be obtained. Once the button 1610 or 1620 is selected, the physician device transmits an instruction to the connected storage box to dispense the associated medication. For example, all In addition to the available medicines, the connected storage box can also transmit the identification or other identifier of each medicine. Then, once a button is selected, the application can transmit an instruction containing an identifier associated with the selected drug. The interface 1600 also includes a cancel button 1630 for returning to a previous interface that does not include a distribution element 1610, 1620, 1630.

FIG. 17 illustrates an alternative user interface 1700 for displaying one of the dispensing buttons for dispensing medication to a patient. In some embodiments, when the associated medication is not available, a button 1720 may be displayed as non-selectable. As shown in the figure, the connected storage box cannot dispense an "Sr Epipen" medication, so the button 1720 is displayed as unselectable. For example, when a drug is expected to be available from an application but is not reported as being available from a connected storage box or when the storage box explicitly reports that the drug is not available, the application may determine that the drug is not available. In various alternative embodiments, the interface 1700 may be substituted with just displaying any buttons for unavailable medications.

FIG. 18 illustrates an exemplary user interface 1800 for displaying a record of a previous communication session. The call history interface 1800 can be accessed by selecting the call history button 1120 on the navigation menu. As shown in the figure, the call history interface displays a number of entries 1810, 1820, 1830, 1840 that identify all previous incoming requests or alternatively all accepted incoming requests. Once a credit item 1810, 1820, 1830, 1840 is selected, the application can display an interface for displaying or entering additional information for the call.

FIG. 19 illustrates an exemplary user interface 1900 for receiving physician annotations related to a communication session. The annotation interface 1900 can be accessed by selecting a entry 1810, 1820, 1830, 1840 from the call history interface 1800. As shown in the figure, the interface 1900 includes call details 1910 and a text field 1920 for receiving a doctor's note. Once the text field 1920 is selected, the text field 1920 may provide the physician with an interface element for entering text, such as, for example, an OS soft keyboard. In addition, the interface 1900 includes a send button 1930 for transmitting the text in the text field 1920 associated with the call record to a command center device to store. Once a cancel button 1940 is selected, the cancel button 1940 causes the application to The formula returns to a previous screen, such as, for example, the call history interface 1800. Although not shown in the figures, in some alternative embodiments, the interface 1900 may additionally or alternatively include a field for receiving a physician signature. For example, some countries may have a requirement that any prescription requires a physician's signature. Once the signature is entered or the send button 1930 is pressed, the physician device may store an image, text or other representation of the signature or transmit an image, text or other representation of the signature to the control center.

FIG. 20 illustrates an exemplary method 2000 for communicating with a medication storage tank. Method 2000 may be performed by a component of a physician device, such as physician device 900. The method starts at step 2005 and proceeds to step 2010. In step 2010, the device receives an incoming request to establish a communication session. In step 2015, the device displays an indication of one of the incoming requests based on the received request, such as, for example, interface 1200. In step 2020, the device determines whether the physician user has accepted the request. If the user does not accept the request, the device transmits a rejection message to the control center or the medicine storage box in step 2025. The control center or medication storage box may then attempt to determine that a request is being transmitted to another physician device thereof and a communication session may be established. The method proceeds to end in step 2055.

However, if the physician has accepted the incoming request in step 2020, the method proceeds to step 2030, in which the device establishes a two-way communication session with the medication dispenser. Next, in step 2035, the device (such as, for example) displays one or more assigned buttons in response to a user request, as described above. Next, in step 2040, the device determines whether the physician has pressed an assign button. If the physician has not pressed the dispense button, the method jumps to step 2050. If the physician has pressed the dispense button, the device transmits an instruction to dispense the associated medication to the user in step 2045. In step 2050, the device determines whether the session has been terminated by, for example, a local user or a user of a remote medication dispenser. If the session is not terminated by the local user or the user of the remote medication dispenser, the method loops back to step 2040 to continue checking the physician selection of a dispensing button. Otherwise, the method proceeds to end in step 2055.

Various modifications to the methods described above will be apparent in view of the additional functionality of the physician device described herein. For example, method 2000 may include the following additional steps: interpreting incoming data describing available medications; muting or pausing a call; sending a text message; and displaying a video stream. I will understand various other modifications.

Based on the foregoing, various exemplary embodiments enable a physician to prescribe and provide fast access to medication at a remote location. For example, by providing a physician device application that establishes an audio or video communication session and transmits distribution instructions to a remote medication dispenser, a qualified person can properly assess an emergency and can provide what is needed or helpful for handling drug. I will appreciate various other benefits in light of the above description.

It should be understood from the above description that various exemplary embodiments of the present invention may be implemented in hardware and / or firmware. In addition, various exemplary embodiments may be implemented as instructions stored on a machine-readable storage medium, which may be 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 computer or laptop, a server, or other computing device. Therefore, a machine-readable storage medium 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 should understand that any block diagram herein represents a conceptual diagram of a schematic circuit embodying the principles of the invention. Similarly, it should be understood that any flow chart, flowchart, state transition diagram, pseudo-code, and the like representations can be substantially represented by a machine-readable medium and therefore executed by a computer or processor (whether or not the computer or process is explicitly shown Device).

Although various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects of the invention, it should be understood that the invention is applicable to other embodiments and details of which can be significantly modified in various aspects. Those skilled in the art will readily understand that changes and modifications can be implemented within the spirit and scope of the invention. Accordingly, the above disclosures, descriptions and drawings are for illustration only. This invention is shown and not limited in any way by the invention as defined solely by the scope of the patent application.

Claims (20)

A non-transitory machine-readable storage medium encoded with instructions for execution by a user device, the medium comprising: displaying an indication of an incoming request for establishment with a patient operating a medicine dispenser An instruction for a communication session; an instruction for establishing a two-way communication session with the patient via the medicine dispenser based on the approval of an incoming request by a physician user of the user device; for displaying during the two-way communication session An instruction to assign a user interface (UI) element; an instruction to receive a selection of one of the assigned user interface (UI) elements from the physician user; and a transmission based on the selection to cause the medicine dispenser to An order to distribute the drug to the patient. If the non-transitory machine-readable storage medium of claim 1, further comprising: an instruction for retrieving drug information describing a drug obtainable through the drug dispenser; and a display for displaying the user interface with the distribution ( UI) element is an instruction directed to one of the drug information. For example, the non-transitory machine-readable storage medium of claim 2, wherein the drug information includes an expiration date of one of the drugs. The non-transitory machine-readable storage medium of claim 1, further comprising: instructions for displaying a second assigned UI element during the two-way communication session; and for receiving the second assigned UI element from the physician user One of a selection instruction; and an instruction for transmitting an order for the medicine dispenser to dispense a second medicine to the patient based on the selection of the second allocation UI element. For example, the non-transitory machine-readable storage medium of claim 1, further comprising: an instruction for receiving information indicating whether the medicine is available for distribution to the patient, wherein: for displaying a distribution user interface (UI The instructions of the component include instructions for displaying the distribution user interface (UI) component as non-selectable when the drug information indicates that the drug is unavailable for distribution to the patient; The instructions receiving selection by one of the distribution user interface (UI) elements are configured to be executed based on the drug information indicating that the drug is available for distribution to the patient. The non-transitory machine-readable storage medium of claim 1, further comprising: an instruction for receiving a video data stream from the medicine dispenser via the two-way communication session; and for using the video data stream based on Display video instructions to the physician user. If the non-transitory machine-readable storage medium of claim 1, further comprising: an instruction for receiving a message entry from the physician user; and a transmission for causing the medicine dispenser to display the input to the patient Command of one of the messages. A method performed by a user device, the method comprising: establishing a two-way communication session between a physician user and a patient of the user device via a remote medicine dispenser; during the two-way communication session Receive information describing a drug associated with the drug dispenser; display during the two-way communication session indicating that one of the drugs is assigned a user interface (UI) element for the physician user to select; during the two-way communication session based on The selection of the distribution user interface (UI) element transmits a command that causes the remote medicine dispenser to dispense the medicine to the patient. If the method of claim 8, wherein the received drug information includes an expiration date, the method further includes: displaying the expiration date associated with the assigned user interface (UI) element. The method of claim 8, wherein the received information additionally describes a second medicine associated with the medicine dispenser, the method further comprising: displaying a first medicine representing the second medicine associated with the medicine dispenser Two distribution UI elements; and transmitting a command to cause the remote medicine dispenser to dispense the second medicine to the patient based on the selection of the second allocation UI element. If the method of item 8, wherein the received information indicates whether the medicine is available for distribution from the remote medicine dispenser, the method further comprises: displaying the medicine based on the received information indicating that the medicine is unavailable for distribution An indication that it is unavailable for distribution; and based on the received information indicating that the medicine is unavailable for distribution and disallowing selection of the distribution user interface (UI) element. The method of claim 8, further comprising: receiving a video data stream from the remote medicine dispenser; and displaying the video to the physician user based on the video data stream. The method of claim 8, further comprising: receiving a message entry from the physician user; and transmitting a command that causes the remote medicine dispenser to display the input message to the patient. A portable communication device is used by a physician user. The portable communication device includes: a communication interface; a display device; a touch input device; a memory; and a processor, which is connected with the memory. Communication, wherein the processor is configured to: display an indication of an incoming request via the display device to establish a communication session with a patient operating a medicine dispenser; based on use by a physician of the user device The author approves the incoming request and establishes a two-way communication session with the patient via the communication interface and the drug dispenser; displays a distribution user interface (UI) element via the display device during the two-way communication session; Receiving a selection of the distribution user interface (UI) element from the physician user by touching the input device; and transmitting through the communication interface based on the selection to cause the medicine dispenser to dispense a medicine to one of the patients command. For example, the portable communication device of claim 14, wherein the processor is further configured to: retrieve drug data describing the medicines obtainable through the medicine dispenser; and display and communicate with the assigned user through the display device. An indication of the drug information associated with an interface (UI) component. For example, the portable communication device of claim 15, wherein the drug information includes an expiration date of one of the drugs. The portable communication device of claim 14, wherein the processor is further configured to: display a second assigned UI element via the display device during the two-way communication session; and from the physician via the touch input device. The user receives a selection of the second distribution UI element; and transmits, via the communication interface and based on the selection of the second distribution UI element, a command that causes the medicine dispenser to distribute a second medicine to the patient. The portable communication device as claimed in claim 14, wherein the processor is further configured to: receive information indicating whether the medicine is available for distribution to the patient, wherein: a distribution user interface (UI) element is displayed The processor is configured to display the distribution user interface (UI) element as non-selectable when the drug information indicates that the drug is not available for distribution to the patient, and the processor is configured to be based on the The drug information indicates that the drug is available for distribution to the patient and accepts the selection of the user interface (UI) component of the distribution from the physician user. The portable communication device of claim 14, wherein the processor is further configured to: receive a video data stream from the medicine dispenser via the two-way communication session; and via the display based on the video data stream The device displays a video to the physician user. The portable communication device of claim 14, wherein the processor is further configured to: receive a message entry from the physician user; and transmit the medicine dispenser to display one of the input messages to the patient command.