JP2020205069A - Non-temporary machine-readable storage medium, method, and portable communication device for storing medicine - Google Patents

Abstract

To provide a system and a method for storing, dispensing, and managing medicine suitable for patients.SOLUTION: In a method 2000, a device receives an incoming request to establish a communication session 2010, and displays an expression of the incoming request based on the received request 2015. The device determines whether a doctor user has accepted the request 2020. If not, the device transmits a denial message to a control center or a medicine storage case 2025. When the doctor accepts the incoming request 2020Y, the device establishes a bidirectional communication session with a medicine distributor 2030. When the doctor presses a distribution button 2040Y, the device transmits a command to distribute a related medicine to a user 2045.SELECTED DRAWING: Figure 20

Description

Cross-reference to related applications This application claims the priority of US Patent Application No. 14 / 575,477 filed on December 18, 2014. This is a partial continuation of US Patent Application No. 14 / 282,884, which was filed on May 20, 2014 and is now patented as US Pat. No. 8,922,367. This is a partial continuation of PCT Application No. PCT / US2013 / 072878 filed on December 3, 2013. This claims the priority of US Provisional Patent Application No. 61 / 732,753 filed on December 3, 2012. All of these disclosures are incorporated herein for all purposes.

The various typical embodiments disclosed herein generally relate to storage, distribution, and administration of the drug.

Some patients suffer from medical conditions that can cause emergencies where prompt administration of the drug is paramount. For example, exposure of a person with severe allergies to an inducer can cause anaphylaxis. Due to the rapid onset and associated mortality depending on the severity of allergies, it is important to administer treatments such as epinephrine as soon as possible. Patients with known allergies are generally prescribed an epinephrine self-injection device to treat sudden anaphylaxis. Patients plan to carry this self-injector with them at all times to ensure that it is available in an emergency. Similarly, patients with other medical conditions that may cause emergencies requiring immediate treatment may be prescribed appropriate medications or devices that they carry.

A brief overview of various typical embodiments is presented in light of the current need for various crisis management programs in the administration of epinephrine and other drugs and devices. In the following overview, some simplifications and omissions may be made, which are intended to highlight and introduce some aspects of various typical embodiments, but within the scope of the invention. Not intended to be limited. A detailed description of preferred exemplary embodiments suitable to enable those skilled in the art to form and use the concepts of the invention follows in subsequent sections.

Various embodiments are associated with a non-temporary machine-readable storage medium encoded by an instruction intended to be executed by a user device to establish a communication session with a patient operating a drug distributor. , A command to display the representation of the incoming request, and a command to establish a two-way communication session with the patient via the drug distributor based on the approval of the incoming request by the physician user of the user device. An instruction to display a distribution user interface (UI) element during a two-way communication session, an instruction to receive a selection of the distribution UI element from the physician user, and distribution of the drug to the patient based on the selection. It is a non-temporary machine-readable storage medium including a command to send a command to the drug distributor.

Various embodiments relate to methods performed by a user device, establishing a two-way communication session between a physician user and a patient of the user device via a remote drug distributor. Receiving information describing the drug associated with the drug distributor, displaying a distribution user interface (UI) element representing the drug for the purpose of selection by the physician user, and displaying the drug to the patient. A method that includes sending a command to cause distribution to the remote drug distributor based on the selection of the distribution UI element.

Various embodiments relate to portable communication devices intended for use by a doctor user, wherein the portable communication device communicates with a communication interface, a display device, a touch input device, a memory, and the memory. The processor displays an incoming request display through the display device in order to establish a communication session with the patient operating the drug distributor, and the doctor user of the user device said. Establishing a two-way communication session with the patient through the communication interface and the drug distributor based on approving the incoming request, and distributing users through the display device during the two-way communication session. Displaying an interface (UI) element, receiving a selection of the distribution UI element from the maintenance user via the touch input device, and causing the drug distributor to distribute the drug to the patient. The command is configured to be transmitted via the communication interface and based on the selection.

Various embodiments are described in the non-temporary machine-readable storage medium of claim 1 with instructions for obtaining drug data describing available drugs via a drug distributor and a distribution UI. A non-temporary machine-readable storage medium containing instructions for displaying representations of drug data associated with an element.

Various embodiments are described in which the drug data includes the expiration date of the drug.

Various embodiments are additionally based on a command to display a second distribution UI element during a two-way communication session, a command to receive a selection of a second distribution UI from a physician user, and a selection of a second distribution UI element. It includes a command to send a command to the drug distributor to distribute the second drug to the patient.

Various embodiments additionally include an instruction to receive drug information indicating whether a drug is available for distribution to the patient, wherein the instruction to display the distribution user interface (UI) element. , Including an instruction to display the distribution UI element as unselectable when the drug information indicates that the drug is not available for distribution to the patient, and the selection of the distribution UI element from the doctor user. The order to receive the drug is configured to be executed based on the drug information indicating that the drug is available for distribution to the patient.

Various embodiments additionally have an instruction to receive a stream of video data from the drug distributor via a two-way communication session and an instruction to display the video to a physician user based on the stream of video data. And include.

Various embodiments additionally include a command to receive an input of a message from a physician user and an instruction to send a command to cause the drug distributor to display the input message to the patient.

Refer to the accompanying drawings for a good understanding of the various typical embodiments.

A typical drug storage case is shown. A block diagram of typical components of a drug storage case is shown. A typical schematic diagram of a typical component of a drug storage case is shown. Shown is a typical sleeve containing a drug. A cross section of a typical drug storage case including a typical actuator that selectively holds and releases the sleeve is shown. A typical method of contacting emergency services via a drug storage case is shown. A typical method of allowing access to a drug in response to a remote command is shown. Shown is a typical network environment for drug storage cases. A typical hardware diagram for a physician device or control center device is shown. A typical user interface for authenticating a physician user is shown. Shows a typical user interface that presents a home screen. Shows a typical user interface that displays a representation of an incoming communication request. Shows a typical user interface for display during a communication session. Shows a typical user interface that displays a patient's video and sends a test message. Demonstrate an alternative user interface for displaying patient videos. Shown is a typical user interface displaying a distribution button for distributing a drug to a patient. Demonstrates an alternative user interface that displays a distribution button for distributing the drug to the patient. Shows a typical user interface that displays a log of previous communication sessions. Demonstrates a typical user interface for receiving doctor's notes about a communication session. A typical method for communicating with a drug storage case is shown.

Emergency planning of giving patients medication to carry with them at all times is often effective, but not a complete solution. There are many situations in which a patient may not have access to appropriate medications to cope with an emergency. For example, if the patient's condition remains undiagnosed, there was no opportunity to prescribe an urgent drug or device in advance. As another example, if the patient is a pediatrician or requires supervision or guidance in the use of a drug or device, the patient may not actually carry the prescription and therefore the prescription will not be available. In addition, there may be no suitable supervisor. Other than these special circumstances, the patient may simply have forgotten the prescription or do not currently have the drug or device prescribed in an emergency. At least for these reasons, there is a need for alternative or supplemental solutions that provide properly prescribed drugs or devices in an emergency event.

As described in more detail below, various embodiments are stored until instructions are received from a remote operator, such as a doctor on duty, to release the drug for use by a local patient or other user. Includes drug storage cases that restrict access to the drug. The storage case should further facilitate two-way communication with the remote operator so that the remote operator can reasonably determine whether and when it is appropriate to distribute the drug from the storage case. Can be done. This communication allows the remote operator to obtain sufficient patient and situation information to determine whether the drug should be distributed.

The descriptions and drawings presented herein exemplify various principles. As will be appreciated, one of ordinary skill in the art can embody these principles and come up with various configurations within the scope of this disclosure, although not expressly described or illustrated herein. .. As used herein, the terms "or", "or" used herein are non-exclusive "or" unless otherwise indicated (eg, "otherwise" or "selectively or"). "(Ie," or "). In addition, the various embodiments described herein are not necessarily mutually exclusive and can be combined to generate additional embodiments that incorporate the principles described herein. Obviously, the methods and devices described herein may be used to distribute drugs, medical devices, and combinations thereof. Therefore, the term "drug" as used herein is understood to include both drugs and medical devices. Furthermore, it can be seen that the various devices described herein may be used to provide controlled access to substances, devices, and other items outside the medical field.

With reference to the drawings here, the same numbers refer to the same component or step, and broad aspects of various typical embodiments are disclosed.

FIG. 1 shows a typical drug storage case 100. Various embodiments of the drug storage cases disclosed herein, including the typical case 100, may also be referred to as medical management systems. As shown, the storage case 100 includes a case body 110 and doors 120 attached by hinges 122a, 122b. The case body 110 includes an internal area 140 accessible through an opening on the front surface of the 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 sufficient fixing hardware to accomplish such installation. For example, the back surface of the case body 110 may include a recess that receives the bolt head of a bolt screwed into the wall. As another example, the fixing hardware may include a separate mounting structure that is screwed to the wall. The back surface of the case 100 is attached to the structure by hooks, clips, or other methods. Various other types of fixing hardware for fixing the storage case 100 to the structure are apparent. In various embodiments, the back surface, bottom surface, or other surface of the body may include connectors such as power, network, and telephone connectors.

The bottom of the case body forms the lower ledge 142, and the dispensed drug 130 is placed on the lower ledge 142 before it is removed by the user. Prior to distribution, the drug 130 is retained in another area of the internal area 140, which is inaccessible or inaccessible to local users. For example, the agent 130 may be retained in a portion of an internal area 140 above the opening and lower ledge 142 and hidden behind the front of the storage case 110. In various embodiments, the storage case 100 is configured to store and distribute a large number of agents that differ from each other. For example, in some embodiments, the storage case can dispense both adult and pediatric formulations of epinephrine self-injectors that can be encapsulated in various packaging such as product boxes.

To hold the drug prior to distribution, the storage case 100 may include a drug lock (not shown) or other lockable holding structure such as a door (not shown). Alternatively, the illustrated door 120 may be lockable in the closed position. Various typical drug locks and other retaining structures are detailed below. In spite of the particular holding structure used, in various embodiments, the holding structure is electronically moved from locked to unlocked by a processor (not shown) controlled actuator (not shown). It is movable. The processor operates according to the instructions received from the remote site and can unlock the holding structure. For example, upon receiving an unlock signal such as an internet packet containing a distribution instruction, the processor sends an access signal to the actuator, which unlocks the holding structure. Once the holding structure is in the unlocked state, the drug can be freed to be removed from the device, or the unlocked holding structure can be manually manipulated by the user (eg, open the unlocked door). The drug can be released.

The storage case 100 also includes a number of I / O 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 may initiate a two-way communication session with the remote site via a communication unit (not shown). This communication session may include voice communication via the microphone 114 and the speaker 115 so that the local user and the remote operator can talk. The Stop button 112 may be configured to end the call or to stop any processing performed by the storage case 112 when the local user presses the Go button 100.

The display 113 may also be provided for various purposes. For example, a display, along with a camera (not shown), can facilitate video feed between a remote site and a local user as part of a two-way communication session. Alternatively, the display 113 may provide the local user with various information such as drug use instructions or status updates regarding the storage case 100 or the current action being performed by the remote operator. In this way, the displayed information can be stored locally and can be 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 doctor. In some embodiments, the display 113 includes a touch screen input. In such an embodiment, the display 113 may include soft buttons in place of or in addition to the Go and Stop buttons 111, 112. The touch screen display 113 is used to give an authenticated user access to the recorded information by giving a management interface accessible through password entry, keycard swipe, or any other authentication process. Or access to an internal compartment for exchanging any drug that has been distributed or expired can also be provided.

The state of the storage case 100 can be communicated in an alternative or additional manner. For example, as shown, the storage case 100 includes a large number of state lights 116. The status light can convey system information such as power on or boot status, or process flow information such as whether a call has been made and whether a drug has been distributed. Various other uses of the state light 116 become apparent.

In various embodiments, the electronics that control the operation of the storage case may always be powered via batteries, power supplies, or other power sources. Other embodiments may implement power saving features that reduce energy consumption. For example, the electronics in the storage case 100 may be turned off or put into a "sleep" mode during periods of non-use. Upon activation by a local user, these electronic devices are powered on or woken up to perform related functions. For example, opening the door 120, pressing the Go button, or pressing a separate "power" button can be configured to initiate powering on or waking up the electronics. Various other power saving functions will be revealed.

Once the drug distribution is complete, service personnel can reload the storage case 100 with additional drug. In some embodiments reloading can be achieved by opening the case 100, but in other embodiments service personnel may reload the case directly through the front opening product access area without opening the case. .. Various alternative methods for reloading may be utilized that do not require special service access (eg, opening the case). For example, the drug is loaded through a slot at the top of the case described below with respect to FIG.

FIG. 2 shows a typical block diagram 200 of a typical component of a drug storage case. In various embodiments, the block diagram represents the various electronic and mechanical components of the typical storage case 100 of FIG.

As shown, block diagram 200 includes an electronic subsystem 210, a mechanical subsystem 240, and a number of additional components 250-266. The electronic subsystem 210 includes a processor 212 and various supporting electronic components 214-232. Processor 212 includes substantially any device that can combine the functionality described herein, such as a microprocessor, field programmable gate array (FPGA), or application specific integrated circuit (ASIC). It's fine. In various embodiments, the processor 212 is a microprocessor of ARM architecture.

Processor 212 is provided with access to SD card interfaces 216 as well as various forms of memory / data storage devices, including onboard programs and data memory 224, 226. The program memory 224 stores software instructions for instructing the processor when performing the various methods described herein, such as the typical methods described with respect to FIGS. 6-7. For example, the program memory 224 can be used with operating systems such as the GUIx® kernel, appropriate device drivers, real-time transfer protocol (RTP) stack instructions, session start protocol (SIP) stack instructions, direct access placement (DAA) stack instructions. , And a command that gives a Qt graphical user interface (GUI) can be stored. Additionally, the program memory 224 is an event handler for responding to incoming events such as door opening / closing, watchdog reset, factory reset, firmware upgrade, manufacturing mode entry, status / report, and fault notification. You may memorize the command. The program memory 224 may also store various audio components such as advanced Linux sound architecture (ALSA) libraries, software codec instructions, and echo / noise canceling algorithms.

The data memory 226 may be used by the processor to store various data such as log data, location information, or temperature information logs relating to the use of the storage case. Various other data for storage in data memory 226 or SD or other memory cards will be apparent in light of this specification. Alternatively or additionally, the SD or other memory card 216 may be used to store boot instructions, firmware images, activity logs, predetermined information and messages, as well as other information.

The electronic subsystem 212 includes a voice interface 214, such as a voice codec, that allows a processor to receive and output voice through various voice devices such as a speaker 250, a headset 252, or a microphone 254. Similarly, the electronic subsystem 210 includes a touch screen interface 218 that outputs visual data and receives touch inputs from the touch screen device 256. For various other input / output devices such as the state LED 258 or the pushbutton 260, the electronic subsystem 210 provides a general purpose input / output (GPIO) interface 220.

Processor 212 can also access a variety of external devices. For example, to connect to other devices via the Internet or other networks, the electronic subsystem 210 communicates over various media such as Ethernet® or WiFi262, a physical network interface (PHY). including. Additionally, the electronic subsystem 210 includes a general telephone system (POTS) interface 228, allowing the establishment of telephone calls over a fixed telephone line 264. To enable system debugging and other maintenance, the electronic subsystem 210 includes an RS-232 serial interface 232 to which a device with a general purpose asynchronous receiver / transmitter (UART) is attached for data. And instructions can be exchanged with the processor.

The electronic subsystem 210 may also include an enclosure I / O interface 240 for communicating with the mechanical subsystem 230. In various embodiments, the enclosure I / O interface 230 may simply utilize the GPIO interface 220. The mechanical subsystem 240 includes two devices. Door open detection devices such as switches, buttons, proximity sensors, or motion detectors 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 activate the electronic subsystem 210. A drug lock / unlock mechanism 244, such as a solenoid interface or other actuator interface, receives an access signal from the processor 212 via the enclosure I / O interface 244. Upon receiving such a signal, the drug lock / unlock mechanism 244 distributes the drug, as detailed below.

FIG. 3 shows a typical schematic diagram 300 of a typical component of a drug storage case. In various embodiments, schematic 300 illustrates various systems of a typical storage case 100 and may illustrate a detailed embodiment of block diagram 200 of FIG.

As shown, the system is arranged around a processor 310, which may be a microprocessor, FPGA, ASIC, or any other device capable of performing the described functions as described above. Processor 310 can include some onboard memory and can additionally access other forms of memory such as SD card connector 311, EEPROM 314, DDR3 memory 315, and NAND 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 may be stored between these memory devices. Moreover, it is clear that less or additional memory devices and different types of memory devices than those shown can be used.

The processor may also utilize other devices, which do not belong to any other described subsystem. For example, in various embodiments, the system 300 can keep a log of usage based on the date and time reported by the real-time clock chip 312. In some embodiments, processor 310 can record or monitor the temperature of the drug or surrounding area, as reported by temperature sensor 313. In some embodiments, the temperature sensor 313 can be used by a processor 310 or other chip (not shown) to regulate the temperature at which the drug is exposed. For example, the storage case may be provided with a fan or other device that controls the internal temperature. In such an embodiment, the processor 310 may be configured to control the fan in response to the temperature sensor 313 reporting a temperature or time / temperature reading above some predetermined threshold. Such features can be particularly useful in embodiments where the storage case is portable or may be exposed to inconsistent climates. Further, as described above, the processor 310 can provide a debug or maintenance interface to other devices via the RS232 transceiver 317 and connector 318.

As described, in various embodiments, the system 300 is powered on or activated in response to detecting that the door has been opened. To provide such functionality, the door open detection module 322 includes one or more proximity sensors 320 for detecting that the door has been moved away from the closed position. Such information can be transmitted to the processor via one or more GPIO lines. In various alternative embodiments, the proximity sensor 322 may be replaced with another device, such as a dedicated power button or one of a plurality of Go Stop buttons 341.

The voice dialogue unit 330 communicates with the processor 330 to facilitate voice communication. That is, the voice dialogue unit 330 includes the voice codec 332, and the voice codec 332 exchanges data with the processor 310 via the multi-channel voice serial port (McASP) and the integrated circuit (12C) bus. The voice codec 332 then renders the voice data received from the processor 310 via the headset 334 and the speaker 336 and digitizes the analog voice data received via the microphone 338. As will be appreciated, the processor may simply act as a pass-through for the voice data that allows data exchange between the voice dialogue unit and the connection unit 350. In other embodiments, the voice dialogue unit 330 may be directly connected to the connection unit 350. Thereby, the data can be transferred to and from the remote location without the processor 310 processing such data. For example, the voice dialogue unit 330 can transmit and receive analog voice data via the RJ-11 connector. In some embodiments, such direct connection may be selectively enabled or disabled by processor 310.

For the purpose of additional types of local user interaction, the system 300 includes a user interface unit 340 that includes various input / output devices. For example, the user interface unit 340 may include a Go and Stop button 341 that can be used to start and interrupt the operation of the system to connect to a remote site. In this way, the Go and Stop buttons 341 can signal the processor 310 via one or more GPIO channels. Similarly, the processor can be configured to illuminate the state and activity LEDs 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 357. Processor 310 transfers visual data, such as information received via a predetermined instruction or connection module 350, stored between memory devices 311, 314, 315, 316 to the LCD display 345 via a display interface. Can be output. Processor 310 also receives any input received by the touch screen 347 via the touch screen interface. Various embodiments also facilitate the use of the system under low light conditions by providing a backlight driver 349 that controls backlight irradiation to the LCD display 345, Go Stop button 341, or other components. can do. The processor can transmit a representation of the desired backlight intensity to the backlight driver 349 via the pulse width modulation channel.

The processor 310 has the ability to communicate with a remote device via the connection module 350. As shown, the connection module 350 provides three communication channels. As you can see, fewer or additional 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. Processor 310 can transfer data to and from the Ethernet PHY chip via a media independent interface (MII). To provide a second network channel, the connection module 350 includes a WiFi module 355 including an antenna and a WiFi PHY chip. The processor 310 can transfer data to and from the WiFi module 355 via the SDIO bus. The third channel provided by the connection module 350 is a fixed telephone line POTS connection. As such, the connection module 350 includes a voice direct access arrangement (DAA) chipset 357 that communicates with the telephone line via the RJ-11 connector 359. The processor 310 can communicate with the voice DAA chipset 357 via the SPI bus and McASP.

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

In some embodiments, various electronic circuits may include self-diagnosis or feedback capabilities. For example, self-diagnosis or feedback methods can be used to monitor the condition of the solenoid loop, to monitor battery deterioration, or to monitor other key functions. It is clear how to implement such capabilities.

As you can see, some devices that can be used to implement a typical system 300 may be omitted. For example, in a system implementation, a telephone line translator may be placed between the voice DAA chipset 357 and the RJ-11 connector, or magnetism may be provided between the Ethernet PHY chip 351 and the Ethernet connector 353. Further, additional communication lines may be provided between various chips. For example, the processor 310 can additionally transmit various signals such as enable signals and read / write signals to the LCD display 345 in addition to the display data. Details of the various additional implementations that have been omitted will be revealed.

As mentioned above, the drug may be distributed with or without packaging. In some embodiments, retention and release of the drug may be facilitated by a separate sleeve, case, or other device that contains or holds the drug. These provide other structural features for engaging with drug locks or other holding structures in the storage case. FIG. 4 shows a typical sleeve 400 containing the drug. The sleeve 400 can be made of virtually any material. In some embodiments, the sleeve 400 is an acrylonitrile butadiene styrene (ABS) plastic or other that is strong enough to withstand or absorb a drop force to maintain the integrity of any drug contained within the sleeve 400. Formed from the material of. The sleeve includes a hollow sleeve body 410, at least one opening 420 near one end, and a rail 430 extending from the top surface of the body 410. The opening is sized to accept the box packaging for the drug. For example, a standard commercial box packaging containing two pens of epinephrine can be inserted through the opening 420 and received within the body 410. Rail 430 is provided to engage a drug lock or other holding structure in the storage case, an example of which is described below with reference to FIG.

Obviously, the sleeve 400 is an example and various alternative structures can be used. For example, the sleeve may not include an opening 420 and instead may include a hinged engagement between two parts of the body so that the sleeve can be opened. As another example, the rail 430 may be replaced with a circular loop, magnet, or other structure or material suitable for engaging with the particular holding structure used. Further, the main body 410 may be formed in a different shape. For example, if the drug is distributed without packaging, the body 410 may instead be a circular sleeve or other shape configured to contain the drug. In some embodiments, the body 410 may be omitted and the rail 430 or other engaging structure may be attached directly to the drug or drug packaging via glue, screws, or other mounting means. Alternatively, it may be formed integrally with the drug or packaging. Various additional modifications will be revealed.

FIG. 5 shows a cross section 500 of the typical drug storage case 110 of FIG. 1 as viewed from the side. A typical actuator for selectively holding and releasing the sleeve is included. The case body 110 has a front surface and a back surface forming an internal area 140.

The sleeve 400 containing the agent 130 is suspended by the sleeve rail 430 within the internal area 140. As shown, the hook 510 is received under the rail 430 and the sleeve 400 is suspended from the hook 510. The hook 510 is held in place at the pivot point 512. For example, inserting a rod, pin, or other structure through the hook 510 at pivot point 512 allows the hook to rotate clockwise or counterclockwise as viewed from the viewpoint of FIG. .. The weight of the sleeve 400 and the agent 130 tends to force the hook to rotate clockwise. As can be seen, the rail 430 slides off the hook 510 when the hook 510 is rotated more than enough clockwise. The sleeve 400 is no longer supported by the hook 510 and falls to land on the lower ledge and is recovered by the user. A spring of sufficient strength is placed between the top of the hook 510 and the case body 110 to counteract the downward force of the sleeve 400 on the hook 510. Therefore, the hook holds the sleeve 400 in a suspended state when no other external force acts on the hook 510.

An actuator including a solenoid 562 and a solenoid controller 362 is provided to enable the release of the 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, moves the solenoid cylinder forward (to the right from the viewpoint of FIG. 5) to the solenoid 562 and a third force on the hook 512. Send enough current to add. The force of the solenoid 562, combined with the downward force of the sleeve 400 and the agent 130, is high enough to rotate the hook 510 against the force of the spring 514 to release the sleeve 400.

Obviously, the sequence of FIG. 5 is merely an example of a holding structure and actuator for distributing the drug, and many additional configurations are possible. For example, the sleeve 400 may be suspended directly from the solenoid cylinder, and upon activation by the solenoid controller 400, the solenoid cylinder is moved to disengage from the sleeve 362. In such an embodiment, the components of the solenoid 562 can function as both a holding structure and an actuator. Similarly, in some embodiments, the solenoid cylinder may be in contact with or formed with other non-dynamic structures that are moved to linearly disengage from engagement with the sleeve 400. As another alternative, instead of suspending the sleeve 400 or the drug 130, the sleeve 400 or the drug 130 may be placed on a movable platform with it. Upon activation, the platform retracts or pivots so that the sleeve 400 or drug 130 is no longer supported and falls into the lower ledge 142.

As you can see again, various arrangements may use actuators other than solenoids. For example, a servomotor or stepper motor can be used to control the angular position of the hook 510 or platform. Alternatively, a servomotor or stepper motor can be used to linearly retract the other holding structure through one or more connecting structures (eg, by winding a cable attached to the structure). .. As another example, if the holding structure is an electromagnet, the actuator may be a controller configured to cut off power to the magnet, thereby releasing the sleeve 400 or the drug 130. Various other types of actuators are revealed.

In addition, various other holding structures and actuator arrays that do not deliver the drug by dropping the drug into the user accessible area are also available. For example, the drug 130 can be locked to the storage case by a ring or clamp that is placed around the drug 130 and can be opened by a suitable actuator. As another example, the agent 130 may be stored behind a locked door, eg behind a secondary door behind the primary door 120, and a control device such as the Go button 111 is also housed behind the primary door. In embodiments that are not, or are not housed in a locked drawer, they may be stored behind the primary door 120. The actuator in such an embodiment functions to unlock such a door or drawer, allowing the user to open the door or drawer to access the drug. That is, in some embodiments, the actuator enables the active release of the drug 130 so that the user can directly retrieve the drug 130 after release, while in other embodiments the actuator is the drug 130. By enabling passive release, the user can manually move the retaining structure to access the drug 130.

FIG. 6 shows a typical method 600 of contacting emergency services via a drug storage case. Method 600 may be executed 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 such processor.

Method 600 starts at step 610 and proceeds to step 620 where the processor receives the expression that the Go button has been pressed. Such button presses can be detected via a physical Go button such as button 111 or via a soft Go button displayed on a touch screen display such as display 113. In various embodiments, step 620 comprises receiving and recognizing an event in the event handler.

Next, in step 630, the processor initiates a landline call to the emergency dispatch. For example, if the storage case is located in the United States, the processor can be configured to call 911 Emergency Services. During or after the connection to the emergency dispatch, the processor transmits a set of predetermined information to the emergency dispatch via a landline telephone line call. For example, the processor may be pre-programmed or determined via GPS or other means, an expression that the call is from a drug storage case, an expression that a voice session has not been established with a local user. The location of the storage case can be sent. Various additional or alternative information to be sent to the emergency dispatch is revealed. The information may be transmitted in any format, such as computer-rendered voice voice, fax data, or other data encoded on an analog telephone signal.

Next, in step 650, the processor initiates a voice over IP (VOIP) call to a control center other than the emergency dispatch. For example, a control center may be operated by the same entity that provides, maintains, or associates with a storage case or the drug contained therein. Again, the storage case can also transmit various predetermined information such as the location or identifier of the storage case. Then, in step 660, the processor exchanges voice data between the voice codec and the VOIP channel so that the local user can talk to the operator in the control center. As described below, the control center operator can transfer the call to the doctor, after which the local user can talk to the doctor. At step 670, the processor determines whether or not to end the VOIP call. For example, the processor can determine whether the Stop button has been pressed or whether the VOIP call has been closed by the other party. If not, the method 600 loops back to step 660 to continue exchanging voice data with the remote site. Otherwise, the processor closes the VOIP channel at step 680 and the method ends at step 690.

As you can see, method 600 is an example of the operation of the drug storage case according to the systems and methods described herein, and various alternative methods may be used. For example, step 670 can be accomplished through event handlers and detection of events that close the call. In some embodiments, it is not necessary to make a call to the emergency dispatch, while in other embodiments, the emergency dispatch is provided to remotely control the distribution of the drug, or the call is to the doctor or it. If transferred to another entity, only the call to 911 may be made. In other embodiments, the various steps of the method are performed in parallel. For example, step 620 may be divided into two threads, a first thread having steps 630 and 640 and a second thread having steps 650-680. In such an embodiment, two calls can be made at the same time. Various other modifications become apparent.

FIG. 7 shows a typical method 700 for allowing access to a drug 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 such processor.

The method starts at step 710 and proceeds to step 720 where the processor receives an unlock signal that acts as a distribution instruction. For example, the processor may receive a packet containing an instruction to distribute the drug. In step 730, the processor determines the index of the drug to be distributed from the instruction. Specifically, the available agents can be indexed in embodiments where the storage case can distribute a large number of different agents and preparations. For example, the adult epinephrine syringe set may be an index of "0" and the pediatric epinephrine syringe set may be an index of "1". The instructions received in step 720 may directly identify the index of the appropriate drug, or may only identify the drug to be distributed. In this case, the processor determines the index of the identified drug, for example, via a look-up table. In embodiments where only a single type of agent can be distributed, step 730 may be omitted.

At step 740, the processor sends an access signal to the actuator associated with the appropriate drug. Again, this step may include correlating the index or drug to the actuator, eg, via a look-up table. Upon receiving the access signal, the actuator releases the drug for recovery by the user. In various alternative embodiments, a single actuator may control the release of multiple agents. In such an embodiment, the processor simply sends an index or other identification of the desired drug to the actuator, which in turn determines the appropriate action to deliver the requested drug.

After distributing the drug, the processor locates the video instructions stored for the drug or receives such instructions via the network interface. At step 750, the processor visually augments the instructions of the physician or other remote operator by outputting the instructions via the display device. The method 700 then ends at step 760.

FIG. 8 shows a typical network environment 800 for a drug storage case. As described in detail above, the operation of the storage case 100 is 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 network. The control center device 820 or physician device 830 may be a virtually arbitrary user device such as a terminal, personal computer, tablet, mobile phone, or other device.

As described, upon activation by the user, storage case 100 initiates a VOIP call to a remote site such as Control Center 820 or emergency dispatch (not shown). Control Center 820 can forward the VOIP call to a physician either onsite or on duty immediately or at some point during the call. In some embodiments, the control center 820 simply acts as an electronic dispatch that automatically transfers the call to the available physician device 830. In such an embodiment, the control center 820 may be a host within a cloud computing environment.

In addition to facilitating voice VoIP calls, the control center 820 or physician device 830 can also give the remote operator the ability to remotely release one or more agents in the storage case 100. For example, the doctor device 830 can execute a mobile application that communicates voice data between the doctor and the storage case and presents the doctor with two buttons. The two buttons are a button for distributing the adult formulation epinephrine syringe and a button for distributing the pediatric formulation epinephrine syringe. With such a button, the physician device can generate a release signal, such as a distribution command packet, and send it to the storage case 100 via the control center 820 or bypassing the control center 820 and directly through the internet 810. A similar function may be provided in the control center 820.

Various modifications and additional features will be revealed. For example, the control center 820 or physician device 830 can be further configured to support unidirectional or bidirectional video feeds with the storage case 100. As another alternative, the control center 820 or physician device 830 may allow the remote operator to select or transmit text or graphics to be displayed on the display device of the storage case 100. In addition, the control center 820 or physician device 830 can interface with other devices (not shown) such as patient record repositories so that remote operators can access the patient's medical history.

In some embodiments, the management system may also communicate with the storage case 10 via the Internet 810 or other network. For example, a separate server, personal computer, table, laptop, cloud virtual machine, or Control Center 820 itself communicates with the storage case to perform functions such as inventory management, call recording and logging, and other management functions. Can be done.

FIG. 9 shows a typical hardware diagram 900 for a physician device or control center device. In various embodiments, a typical hardware diagram 900 may also describe at least a portion of the storage case. As shown, hardware 200 includes processors 920, memory 930, user interface 940, network interface 950, and storage device 960 interconnected via one or more system buses 910. As is understood, FIG. 9 constitutes an abstraction in some respects, and the actual organizational structure of the components of hardware 900 can be more complex than the illustration.

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

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

The user interface 940 may include one or more devices that allow communication with users such as administrators. For example, the user interface 940 may include a display, a mouse, and a keyboard to receive user commands. In some embodiments, the user interface 240 may include a command line interface or a graphical user interface that may be presented to a remote terminal via the network interface 950.

The network interface 950 may include one or more devices that allow 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. Additionally, the network interface 950 may implement a TCP / IP stack for communication according to the TCP / IP protocol. Various alternative or additional hardware or configurations for the network interface 950 will be revealed.

The storage device 960 may include one or more machine-readable storage media such as read-only memory (ROM), random access memory (RAM), magnetic disk storage medium, optical storage medium, flash memory device, or similar storage medium. .. In various embodiments, the storage device 960 may store instructions for execution by the processor 920, or may store data that operates with the processor 920. For example, the storage device 960 may be such as Linux®, MICROSOFT® WINDOWS® OS, APPLE® OSX, APPLE iOS, or Google® ANDROID® OS. It can store the basic operating system (OS) 961. The storage device 960 also includes instructions defining an application 962 that communicates with one or more storage cases. As part of the storage case app 962, the storage device 960 instructs the storage case to release the drug by means of a VOIP instruction 963 for communicating audio or video data with the storage case and a command from the user of the hardware 900. Release command 900 and can be stored.

It is clear that various information described to be stored in storage device 960 may be additionally or alternatively stored in memory 930. For example, the operating system 961 and the wall unit application 962 may be at least partially copied to memory 920 for execution by processor 930. In this respect, the memory 930 may be considered to constitute the "storage device" and the storage device 960 may be considered to constitute the "memory". Various other sequences are revealed. Further, both the memory 930 and the storage device 960 may be regarded as "non-transitory machine-readable media". As used herein, the term "non-temporary" excludes temporary signals, but is understood to include all forms of storage, including both volatile and non-volatile memory.

Although hardware 900 is shown to include one of each described component, different components may be replicated in different embodiments. For example, processor 920 may include a large number of microprocessors. These microprocessors are configured to perform the methods described herein independently or of the methods described herein so that a large number of processors work together to achieve the functions described herein. It is configured to execute a step or subroutine.

Although typical hardware and features for a physician device have been described, typical user interfaces and related features for such a physician device are now described with reference to FIGS. 10-20. As will be appreciated, various interfaces can be generated by the storage case app 962 and displayed via the user interface 940. Various modifications will be revealed.

FIG. 10 shows a typical user interface 1000 for authenticating a physician user. As shown, this interface includes fields 1010 and 1020 that receive a username and a password, respectively. When the user selects one of the fields 1010 and 1020, he is given an interface for entering alphanumeric values, such as the soft keyboard interface provided by the operating system. The interface also includes a login button 1030 that confirms the entry of a username and password. When the login button 1030 is selected, the entered credentials can be used to authenticate by comparing the credentials with locally stored credentials, or by comparing the credentials with, for example, a control center device. It can be enabled by sending it to another server. The app may proceed to the home screen upon receiving an expression or decision that the user has been authenticated.

FIG. 11 shows a typical user interface 1100 that presents a home screen. The home screen interface 1100 includes a home button 1110 (displayed when it is already selected) for accessing the home screen, a call log button 1120 for accessing the call log, and a setting for accessing the setting menu. A navigation bar containing buttons 1130 and may be presented. On the home screen interface 1100 (and potentially on other interfaces after login), the app can receive incoming calls. Specifically, the control center or drug storage case can send a request to the physician device to establish a communication session.

FIG. 12 shows a typical user interface 1200 for displaying a representation of an incoming communication request. The incoming request interface 1200 may be displayed in response to, for example, a physician device receiving an incoming request to establish a communication session from a control center device or drug storage case. The incoming request interface 1200 includes a representation 1210 of the drug storage case associated with the incoming request. Also, the user is presented with two buttons. One is the Answer button 1220 for approving the incoming request, and the other is the Decline button 1230 for rejecting the incoming request. If you select the reject button 1230, the app may return to the home screen or to another screen that was previously displayed before receiving the incoming request. When the response button 1220 is selected, the app may display the active communication session screen.

FIG. 13 shows an exemplary user interface 1300 to display during a communication session. While the active session interface 1300 is displayed, the app may also provide at least a voice communication session via the device hardware. In other words, the user can communicate with the calling drug storage case via the speaker and microphone of the physician device via a VOIP session. The active session interface 1300 includes a menu 1310 containing a large number of buttons. As described in detail below, Menu 1310 provides a button to switch video streams, a button to mute the microphone, a button to put the call on hold, a button to access the text message interface, and a button to access the distribution interface. May include buttons. The active session interface 1300 further includes a call end (End Call) button 1320 that terminates the active session and returns to the home screen or another screen previously displayed before receiving the incoming request.

FIG. 14 shows a typical user interface 1400 that displays a patient's video and sends a test message. As shown, the moving image button on the menu 1310 is selected, and as a result, the moving image stream 1410 is displayed. The video stream 1410 can be received from a connected drug storage case or from a control center device. For example, when you press the video button, the app may start rendering the video data that the connected storage case has already sent, or sends a command to the storage case to start sending such video data. You can. As further illustrated, the hold button on menu 1310 is also shown to be selected. This indicates that the communication is held and the communication is not received or transmitted until the hold is released.

Menu 1310 also indicates that a text message button is selected, resulting in the display of text message interface elements 1420, 1430. As shown, interface 1400 includes a text area 1420 that receives input text messages. Selecting the text area 1420 may present the user with an interface element for entering text, such as an OS soft keyboard. Interface 1400 also includes a Send button 1430. When the send button 1430 is selected, the app sends a text message to the in-call storage case, which can display the message to the patient, for example, via an LCD screen when the text message is received.

FIG. 15 shows an alternative user interface 1500 displaying a moving image of a patient. The Alternate User Interface 1500 may be displayed, for example, when a video feed is activated and the physician rotates the phone 90 degrees. The app accesses the operating system to determine the current orientation of the physician device and switches to the alternate interface 1500 if the device is held in a nearly landscape orientation. As shown, the alternative interface presents a video stream in full screen 1510. It is clear that various alternative arrangements are possible. For example, a menu similar to menu 1310 can be displayed on the moving image area 1510. When the physician device is rotated to return to a nearly portrait orientation, the app can return to a previous interface, such as the interface 1400.

FIG. 16 shows an exemplary user interface 1600 for displaying a distribution button for distributing a drug to a patient. As shown, menu 1310 indicates that the distribution button has been selected. As a result, a large number of distributed interface elements 1610, 1620, 1630 are displayed as part of the interface 1600. The interface 1600 includes two distribution buttons 1610, 1620 associated with the drug available for distribution from the connected drug storage case. As you can see, in various embodiments, it may include fewer or additional buttons. In some embodiments, the connected storage case can send information identifying available medications to the physician device along with other information such as the expiration date. The interface 1600 can then render the corresponding buttons 1610, 1620. Although not shown, in some alternative embodiments, the interface 1600 may additionally include a field for receiving a physician's signature. For example, some states have rules that require a doctor's signature on any prescription. Upon entering the signature or pressing the distribution button, the physician device may memorize an image, text, or other representation of the signature or send it to the control center.

As shown, the interface 1600 identifies two agents available for distribution from the connected storage case. The first button 1610 indicates that the "Jr. Epipen" drug with an expiration date of December 20, 2015 is available. The second button 1620 indicates that the "Sr. Epipen" drug with an expiration date of February 15, 2015 is available. When either button 1610 or 1620 is selected, the physician device sends a command to distribute the associated drug to the connected storage case. For example, the connected storage case may transmit an index or other identifier for each drug, along with available drugs. The app may then send an instruction containing the identifier associated with the selected drug when the button is selected. The interface 1600 also includes a Cancel button 1630 for returning to a previous interface that does not include the distribution elements 1610, 1620, 1630.

FIG. 17 shows an alternative user interface 1700 that displays a distribution button that distributes the drug to the patient. In some embodiments, the button 1720 is displayed as unavailable for selection when the associated agent is unavailable. As shown, the connected storage case is unable to dispense the "Sr Epipen" drug and therefore the button 1720 is displayed as non-selectable. The app, for example, if the drug is expected to be available by the app but is not reported as available by the connected storage case, or the storage case explicitly reports that the drug is not available. If so, determine that the drug is unavailable. In various alternative embodiments, the interface 1700 may instead simply omit the display of any button of the unavailable drug.

FIG. 18 shows a typical user interface 1800 displaying a log of previous communication sessions. The call history interface 1800 can be accessed by selecting the call history button 1120 on the navigation menu. As illustrated, the call history interface displays a number of items 1810, 1820, 1830, 1840 that identify all previous incoming requests, or alternative, all accepted incoming requests. When input items 1810, 1820, 1830, 1840 are selected, the app displays an interface for displaying or inputting additional information for the call.

FIG. 19 shows a typical user interface 1900 for receiving a physician's note regarding a communication session. The memo interface 1900 can be accessed by selecting the input items 1810, 1820, 1830, 1840 from the call history interface 1800. As illustrated, the interface 1900 includes call details 1910 and a text field 1920 for receiving doctor's notes. When selected, the text field 1920 can give the physician an interface element for text input, such as an OS soft keyboard. Interface 1900 additionally includes a transmit button 1920 that sends the text in the text field 1930 to the command center device for storage in association with the call log. When selected, the cancel button 1940 returns the app to a previous screen, such as the Call History Interface 1800. Although not shown, in some alternative embodiments, the interface 1600 may additionally or alternatively include a field for receiving a physician's signature. For example, some states have rules that require a doctor's signature on any prescription. Upon entering the signature or pressing the submit button 1930, the physician device may memorize an image, text, or other representation of the signature or send it to the control center.

FIG. 20 shows a typical method 2000 of communicating with a drug storage case. Method 2000 can be performed by components of the physician device, such as the physician device 900. The method starts at step 2005 and proceeds to step 2010 where the device receives the incoming request and establishes a communication session. Based on this received request, the device displays a representation of the incoming request, such as interface 1200, in step 2015. In step 2020, the device determines whether the physician user has accepted the request. If not, the device sends a rejection message to the control center or drug storage case in step 2025. The control center or drug storage case may subsequently attempt to send a request to locate other physician devices capable of establishing a communication session. The method ends at step 2055.

However, if the physician accepts the incoming request in step 2020, the method proceeds to step 2030 in which the device establishes a two-way communication session with the drug distributor. Then, in step 2035, the device displays one or more distribution buttons in response to a user request to display the buttons, eg, as described above. Then, in step 2040, the device determines whether the doctor has pressed the distribution button. If not, the method skips to step 2050. If the physician presses the distribution button, the device sends an instruction to distribute the associated drug to the user in step 2045. At step 2050, the device determines whether the session has been terminated, for example, by a local user or a user of a remote drug distributor. If not, the method loops back to step 2040 and continues to check if the physician has selected the distribution button. Otherwise, the method ends at step 2055.

Various modifications to the above method will become apparent in view of the additional functionality of the physician device described herein. For example, Method 2000 provides additional steps aimed at interpreting incoming data describing available drugs, muting or holding a call, sending a text message, and displaying a video stream. May include. Various additional modifications will be revealed.

According to the above, various typical embodiments allow a physician to prescribe a drug and have rapid access to the drug at a remote location. For example, by providing a physician device application that can establish a voice or video communication session and send a distribution command to a remote drug distributor, qualified personnel can adequately assess the emergency situation and that situation. It is possible to effectively provide a drug that is deemed necessary or useful to deal with. In view of the above description, various other advantages become apparent.

As is clear from the above description, various typical embodiments of the present invention can be implemented in hardware and / or firmware. In addition, various typical embodiments can be implemented as instructions stored on a machine-readable storage medium, which storage medium is read by at least one processor to perform the operations detailed herein. Can be executed. Machine-readable storage media can include any mechanism that stores information in a machine-readable format, such as personal computers or laptop computers, servers, or other computing devices. That is, the machine-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk storage medium, optical storage medium, flash memory device, and similar storage media.

As will be appreciated by those skilled in the art, all block diagrams herein represent conceptual diagrams of exemplary circuits that embody the principles of the present invention. Similarly, flowcharts, flow diagrams, state transition diagrams, pseudocodes, etc. are all represented in substantially machine-readable media and executed by the computer or processor, whether or not the computer or processor is explicitly indicated. It is understood to represent the various processes that can be done.

Despite the fact that various typical embodiments have been described in detail with reference to certain typical aspects, the present invention may also be in other embodiments, the details of which are also in various obvious points. It should be understood that it can be modified. As will be readily apparent to those skilled in the art, modifications and modifications can be influenced while remaining within the gist and scope of the invention. Therefore, the above disclosures, descriptions, and drawings are for illustrative purposes only and are not intended to limit the invention as defined solely by the claims.

Claims (20)

A non-temporary machine-readable storage medium encoded by an instruction intended to be executed by a user device.
A command to display the representation of an incoming request that establishes a communication session with the patient operating the drug distributor,
An instruction to establish a two-way communication session with the patient via the drug distributor based on the approval of the incoming request by the physician user of the user device.
An instruction to display a distributed user interface (UI) element during the two-way communication session,
An instruction to receive the selection of the distribution UI element from the doctor user, and
A non-temporary machine-readable storage medium comprising a command to cause the drug distributor to distribute a drug to the patient based on the selection. An instruction to obtain drug data describing available drugs via the drug distributor, and
The non-temporary machine-readable storage medium of claim 1, further comprising an instruction to display a representation of said drug data related to said distributed UI element. The non-temporary machine-readable storage medium of claim 2, wherein the drug data includes an expiration date of the drug. An instruction to display the second distribution UI element during the two-way communication session,
An instruction to receive the selection of the second distribution UI element from the doctor user, and
The non-temporary machine-readable storage medium of claim 1, further comprising a command to cause the drug distributor to distribute the second drug to the patient based on the selection of the second distribution UI element. It further includes an instruction to receive drug information indicating whether the drug is available for distribution to the patient.
The instruction to represent the distribution user interface (UI) element displays the distribution UI element as non-selectable when the drug information indicates that the drug is not available for distribution to the patient. Including instructions to make
The instruction to receive the selection of the distribution UI element from the physician user is configured to be executed based on the drug information indicating that the drug is available for distribution to the patient. The non-temporary machine-readable storage medium of claim 1. An instruction to receive a stream of video data from the drug distributor via the two-way communication session.
The non-temporary machine-readable storage medium of claim 1, further comprising an instruction to display the moving image to the doctor user based on the stream of the moving image data. The command to receive the input of the message from the doctor user and
The non-temporary machine-readable storage medium of claim 1, further comprising an instruction to transmit a command to cause the drug distributor to display the input message to the patient. The method that the user device does
To establish a two-way communication session between the physician user and the patient of the user device via a remote drug distributor.
Receiving information describing the drug associated with the drug distributor and
Displaying a Distributor User Interface (UI) element representing the drug for the purpose of selection by the physician user.
A method comprising sending a command to cause the remote drug distributor to distribute the drug to the patient based on the selection of the distribution UI element. The received drug information includes the expiration date and
The method of claim 8, wherein the method further comprises displaying the expiration date in association with the distribution UI element. The received information additionally describes a second drug associated with the drug distributor.
The method further
Displaying a second distribution UI element representing the second drug associated with the drug distributor, and
8. The method of claim 8, comprising transmitting a command to cause the remote drug distributor to distribute the second drug to the patient based on the selection of the second distribution UI element. The received information indicates whether the drug is available for distribution from the remote drug distributor.
The method further
Displaying an expression that the drug is unavailable for distribution, based on the received information indicating that the drug is unavailable for distribution.
8. The method of claim 8, comprising refusing to select the distribution UI element based on the received information indicating that the drug is not available for distribution. Receiving a stream of video data from the remote drug distributor
The method of claim 8, further comprising displaying the moving image to the physician user based on the stream of the moving image data. Receiving the input of the message from the doctor user and
8. The method of claim 8, further comprising sending a command to cause the remote drug distributor to display the input message to the patient. A portable communication device intended for use by doctor users.
Communication interface and
With display devices
With touch input devices,
With memory
Including a processor that communicates with the memory
The processor
Displaying the representation of an incoming request via the display device to establish a communication session with the patient operating the drug distributor.
Establishing a two-way communication session with the patient via the communication interface and the drug distributor based on the physician user approving the incoming request.
Displaying distributed user interface (UI) elements through the display device during the two-way communication session.
Receiving the selection of the distribution UI element from the physician user via the touch input device and
A portable communication device configured to send a command to cause the drug distributor to distribute a drug to the patient via the communication interface and based on the selection. The processor further
Acquiring drug data describing available drugs via the drug distributor,
14. The portable communication device of claim 14, configured to display a representation of the drug data associated with the distribution UI element via the display device. The portable communication device of claim 15, wherein the drug data includes an expiration date of the drug. The processor further
Displaying the second distribution UI element via the display device during the two-way communication session.
Receiving the selection of the second distribution UI element from the physician user via the touch input device and
It is configured to send a command to cause the drug distributor to distribute the second drug to the patient via the communication interface and based on the selection of the second distribution UI element. The portable communication device according to claim 14. The processor is further configured to receive drug information indicating whether the drug is available for distribution to the patient.
Distributing When displaying a user interface (UI) element, the processor distributes the drug to the patient if the drug information indicates that the drug is not available for distribution to the patient. Configured to display UI elements as non-selectable,
The processor is configured to accept the selection of the distribution UI element from the physician user based on the drug information indicating that the drug is available for distribution to the patient. Item 14. The portable communication device of item 14. The processor further
Receiving a stream of video data from the drug distributor via the two-way communication session,
The portable communication device according to claim 14, wherein a moving image is displayed to the doctor user based on a stream of the moving image data via the display device. The processor further
Receiving the input of the message from the doctor user and
14. The portable communication device of claim 14, configured to transmit a command to cause the drug distributor to display the input message to the patient.

Images