CN107408145B - System and method for medicament storage, dispensing and administration - Google Patents
System and method for medicament storage, dispensing and administration Download PDFInfo
- Publication number
- CN107408145B CN107408145B CN201580074665.XA CN201580074665A CN107408145B CN 107408145 B CN107408145 B CN 107408145B CN 201580074665 A CN201580074665 A CN 201580074665A CN 107408145 B CN107408145 B CN 107408145B
- Authority
- CN
- China
- Prior art keywords
- medication
- instructions
- patient
- dispense
- medications
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
- G16H20/13—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered from dispensers
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
- Y02A90/00—Technologies having an indirect contribution to adaptation to climate change
- Y02A90/10—Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Biomedical Technology (AREA)
- Public Health (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Chemical & Material Sciences (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Medicinal Chemistry (AREA)
- Infusion, Injection, And Reservoir Apparatuses (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Medical Preparation Storing Or Oral Administration Devices (AREA)
Abstract
Various exemplary embodiments relate to a method, apparatus, and non-transitory machine-readable storage medium encoded with instructions for execution by a user device. The medium includes: instructions for displaying an indication of an incoming request to establish a communication session with a patient operating a medication dispenser; instructions for establishing a two-way communication session with a patient via a medication dispenser based on approval of an incoming request by a physician user of a user device; instructions for displaying an assignment User Interface (UI) element during the two-way communication session; instructions for receiving a selection of an assignment UI element from a physician user; and instructions for sending a command for the medication dispenser to dispense medication to the patient based on the selection.
Description
Cross Reference to Related Applications
This patent application claims priority to U.S. patent application No. 14/575,477 filed on month 12 and 18 of 2014, which is U.S. patent application No. 14/282,884 filed on month 5 and 20 of 2014, now a continuation-in-part application with U.S. patent No. 8,922,367. U.S. patent application No. 14/282,884 is a partial continuation of PCT/US2013/072878 patent application filed on 3.12.2013, which claims priority to U.S. provisional patent application No. 61/732,753 filed on 3.12.2012. The entire disclosure of said application is hereby incorporated by reference herein for all purposes.
Technical Field
Various exemplary embodiments disclosed herein relate generally to the storage, dispensing, and administration of medicaments.
Background
Some people suffer from medical conditions that may cause emergency situations, in which case rapid administration of the drug is very important. For example, a severely allergic person exposed to a trigger substance may develop an allergic reaction. Since there is a possibility of rapid morbidity and concomitant mortality (depending on the severity of the allergy), it is important to administer the treatment as quickly as possible, for example a dose of epinephrine. Patients with known allergies are often fitted with an auto-injector of epinephrine to treat sudden allergic reactions, with the expectation that the patient will always carry the auto-injector so that it is always available in an emergency situation. Similarly, patients with other medical conditions that may cause an emergency situation requiring immediate treatment may be prescribed the appropriate medication or device.
Disclosure of Invention
In view of the various contingency plans currently required during the administration of epinephrine and other drugs, various exemplary embodiments are briefly summarized. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments and is not intended to limit the scope of the invention. In the following sections, detailed descriptions of preferred exemplary embodiments will be given, which are sufficient to enable those skilled in the art to make and use the inventive concept.
Various exemplary embodiments relate to a non-transitory machine-readable storage medium encoded with instructions for execution by a user device. The medium includes: instructions for displaying an indication of an incoming request to establish a communication session with a patient operating a medication dispenser; instructions for establishing a two-way communication session with a patient via a medication dispenser based on approval of an incoming request by a physician user of a user device; instructions for displaying an assignment User Interface (UI) element during the two-way communication session; instructions for receiving a selection of an assignment UI element from a physician user; and instructions for sending a command for the medication dispenser to dispense medication to the patient based on the selection.
Various embodiments relate to a method performed by a user device. The method comprises the following steps: establishing a two-way communication session between a physician user of the user device and the patient via the remote medication dispenser; receiving information describing a medication associated with a medication dispenser; displaying a dispensing User Interface (UI) element representing a medication for selection by a physician user; a command is sent for the remote medication dispenser to dispense medication to the patient based on the selection of the dispense UI element.
Various embodiments relate to a portable communication device for use by a physician user. The portable communication device includes: a communication interface; a display device; a touch input device; a memory; and a processor in communication with the memory, wherein the processor is configured to: displaying, via a display device, an indication of an incoming request to establish a communication session with a patient operating a medication dispenser; establishing a two-way communication session with the patient via the communication interface and the medication dispenser based on approval of the incoming request by a physician user of the user device; displaying, via a display device, an assignment User Interface (UI) element during a two-way communication session; receiving a selection of an allocation UI element from a physician user via a touch input device; and sending, via the communication interface and based on the selection, a command for the medication dispenser to dispense medication to the patient.
Various embodiments describe the non-transitory machine-readable storage medium of claim 1, the non-transitory machine-readable storage medium further comprising: instructions for obtaining medication data describing a medication, the medication being available via a medication dispenser; and instructions for displaying an indication of the medication data in association with an assignment UI element.
Various embodiments are described in which the drug data includes a drug's expiration date.
Various embodiments additionally include: instructions for displaying a second allocation UI element during the two-way communication session; instructions for receiving a selection of a second assignment UI element from a physician user; and instructions for sending a command for the medication dispenser to dispense medication to the patient based on the selection of the second 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 an assignment User Interface (UI) element include: when the medication information indicates that the medication is not available for dispensing to the patient, the instructions for displaying the dispense UI element as non-selectable, and the 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 dispensing to the patient.
Various embodiments additionally include: instructions for receiving a video data stream from a medication dispenser via a two-way communication session; and instructions to display the video to the physician user based on the video data.
Various embodiments additionally include: instructions for receiving entry of a message from a physician user; and instructions for sending a command for the medication dispenser to display the entered message to the patient.
Brief description of the drawings
For a better understanding of the various exemplary embodiments, reference is made to the accompanying drawings, in which:
fig. 1 illustrates an exemplary medicament storage case;
fig. 2 shows a block diagram of exemplary components of a medicament storage case;
fig. 3 illustrates an exemplary schematic of exemplary components of a medicament storage case;
FIG. 4 illustrates an exemplary cannula for containing a medicament;
fig. 5 illustrates a cross-section of an exemplary medicament storage case including an exemplary detent for selectively retaining and releasing the sleeve;
FIG. 6 illustrates an exemplary method for contacting emergency services via a medicament storage case;
FIG. 7 illustrates an exemplary method of allowing access to a medicament in response to a remote command;
FIG. 8 illustrates an exemplary network environment of a medicament storage case;
FIG. 9 shows an exemplary hardware diagram of a physician device or a control center device;
FIG. 10 shows an exemplary user interface for authenticating a physician user;
FIG. 11 illustrates an exemplary user interface for presenting a home screen;
FIG. 12 illustrates an exemplary user interface for displaying an indication of an incoming communication request;
FIG. 13 illustrates an exemplary user interface for display during a communication session;
FIG. 14 illustrates an exemplary user interface for displaying patient video and sending test messages;
FIG. 15 illustrates an alternative user interface for displaying patient video;
FIG. 16 illustrates an exemplary user interface for displaying a dispense button for dispensing medication to a patient;
FIG. 17 illustrates an alternative user interface for displaying a dispense button for dispensing medication to a patient;
FIG. 18 illustrates an exemplary user interface for displaying a log of previous communication sessions;
FIG. 19 shows an exemplary user interface for receiving physician notes regarding a communication session; and
fig. 20 illustrates an exemplary method for communicating with a drug storage bin.
Detailed Description
While often effective, providing patients with an emergency plan of always carrying medications is not a complete solution. There are many situations where a patient may not have access to the appropriate medication to cope with an emergency situation. For example, in the event that the patient's condition has not been diagnosed, there is no opportunity to pre-arm an emergency medication or device. As another example, where the patient is a child or otherwise requires supervision or guidance in using the medication or device, the patient may not actually carry the prescription and thus the prescription may not be available. Furthermore, there may not be a proper administration guardian. Outside of special circumstances such as these, the patient may simply forget the prescription in an emergency or may not currently have a prescribed medication or device at hand. For at least these reasons, alternative or complementary solutions for providing an appropriate prescribed medication or device in an emergency situation are needed.
As will be explained in more detail below, various embodiments include a medicament storage case that restricts access to stored medicament until an instruction is received from a remote operator (e.g., an armed physician) to release the medicament for use by a local patient or other user. To enable the remote operator to adequately determine whether and when the medicament is dispensed from the storage bin, the storage bin additionally facilitates two-way communication with the remote operator. Through this communication, the remote operator can obtain information about the patient and the situation, which is sufficient to decide whether or not the medicament should be dispensed.
The description and drawings presented herein illustrate various principles. It will be appreciated that those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody these principles and are included within the scope of the present disclosure. As used herein, the term "or" as used herein refers to a non-exclusive or (i.e., or), unless otherwise specified (e.g., "otherwise" or in the alternative "). In addition, the various embodiments described herein are not necessarily mutually exclusive and may be combined to produce additional embodiments incorporating the principles described herein. It will be appreciated that the methods and devices described herein may be used to dispense medicaments, medical devices, and combinations thereof. Thus, the term "medicament" as used herein will be understood to encompass both drugs and medical devices. Further, it will be appreciated that the various devices described herein may be used to provide controlled access to substances, devices, and other items outside of the medical field.
Referring now to the drawings, macroscopic aspects of various exemplary embodiments are disclosed. In the drawings, like reference numerals refer to like parts or steps.
Fig. 1 illustrates an exemplary medicament storage case 100. The various embodiments of the medicament storage case disclosed herein (including the exemplary case 100) may also be referred to as a medical management system. As shown, the storage box 100 includes a box 110 and a door 120 attached to the box by hinges 122a, 122 b. The housing 110 includes an interior region 140 that is accessible via an opening in a front surface of the housing 110. In various embodiments, the storage box 100 may be mounted to a wall or other structure. Thus, the storage bin may also include securing hardware sufficient to accomplish this installation. For example, the rear surface of the case 110 may include a recess for receiving a bolt head of a bolt that has been screwed into a wall. As another example, the securing hardware may include a separate mounting structure that is secured to the wall using screws, and to which the rear surface of the case 110 is hooked, clipped, or otherwise attached. Various other types of securing hardware for securing the storage box 100 to a structure will be apparent. In various embodiments, the back, bottom, or other surface of the case may include connectors, such as power, network, and telephone connections.
The bottom of the case forms a lower ledge 142 on which the dispensed medicament 130 rests prior to removal by the user. Prior to being dispensed, the medicament 130 is held at another area of the interior area 140 that is not accessible or difficult to access by a local user. For example, the medicament 130 may be retained at a portion of the interior region 140 that is above the opening and lower ledge 142 and is hidden behind the front surface of the storage case 110. In various embodiments, the storage case 100 is configured to store and dispense a plurality of medicaments that may be different from one another. For example, in some embodiments, the storage case is capable of dispensing both adult and pediatric dosage forms of an epinephrine auto-injector, which may be contained in various packages, e.g., product cartridges.
To retain the medicament prior to dispensing, the storage case 100 may include a medicament lock (not shown) or other lockable retaining structure, such as a door (not shown). Alternatively, the illustrated door 120 is lockable in the closed position. Various exemplary medicament locks and other retaining structures will be described in greater detail below. Regardless of the particular retaining structure used, in various embodiments, the retaining structure may be electronically moved from the locked state to the unlocked state by an actuator (not shown) controlled by a processor (not shown) that may operate in accordance with received instructions for unlocking the retaining structure from a remote site. For example, upon receiving an unlock signal, such as an internet packet including a dispense instruction, the processor may transmit an access signal to the actuator, which in turn unlocks the holding structure. Once the retaining structure is in the unlocked state, the medicament may be freely removed from the device, or the user may be able to manually operate the unlocked retaining structure (e.g., open the unlocked door) to release the medicament.
The storage box 100 also includes a plurality of input/output devices for communicating with a local user. As shown, the storage bin includes a "start" button 111 and a "stop" button 112. After pressing the start button 111, the storage case 100 may initiate a two-way communication session with a remote site via a communication unit (not shown). The communication session may involve audio communication via microphone 114 and speaker 115 so that the local user and the remote operator may converse. The stop button 112 may be configured to end a call or abort any process performed by the storage case 100 after the local user presses the start button 112.
A display 113 may also be provided for various purposes. For example, the display may facilitate video feeding between a remote site and a local user as part of a two-way communication session and in conjunction with a camera (not shown). Alternatively, the display 113 may show various information to the local user, such as a medicament usage instruction or a status update regarding the current action being performed by the storage case 100 or a remote operator. Thus, the displayed information may be stored locally or received from a remote site or elsewhere. In various embodiments, the information displayed on the display 113 is controlled by a remote operator, such as a physician. In some embodiments, the display 113 includes a touch screen input. In these embodiments, the display 113 may include soft buttons instead of or in addition to the start button 111 and the stop button 112. The touch screen display 113 may also be used to provide a management interface that may be accessed via: entering a password, swiping a key fob, or any other authentication process to provide an authorized user with access to recorded information or access to the internal compartment to replace any dispensed or expired medicament.
The status of the storage bin 100 may be communicated in alternative or additional ways. For example, as shown, the storage bin 100 includes a plurality of status lights 116. The status light may convey system information, such as a power-on or start-up status, or process flow information, such as whether a call has been placed or whether a medicament has been dispensed. Various other uses of the status light 116 will be apparent.
In various embodiments, power may be provided to the electronics that control operation of the storage tank at all times via a battery, power supply, or other power source. Other embodiments may implement power saving features that reduce energy consumption. For example, the electronics of the storage case 100 may be turned off or placed in a "sleep" mode during periods of non-use. Upon activation by a local user, these electronics may be powered on or awakened to perform the associated function. For example, the opening of the door 120, the pressing of an activation button, or the pressing of a separate "power" button may be configured to initiate power-up or wake-up of the electronics. Various other power saving features will be apparent.
Once the medicament has been dispensed, the storage case 100 may be reloaded with additional medicament by service personnel. While in some embodiments reloading may be accomplished by opening the bin 100, in other embodiments service personnel may reload the bin directly through the product access area that is open at the front, without opening the bin. Various alternative methods for reloading may be used without requiring special service access (e.g., opening the case), such as loading the medicament through a slot in the top of the case, as described below with respect to fig. 16.
Fig. 2 illustrates an exemplary block diagram 200 of exemplary components of a medicament storage case. In various embodiments, the block diagrams illustrate various electronic and mechanical components of the exemplary storage case 100 of fig. 1.
As shown, block diagram 200 includes electronics subsystem 210, mechanical subsystem 240, and numerous additional components 250 through 266. Electronics subsystem 210 includes a processor 212 and various supporting electronic components 214 through 232. The processor 212 may include virtually any device capable of coordinating the functions described herein, such as a microprocessor, a Field Programmable Gate Array (FPGA), or an Application Specific Integrated Circuit (ASIC). In various embodiments, the processor 212 is an ARM architecture microprocessor.
The processor 212 is provided with access to various forms of memory/data storage, including an SD card interface 216 and on-board program and data storage 224, 226. The program memory 224 stores software instructions for directing the processor to perform various methods described herein, such as the exemplary methods described with respect to fig. 6-7. For example, program memory 224 may store an operating system such as a linux kernel and appropriate device drivers, real-time transport protocol (RTP) stack instructions, Session Initiation Protocol (SIP) stack instructions, direct access configuration (DAA) stack instructions, and instructions for providing a Qt Graphical User Interface (GUI). Additionally, the program memory 224 may store event processing instructions for responding to incoming events, such as door open/close, monitor reset, factory reset, firmware update, entry into manufacturing mode, status/reporting, and failure notification. The program memory 224 may also store various audio components such as an Advanced Linux Sound Architecture (ALSA) library, software codec instructions, and echo/noise cancellation algorithms.
The data storage 226 may be used by the processor to store various data, such as log data relating to the usage of the storage bin, the recording of location information or temperature information. Various other data for storage in the data memory 226 or on an SD or other memory card will be apparent from this description. Alternatively or additionally, an SD or other memory card 216 may be used to store boot instructions, firmware images, activity logs, predefined information and messages, and other information.
The electronics subsystem 212 includes an audio interface 214, such as an audio codec, for enabling the processor to receive and output audio via various audio devices, such as a speaker 250, an earpiece 252, or a microphone 254. Similarly, electronics subsystem 210 includes a touch screen interface 218 for outputting visual data to a touch screen device 256 and receiving touch input from the touch screen device 256. The electronics subsystem 210 provides a general purpose input/output (GPIO) interface 220 for various other input/output devices, such as status LEDs 258 or push buttons 260.
The processor 212 may also have access to various external devices. For example, to connect to other devices via the internet or other network, electronics subsystem 210 includes a physical network interface (PHY) that communicates via various media such as ethernet or WiFi 262. Additionally, the electronics subsystem 210 includes a Plain Ordinary Telephone System (POTS) interface 228 to enable telephone calls to be established via a landline (landline) 264. To enable system debugging and other maintenance, electronics subsystem 210 includes an RS-232 serial interface 232, to which serial interface 232 a device having a universal asynchronous receiver/transmitter (UART) may be attached to exchange data and instructions with the processor.
Fig. 3 illustrates an exemplary schematic 300 of exemplary components of a medicament storage case. In various embodiments, the schematic 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. 2.
As shown, the system is arranged around a processor 310, which processor 310 may be a microprocessor, FPGA, ASIC, or any other device capable of performing the described functions, as described above. The processor 310 may contain some on-board memory and may additionally have access to other forms of memory, such as an SD card connector 311 and EEPROM 314, DDR3 memory 315, and NAND flash memory 316. The processor 310 may communicate with the SD card connector 311 via a Secure Digital Input Output (SDIO) bus. Various data and instructions may be stored in these memory devices. Further, it will be appreciated that fewer or additional memory devices, and different types of memory devices than those shown, may be utilized.
The processor may also utilize other devices not belonging to the further described subsystems. For example, in various embodiments, the system 300 may maintain a usage log based on the date and time reported by the real-time clock chip 312. In some embodiments, the processor 310 may record or monitor the temperature of the medicament or the temperature of the surrounding area as reported by the temperature sensor 313. In some embodiments, the temperature sensor 313 may be used by the processor 310 or other chip (not shown) to regulate the temperature to which the medicament is exposed. For example, the storage tank may be provided with a fan or other device for controlling the internal temperature. Processor 310 may be configured in these embodiments to control the fan in response to temperature sensor 313 reporting a temperature or time-temperature reading above some predetermined threshold. These features may be particularly useful in embodiments where the storage case is portable or may otherwise be subject to inconsistent climates. Further, as described above, the processor 310 may provide a debug or maintenance interface to other devices via the RS232 transceiver 317 and the connector 318.
As illustrated, in various embodiments, the system 300 may be powered on or awakened in response to detecting that the door has been opened. To provide this functionality, the door opening detection module 320 includes one or more proximity sensors 322 for detecting that the door has moved away from a closed position. This information may be transmitted to the processor via one or more GPIO lines. In various alternative embodiments, other devices such as a dedicated power button or one start-stop button 341 may be used in place of the proximity sensor 322.
To facilitate audio communication, the audio interaction unit 330 is in communication with the processor 330. That is, the audio interaction unit 330 includes an audio codec 332, and the audio codec 332 exchanges data with the processor 310 via a multi-channel audio serial port (McASP) and an integrated circuit (I2C) bus. The audio codec 332 then reproduces the audio data received from the processor 310 through the headphones 334 and the speaker 336, and digitizes the analog audio data received via the microphone 338. As will be appreciated, the processor may simply act as a pathway for such audio data, enabling data to be exchanged between the audio interaction unit and the connectivity unit 350. In other embodiments, the audio interaction unit 330 may be directly connected to the connectivity unit 350, thereby allowing the data to be communicated with a remote location without the processor 310 handling the data. For example, the audio interaction unit 330 may transmit and receive analog audio data via an RJ-11 connector. In some embodiments, this direct connection may be selectively enabled or disabled by the processor 310.
For additional types of local user interaction, the system 300 includes a user interface unit 340, the user interface unit 340 including various input and output devices. For example, the user interface unit 340 may include start and stop buttons 341 that may be used to initiate and interrupt operation of the system to connect to a remote site. Accordingly, the start and stop buttons 341 may provide signals to the processor 310 via one or more GPIO channels. Similarly, the processor may be configured to illuminate the status and active LED 343 by transmitting signals via 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 may output visual data (e.g., predefined instructions stored in the memory devices 311, 314, 315, 316) or information received via the connectivity module 350 to the LCD display 345 via the display interface. The processor 310 also receives any input received by the touch screen 347 through the touch screen interface. Various embodiments may also facilitate using the system in low light conditions by providing a backlight driver 349 for controlling the backlight of the LCD display 345, start-stop button 341, or other components. The processor may transmit an indication of the desired intensity of the backlight to the backlight driver 349 via the pulse width modulation channel.
The processor 310 is provided with the ability to communicate with remote devices via the connectivity module 350. As shown, the connectivity module 350 provides three communication channels. It will be appreciated that fewer or additional communication channels may be supported. As a first lane, the connectivity module includes an ethernet PHY chip 351, the ethernet PHY chip 351 enabling wired network communications via an ethernet connector 353, such as an RJ-45 connection. The processor 310 may pass data to and from the ethernet PHY chip via a Media Independent Interface (MII). To provide the second network channel, the connectivity module 350 includes a WiFi module 355, the WiFi module 355 including an antenna and a WiFi PHY chip. The processor 310 may pass data to and from the WiFi module 355 via the SDIO bus. The third channel provided by the connectivity module 350 is a landline POTS connection. Thus, the connectivity module 350 includes a direct voice access arrangement (DAA) chipset 357 that communicates with a telephone line via an RJ-11 connector 359. Processor 310 may communicate with voice DAA chipset 357 via SPI bus and McASP.
To effect release of the medicament, the processor 310 communicates with the medicament device dispense circuitry 360. In particular, the processor 310 may communicate with one or more solenoid interfaces 362, 364 or other interfaces for effecting dispensing of the medicament. In various embodiments, processor 310 communicates with each of solenoid interfaces 362, 364 via a general purpose IO channel, respectively.
In some embodiments, the various electronic circuits may include self-diagnostic or feedback capabilities. For example, self-diagnostic or feedback methods may be employed to monitor the status of the solenoid loop, monitor battery degradation, or monitor other critical functionality. Methods for implementing these capabilities will be apparent.
It will be appreciated that some of the devices that may be used to implement the exemplary system 300 may be omitted. For example, in an implementation of the system, a telephone line converter may be located 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. In addition, additional communication lines may be provided between the various chips. For example, the processor 310 may additionally transmit various signals other than display data to the LCD display 345, such as enable or read/write signals. Various additional implementation details that have been omitted will be apparent.
As noted, the medicament may be dispensed with or without packaging. In some embodiments, retention and release of the medicament may be facilitated by a separate cannula, case, or other device that contains or retains the medicament and provides other structural features for engagement with a medicament lock or other retaining structure of the storage case. Fig. 4 illustrates an exemplary cannula 400 for containing a medicament. The sleeve 400 may be made of virtually any material; in some embodiments, the cannula 400 is formed from Acrylonitrile Butadiene Styrene (ABS) plastic or other material that is sufficiently strong to withstand or absorb drop forces to preserve the integrity of any medicament contained within the cannula 400. The cannula includes a hollow cannula body 410, at least one opening 420 near at least one end, and a track 430 extending from an upper surface of the body 410. The opening is sized to receive a cartridge package of medicament. For example, a standard commercial cartridge package containing two epinephrine pens may be inserted through opening 420 and received within body 410. The track 430 is provided to engage a medicament lock or other retaining structure of the storage case, an example of which will be described below with reference to fig. 5.
It will be apparent that the sleeve 400 is one example, and that a variety of alternative structures may be used. For example, the sleeve may not include the opening 420, but may include a hinged engagement between two portions of the body such that the sleeve may be opened. As another example, a circular ring, magnet, or other structure or material suitable for engaging the particular retaining structure used may be used in place of track 430. Further, the body 410 may be formed in various shapes. For example, where the medicament is dispensed unpackaged, the body 410 may alternatively be a circular cannula or other shape structured to contain the medicament. In some embodiments, the body 410 may be omitted and the track 430 or other engagement structure may be directly attached to the medicament or medicament package via an adhesive, screw, or other attachment means, or may be integrally formed with the medicament or package. Various additional modifications will be apparent.
Fig. 5 illustrates a cross-section 500 of the exemplary medicament storage case 110 of fig. 1, viewed from the side, containing an exemplary actuator for selectively retaining and releasing the cannula. The case 110 provides front and rear surfaces that form an interior region 140 therebetween.
The cannula 400 containing the medicament 130 is suspended within the interior region 140 by a cannula track 430. As shown, the hook 510 is received under the track 430 such that the cannula 400 hangs from the hook 510. Holding the hook 510 in place at pivot point 512. For example, a rod, pin, or other structure may be inserted through the hook 510 at a pivot point 512, the pivot point 512 allowing the hook to rotate clockwise or counterclockwise (from the perspective of fig. 5). The weight of the cannula 400 and medicament 130 tends to force the hook to rotate clockwise; as can be seen, after the hook 510 is rotated clockwise sufficiently far, the track 430 will slide off the hook 510. No longer supported by the hook 510, the sleeve 400 will fall and fall onto the lower ledge for retrieval by the user. To counteract the downward force of the sleeve 400 against the hook 510, a spring of sufficient strength is disposed between the top portion of the hook 510 and the case 110. As such, the hook suspendedly holds the sleeve 400 when no other external force acts on the hook 510.
To effect release of the retaining structure, such as the hook 510 and spring 514, an actuator is provided that includes a solenoid 562 and a solenoid controller 362. As described above, the solenoid controller 362 receives an access signal from the processor and, in response, sends a current through the solenoid 562 sufficient to move the solenoid cylinder forward (to the right from the perspective of fig. 5) and to force a third force against the hook 512. The force of the solenoid 562, together with the downward force of the sleeve 400 and medicament 130, sufficiently high to counteract the force of the spring 514 and, in turn, cause the hook 510 to rotate and release the sleeve 400.
It will be apparent that the arrangement of figure 5 is only one example of a retaining structure and actuator for dispensing a medicament, and that numerous additional configurations are possible. For example, the sleeve 400 may be directly suspended from a solenoid cylinder that moves out of engagement with the sleeve 400 upon activation by the solenoid controller 362. In this embodiment, the components of the solenoid 562 may serve as both the retaining structure and the actuator. Similarly, in some embodiments, the solenoid cylinder may be in contact with or formed with another non-pivoting structure that moves linearly out of engagement with the sleeve 400. As another alternative, instead of suspending the cannula 400 or medicament 130, the cannula 400 or medicament 130 may rest together on a movable platform. After activation, the platform may retract or pivot such that the cannula 400 or medicament 130 is no longer supported and falls to the lower ledge 142.
It will also be appreciated that various arrangements may use actuators other than solenoids. For example, a servo motor or stepper motor may be used to control the angular position of the hook 510 or platform, or may be used to linearly retract another holding structure via one or more linkage structures (e.g., by winding a cable attached to the structure). As another example, where the retaining structure is an electromagnet, the actuator may be a controller adapted to cut off power to the magnet, thereby releasing the cannula 400 or medicament 130. Various other types of actuators will be apparent.
Further various other retaining structures and actuator arrangements may be utilized that deliver the medicament without dropping the medicament to a user accessible area. For example, the medicament 130 may be locked to the storage case by a ring or clip that is disposed around the medicament 130 and may be opened by a suitable actuator. As another example, the medicament 130 may be stored behind a locked door, such as a secondary door behind the main door 120, or behind the main door 120 in embodiments where a control, such as the activation button 111, is not also housed behind the main door, or in a locked drawer. The actuator in these embodiments may be used to unlock the door or drawer, allowing the user to open the door or drawer and access the medicament. Thus, in some embodiments, the actuator enables an active release of the medicament 130 such that the user may retrieve the medicament 130 directly after the release, while in other embodiments the actuator enables a passive release of the medicament 130 such that the user can manually move the retaining structure so that the medicament 130 may be used.
Fig. 6 illustrates an exemplary method 600 for contacting emergency services via a medicament storage case. The method 600 may be performed by a processor of the storage case 100, such as the processor 212 or the processor 310, and may be encoded as program instructions for execution by such a processor.
The method 600 begins in step 610 and proceeds to step 620 where the processor receives an indication that the start button has been pressed in step 620. This button press may be detected via a physical start button, such as button 111, or via a soft start button, such as may be displayed on a touch screen display, such as display 113. In various embodiments, step 620 consists of: the processor receives and recognizes the event at the event handler.
Next, in step 630, the processor initiates a landline call to the conforming emergency. For example, where the storage bin is located in the united states, the processor may be configured to place a telephone call to a 911 emergency service. During or after connecting to the conforming emergency, the processor transmits a set of predetermined information to the conforming emergency via a landline call. For example, the processor may transmit an indication that the call is from a medicament storage case, an indication that a voice session is not established with a local user, or the location of the storage case, which may be preprogrammed or determined via GPS or other means. Various additional or alternative information to be transmitted to the conforming emergency will be apparent. The information may be transmitted in any format, such as computer-rendered voice audio, facsimile data, or data otherwise encoded on an analog telephone signal.
Next, in step 650, the processor initiates a Voice Over IP (VOIP) call to the control center instead of the conforming emergency. For example, the control center may be operated by the same entity that provides, maintains, or is associated with the storage tank or the medicament contained therein. Furthermore, the storage bin may also transmit various predefined information, such as the location or identifier of the storage bin. The processor then exchanges audio data between the audio codec and the VOIP channel so that the local user can talk to an operator at the control center in step 660. As will be described below, the control center operator may transfer the call to a physician, after which the local user may talk to the physician. In step 670, the processor determines whether to end the VOIP call. For example, the processor may determine whether a stop button has been pressed, or whether the other end has closed the VOIP call. If not, the method 600 loops back to step 660 to continue exchanging audio data with the remote site. Otherwise, the processor proceeds to close the VOIP channel in step 680 and the method ends in step 690.
It will be appreciated that the method 600 is one example of operating a medicament storage case according to the systems and methods described herein, and that various alternative methods may be used. For example, step 670 may be accomplished by an event handler and detection of an event that will close the call. In some embodiments, a call to the emergency dispatch may not be placed, while in other embodiments, a call to 911 only may be placed, in which case the emergency dispatch is equipped to remotely control the dispensing of the medication, or to transfer the call to a physician or other entity so equipped. In other embodiments, the various steps of the method are performed in parallel. For example, step 620 may be split into two threads: a first thread having steps 630, 640 and a second thread having steps 650 to 680. In these embodiments, two calls may be placed simultaneously. Various other modifications will be apparent.
Fig. 7 illustrates an exemplary method 700 for allowing access to a medicament in response to a remote instruction. The method 700 may be performed by a processor of the storage case 100, such as the processor 212 or the processor 310, and may be encoded as program instructions for execution by such a processor.
The method begins in step 710 and proceeds to step 720 where the processor receives an unlock signal that is used as a dispense instruction in step 720. For example, the processor may receive a data packet that includes instructions to dispense a medicament. In step 730, the processor determines from the instructions an index of the medicament to be dispensed. In particular, in embodiments where the storage case is capable of dispensing a plurality of different medicaments and doses, the available medicaments may be indexed. For example, the adult epinephrine injector group may be indexed to "0" while the pediatric epinephrine injector group may be indexed to "1". The instruction received in step 720 may directly specify the index of the appropriate medicament or may specify only the medicament to be dispensed, in which case the processor determines the index of the identified medicament by, for example, a look-up table. In embodiments where only a single type of medicament may be dispensed, step 730 may be omitted.
In step 740, the processor sends an access signal to the actuator associated with the appropriate medicament. Moreover, this step may include: the index or medicament is correlated to the actuator by, for example, a look-up table. Upon receiving the access signal, the actuator releases the medicament for retrieval by the user. In various alternative embodiments, a single actuator may control the release of multiple medicants; in these embodiments, the processor may simply send an index or other identification of the desired medicament to the actuator, which in turn determines the appropriate action to dispense the requested medicament.
After dispensing the medicament, the processor locates the stored video instructions for the medicament or receives the instructions via the network interface. In step 750, the processor outputs the instructions via a display device, thereby using vision to augment any physician or other remote operator instructions. The method 700 then continues to end at step 760.
Fig. 8 illustrates an exemplary network environment 800 of a medicament storage case. As explained in detail above, the operation of the storage case 100 is controlled, at least in part, by a remote device, such as the control center device 820 or the physician device 830 via the internet 810 or other network. The control center device 820 or physician device 830 can be virtually any user device, such as a terminal, personal computer, tablet computer, mobile phone, or other device.
As illustrated, upon user activation, the storage box 100 initiates a VOIP call to a remote site, such as the control center 820 or a conforming emergency (not shown). The control center 820 may transfer the VOIP call to a physician on-site or on-hold, either immediately or at some time during the call. In some embodiments, the control center 820 may operate merely as an electronic dispatch that automatically forwards the call to the available physician device 830. In these embodiments, the control center 820 may be hosted within a cloud computing environment.
In addition to facilitating audio VOIP calls, the control center 820 or physician device 830 may also provide the remote operator with the ability to remotely release one or more medicaments at the storage bin 100. For example, the physician device 830 may run a mobile application that communicates audio data between the physician and the storage box and presents two buttons to the physician: a button to dispense an adult dosage form epinephrine injector; and a button to dispense the pediatric dosage form epinephrine injector. These buttons may cause the physician device to generate a release signal, e.g., a dispensing instruction packet, and transmit the release signal to the storage box 100 directly over the internet 810, either via the control center 820 or bypassing the control center 820. Similar functionality may be provided at the control center 820.
Various modifications and additional features will be apparent. For example, the control center 820 or physician device 830 may be further configured to support one or two-way video feeds with the storage box 100. As another alternative, the control center 820 or physician device 830 may enable a 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 a patient medical record repository, so that a remote operator can access the patient's medical history.
In some embodiments, the management system may also communicate with the storage bins 100 via the internet 810 or other network. For example, a separate server, personal computer, desktop computer, laptop computer, cloud virtual machine, or control center 820 may itself communicate with the storage bin to perform functions such as inventory management, call logging and entry, and other management functions.
Fig. 9 shows an exemplary hardware diagram 900 of a physician device or a control center device. In various embodiments, the exemplary hardware diagram 900 may also depict at least a portion of a storage box. As shown, hardware 200 includes a processor 920, a memory 930, a user interface 940, a network interface 950, and a storage 960 interconnected via one or more system buses 910. It will be appreciated that in some aspects, FIG. 9 constitutes an abstraction and that the actual organization of the components of hardware 900 may be more complex than that shown.
The network interface 950 may include one or more means for enabling communication with other hardware devices. For example, the network interface 950 may include a Network Interface Card (NIC) configured to communicate according to an ethernet protocol. Additionally, network interface 950 may implement a TCP/IP stack for communicating according to the TCP/IP protocol. Various alternative or additional hardware or configurations of the network interface 950 will be apparent.
It will be apparent that various information described as being stored in storage device 960 may additionally, or alternatively, be stored in memory 930. For example, the operating system 961 and the wall unit application 962 can be at least partially copied to the memory 930 for execution by the processor 920. In this regard, memory 930 can also be considered to constitute "storage", and storage 960 can be considered to be "memory". Various other arrangements will be apparent. Further, both memory 930 and storage 960 may be considered "non-transitory machine-readable media". As used herein, the term "non-transitory" will be understood to exclude transitory signals, but will include all forms of storage, including both volatile and non-volatile memory.
Although hardware 900 is shown to contain one of each of the described components, in various embodiments various components may be duplicated. For example, the processor 920 may include multiple microprocessors configured to independently perform, or configured to perform, the steps or routines of the methods described herein, such that the multiple processors cooperate to achieve the functionality described herein.
Having described exemplary hardware and functionality of the physician apparatus, exemplary user interfaces and related functionality of the physician apparatus will now be described with reference to fig. 10-20. As will be appreciated, various interfaces may be generated by the storage box application 962 and displayed via the user interface 940. Various modifications will be apparent.
Fig. 10 shows an exemplary user interface 1000 for authenticating a physician user. As shown, the interface includes fields 1010, 1020 for receiving a username and password, respectively. Upon selection of one of the fields 1010, 1020, the user may be provided with an interface for entering an alphanumeric value, such as a soft keyboard interface provided by the operating system. The interface also includes a login button 1030 to confirm entry of the username and password. Upon selection of the login button 1030, the entered credentials may be verified by comparing the credentials with locally stored credentials or by authenticating by sending the credentials to another server, such as a control center device. The application may enter the home screen when an indication is received or it is determined that the user is authenticated.
Fig. 11 illustrates an exemplary user interface 1100 for presenting a home screen. Home screen interface 1100 may present a navigation bar that includes a home button 1110 for accessing the home screen (shown as selected), a call log button 1120 for accessing a call log, and a settings button 1130 for accessing settings menus. While in the home screen interface 1100 (and potentially on other interfaces after login), the application may receive an incoming call. In particular, the control center or the medicament storage case may send a request to the physician device to establish a communication session.
Fig. 12 illustrates an exemplary user interface 1200 for displaying an indication of an incoming communication request. The incoming request interface 1200 may be displayed in response to the physician device receiving an incoming request to establish a communication session from, for example, a control center device or a medicament storage case. The incoming request interface 1200 includes an indication 1210 of a medicament storage bin associated with the incoming request. The user is also presented with two buttons: an answer button 1220 for approving the incoming request and a reject button 1230 for rejecting the incoming request. Upon selection of the decline button 1230, the application may return to the main screen or to another screen previously displayed prior to receiving the incoming request. Upon selection of the answer button 1220, the application may display an active communication session screen.
Fig. 13 illustrates an exemplary user interface 1300 for display during a communication session. The application may also provide at least one audio communication session via the device hardware when the active session interface 1300 is displayed. In other words, the user may be able to communicate with the calling medicament storage case via a VOIP session through the speaker and microphone of the physician device. The active session interface 1300 includes a menu 1310 that includes a plurality of buttons. As will be explained in more detail below, the menu 1310 may include buttons for switching video streams, muting a microphone, placing a call on hold, accessing a text message interface, and accessing an assignment interface. The active session interface 1300 additionally includes an end call button 1320 to end the active session and return to the main screen or to another screen previously displayed prior to receiving the incoming request.
Fig. 14 shows an exemplary user interface 1400 for displaying patient videos and sending test messages. As shown, the video button on menu 1310 has been selected, thus displaying video stream 1410. The video stream 1410 may be received from an attached medicament storage tank or from a control center device. For example, when a video button is pressed, the application may start reproducing the video data that has started to be transmitted by the connected storage box, or may transmit an instruction to the storage box to start transmitting the video data. As further shown, the hold button of menu 1310 is also shown as selected, indicating that the communication has been held, and that no communication will be received or sent until the hold is cancelled.
Fig. 15 shows an alternative user interface 1500 for displaying patient video. For example, when a video feed is activated and the physician rotates the phone 90 degrees, an alternate user interface 1500 may be displayed. The application may access the operating system to determine the current position of the physician device and switch to the backup interface 1500 if the physician device remains substantially landscape. As shown, the alternative interface presents the video stream in a full screen 1510. It will be apparent that various alternative arrangements are possible. For example, a menu similar to menu 1310 may be displayed on video region 1510. When the physician device is rotated back to the generally longitudinal orientation, the application may be converted back to the previous interface, such as interface 1400.
Fig. 16 shows an exemplary user interface 1600 for displaying a dispense button for dispensing medication to a patient. As shown, menu 1310 represents that an assign button has been selected. Accordingly, a plurality of dispense interface elements 1610, 1620, 1630 are displayed as part of interface 1600. The interface 1600 includes two dispense buttons 1610, 1620 associated with the medicaments available for dispensing from an attached medicament storage case. It will be appreciated that fewer or additional buttons may be included in various embodiments. In some embodiments, the connected storage bin may send information identifying available medications to the physician device, as well as other information such as expiration dates. The interface 1600 may 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 signature. For example, some states may specify a physician signature that requires any prescription. Upon entering a signature or pressing an assignment button, the physician device may store or send an image, text or other representation of the signature to the control center.
As shown, the interface 1600 identifies two medicaments that may be dispensed from a connected reservoir. The first button 1610 indicates that a "pediatric epinephrine (jr. epipen)" medicament is available with an expiration date of 2015, 12 months, 20 days. The second button 1620 indicates that an "adult-sized epinephrine (sr. epipen)" medicament having an expiration date of 2015, 2, month, 15 is available. Upon selection of one of the buttons 1610, 1620, the physician device sends instructions to the connected storage bin to dispense the relevant medicament. For example, a connected storage case may send an index (index) or other identifier for each medicament at the same time that the available medicaments are sent. Then, when the button is selected, the application may send instructions including an identifier associated with the selected medicament. The interface 1600 also includes a cancel button 1630 to return to a previous interface that did not include the dispense elements 1610, 1620, 1630.
Fig. 17 shows an alternative user interface 1700 for displaying an dispense button for dispensing medication to a patient. In some embodiments, button 1720 may be displayed as non-selectable when the associated medicament is not available. As shown, the connected storage bin is unable to dispense "adult epinephrine" medicament, and therefore button 1720 is displayed as being non-selectable. For example, the application may determine that a medicament is unavailable when it is desired that the medicament is available for use by the application but an unconnected storage bin is reported as available, or when the storage bin explicitly reports the medicament as unavailable. In various alternative embodiments, interface 1700 may instead simply omit displaying any buttons for unavailable medications.
Fig. 18 illustrates an exemplary user interface 1800 for displaying a log of previous communication sessions. Call history interface 1800 may be accessed by selecting call history button 1120 on a navigational menu. As shown, the call history interface displays a plurality of entries 1810, 1820, 1830, 1840 that identify all previous incoming requests, or alternatively, all accepted incoming requests. Upon selection of an entry 1810, 1820, 1830, 1840, the application may be displayed in an interface for displaying or entering additional information for the call.
Fig. 19 shows an exemplary user interface 1900 for receiving physician notes regarding a communication session. The remarks interface 1900 may be accessed by selecting an entry 1810, 1820, 1830, 1840 from the call history interface 1800. As shown, interface 1900 includes call details 1910 and a text field 1920 for receiving physician notes. Upon selection, the text field 1920 may provide an interface element, such as an OS soft keyboard, to the physician for entering text. The interface 1900 also includes a send button 1930 for sending text in the text field 1920 to the command center device for storage in association with the call record. Upon selection, the cancel button 1940 causes the application to return to, for example, the previous screen of 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 signature. For example, some states may have a doctor signature that specifies that any prescription is required. Upon entering a signature or pressing send button 1930, the physician device can store or send an image, text, or other representation of the signature to the control center.
Fig. 20 illustrates an exemplary method 2000 for communicating with a medicament storage case. Method 2000 may be performed by a physician apparatus, such as components of physician apparatus 900. The method starts in step 2005 and proceeds to step 2010, where in step 2010 the device receives an incoming request to establish a communication session. Based on the received request, the apparatus displays an indication of an entry request in step 2015, e.g., in interface 1200. In step 2020, the apparatus determines whether the physician user has accepted the request. If not, the device sends a rejection message to the control center or the medicament storage tank in step 2025. The control center or the medicament storage case may then attempt to locate another physician device to which to send the request and possibly establish a communication session. The method continues to end in step 2055.
However, if the physician accepts the incoming request in step 2020, the method proceeds to step 2030, where in step 2030 the device establishes a two-way communication session with the medication dispenser. Then, in step 2035, the apparatus displays one or more assignment buttons, e.g., in response to a user request to display buttons, as described above. The device then determines whether the physician has pressed the dispense button in step 2040. If not, the method jumps to step 2050. If the physician does press the dispense button, then in step 2045 the device sends an instruction to dispense the relevant medicament to the user. In step 2050, the device determines whether the session has been terminated by, for example, a local user or a user of a remote medication dispenser. If not, the method loops back to step 2040 to continue checking the assignment button selected by the physician. Otherwise, the method continues to end in step 2055.
Various modifications to the above-described method will be apparent in view of the additional functionality of the physician device described herein. For example, the method 2000 may include additional subsidies for interpreting incoming data describing available medications, muting or holding a call, sending a text message, and displaying a video stream. Various additional modifications will be apparent.
In light of the foregoing, various exemplary embodiments enable physicians to prescribe and provide quick access to medications at remote locations. For example, by providing a physician device application capable of establishing an audio or video communication session and sending dispensing instructions to a remote medicament dispenser, qualified personnel can adequately assess an emergency condition and effect the provision of a medicament deemed necessary or helpful for the therapeutic situation. Various other benefits will be apparent in view of the foregoing description.
It should be apparent from the foregoing description that various exemplary embodiments of the present invention may be implemented in hardware and/or firmware. Further, various exemplary embodiments may be implemented as instructions stored on a machine-readable storage medium, which may be read and executed by at least one processor to perform the operations described in detail herein. A machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal computer or laptop, a server, or other computing device. Thus, a machine-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media.
It will be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in machine readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
While various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects thereof, it should be understood that the invention is capable of other embodiments and its details are capable of modifications in various obvious respects. As will be readily apparent to those skilled in the art, variations and modifications can be made while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only and do not in any way limit the invention, which is defined only by the claims.
Claims (17)
1. A non-transitory machine-readable storage medium encoded with instructions for execution by a user device, the medium comprising:
instructions for displaying an indication of an incoming request to establish a communication session with a patient operating a medication dispenser configured to store and dispense a plurality of medications that are different from one another;
instructions for establishing a two-way communication session with the patient via the medication dispenser based on approval of the incoming request by a physician user of the user device;
instructions for displaying a dispense button for a plurality of medications during the two-way communication session;
instructions for receiving a selection of any of the assignment buttons from the physician user; and
instructions for sending a command for the medication dispenser to dispense medication associated with the dispense button to the patient based on the selection.
2. The non-transitory machine-readable storage medium of claim 1, further comprising:
instructions for obtaining medication data describing the plurality of medications, the plurality of medications being available via the medication dispenser; and
instructions for displaying an indication of the medication data in association with the plurality of dispense buttons.
3. The non-transitory machine-readable storage medium of claim 2, wherein the medication data comprises an expiration date for the medication.
4. The non-transitory machine-readable storage medium of claim 1, further comprising:
instructions for receiving medication information indicating whether the plurality of medications are available for allocation to the patient, wherein:
the instructions for displaying a dispense button for a plurality of medications include: when any of the medication information indicates that any of the medications is not available for dispensing to the patient, displaying a dispense button for the medication as a non-selectable instruction, an
The instructions for receiving a selection of the any one of the dispense buttons from the physician user are configured to be performed based on the medication information indicating that the medication is available for dispensing to the patient.
5. The non-transitory machine-readable storage medium of claim 1, further comprising:
instructions for receiving a video data stream from the medication dispenser via the bi-directional communication session; and
instructions to display video to the physician user based on the video data.
6. The non-transitory machine-readable storage medium of claim 1, further comprising:
instructions for receiving entry of a message from the physician user; and
instructions for sending a command for the medication dispenser to display the entered message to the patient.
7. 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 plurality of medications associated with the medication dispenser;
displaying dispense buttons for the plurality of medications, the dispense button for each medication representing a medication for selection by the physician user;
sending a command for the remote medication dispenser to dispense a medication associated with either dispense button to the patient based on selection of the dispense button.
8. The method of claim 7, wherein the received medication information includes an expiration date, the method further comprising: displaying the validity period in association with the plurality of allocation buttons.
9. The method of claim 7, wherein the received information indicates whether the plurality of medications are available for dispensing by the remote medication dispenser, the method further comprising:
displaying an indication that any of the medications is unavailable for dispensing based on the received information indicating that the medication is unavailable for dispensing; and
disabling selection of the dispense button based on the received information indicating that any of the medications is not available for dispensing.
10. The method of claim 7, further comprising:
receiving a video data stream from the remote medication dispenser; and
displaying video to the physician user based on the video data.
11. The method of claim 7, further comprising:
receiving entry of a message from the physician user; and
sending a command for the remote medication dispenser to display the entered message to the patient.
12. A portable communication device for use by a physician user, the portable communication device comprising:
a communication interface;
a display device;
a touch input device;
a memory; and
a processor in communication with the memory, wherein the processor is configured to:
displaying, via the display device, an indication of an incoming request to establish a communication session with a patient operating a medication dispenser configured to store and dispense a plurality of medications that are different from one another;
establishing a two-way communication session with the patient via the communication interface and the medication dispenser based on approval of the incoming request by a physician user of the user device;
displaying, via the display device, a dispense button for a plurality of medications during the two-way communication session;
receiving a selection of any of the assignment buttons from the physician user via the touch input device; and
sending, via the communication interface and based on the selection, a command for the medication dispenser to dispense the medication associated with the dispense button to the patient.
13. The portable communication device of claim 12, wherein the processor is further configured to:
obtaining medication data describing the plurality of medications available via the medication dispenser; and
displaying, via the display device, an indication of the medication data in association with the plurality of dispense buttons.
14. The portable communication device of claim 13, wherein the medication data includes an expiration date for the medication.
15. The portable communication device of claim 12, wherein the processor is further configured to:
receiving medication information indicating whether the medication is available for allocation to the patient, wherein:
in displaying dispense buttons for a plurality of medications, the processor is configured to display the dispense button with the medication as non-selectable when any of the medication information indicates that any of the medications is not available for dispensing to the patient, and
the processor is configured to accept a selection of an dispense button for the medication from the physician user based on any of the medication information indicating that any of the medications is available for dispensing to the patient.
16. The portable communication device of claim 12, wherein the processor is further configured to:
receiving a video data stream from the medication dispenser via the bi-directional communication session; and
displaying video to the physician user via the display device based on the video data stream.
17. The portable communication device of claim 12, wherein the processor is further configured to:
receiving entry of a message from the physician user; and
sending a command for the medication dispenser to display the entered message to the patient.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/575,477 | 2014-12-18 | ||
| US14/575,477 US9643770B2 (en) | 2012-12-03 | 2014-12-18 | System and method for medicament storage, dispensing, and administration |
| PCT/US2015/063808 WO2016099934A1 (en) | 2014-12-18 | 2015-12-03 | System and method for medicament storage, dispensing, and administration |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107408145A CN107408145A (en) | 2017-11-28 |
| CN107408145B true CN107408145B (en) | 2021-01-08 |
Family
ID=55085888
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201580074665.XA Expired - Fee Related CN107408145B (en) | 2014-12-18 | 2015-12-03 | System and method for medicament storage, dispensing and administration |
Country Status (8)
| Country | Link |
|---|---|
| EP (1) | EP3234836A1 (en) |
| JP (2) | JP2018504951A (en) |
| CN (1) | CN107408145B (en) |
| AR (1) | AR103074A1 (en) |
| AU (1) | AU2015363073A1 (en) |
| CA (1) | CA2971386A1 (en) |
| TW (1) | TWI678678B (en) |
| WO (1) | WO2016099934A1 (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140155827A1 (en) | 2012-12-03 | 2014-06-05 | Mylan, Inc. | Medicament information system and method |
| US9643770B2 (en) | 2012-12-03 | 2017-05-09 | Mylan Inc. | System and method for medicament storage, dispensing, and administration |
| GB2565978B (en) | 2016-06-06 | 2022-03-02 | E3D Agricultural Cooporative Association Ltd | Multiple use computerized injector |
| WO2020251960A1 (en) * | 2019-06-09 | 2020-12-17 | Banov Jacob | Device and system for remote regulation and monitoring of drug delivery and method of same |
| JP7413816B2 (en) | 2020-02-14 | 2024-01-16 | ニプロ株式会社 | Medication management system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1761965A (en) * | 2003-03-18 | 2006-04-19 | Shl医药公司 | System and method for presenting and distributing medication information |
| CN1811782A (en) * | 2004-09-16 | 2006-08-02 | 西门子医疗健康服务公司 | Medical order management system and user interface |
| CN103339663A (en) * | 2010-12-06 | 2013-10-02 | 欧美尼赛尔有限公司 | Medication dispensing cart |
| US8670865B2 (en) * | 2009-06-02 | 2014-03-11 | One World DMG, Ltd. | Interactive medicine organizer |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080059228A1 (en) * | 2004-04-24 | 2008-03-06 | Christopher Bossi | Operation Of A Remote Medication Management System |
| TWI257560B (en) * | 2004-09-14 | 2006-07-01 | Softnext Technologies Co Ltd | Medicine online information system of union pharmacy |
| US8753308B2 (en) * | 2006-01-06 | 2014-06-17 | Acelrx Pharmaceuticals, Inc. | Methods for administering small volume oral transmucosal dosage forms using a dispensing device |
| US8818552B2 (en) * | 2007-07-10 | 2014-08-26 | Carefusion 303, Inc. | Point-of-care medication dispensing |
| AR092077A1 (en) * | 2012-08-10 | 2015-03-18 | Sanofi Aventis Deutschland | MEDICAL SYSTEM |
| TWM482128U (en) * | 2013-12-17 | 2014-07-11 | Internat Mobile Iot Corp | Health care system based on internet of things |
-
2015
- 2015-12-03 JP JP2017532100A patent/JP2018504951A/en active Pending
- 2015-12-03 EP EP15823421.1A patent/EP3234836A1/en not_active Withdrawn
- 2015-12-03 WO PCT/US2015/063808 patent/WO2016099934A1/en active Application Filing
- 2015-12-03 AU AU2015363073A patent/AU2015363073A1/en not_active Abandoned
- 2015-12-03 CN CN201580074665.XA patent/CN107408145B/en not_active Expired - Fee Related
- 2015-12-03 CA CA2971386A patent/CA2971386A1/en not_active Abandoned
- 2015-12-17 AR ARP150104148A patent/AR103074A1/en unknown
- 2015-12-17 TW TW104142544A patent/TWI678678B/en not_active IP Right Cessation
-
2020
- 2020-08-24 JP JP2020140612A patent/JP2020205069A/en not_active Withdrawn
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1761965A (en) * | 2003-03-18 | 2006-04-19 | Shl医药公司 | System and method for presenting and distributing medication information |
| CN1811782A (en) * | 2004-09-16 | 2006-08-02 | 西门子医疗健康服务公司 | Medical order management system and user interface |
| US8670865B2 (en) * | 2009-06-02 | 2014-03-11 | One World DMG, Ltd. | Interactive medicine organizer |
| CN103339663A (en) * | 2010-12-06 | 2013-10-02 | 欧美尼赛尔有限公司 | Medication dispensing cart |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107408145A (en) | 2017-11-28 |
| TWI678678B (en) | 2019-12-01 |
| TW201633250A (en) | 2016-09-16 |
| JP2018504951A (en) | 2018-02-22 |
| AU2015363073A1 (en) | 2017-07-13 |
| JP2020205069A (en) | 2020-12-24 |
| EP3234836A1 (en) | 2017-10-25 |
| CA2971386A1 (en) | 2016-06-23 |
| WO2016099934A1 (en) | 2016-06-23 |
| AR103074A1 (en) | 2017-04-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9643770B2 (en) | System and method for medicament storage, dispensing, and administration | |
| AU2015264706B2 (en) | System and method for medicament storage, dispensing, and administration | |
| CN107408145B (en) | System and method for medicament storage, dispensing and administration | |
| US11728021B2 (en) | Pill dispenser | |
| EP3556341B1 (en) | System, method, and apparatus for dispensing oral medications | |
| US12016828B2 (en) | Medication dispensing system | |
| JP6156749B2 (en) | Biometric electronic communication drug dispenser | |
| JP2018504951A5 (en) | ||
| WO2011054000A1 (en) | Smart medicament management methods and devices | |
| US20230335250A1 (en) | Pill dispenser |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20210108 Termination date: 20211203 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |