JP2018504951A5 - - Google Patents

Description

Non-transitory machine-readable storage medium, method and portable communication device for drug dispensing

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

  The various exemplary embodiments described herein generally relate to storing, dispensing, and managing medications.

  Some suffer from medical conditions that can result in emergencies, where rapid drug administration is paramount. For example, people who develop allergies when exposed to certain substances can develop anaphylaxis. Because of its sudden onset and subsequent potential death from allergic severity, it is important to treat as early as possible epinephrine self-injection. Patients with known allergies are commonly prescribed an epinephrine auto-injector to treat sudden anaphylaxis, and the patient carries the auto-injector constantly to respond to emergencies according to the plan. Similarly, patients with other medical conditions that may cause an emergency requiring immediate treatment may be prescribed an appropriate medication or device to carry.

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

Various embodiments relate to a non-transitory machine-readable storage medium encoded with instructions to be executed by a user device, the medium comprising an incoming request to establish a communication session with a patient operating a drug dispenser. Instructions for displaying the instruction information of the patient, instructions for establishing a two-way communication session with the patient via the medication dispenser based on the physician user of the user device approving the incoming request, and two-way communication session Instructions for displaying a dispense user interface (UI) element during reception, instructions for receiving a selection of the dispense UI element from a physician user, and for dispensing a medication to the patient based on the selection. No Including instructions for transmitting a command.

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

Various embodiments relate to a portable communication device for use by a physician user, the portable communication device including a communication interface, a display device, a touch input device, a memory, and a processor in communication with the memory, wherein the processor comprises a drug dispenser. A communication interface and a drug dispenser based on a physician user of a user device for displaying an indication of an incoming request to establish a communication session with a patient operating the display device and approving the incoming request. Establishing a two-way communication session with the patient via the display device, displaying a dispense user interface (UI) element via the display device during the two-way communication session, and selecting a dispense UI element via the touch input device. Received from user And, via the communication interface based on the selection, and medicament dispenser is an agent to send a command for dispensing to the patient.

Various embodiments are described in the non-transitory machine-readable storage medium of claim 1, further comprising instructions for obtaining drug data via the drug dispenser describing available drugs, and a dispense UI element. For displaying the instruction information of the medicine data.

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

  Various embodiments further include instructions for displaying a second dispense UI element during a two-way communication session, instructions for receiving a selection of a second dispense UI element from a physician user, and a second instruction. The dispenser sends an instruction to dispense the second medication to the patient based on the selection of the dispense UI element.

  Various embodiments additionally include instructions for receiving medication information indicating whether a medication is available for dispensing to a patient, wherein the instructions for displaying a dispense user interface (UI) element include: If the information indicates that a medicament for dispensing to the patient is not available, instructions for displaying the dispense UI element as not selectable and for receiving a selection of the dispense UI element from the physician user are: , Instructions to be performed based on medication information indicating that the medication is available for distribution to the patient.

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

  Various embodiments additionally include instructions for receiving a message entered by a physician user and instructions for the medication dispenser to send a command to display the entered message to a patient.

  For a better understanding of various exemplary embodiments, refer to the following drawings.

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

  Although often effective, an emergency response where the patient always carries the drug is not a complete solution. There are many situations where patients do not have access to appropriate medications to deal with emergencies. For example, if a patient's condition is still undiagnosed, there is no opportunity to urgently prescribe a drug or device. As another example, if the patient is a child or if the use of the drug or device requires supervision or guidance, the patient's prescription may not be available and may not be available. In addition, there may not be an appropriate administrator for administration. Except for these special circumstances, the patient may simply forget the prescription or may not have the prescribed medication or device in an emergency. For at least these reasons, there is a need for alternative or additional solutions to provide a properly prescribed drug or device in an emergency.

  As will be described in more detail below, various embodiments limit access to stored medication until instructions are received from a remote operator, such as a physician at the time of the call, allowing the local patient or other user to access the stored medication. A medicine storage case for releasing the medicine to be used is included. The storage case additionally has two-way communication with the remote operator in order to properly and reliably determine whether and when the remote operator will dispense medication from the storage case. This communication allows the remote operator to obtain sufficient information about the patient and the situation to determine whether the medication should be dispensed.

  The description and drawings described herein illustrate various principles. One of ordinary skill in the art can implement these principles and formulate various arrangements that fall within the scope of this disclosure, even if not explicitly described or shown in the specification. As used herein, the term "or" means "or" which is not exclusive (i.e., "or") and unless otherwise indicated (e.g., "or another" or "or optional"). "). Moreover, the various embodiments described herein are not mutually exclusive and can be combined to form additional embodiments that incorporate the principles described herein. Obviously, the methods and devices described herein can be used to dispense drugs, medical devices, and combinations thereof. Thus, it will be understood that the term "agent" as used herein refers to both an agent and a medical device. Further, it will be appreciated that the various devices described herein may be used to control access to materials, devices, and other items outside the medical field.

  Referring to the drawings, in which like numerals refer to like components or steps, the broad aspects of various example embodiments are described.

  FIG. 1 illustrates an exemplary drug storage case 100. Various embodiments of a drug storage case are disclosed herein, and the example case 100 may also be referred to as a medical management system. As shown, the storage case 100 includes a case body 110 and a door 120 connected to the case body 110 by hinges 122a and 122b. Case body 110 includes an interior region 140 that is accessible by an opening in a front surface of case body 110. In various embodiments, the storage case 100 is attachable to a wall or other structure. As such, the storage case may also include sufficient fixed hardware to complete the installation. For example, the back surface of the case body 110 may include a recess for receiving a bolt head of a bolt screwed to a wall. As another example, the fixed hardware may include a separate mounting structure, which is screwed to the wall, and a hook, clip, or other structure on the back surface of the case body 110. It is attached. Various other types of fixed hardware for attaching storage case 100 to a structure will be apparent. In various embodiments, the back, bottom, or other surface of the case body may include connectors for power, network, and telephone connections.

  A lower ledge 142 is formed at the bottom of the case body, on which the dispensed drug 130 remains before being removed by the user. Before being dispensed, the medication 130 is retained in another area of the interior area 140, which is inaccessible or accessible to local users. For example, the medication 130 may be retained in a portion of the interior region 140, which is hidden behind the front surface of the storage case 110 over the opening and lower ledge 142. In various embodiments, the storage case 100 is configured to store and dispense a plurality of medications that may be different from one another. For example, in some implementations, the storage case can dispense both epinephrine self-injectors for adults and children, and can be retained inside various packaging, such as a product box.

  To hold the medication prior to dispensing, storage case 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 lockable in a closed state. Various exemplary drug locks and other retaining structures are described in more detail below. Although a particular retaining structure was used, in various embodiments, the retaining structure is electrically switched from a locked state to an unlocked state by an actuator (not shown) controlled by a processor (not shown). And can act in accordance with instructions received from a remote site on an unlocked holding structure. For example, upon receiving an unlock signal, such as an Internet packet containing distribution instructions, the processor sends an access signal to the actuator, which can then cause the holding structure to be unlocked. Once the holding structure is unlocked, the medicament is free to move from the device, i.e., the user manually operates an unlocked holding structure (e.g., opens an unlocked door). Can access the drug freely.

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

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

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

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

  Once the medication has been dispensed, the storage case 100 can be refilled with additional medication by service staff. In some implementations, the refill may be performed after opening the case 100, but in other embodiments, service staff may not open the case, but directly into the case via the front open product access area. May be refilled. Various alternatives for refilling that do not require special service access (eg, opening the case) may be utilized, including, for example, a slot at the top of the case, as described below with respect to FIG. To fill the drug.

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

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

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

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

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

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

  Electronic subsystem 210 may also include an enclosure I / O interface 230 for communicating with mechanical subsystem 240. In various embodiments, the enclosure I / O interface 230 may simply use the GPIO interface 220. Mechanical subsystem 240 includes two devices. Devices that detect that the door is open, 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 opens. In various embodiments, this signal may be used to power up or wake up 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 the signal, the drug lock / unlock mechanism 244 dispenses the drug, as described in more detail below.

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

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

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

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

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

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

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

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

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

  In some implementations, various electronics circuits may include a self-diagnostic function or feedback capability. For example, a self-diagnosis or feedback method may be employed to monitor the status of the solenoid loop, monitor battery degradation, or monitor other key functions. The way to implement this capability is obvious.

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

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

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

  FIG. 5 illustrates a cross-sectional view 500 as viewed from the side of the example drug storage case 110 of FIG. Case body 110 has a front side surface and a back side surface defining an interior region 140 therebetween.

  The sleeve 400 holding the medicament 130 is suspended in the interior region 140 by the sleeve rail 430. As shown, the hook 510 is received below the rail 430 and allows the sleeve 400 to hang from the hook 510. Hook 510 is properly held at pivot point 512. For example, a rod, pin, or other structure may be inserted into hook 510 at pivot point 512, and the hook may rotate clockwise or counterclockwise as seen from the perspective view of FIG. The hooks tend to rotate clockwise due to the mass of sleeve 400 and drug 130. As shown, as the hook 510 rotates clockwise far enough, the rail 430 slides down from the hook 510. When not supported by the hook 510, the sleeve 400 falls and reaches the lower ledge for collection by the user. A spring of sufficient force is disposed between the head of the hook 510 and the case body 110 to oppose the force of the sleeve 400 falling from the hook 510. As such, the hook holds the sleeve 400 suspended if no other external force acts on the hook 510.

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

  The arrangement of FIG. 5 is an example of a holding structure and actuator for dispensing a medicament, and it is clear that many other configurations are possible. For example, the sleeve 400 can be suspended directly by a solenoid cylinder, and operates such that activation of the solenoid controller 362 disengages the sleeve 400. In such an embodiment, the components of the solenoid 562 function as both a holding structure and an actuator. Similarly, in some implementations, the solenoid cylinder may contact or be configured with another non-swirl structure and move linearly out of engagement with the sleeve 400. In another embodiment, instead of suspending the sleeve 400 or the drug 130, the sleeve 400 or the drug 130 may be positioned along a movable platform. When activated, the platform may retract or pivot, causing the sleeve 400 or the medication 130 to become unsupported and fall to the lower ledge 142.

  Various arrangements may use an actuator rather than a solenoid. For example, a servomotor or stepper motor may be used to control the angular position of the hook 510 or platform, or separate holding structures from one or more coupling structures (eg, a winding cable attached to the structure) Can be used to retract linearly through As another example, if the holding structure is an electromagnetic magnet, the actuator may be a controller configured to turn off power to the magnet, thus releasing the sleeve 400 or drug 130. Various other types of actuators are apparent.

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

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

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

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

  Next, at step 650, the processor initiates a Voice over IP (VOIP) call to the control center rather than an emergency dispatch. For example, the control center may be operated by the same operator that provides, maintains, or associates the containment case or the medication contained therein. Again, the storage case may also transmit various predetermined information such as storage case location or identification information. Next, at step 660, the processor transfers the audio data between the audio codec and the VOIP channel, allowing the local user to contact the control center operator. As shown below, the control center operator may transfer the call to a physician, after which the local user may contact the physician. At 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 closed from the other end. If not, the method 600 loops back to step 660 and continues transferring the audio data to the remote site. Otherwise, the processor proceeds to step 680, closes the VOIP channel, and the method ends at step 690.

  Method 600 is an example of operation of a drug storage case according to the systems and methods described herein, and various alternatives may be used. For example, step 670 may be performed by an event handler that closes the call and an indication of the event. In some implementations, a call to the emergency dispatch may not occur, but in other embodiments only a call to 911 is made, where the emergency dispatch remotely controls the dispensing of the drug, or Transfer to a physician or other operator that has also been implemented. In other embodiments, the various steps of the method are performed in parallel. For example, step 620 can be split into two threads, a first thread involving steps 630, 640, and a second thread involving steps 650-680. In this embodiment, two calls are performed simultaneously. Various other variations are apparent.

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

  The method begins at step 710 and proceeds to step 720, where the processor receives an unlock signal that functions as a distribution instruction. For example, a processor may receive a packet containing instructions for dispensing a drug. At step 730, the processor determines, by instructions, the index of the drug to be dispensed. Available medications may be indexed, particularly in embodiments where the storage case is capable of dispensing multiple different medications and dosages. For example, an adult epinephrine autoinjector set may be indexed as "0" and a child epinephrine autoinjector set may be indexed as "1". The instructions received in step 720 may directly specify the index to the appropriate drug, or may only specify the drug to be dispensed, in which case the processor may look up the index of the specified drug, e.g. Can be determined by table. For embodiments where only a single type of drug can be dispensed, step 730 may be omitted.

  At step 740, the processor sends an access signal to the actuator corresponding to the appropriate medication. Again, this step may include correlating the index or drug with the actuator, for example, by a look-up table. Upon receiving the access signal, the actuator releases the medicament for removal by the user. In various alternative embodiments, a single actuator may control the release of multiple drugs, in which embodiments the processor may simply send the desired drug index or other identifying information to the actuator, Then, an appropriate action to dispense the requested drug is determined.

  After dispensing the medication, the processor records and places the video instructions for the medication, or receives the instructions via the network interface. At step 750, the processor outputs the instructions to a display device so that the instructions are displayed graphically to any physician or other remote operator. The method 700 proceeds to end at step 760.

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

  As described, when activated by a user, storage case 100 initiates a VOIP call to a remote site, such as control center 820 or an emergency dispatch (not shown). The control center 820 may forward the VOIP call immediately, i.e., during the call, to a physician who is on-site or will be called. In some implementations, control center 820 may simply operate as an electronic device and automatically forward calls to available physician devices 830. In such an embodiment, control center 820 may be hosted within a cloud computing environment.

  The control center 820 or physician device 830 also includes the capability of a remote operator to remotely release one or more medications in the storage case 100 in addition to assisting with an audio VOIP call. For example, the physician device 830 executes the mobile application to communicate audio data between the physician and the storage case, and provides the physician with the following two buttons. Buttons for dispensing adult forms of epinephrine self-injector and buttons for dispensing children's form of epinephrine self-injector. The button may cause the physician device to generate a release signal, such as a dispensing instruction packet, and be transmitted to the storage case 100 via the control center 820 or directly via the Internet 810 without the control center 820. Similar functions may be provided in the control center 820.

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

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

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

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

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

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

  Network interface 950 may include one or more devices to 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. Further, network interface 950 may implement a TCP / IP stack for communicating according to the TCP / IP protocol. Various alternative or additional hardware or configurations for the network interface 950 will be apparent.

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

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

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

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

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

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

FIG. 12 illustrates an example user interface 1200 for displaying an indication of an incoming communication request. Doctor device receives a request coming, for example, to establish a communication session from a control center device or agent storage case, incoming request interface 1200 may be displayed. The incoming request interface 1200 includes instruction information 1210 of the medicine storage case corresponding to the incoming request. Two buttons are provided to the user, they answered buttons 1220 to approve the request for incoming a negative button 1230 to deny the request to incoming. Selecting the deny button 1230 may return the application to the home screen or another screen that was being displayed before the incoming request was received. Upon selecting answer button 1220, the application may display an active communication session screen.

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

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

  Menu 1310 further indicates that when the text message button is selected, text message interface elements 1420, 1430 are shown. As shown, interface 1400 includes a text area 1420 for receiving an entered text message. Upon selecting text area 1420, the user may be presented with an interface element for entering text with, for example, an OS soft keyboard or the like. Interface 1400 also includes a submit button 1430. Upon selecting the send button 1430, the application may send a text message to the paging storage case and upon receiving the text message, display the message to the patient, for example, by an LCD screen.

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

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

  As shown, interface 1600 identifies two available medications to dispense from the connected storage case. The first button 1610 indicates that a “Jr. Epipen” drug with an expiration date of December 20, 2015 is available. The second button 1620 indicates that a “Sr. Epipen” drug with an expiration date of February 15, 2015 is available. Upon selecting any of the buttons 1610, 1620, the physician device sends instructions to the connected storage case to dispense the corresponding medication. For example, the connected storage case may transmit an index or other instructional information for each drug along with the available drugs. Next, upon selecting the button, the application may send instructions including instruction information corresponding to the selected medication. Interface 1600 also includes a cancel button 1630 that returns to the previous interface without distributing elements 1610, 1620, 1630.

  FIG. 17 illustrates an alternative user interface 1700 for displaying a dispense button for dispensing a drug to a patient. In some implementations, button 1720 may indicate that a selection is not possible if the corresponding medication is not available. As shown, the connected storage case indicates that the button 1720 is not selectable, so that the “Sr Epipen” medicine cannot be dispensed. The application may determine that the drug is not available, e.g., if the application assumes that the drug is available but does not report that it is available from the connected storage case, or if the storage case is clearly They may report that the drug is not available. In various alternative embodiments, interface 1700 may simply omit displaying all buttons for unavailable drugs.

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

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

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

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

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

  In accordance with the foregoing description, various exemplary embodiments allow a physician to quickly access and prescribe medication at a remote location. For example, by providing a physician device application that can establish an audio or video communication session and send dispensing instructions to a remote medication dispenser, a competent person may need or be able to understand the emergency and handle the medication Can be provided effectively. Various other advantageous effects are apparent from the foregoing description.

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

  Those skilled in the art will appreciate that any block diagrams described herein have been conceptually illustrated in order to implement the principles of the present invention. Similarly, it will be understood that any flowcharts, flowcharts, state transition diagrams, pseudo-codes, etc., represent various processes, and various processes may be substantially represented in a machine-readable medium, Or executed by the computer or processor, whether or not the processor is explicitly indicated.

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

Claims (20)

A non-transitory machine-readable storage medium on which instructions executed by the user device are encoded ,
Instructions for displaying instruction information of an incoming request to establish a communication session with a patient operating the drug dispenser;
And instructions for establishing the patient two-way communication session through the medicament dispenser based on a physician user of the user device approves the incoming request,
Instructions for displaying a dispense user interface (UI) element after the two-way communication session is established ;
And instructions for receiving a selection of the dispensing UI elements from the physician user,
Based on the selection, the medicament dispenser includes a <br/> and instructions for transmitting a command for dispensing medication to the patient, a non-transitory machine-readable storage medium. An agent data describing the incoming hand capable agent, and instructions for obtaining through the medicament dispenser,
The dispensing further comprises a <br/> and instructions for displaying the indication information of the drug data in UI elements, non-transitory machine-readable storage media of claim 1. Before Symbol drug data includes an expiration date of the drug, a non-transitory machine-readable storage media of claim 2. And instructions for displaying a second dispensing UI elements during the previous SL-way communication session,
Instructions for receiving a selection of the second dispense UI element from the physician user;
Based on the selection of the second dispensing UI element, the medicament dispenser further comprises an <br/> and instructions for transmitting a command to dispense a second agent to said patient, a non-transitory of claim 1 Machine readable storage medium. The pre-Symbol medicament further comprises instructions for receiving a medication information indicating whether available for distribution to the patient,
The instructions for displaying the dispense user interface (UI) element may include dispensing the dispense UI element as not selectable if the medication information indicates that the medication for dispensing to the patient is not available. Includes instructions to display,
Instructions for receiving a selection of the dispense UI element from the physician user are configured to be performed based on the medication information indicating that the medication is available for distribution to the patient . The non-transitory machine-readable storage medium of claim 1 . Before Symbol medicament dispenser through the two-way communication session, and instructions for receiving a stream of video data,
Further comprising non-transitory machine-readable storage media of claim 1 <br/> and instructions for displaying video on the physician user based on the stream of the video data. And instructions for receiving a message that is input from the previous SL physician user,
Further comprising non-transitory machine-readable storage media of claim 1 <br/> and instructions for sending a command to display a message that the medicament dispenser is entered into the patient. A method performed by a user device, the method comprising :
Establishing a two-way communication session between a physician user of the user device and a patient via a remote medication dispenser;
Receiving information describing a drug for the drug dispenser;
Displaying a dispense user interface (UI) element indicating the medication for the physician user to select after the two-way communication session is established ;
On the basis of the selection of the dispensing UI element, it said remote medicament dispenser includes a <br/> the step of transmitting a command for dispensing the drug to the patient. Expiration date included in the previous Symbol received drug information,
The method of claim 8, wherein the method includes displaying the expiration date via the dispense UI element. Information received prior SL will describe a second agent for said medicament dispenser additionally,
The method comprises:
Displaying a second dispense UI element indicating the second medication for the medication dispenser;
Based on the selection of the second dispensing UI element, further comprising the <br/> and process the remote medicament dispenser sends a command to dispense the second drug to the patient, according to claim 8 method of. Information received prior SL indicates whether the agent whether available for dispensing from the medicament dispenser of the remote,
The method comprises:
Based on the received information indicating that the medicine cannot be dispensed, displaying information indicating that the medicine cannot be dispensed,
Based on the received information indicating the inability to dispense the drug, further comprising the <br/> the step of disabling the selection of the dispensing UI elements The method of claim 8. A step of receiving a stream of video data from the previous SL remote medicament dispenser,
Wherein based on the stream of video data further comprises the <br/> the step of displaying the video on the physician user The method of claim 8. The method comprising the steps of: receiving a message before Symbol physician user to input,
Further comprising a step of remote medicament dispenser sends a command for displaying the message input to said patient a <br/>, The method of claim 8. A portable communication device used by a physician user, the device comprising :
A communication interface,
A display device;
A touch input device;
Memory and
It includes <br/> a processor in communication with said memory,
The processor comprises:
And the instruction information of an incoming request to establish a communication session with the patient to operate the medicament dispenser, available for viewing via the display device,
And said doctor user based on authorizing the incoming request, via the communication interface and the medicament dispenser, establishes a two-way communication session with the patient,
And said during a two-way communication session, through the display device to display the dispense user interface (UI) element after establishment of the two-way communication session,
And that through the touch input device, receiving a selection of the dispensing UI elements of the physician user,
Via the communication interface, the drug dispenser, based on the selection, transmitting a command to dispense a drug to the patient ;
A portable communication device configured to : Before Symbol processor,
Acquiring drug data from the drug dispenser that describes available drugs,
Via the display device, and displaying the indication information of the drug data in said dispensing UI element
Further configured to perform, a portable communication device of claim 14. Before Symbol drug data includes an expiration date of the drug, the portable communication device of claim 15. The processor comprises :
And said during a two-way communication session, through the display device to display a second dispensing UI element,
Receiving a selection of the second dispense UI element from the physician user via the touch input device;
The medication dispenser sending a command to dispense a second medication to the patient based on the selection of the second dispense UI element via the communication interface ;
Further configured to perform, a portable communication device of claim 14. The processor, the medicament for dispensing to the patient is further configured to receive the drug information indicating whether available,
During display of a dispense user interface (UI) element, the processor may cause the dispense UI element to not be selectable if the medication information indicates that the medication is not available for distribution to the patient. Is composed of
Wherein the processor, based on the medicine information indicating that said agent for distribution to the patient are available, configured to receive a selection of the dispensing UI elements from the physician user, claim 14. Portable communication device. Before Symbol processor,
Receiving a stream of video data from the drug dispenser via the two-way communication session;
Displaying a video to the physician user via the display device based on the stream of video data ;
Further configured to perform, a portable communication device of claim 14. Before Symbol processor,
Receiving a message that the physician user inputs,
The drug dispenser sends a command to display the input message to the patient ;
Further configured to perform, a portable communication device of claim 14.

Images