U.S. patent application number 15/047332 was filed with the patent office on 2017-01-19 for systems and methods for medical dispensing, management and monitoring.
The applicant listed for this patent is Ahkeo Labs, LLC. Invention is credited to Brent M. Skoda.
Application Number | 20170017774 15/047332 |
Document ID | / |
Family ID | 57776147 |
Filed Date | 2017-01-19 |
United States Patent
Application |
20170017774 |
Kind Code |
A1 |
Skoda; Brent M. |
January 19, 2017 |
SYSTEMS AND METHODS FOR MEDICAL DISPENSING, MANAGEMENT AND
MONITORING
Abstract
The present disclosure relates to a system for medical
dispensing, management and monitoring. According to one aspect, a
remote medical management environment can include a medical
management system intermediary to a plurality of patients and a
plurality of medical care providers. The medical management system
can communicate with medical dispensing devices configured to
dispense medication to patients. Further, the medical management
system can communicate with provider devices through which medical
care providers can access medicine related information of patients
and provide instructions, which can administer treatment protocols
to patients of the medical dispensing devices. The remote medical
management environment can allow medical care providers, such as
doctors, the ability to remotely manage and administer medications
to patients, while at the same time, avoid accidental medicinal
drug use and abuse by patients.
Inventors: |
Skoda; Brent M.; (Irving,
TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Ahkeo Labs, LLC |
Mayfield Village |
OH |
US |
|
|
Family ID: |
57776147 |
Appl. No.: |
15/047332 |
Filed: |
February 18, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62118341 |
Feb 19, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/42 20130101;
H04L 67/18 20130101; H04L 67/025 20130101; G16H 40/63 20180101;
G16H 20/13 20180101; G16H 40/67 20180101; G06F 19/3456 20130101;
H04L 67/10 20130101; H04L 67/02 20130101; H04L 67/1097 20130101;
G06F 19/324 20130101; H04L 67/12 20130101; H04L 67/28 20130101 |
International
Class: |
G06F 19/00 20060101
G06F019/00; H04L 29/06 20060101 H04L029/06; H04L 29/08 20060101
H04L029/08 |
Claims
1. A system, comprising: a processor and a memory including
computer-executable instructions, which when executed by the
processors, causes the processor to: establish, via a network, a
first connection with a first device and a second connection with a
second device; receive, via the network, one or more packets
including a payload that includes data measured via one or more
sensors of the second device; transmit, via the network, the data
measured via the one or more sensors of the second device to the
first device; receive, via the network, a request to securely
transmit instructions to a third device, the instructions
identifying the second device.
Description
RELATED APPLICATION
[0001] The present application claims priority to and the benefit
of U.S. Provisional Application No. 62/118,341, titled "Systems and
Methods for Medical Dispensing, Management and Monitoring" and
filed on Feb. 19, 2015, which is incorporated herein by reference
in its entirety for all purposes.
FIELD OF THE DISCLOSURE
[0002] The present application relates generally to systems and
methods for medical dispensing, management and monitoring, and more
particularly, to methods and systems for providing medical care
providers the ability to remotely manage and monitor the
administering of medications to patients via remotely controlled
medical dispensing devices.
BACKGROUND
[0003] Patients in need of medication either have to visit
pharmacies to pick up medication or have the medicines delivered to
them. Oftentimes, doctors treating these patients are unable to
gauge the efficacy of the medications they prescribe until the
patient either returns to the clinic for follow up testing or goes
to a laboratory for blood work.
SUMMARY
[0004] The present disclosure relates to systems and methods for
medical dispensing, management and monitoring. According to one
aspect, a remote medical management environment can include a
medical management system intermediary to a plurality of patients
and a plurality of medical care providers. The medical management
system can communicate with medical dispensing devices configured
to dispense medication to patients. Further, the medical management
system can communicate with provider devices through which medical
care providers can access medicine related information of patients
and provide instructions, which can administer treatment protocols
to patients of the medical dispensing devices. The remote medical
management environment can allow medical care providers, such as
doctors, the ability to remotely manage and administer medications
to patients, while at the same time, avoid medicinal drug abuse by
patients.
[0005] The medical management system can include a processor and a
memory including instructions configured to cause the medical
management system to allow a medical care provider to remotely
manage and administer medications to one or more patients. The
medical management system includes a patient database, a provider
database, a medical manager and a prescription manager. The medical
management system can include one or more communication modules
through which the medical management system can communicate with
patient devices and provider devices.
[0006] The patient device, otherwise referred to as a medical
dispensing device can be configured to allow a medical care
provider, for example, a doctor, the ability to remotely monitor,
regulate and manipulate medication administration to a patient
associated with the patient device. Through the medical dispensing
device, the medical care provider can adjust either the dosage of
medications or the time at which the medication is administered. In
some implementations, the medical care provider may receive
feedback through the medical dispensing device or other medical
device monitoring the patient and adjust the dosage or time at
which to administer medication based on the received feedback. The
medical dispensing device can be equipped with a communications
module that is configured to communicate with the medical
management system through which the medical care provider can
remotely communicate with the medical dispensing device. The
communications module can include both hardware and software
components that allow the medical dispensing device to receive and
transmit instructions and information. In some implementations, the
communications module can be configured to provide wireless
communications, for example, BLUETOOTH, WiFi, cellular
communications, among others. In some implementations, the
communications module can be configured to communicate with another
device, such as a smartphone, tablet, or other device that allows
the medical dispensing device to receive and execute instructions
received from the medical care provider. The medical dispensing
device can include one or more electronic actuators that can be
configured or programmed to control the amount of medication
dispensed from the medical dispensing device.
[0007] In some implementations, the medical dispensing device is
programmable and capable of maintaining activity logs. The activity
logs can identify a date and time at which medication was
dispensed, a dosage of medication dispensed as well as any other
physiological measurements, for example, temperature, pulse, heart
rate, blood pressure, sugar levels, among others, taken around the
time the medication was dispensed. In addition to medication
dispensing related activity, the activity logs can identify when a
medical care provider communicated with the medical dispensing
device. In some implementations, the activity logs can include
information related to dosage changes as well as changes in the
time at which medication is to be administered.
[0008] The medical dispensing device can also include sensors
measuring a quantity of medication remaining in the medical
dispensing device. In some implementations, the medical dispensing
device an determine an amount of medication remaining in the
medical dispensing device based on the amount of medication
included in a medicine cartridge and an amount of medication
already dispensed since the medicine cartridge was first inserted.
The medical dispensing device can be configured to communicate
medicine quantity levels such that refills can be ordered before
the medicine cartridge is completely empty.
[0009] The medical dispensing device can be tamper proof. This is
to prevent medication abuse and fraud. In some implementations, the
medical dispensing device can include an alert system that triggers
an alert upon determining that the medical dispensing device has
been tampered or an attempt to tamper the medical dispensing device
was made. In some implementations, the medical dispensing device
can include one or more security modules. The security modules can
include hardware and software to ensure that the medication is
dispensed to an authorized user or patient. In some
implementations, the medical dispensing device can include a user
recognition or identification system. In some implementations, the
medical dispensing device can include a fingerprint reader, an iris
scanner, or any other biometric scanner to confirm the identity of
the user. In some implementations, the medical dispensing device
can be password protected. In some implementations the medical
dispensing device can only be actuated via a second device, such as
a smartphone or tablet, registered with the medical management
system.
[0010] In some implementations, the medical dispensing device can
include a temperature control module to control the temperature of
medication within the medical dispensing device. In this way, if
the medicine in the medical dispensing device is to be maintained
at a particular temperature, and the medical dispensing device is
in a location that has an ambient temperature much higher than the
temperature at which to maintain the medicine, the medical
dispensing device can provide cooling to the medication.
Conversely, the medical dispensing device can provide heating to
medications that are supposed to be stored or maintained at
temperatures higher than the ambient temperature at which the
medical dispensing device is located.
[0011] In some implementations, the medical dispensing device can
be a programmable, remotely controlled prescription drug bottle.
The medical dispensing device may include Bluetooth, RFID, GPS, a
battery, a controller, a cellular chip, etc. The medical dispensing
device could dispense pills, liquid, powder, any vaporizable
substance, collectively, respectively, and independently. The
medical dispensing device can be configured to provide the ability
to remotely regulate, monitor, control and/or verify dosage. In
this way, a medical care provider can regulate or control the
number of pills dispensed, the time at which they are dispensed and
the location at which they can be dispensed, among others. For
instance, if the pills can only be dispensed within a particular
geographic location identifiable via cellular triangulation
techniques, IP addressing, or GPS coordinates, the risk of drug
abuse, theft, resale, and redistribution can be minimized. In some
implementations, the medical dispensing device can be configured to
only dispense medications when it is within a few feet from a
stationary object, such as a RFID scanner or Bluetooth source that
may be tied to a particular location.
[0012] In some implementations, the medical dispensing device may
be configured to communicate with a mobile device of the patient to
verify the identity of a person accessing or requesting access to
the medical dispensing device. For instance, the medical dispensing
device may only dispense medication in response to receiving a
communication or signal from a paired mobile device that can
generate the communication or signal upon verifying the identity of
the patient. In some implementations, the mobile device can verify
the identity of the patient through facial recognition, fingerprint
scanning, passwords, or other security measures that can be
received, identified or otherwise incorporated via the mobile
device. In this way, there is no need for the medical dispensing
device to be designed with an integrated fingerprint scanner,
camera to detect facial recognition, or keypad to receive a
password from the patient, thereby reducing manufacturing costs of
the medical dispensing device.
[0013] In some implementations, the location of the medical
dispensing device or the mobile device with which the medical
dispensing device can communicate may be monitored. In some
implementations, the medical dispensing device can restrict the
dispensing of medications based on one or more predetermined
locations. In some implementations, one or more location based
policies can be established to ensure additional security. For
instance, the medical dispensing device may be configured to only
dispense the medicine at predetermined locations, for example, a
patient's home, a patient's work location, a nursing home, a
hospital or other medical care provider's address, among others. In
this way, if the device is stolen or otherwise provided to an
unauthorized user, the unauthorized user may be unable to receive
medication from the medical dispensing device at locations
different from the predetermined locations. In addition, the
medical dispensing device may only transmit or receive data from
the medical management system at the predetermined locations to
reduce security breaches.
[0014] In some implementations, the medical dispensing device can
operate using batteries. In some implementations, the batteries may
be rechargeable or disposable. In some implementations in which the
batteries are rechargeable, the batteries may be charged via a USB
cable, via a power supply channel, or via wireless induction. In
some implementations, to implement wireless induction, the medical
dispensing device can be incorporated with a wireless charging
coil, for example, a wireless charging coil supplied by DIGIKEY and
manufactured by Wurth Electronics, Inc. In some implementations,
the wireless charging coil can be Part Number 76030811,
manufactured by Wurth Electronics, Inc. The shape, size and
position of the one or more wireless charging coils can be designed
to fit within the medical dispensing device.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1A is a block diagram depicting an embodiment of a
network environment comprising local devices in communication with
remote devices.
[0016] FIGS. 1B-1D are block diagrams depicting embodiments of
computers useful in connection with the methods and systems
described herein.
[0017] FIG. 2 is a block diagram depicting a medical management
environment including a medical management system intermediary to a
plurality of provider devices and patient devices.
[0018] FIG. 3 is a block diagram depicting a patient device
configured to dispense medication to a patient.
[0019] FIG. 4 is a block diagram depicting a provider device
configured to allow a medical care provider to manage medications
of patients receiving medication through the patient device of FIG.
3.
DETAILED DESCRIPTION
[0020] For purposes of reading the description of the various
embodiments below, the following descriptions of the sections of
the specification and their respective contents may be helpful:
[0021] Section A describes a network environment and computing
environment which may be useful for practicing embodiments
described herein.
[0022] Section B describes embodiments of systems and methods for
medical dispensing, management and monitoring.
A. Computing and Network Environment
[0023] In addition to discussing specific embodiments of the
present solution, it may be helpful to describe aspects of the
operating environment as well as associated system components
(e.g., hardware elements) in connection with the methods and
systems described herein. Referring to FIG. 1A, an embodiment of a
network environment is depicted. In brief overview, the network
environment includes one or more clients 102a-102n (also generally
referred to as local machine(s) 102, client(s) 102, client node(s)
102, client machine(s) 102, client computer(s) 102, client
device(s) 102, endpoint(s) 102, or endpoint node(s) 102) in
communication with one or more servers 106a-106n (also generally
referred to as server(s) 106, node 106, or remote machine(s) 106)
via one or more networks 104. In some embodiments, a client 102 has
the capacity to function as both a client node seeking access to
resources provided by a server and as a server providing access to
hosted resources for other clients 102a-102n.
[0024] Although FIG. 1A shows a network 104 between the clients 102
and the servers 106, the clients 102 and the servers 106 may be on
the same network 104. In some embodiments, there are multiple
networks 104 between the clients 102 and the servers 106. In one of
these embodiments, a network 104' (not shown) may be a private
network and a network 104 may be a public network. In another of
these embodiments, a network 104 may be a private network and a
network 104' a public network. In still another of these
embodiments, networks 104 and 104' may both be private
networks.
[0025] The network 104 may be connected via wired or wireless
links. Wired links may include Digital Subscriber Line (DSL),
coaxial cable lines, or optical fiber lines. The wireless links may
include BLUETOOTH, Wi-Fi, Worldwide Interoperability for Microwave
Access (WiMAX), an infrared channel or satellite band. The wireless
links may also include any cellular network standards used to
communicate among mobile devices, including standards that qualify
as 1G, 2G, 3G, or 1G. The network standards may qualify as one or
more generation of mobile telecommunication standards by fulfilling
a specification or standards such as the specifications maintained
by International Telecommunication Union. The 3G standards, for
example, may correspond to the International Mobile
Telecommunications-2000 (IMT-2000) specification, and the 1G
standards may correspond to the International Mobile
Telecommunications Advanced (IMT-Advanced) specification. Examples
of cellular network standards include AMPS, GSM, GPRS, UMTS, LTE,
LTE Advanced, Mobile WiMAX, and WiMAX-Advanced. Cellular network
standards may use various channel access methods e.g. FDMA, TDMA,
CDMA, or SDMA. In some embodiments, different types of data may be
transmitted via different links and standards. In other
embodiments, the same types of data may be transmitted via
different links and standards.
[0026] The network 104 may be any type and/or form of network. The
geographical scope of the network 104 may vary widely and the
network 104 can be a body area network (BAN), a personal area
network (PAN), a local-area network (LAN), e.g. Intranet, a
metropolitan area network (MAN), a wide area network (WAN), or the
Internet. The topology of the network 104 may be of any form and
may include, e.g., any of the following: point-to-point, bus, star,
ring, mesh, or tree. The network 104 may be an overlay network
which is virtual and sits on top of one or more layers of other
networks 104'. The network 104 may be of any such network topology
as known to those ordinarily skilled in the art capable of
supporting the operations described herein. The network 104 may
utilize different techniques and layers or stacks of protocols,
including, e.g., the Ethernet protocol, the internet protocol suite
(TCP/IP), the ATM (Asynchronous Transfer Mode) technique, the SONET
(Synchronous Optical Networking) protocol, or the SDH (Synchronous
Digital Hierarchy) protocol. The TCP/IP internet protocol suite may
include application layer, transport layer, internet layer
(including, e.g., IPv6), or the link layer. The network 104 may be
a type of a broadcast network, a telecommunications network, a data
communication network, or a computer network.
[0027] In some embodiments, the system may include multiple,
logically-grouped servers 106. In one of these embodiments, the
logical group of servers may be referred to as a server farm 38 or
a machine farm 38. In another of these embodiments, the servers 106
may be geographically dispersed. In other embodiments, a machine
farm 38 may be administered as a single entity. In still other
embodiments, the machine farm 38 includes a plurality of machine
farms 38. The servers 106 within each machine farm 38 can be
heterogeneous--one or more of the servers 106 or machines 106 can
operate according to one type of operating system platform (e.g.,
WINDOWS NT, manufactured by Microsoft Corp. of Redmond, Wash.),
while one or more of the other servers 106 can operate on according
to another type of operating system platform (e.g., Unix, Linux, or
Mac OS X).
[0028] In one embodiment, servers 106 in the machine farm 38 may be
stored in high-density rack systems, along with associated storage
systems, and located in an enterprise data center. In this
embodiment, consolidating the servers 106 in this way may improve
system manageability, data security, the physical security of the
system, and system performance by locating servers 106 and high
performance storage systems on localized high performance networks.
Centralizing the servers 106 and storage systems and coupling them
with advanced system management tools allows more efficient use of
server resources.
[0029] The servers 106 of each machine farm 38 do not need to be
physically proximate to another server 106 in the same machine farm
38. Thus, the group of servers 106 logically grouped as a machine
farm 38 may be interconnected using a wide-area network (WAN)
connection or a metropolitan-area network (MAN) connection. For
example, a machine farm 38 may include servers 106 physically
located in different continents or different regions of a
continent, country, state, city, campus, or room. Data transmission
speeds between servers 106 in the machine farm 38 can be increased
if the servers 106 are connected using a local-area network (LAN)
connection or some form of direct connection. Additionally, a
heterogeneous machine farm 38 may include one or more servers 106
operating according to a type of operating system, while one or
more other servers 106 execute one or more types of hypervisors
rather than operating systems. In these embodiments, hypervisors
may be used to emulate virtual hardware, partition physical
hardware, virtualize physical hardware, and execute virtual
machines that provide access to computing environments, allowing
multiple operating systems to run concurrently on a host computer.
Native hypervisors may run directly on the host computer.
Hypervisors may include VMware ESX/ESXi, manufactured by VMWare,
Inc., of Palo Alto, Calif.; the Xen hypervisor, an open source
product whose development is overseen by Citrix Systems, Inc.; the
HYPER-V hypervisors provided by Microsoft or others. Hosted
hypervisors may run within an operating system on a second software
level. Examples of hosted hypervisors may include VMware
Workstation and VIRTUALBOX.
[0030] Management of the machine farm 38 may be de-centralized. For
example, one or more servers 106 may comprise components,
subsystems and modules to support one or more management services
for the machine farm 38. In one of these embodiments, one or more
servers 106 provide functionality for management of dynamic data,
including techniques for handling failover, data replication, and
increasing the robustness of the machine farm 38. Each server 106
may communicate with a persistent store and, in some embodiments,
with a dynamic store.
[0031] Server 106 may be a file server, application server, web
server, proxy server, appliance, network appliance, gateway,
gateway server, virtualization server, deployment server, SSL VPN
server, or firewall. In one embodiment, the server 106 may be
referred to as a remote machine or a node. In another embodiment, a
plurality of nodes 290 may be in the path between any two
communicating servers.
[0032] Referring to FIG. 1B, a cloud computing environment is
depicted. A cloud computing environment may provide client 102 with
one or more resources provided by a network environment. The cloud
computing environment may include one or more clients 102a-102n, in
communication with the cloud 108 over one or more networks 104.
Clients 102 may include, e.g., thick clients, thin clients, and
zero clients. A thick client may provide at least some
functionality even when disconnected from the cloud 108 or servers
106. A thin client or a zero client may depend on the connection to
the cloud 108 or server 106 to provide functionality. A zero client
may depend on the cloud 108 or other networks 104 or servers 106 to
retrieve operating system data for the client device. The cloud 108
may include back end platforms, e.g., servers 106, storage, server
farms or data centers.
[0033] The cloud 108 may be public, private, or hybrid. Public
clouds may include public servers 106 that are maintained by third
parties to the clients 102 or the owners of the clients. The
servers 106 may be located off-site in remote geographical
locations as disclosed above or otherwise. Public clouds may be
connected to the servers 106 over a public network. Private clouds
may include private servers 106 that are physically maintained by
clients 102 or owners of clients. Private clouds may be connected
to the servers 106 over a private network 104. Hybrid clouds 108
may include both the private and public networks 104 and servers
106.
[0034] The cloud 108 may also include a cloud based delivery, e.g.
Software as a Service (SaaS) 110, Platform as a Service (PaaS) 112,
and Infrastructure as a Service (IaaS) 114. IaaS may refer to a
user renting the use of infrastructure resources that are needed
during a specified time period. IaaS providers may offer storage,
networking, servers or virtualization resources from large pools,
allowing the users to quickly scale up by accessing more resources
as needed. Examples of IaaS include AMAZON WEB SERVICES provided by
Amazon.com, Inc., of Seattle, Wash., RACKSPACE CLOUD provided by
Rackspace US, Inc., of San Antonio, Tex., Google Compute Engine
provided by Google Inc. of Mountain View, Calif., or RIGHTSCALE
provided by RightScale, Inc., of Santa Barbara, Calif. PaaS
providers may offer functionality provided by IaaS, including,
e.g., storage, networking, servers or virtualization, as well as
additional resources such as, e.g., the operating system,
middleware, or runtime resources. Examples of PaaS include WINDOWS
AZURE provided by Microsoft Corporation of Redmond, Wash., Google
App Engine provided by Google Inc., and HEROKU provided by Heroku,
Inc. of San Francisco, Calif. SaaS providers may offer the
resources that PaaS provides, including storage, networking,
servers, virtualization, operating system, middleware, or runtime
resources. In some embodiments, SaaS providers may offer additional
resources including, e.g., data and application resources. Examples
of SaaS include GOOGLE APPS provided by Google Inc., SALESFORCE
provided by Salesforce.com Inc. of San Francisco, Calif., or OFFICE
365 provided by Microsoft Corporation. Examples of SaaS may also
include data storage providers, e.g. DROPBOX provided by Dropbox,
Inc. of San Francisco, Calif., Microsoft SKYDRIVE provided by
Microsoft Corporation, Google Drive provided by Google Inc., or
Apple ICLOUD provided by Apple Inc. of Cupertino, Calif.
[0035] Clients 102 may access IaaS resources with one or more IaaS
standards, including, e.g., Amazon Elastic Compute Cloud (EC2),
Open Cloud Computing Interface (OCCI), Cloud Infrastructure
Management Interface (CIMI), or OpenStack standards. Some IaaS
standards may allow clients access to resources over HTTP, and may
use Representational State Transfer (REST) protocol or Simple
Object Access Protocol (SOAP). Clients 102 may access PaaS
resources with different PaaS interfaces. Some PaaS interfaces use
HTTP packages, standard Java APIs, JavaMail API, Java Data Objects
(JDO), Java Persistence API (JPA), Python APIs, web integration
APIs for different programming languages including, e.g., Rack for
Ruby, WSGI for Python, or PSGI for Perl, or other APIs that may be
built on REST, HTTP, XML, or other protocols. Clients 102 may
access SaaS resources through the use of web-based user interfaces,
provided by a web browser (e.g. GOOGLE CHROME, Microsoft INTERNET
EXPLORER, or Mozilla Firefox provided by Mozilla Foundation of
Mountain View, Calif.). Clients 102 may also access SaaS resources
through smartphone or tablet applications, including, for example,
Salesforce Sales Cloud, or Google Drive app. Clients 102 may also
access SaaS resources through the client operating system,
including, e.g., Windows file system for DROPB OX.
[0036] In some embodiments, access to IaaS, PaaS, or SaaS resources
may be authenticated. For example, a server or authentication
server may authenticate a user via security certificates, HTTPS, or
API keys. API keys may include various encryption standards such
as, e.g., Advanced Encryption Standard (AES). Data resources may be
sent over Transport Layer Security (TLS) or Secure Sockets Layer
(SSL).
[0037] The client 102 and server 106 may be deployed as and/or
executed on any type and form of computing device, e.g. a computer,
network device or appliance capable of communicating on any type
and form of network and performing the operations described herein.
FIGS. 1C and 1D depict block diagrams of a computing device 100
useful for practicing an embodiment of the client 102 or a server
106. As shown in FIGS. 1C and 1D, each computing device 100
includes a central processing unit 121, and a main memory unit 122.
As shown in FIG. 1C, a computing device 100 may include a storage
device 128, an installation device 116, a network interface 118, an
I/O controller 123, display devices 124a-124n, a keyboard 126 and a
pointing device 127, e.g. a mouse. The storage device 128 may
include, without limitation, an operating system, software, and a
software of a medical management system (MMS) 120. As shown in FIG.
1D, each computing device 100 may also include additional optional
elements, e.g. a memory port 103, a bridge 170, one or more
input/output devices 130a-130n (generally referred to using
reference numeral 130), and a cache memory 140 in communication
with the central processing unit 121.
[0038] The central processing unit 121 is any logic circuitry that
responds to and processes instructions fetched from the main memory
unit 122. In many embodiments, the central processing unit 121 is
provided by a microprocessor unit, e.g.: those manufactured by
Intel Corporation of Mountain View, Calif.; those manufactured by
Motorola Corporation of Schaumburg, Ill.; the ARM processor and
TEGRA system on a chip (SoC) manufactured by Nvidia of Santa Clara,
Calif.; the POWER7 processor, those manufactured by International
Business Machines of White Plains, N.Y.; or those manufactured by
Advanced Micro Devices of Sunnyvale, Calif. The computing device
100 may be based on any of these processors, or any other processor
capable of operating as described herein. The central processing
unit 121 may utilize instruction level parallelism, thread level
parallelism, different levels of cache, and multi-core processors.
A multi-core processor may include two or more processing units on
a single computing component. Examples of a multi-core processors
include the AMD PHENOM IIX2, INTEL CORE i5 and INTEL CORE i7.
[0039] Main memory unit 122 may include one or more memory chips
capable of storing data and allowing any storage location to be
directly accessed by the microprocessor 121. Main memory unit 122
may be volatile and faster than storage 128 memory. Main memory
units 122 may be Dynamic random access memory (DRAM) or any
variants, including static random access memory (SRAM), Burst SRAM
or SynchBurst SRAM (BSRAM), Fast Page Mode DRAM (FPM DRAM),
Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended
Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO
DRAM), Single Data Rate Synchronous DRAM (SDR SDRAM), Double Data
Rate SDRAM (DDR SDRAM), Direct Rambus DRAM (DRDRAM), or Extreme
Data Rate DRAM (XDR DRAM). In some embodiments, the main memory 122
or the storage 128 may be non-volatile; e.g., non-volatile read
access memory (NVRAM), flash memory non-volatile static RAM
(nvSRAM), Ferroelectric RAM (FeRAM), Magnetoresistive RAM (MRAIVI),
Phase-change memory (PRAM), conductive-bridging RAM (CBRAIVI),
Silicon-Oxide-Nitride-Oxide-Silicon (SONOS), Resistive RAM
(RRAIVI), Racetrack, Nano-RAM (NRAIVI), or Millipede memory. The
main memory 122 may be based on any of the above described memory
chips, or any other available memory chips capable of operating as
described herein. In the embodiment shown in FIG. 1C, the processor
121 communicates with main memory 122 via a system bus 150
(described in more detail below). FIG. 1D depicts an embodiment of
a computing device 100 in which the processor communicates directly
with main memory 122 via a memory port 103. For example, in FIG. 1D
the main memory 122 may be DRDRAM.
[0040] FIG. 1D depicts an embodiment in which the main processor
121 communicates directly with cache memory 140 via a secondary
bus, sometimes referred to as a backside bus. In other embodiments,
the main processor 121 communicates with cache memory 140 using the
system bus 150. Cache memory 140 typically has a faster response
time than main memory 122 and is typically provided by SRAM, BSRAM,
or EDRAM. In the embodiment shown in FIG. 1D, the processor 121
communicates with various I/O devices 130 via a local system bus
150. Various buses may be used to connect the central processing
unit 121 to any of the I/O devices 130, including a PCI bus, a
PCI-X bus, or a PCI-Express bus, or a NuBus. For embodiments in
which the I/O device is a video display 124, the processor 121 may
use an Advanced Graphics Port (AGP) to communicate with the display
124 or the I/O controller 123 for the display 124. FIG. 1D depicts
an embodiment of a computer 100 in which the main processor 121
communicates directly with I/O device 130b or other processors 121'
via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communications
technology. FIG. 1D also depicts an embodiment in which local
busses and direct communication are mixed: the processor 121
communicates with I/O device 130a using a local interconnect bus
while communicating with I/O device 130b directly.
[0041] A wide variety of I/O devices 130a-130n may be present in
the computing device 100. Input devices may include keyboards,
mice, trackpads, trackballs, touchpads, touch mice, multi-touch
touchpads and touch mice, microphones, multi-array microphones,
drawing tablets, cameras, single-lens reflex camera (SLR), digital
SLR (DSLR), CMOS sensors, accelerometers, infrared optical sensors,
pressure sensors, magnetometer sensors, angular rate sensors, depth
sensors, proximity sensors, ambient light sensors, gyroscopic
sensors, or other sensors. Output devices may include video
displays, graphical displays, speakers, headphones, inkjet
printers, laser printers, and 3D printers.
[0042] Devices 130a-130n may include a combination of multiple
input or output devices, including, e.g., Microsoft KINECT,
Nintendo Wiimote for the WII, Nintendo WII U GAMEPAD, or Apple
IPHONE. Some devices 130a-130n allow gesture recognition inputs
through combining some of the inputs and outputs. Some devices
130a-130n provides for facial recognition which may be utilized as
an input for different purposes including authentication and other
commands. Some devices 130a-130n provides for voice recognition and
inputs, including, e.g., Microsoft KINECT, SIRI for IPHONE by
Apple, Google Now or Google Voice Search.
[0043] Additional devices 130a-130n have both input and output
capabilities, including, e.g., haptic feedback devices, touchscreen
displays, or multi-touch displays. Touchscreen, multi-touch
displays, touchpads, touch mice, or other touch sensing devices may
use different technologies to sense touch, including, e.g.,
capacitive, surface capacitive, projected capacitive touch (PCT),
in-cell capacitive, resistive, infrared, waveguide, dispersive
signal touch (DST), in-cell optical, surface acoustic wave (SAW),
bending wave touch (BWT), or force-based sensing technologies. Some
multi-touch devices may allow two or more contact points with the
surface, allowing advanced functionality including, e.g., pinch,
spread, rotate, scroll, or other gestures. Some touchscreen
devices, including, e.g., Microsoft PIXEL SENSE or Multi-Touch
Collaboration Wall, may have larger surfaces, such as on a
table-top or on a wall, and may also interact with other electronic
devices. Some I/O devices 130a-130n, display devices 124a-124n or
group of devices may be augment reality devices. The I/O devices
may be controlled by an I/O controller 123 as shown in FIG. 1C. The
I/O controller may control one or more I/O devices, such as, e.g.,
a keyboard 126 and a pointing device 127, e.g., a mouse or optical
pen. Furthermore, an I/O device may also provide storage and/or an
installation medium 116 for the computing device 100. In still
other embodiments, the computing device 100 may provide USB
connections (not shown) to receive handheld USB storage devices. In
further embodiments, an I/O device 130 may be a bridge between the
system bus 150 and an external communication bus, e.g. a USB bus, a
SCSI bus, a FireWire bus, an Ethernet bus, a Gigabit Ethernet bus,
a Fibre Channel bus, or a Thunderbolt bus.
[0044] In some embodiments, display devices 124a-124n may be
connected to I/O controller 123. Display devices may include, e.g.,
liquid crystal displays (LCD), thin film transistor LCD (TFT-LCD),
blue phase LCD, electronic papers (e-ink) displays, flexile
displays, light emitting diode displays (LED), digital light
processing (DLP) displays, liquid crystal on silicon (LCOS)
displays, organic light-emitting diode (OLED) displays,
active-matrix organic light-emitting diode (AMOLED) displays,
liquid crystal laser displays, time-multiplexed optical shutter
(TMOS) displays, or 3D displays. Examples of 3D displays may use,
e.g. stereoscopy, polarization filters, active shutters, or
autostereoscopy. Display devices 124a-124n may also be a
head-mounted display (HIVID). In some embodiments, display devices
124a-124n or the corresponding I/O controllers 123 may be
controlled through or have hardware support for OPENGL or DIRECTX
API or other graphics libraries.
[0045] In some embodiments, the computing device 100 may include or
connect to multiple display devices 124a-124n, which each may be of
the same or different type and/or form. As such, any of the I/O
devices 130a-130n and/or the I/O controller 123 may include any
type and/or form of suitable hardware, software, or combination of
hardware and software to support, enable or provide for the
connection and use of multiple display devices 124a-124n by the
computing device 100. For example, the computing device 100 may
include any type and/or form of video adapter, video card, driver,
and/or library to interface, communicate, connect or otherwise use
the display devices 124a-124n. In one embodiment, a video adapter
may include multiple connectors to interface to multiple display
devices 124a-124n. In other embodiments, the computing device 100
may include multiple video adapters, with each video adapter
connected to one or more of the display devices 124a-124n. In some
embodiments, any portion of the operating system of the computing
device 100 may be configured for using multiple displays 124a-124n.
In other embodiments, one or more of the display devices 124a-124n
may be provided by one or more other computing devices 100a or 100b
connected to the computing device 100, via the network 104. In some
embodiments software may be designed and constructed to use another
computer's display device as a second display device 124a for the
computing device 100. For example, in one embodiment, an Apple iPad
may connect to a computing device 100 and use the display of the
device 100 as an additional display screen that may be used as an
extended desktop. One ordinarily skilled in the art will recognize
and appreciate the various ways and embodiments that a computing
device 100 may be configured to have multiple display devices
124a-124n.
[0046] Referring again to FIG. 1C, the computing device 100 may
comprise a storage device 128 (e.g. one or more hard disk drives or
redundant arrays of independent disks) for storing an operating
system or other related software, and for storing application
software programs such as any program related to the software for
the medical monitoring system 120. Examples of storage device 128
include, e.g., hard disk drive (HDD); optical drive including CD
drive, DVD drive, or BLU-RAY drive; solid-state drive (SSD); USB
flash drive; or any other device suitable for storing data. Some
storage devices may include multiple volatile and non-volatile
memories, including, e.g., solid state hybrid drives that combine
hard disks with solid state cache. Some storage device 128 may be
non-volatile, mutable, or read-only. Some storage device 128 may be
internal and connect to the computing device 100 via a bus 150.
Some storage device 128 may be external and connect to the
computing device 100 via a I/O device 130 that provides an external
bus. Some storage device 128 may connect to the computing device
100 via the network interface 118 over a network 104, including,
e.g., the Remote Disk for MACBOOK AIR by Apple. Some client devices
100 may not require a non-volatile storage device 128 and may be
thin clients or zero clients 102. Some storage device 128 may also
be used as an installation device 116, and may be suitable for
installing software and programs. Additionally, the operating
system and the software can be run from a bootable medium, for
example, a bootable CD, e.g. KNOPPIX, a bootable CD for GNU/Linux
that is available as a GNU/Linux distribution from knoppix.net.
[0047] Client device 100 may also install software or application
from an application distribution platform. Examples of application
distribution platforms include the App Store for iOS provided by
Apple, Inc., the Mac App Store provided by Apple, Inc., GOOGLE PLAY
for Android OS provided by Google Inc., Chrome Webstore for CHROME
OS provided by Google Inc., and Amazon Appstore for Android OS and
KINDLE FIRE provided by Amazon.com, Inc. An application
distribution platform may facilitate installation of software on a
client device 102. An application distribution platform may include
a repository of applications on a server 106 or a cloud 108, which
the clients 102a-102n may access over a network 104. An application
distribution platform may include application developed and
provided by various developers. A user of a client device 102 may
select, purchase and/or download an application via the application
distribution platform.
[0048] Furthermore, the computing device 100 may include a network
interface 118 to interface to the network 104 through a variety of
connections including, but not limited to, standard telephone lines
LAN or WAN links (e.g., 802.11, T1, T3, Gigabit Ethernet,
Infiniband), broadband connections (e.g., ISDN, Frame Relay, ATM,
Gigabit Ethernet, Ethernet-over-SONET, ADSL, VDSL, BPON, GPON,
fiber optical including FiOS), wireless connections, or some
combination of any or all of the above. Connections can be
established using a variety of communication protocols (e.g.,
TCP/IP, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data
Interface (FDDI), IEEE 802.11a/b/g/n/ac CDMA, GSM, WiMax and direct
asynchronous connections). In one embodiment, the computing device
100 communicates with other computing devices 100' via any type
and/or form of gateway or tunneling protocol e.g. Secure Socket
Layer (SSL) or Transport Layer Security (TLS), or the Citrix
Gateway Protocol manufactured by Citrix Systems, Inc. of Ft.
Lauderdale, Fla. The network interface 118 may comprise a built-in
network adapter, network interface card, PCMCIA network card,
EXPRESSCARD network card, card bus network adapter, wireless
network adapter, USB network adapter, modem or any other device
suitable for interfacing the computing device 100 to any type of
network capable of communication and performing the operations
described herein.
[0049] A computing device 100 of the sort depicted in FIGS. 1B and
1C may operate under the control of an operating system, which
controls scheduling of tasks and access to system resources. The
computing device 100 can be running any operating system such as
any of the versions of the MICROSOFT WINDOWS operating systems, the
different releases of the Unix and Linux operating systems, any
version of the MAC OS for Macintosh computers, any embedded
operating system, any real-time operating system, any open source
operating system, any proprietary operating system, any operating
systems for mobile computing devices, or any other operating system
capable of running on the computing device and performing the
operations described herein. Typical operating systems include, but
are not limited to: WINDOWS 2000, WINDOWS Server 2012, WINDOWS CE,
WINDOWS Phone, WINDOWS XP, WINDOWS VISTA, and WINDOWS 7, WINDOWS
RT, and WINDOWS 8 all of which are manufactured by Microsoft
Corporation of Redmond, Wash.; MAC OS and iOS, manufactured by
Apple, Inc. of Cupertino, Calif.; and Linux, a freely-available
operating system, e.g. Linux Mint distribution ("distro") or
Ubuntu, distributed by Canonical Ltd. of London, United Kingdom; or
Unix or other Unix-like derivative operating systems; and Android,
designed by Google, of Mountain View, Calif., among others. Some
operating systems, including, e.g., the CHROME OS by Google, may be
used on zero clients or thin clients, including, e.g.,
CHROMEBOOKS.
[0050] The computer system 100 can be any workstation, telephone,
desktop computer, laptop or notebook computer, netbook, ULTRABOOK,
tablet, server, handheld computer, mobile telephone, smartphone or
other portable telecommunications device, media playing device, a
gaming system, mobile computing device, or any other type and/or
form of computing, telecommunications or media device that is
capable of communication. The computer system 100 has sufficient
processor power and memory capacity to perform the operations
described herein. In some embodiments, the computing device 100 may
have different processors, operating systems, and input devices
consistent with the device. The Samsung GALAXY smartphones, e.g.,
operate under the control of Android operating system developed by
Google, Inc. GALAXY smartphones receive input via a touch
interface.
[0051] In some embodiments, the computing device 100 is a gaming
system. For example, the computer system 100 may comprise a
PLAYSTATION 3, or PERSONAL PLAYSTATION PORTABLE (PSP), or a
PLAYSTATION VITA device manufactured by the Sony Corporation of
Tokyo, Japan, a NINTENDO DS, NINTENDO 3DS, NINTENDO WII, or a
NINTENDO WIT U device manufactured by Nintendo Co., Ltd., of Kyoto,
Japan, an XBOX 360 device manufactured by the Microsoft Corporation
of Redmond, Wash.
[0052] In some embodiments, the computing device 100 is a digital
audio player such as the Apple IPOD, IPOD Touch, and IPOD NANO
lines of devices, manufactured by Apple Computer of Cupertino,
Calif. Some digital audio players may have other functionality,
including, e.g., a gaming system or any functionality made
available by an application from a digital application distribution
platform. For example, the IPOD Touch may access the Apple App
Store. In some embodiments, the computing device 100 is a portable
media player or digital audio player supporting file formats
including, but not limited to, MP3, WAV, M4A/AAC, WMA Protected
AAC, AIFF, Audible audiobook, Apple Lossless audio file formats and
.mov, .m4v, and .mp4 MPEG-4 (H.264/MPEG-4 AVC) video file
formats.
[0053] In some embodiments, the computing device 100 is a tablet
e.g. the IPAD line of devices by Apple; GALAXY TAB family of
devices by Samsung; or KINDLE FIRE, by Amazon.com, Inc. of Seattle,
Wash. In other embodiments, the computing device 100 is a eBook
reader, e.g. the KINDLE family of devices by Amazon.com, or NOOK
family of devices by Barnes & Noble, Inc. of New York City,
N.Y.
[0054] In some embodiments, the communications device 102 includes
a combination of devices, e.g. a smartphone combined with a digital
audio player or portable media player. For example, one of these
embodiments is a smartphone, e.g. the IPHONE family of smartphones
manufactured by Apple, Inc.; a Samsung GALAXY family of smartphones
manufactured by Samsung, Inc; or a Motorola DROID family of
smartphones. In yet another embodiment, the communications device
102 is a laptop or desktop computer equipped with a web browser and
a microphone and speaker system, e.g. a telephony headset. In these
embodiments, the communications devices 102 are web-enabled and can
receive and initiate phone calls. In some embodiments, a laptop or
desktop computer is also equipped with a webcam or other video
capture device that enables video chat and video call.
[0055] In some embodiments, the status of one or more machines 102,
106 in the network 104 is monitored, generally as part of network
management. In one of these embodiments, the status of a machine
may include an identification of load information (e.g., the number
of processes on the machine, CPU and memory utilization), of port
information (e.g., the number of available communication ports and
the port addresses), or of session status (e.g., the duration and
type of processes, and whether a process is active or idle). In
another of these embodiments, this information may be identified by
a plurality of metrics, and the plurality of metrics can be applied
at least in part towards decisions in load distribution, network
traffic management, and network failure recovery as well as any
aspects of operations of the present solution described herein.
Aspects of the operating environments and components described
above will become apparent in the context of the systems and
methods disclosed herein.
B. Systems and Methods for Medical Dispensing, Management and
Monitoring
[0056] The present disclosure relates to systems and methods for
medical dispensing, management and monitoring. According to one
aspect, a remote medical management environment can include a
medical management system intermediary to a plurality of patients
and a plurality of medical care providers. The medical management
system can communicate with medical dispensing devices configured
to dispense medication to patients. Further, the medical management
system can communicate with provider devices through which medical
care providers can access medicine related information of patients
and provide instructions, which can administer treatment protocols
to patients of the medical dispensing devices. The remote medical
management environment can allow medical care providers, such as
doctors, the ability to remotely manage and administer medications
to patients, while at the same time, avoid medicinal drug abuse by
patients.
[0057] FIG. 2 is a block diagram depicting a medical management
environment including a medical management system 120 intermediary
to a plurality of patient devices 302A-302N and provider devices
402A-402N. The medical management system 120 can communicate with
the plurality of patient devices 302 via one or more networks.
Similarly, the medical management system 120 can also communicate
with the plurality of provider devices 302 via one or more
networks. The medical management system 120 can include one or more
processors 204, memory 206, one or more patient databases 210, one
or more provider databases 212, a medical manager 220 and a
prescription manager 222. The medical management system 120 can
also communicate with one or more third-party data sources 240, for
example, weather databases, location databases, pharmaceutical drug
databases, pharmacy databases, among others.
[0058] The patient database 210 can include one or more tables
storing information related to one or more patients and their
corresponding patient devices. The patient database can include
information relating to one or more patients registered with the
medical management system 120. In some implementations, the patient
database can store, for each patient, one or more of the patient's
name, the patient's identifier unique to the patient, the patient's
date of birth, a phone number of the patient, home and work
addresses of the patient, information related to the patient's
medical records, for example, medical history, medical diagnosis,
medical treatments, among others. In addition, the database can
include prescription information for the patient, dosage
information, allergies of the patient, medical care provider's
name, pharmacy name, address and phone number, prescription
information, health insurance information, among others. The
patient database can also include a patient device identifier
unique to the patient device and associated with the patient. The
patient database can be maintained by the medical management system
120. In some implementations, the medical management system 120 can
periodically update the patient database. In some implementations,
each time the medical management system 120 receives information
from a provider device 402 of a medical care provider or a patient
device 302 of a patient, the medical management system 120 can
identify the patient to which the information corresponds and
update the patient database 210 to update an entry of the patient
to include the received information.
[0059] The provider database 212 can include one or more tables
storing information related to one or more medical care providers.
The patient database can include information relating to one or
more medical care providers registered with the medical management
system 120 to manage and monitor patients and their medications via
the medical management system 120. In some implementations, the
provider database 212 can store, for each provider, one or more of
the provider's name, the provider's identifier unique to the
provider, the provider's date of birth, a phone number of the
provider, home and work addresses of the provider, information
related to the provider's medical licensing information, among
others. In addition, the provider database 212 can include a list
of patients the medical provider is authorized to treat via the
medical management system 120. The provider database 212 can be
maintained by the medical management system 120. In some
implementations, the medical management system 120 can periodically
update the provider database 212. In some implementations, each
time the medical management system 120 receives information from a
provider device 402 of a medical care provider or a patient device
302 of a patient, the medical management system 120 can identify
the medical care provider to which the information corresponds and
update the provider database 212 to update an entry of the provider
to include the received information.
[0060] The medical manager 220 can include hardware, software or a
combination and hardware and software. The medical manager 220 can
be a script, program, file, or other software construct, which when
executed by the processor 204, can be configured to communicate
with one or more patient devices 302 and one or more provider
devices 402. The medical manager 220 can be configured to allow a
provider device 402 to remotely dispense, manage and monitor
medications provided to a patient via a patient device 302.
[0061] The medical manager 220 can be configured to establish
communications with the provider device 402. In some
implementations, the medical manager 220 can initiate a request to
communicate with the provider device 402. In some implementations,
the medical manager 220 can initiate a request to communicate with
the provider device 402 in response to a triggering event, for
example, receiving a communication request from a patient or a
patient device, determining that a patient device is running low on
a prescription medication, identifying that a patient of the
provider needs the provider's attention, among others. In some
implementations, the medical manager 220 can receive a request from
the provider device to establish a communication link with the
medical manager 220. The provider may submit a request via the
provider device to access a provider dashboard through which the
provider can monitor the status of patients and the associated
patient devices 302.
[0062] The medical manager 220 can be configured to provide a user
interface to the provider device 402. In some implementations, the
medical manager 220 can be configured to receive a request from the
provider device 402 to access information related to a patient. The
request can include identifying information of the medical care
provider. The medical manager 220 can perform a lookup in the
provider database 212 to validate the identity of the medical care
provider and to authenticate the provider device 402 from which the
request was received. The medical manager 220 can identify a
patient device to which the provider 220 requests access. In some
implementations, the medical manager 220 can identify the patient
device from the request from the provider device 402. In some
implementations, responsive to authenticating the provider device
402, the medical manager 220 can provide a dashboard on a user
interface of the provider device through which the medical care
provider can access information related to one or more patients of
the medical care provider. In some implementations, the medical
manager 220 can receive a request to access information related to
a patient from the provider device. In some implementations, the
medical manager 220 can identify one or more conditions that can
cause the medical manager 220 to trigger a notification to the
provider device of the medical care provider. The notification can
be specific to a particular patient. For example, responsive to the
medical manager determining that a patient device is running out of
a medication, the medical manager 220 can generate a notification
to the provider device of the medical care provider of the patient
associated with the patient device 302 to notify the medical care
provider to put in a request to refill the prescription
medication.
[0063] The medical manager 220 can be configured to retrieve or
receive information from the patient devices associated with
patients subscribed to the medical management system 120. The
medical manager 220 can identify, for each patient device 302,
which medications are configured to be dispensed via the patient
devices, the times at which medications are dispensed, the type and
amount of medication in each channel or cartridge of the patient
device, as well as other information relating to the patient
device. In some implementations, the medical manager 220 can
receive location information identifying a location of the patient
device, a temperature within each of the medicine cartridges of the
patient device, an ambient temperature around the patient device,
among others.
[0064] The medical manager 220 can be configured to also receive
additional information related to each of the patients. In some
implementations, the medical management system 120 can communicate
with other devices associated with the patient, including wearable
devices that may provide physiological feedback or data to the
medical management system 120. In some implementations, the
wearable devices can measure body temperature, heart rate,
breathing rate, oxygen volume, sugar levels, pH levels in fluids,
among others.
[0065] The medical manager 220 can be configured to communicate
with a patient communication device, such as a patient's smartphone
or tablet, through which the medical manager 220 can be configured
to send notifications to the patient reminding them to take their
medications or to perform one or more tasks. In some
implementations, the medical manager 220 can be configured to
receive data provided by the patient via the patient communication
device. In some implementations, the medical manager 220 can
establish a communication link with the patient communication
device, which can serve as a hub for one or more wearable devices
monitoring physiological and other data of the patient as well as
the patient device 302.
[0066] The medical manager 220 can be configured to actuate one or
more components of the patient device 302. In some implementations,
the medical manager 220 can be configured to send instructions to
the patient device 302, which when executed by a processor of the
patient device 302, can cause one or more valves or other actuators
of the patient device 302 to dispense medications. In some
implementations, the instructions can specify a length of time for
which to keep the valves open to ensure that a specific amount of
medication is dispensed. In some implementations, the medical
manager 220 can be configured to send instructions to regulate the
temperature around one or more of the cartridges within which the
medications are stored. In some implementations, the medical
manager 220 can send instructions to provide cooling to cartridges
that include medications that need to be maintained at temperatures
below the ambient temperature of the patient device 302 or provide
heating to cartridges that include medications that need to be
maintained at temperatures above the ambient temperature of the
patient device 302.
[0067] The medical manager 220 can be configured to maintain and
update records for each patient device. In some implementations the
medical manager 220 can monitor and track the dispensing of
medications to the patient of the patient device. The medical
manager 220 can store the medication dispensing activity in one or
more databases, such as the patient database. In some
implementations, the medical manager 220 can monitor and track a
time at which the medication was dispensed, an amount of medication
dispensed, physiological and other patient related measurements
around the time the medication was dispensed, a location at which
the medication was dispensed, among others. In some
implementations, the medical manager 220 can store this information
each time medication is dispensed. In some implementations, the
patient device may take over the function of monitoring and
tracking medication dispensing activity and provide the information
to the medical manager 220, which can then update the records of
the patient device 302 in the patient database 210.
[0068] The prescription manager 222 can be configured to manage
prescriptions of the patients subscribed to the medical management
system 120. The prescription manager 222 can be configured to
monitor the amounts of medications remaining in the patient devices
such that when one or more medications are running low, the
prescription manager 222 can be configured to submit requests to
the medical care provider and/or one or more pharmacies to refill
the prescription. In some implementations, the prescription manager
222 can be configured to automatically submit requests to
pharmacies for refills. In some implementations, the prescription
manager 222 can utilize health insurance information of the patient
stored in the patient database 210 to submit orders for
prescriptions to the pharmacies. The prescription manager 222 can
be configured to identify the one or more medications included in
each of the cartridges of the patient device. The prescription
manager 222 can utilize one or more content sources to determine if
any of the medications counteracts with one of the remaining
medications in the cartridges or if they include ingredients,
compounds, or medications that the patient is allergic to.
[0069] Referring now also to FIG. 3, FIG. 3 is a block diagram
depicting a patient device configured to dispense medication to a
patient. The patient device or medical dispensing device 302
includes one or more processors 304, memory 306 and at least one
communication module 308. The communication module 308 can include
a Bluetooth module 310, a GPS module 312, a RFID module 314 and a
WiFi module 316. In some implementations, the communication module
308 can include cellular communications module that allows the
medical dispensing device 302 to communicate with the medical
management system 120 via cellular networks.
[0070] The medical dispensing device 302 can communicate with the
medical management system 120 via one or more networks. The medical
dispensing device 302 can communicate with the medical management
system 120 via Bluetooth, WiFi, a wired internet connection,
cellular networks, or other communication channels. In some
implementations, the medical dispensing device 302 can communicate
with the medical management system 120 using a patient's smartphone
or other device as an intermediary. In some implementations, the
medical dispensing device 302 can establish a Bluetooth connection
with the patient's mobile device and the patient's mobile device
can establish a connection with the medical dispensing device 302
via one or more cellular, wired or wireless internet networks. In
some implementations in which the medical dispensing device 302
utilizes a Bluetooth network, the medical dispensing device 302 may
operate within a communication range of a paired device, for
example, a mobile phone, that is in communication with the medical
management system 120.
[0071] The medical dispensing device 302 also includes an ID module
318 configured to validate communication requests received from
other devices. This can serve as a security measure to prevent
unauthorized devices from tampering with the medical dispensing
device 302 as well as attempting to access health related
information of one or more patients that subscribe to the medical
management system 120. The ID module 318 can also be configured to
validate the identity of the patient to which the medical
dispensing device 302 is assigned. In some implementations, the ID
module 318 can include a fingerprint reader or scanner to receive
fingerprint information from the patient and determine if the
received fingerprint information matches the patient. Similarly,
the ID module 318 can include an iris scanner to validate the
identity of the patient. In some implementations, the ID module 318
can include a camera for facial recognition based on one or more
facial features of the patient. In some implementations, the ID
module 318 can validate a patient based on voice recognition. In
some implementations, the ID module 318 can validate a patient
based on voice recognition. In some implementations, the ID module
318 can validate a patient via a communication link established
with a trusted device, such as a smartphone or tablet. In some
implementations, the patient can be required to enter a passcode or
set of unique characters or gestures on a mobile device in
communication with the medical dispensing device.
[0072] In some implementations, the medical dispensing device may
be configured to communicate with a mobile device of the patient to
verify the identity of a person accessing or requesting access to
the medical dispensing device. For instance, the medical dispensing
device may only dispense medication in response to receiving a
communication or signal from a paired mobile device that can
generate the communication or signal upon verifying the identity of
the patient. In some implementations, the mobile device can verify
the identity of the patient through facial recognition, fingerprint
scanning, passwords, or other security measures that can be
received, identified or otherwise incorporated via the mobile
device. In this way, there is no need for the medical dispensing
device to be designed with an integrated fingerprint scanner,
camera to detect facial recognition, or keypad to receive a
password from the patient, thereby reducing manufacturing costs of
the medical dispensing device.
[0073] The medical dispensing device can be tamper proof. This is
to prevent medication abuse and fraud. In some implementations, the
medical dispensing device 320 can include an alert system that
triggers an alert upon determining that the medical dispensing
device has been tampered or an attempt to tamper the medical
dispensing device was made. In some implementations, the medical
dispensing device 320 can include one or more security modules. The
security modules can include hardware and software to ensure that
the medication is dispensed to an authorized user or patient. In
some implementations, the medical dispensing device can include a
user recognition or identification system. In some implementations,
the medical dispensing device can include a fingerprint reader, an
iris scanner, or any other biometric scanner to confirm the
identity of the user. In some implementations, the medical
dispensing device can be password protected. In some
implementations the medical dispensing device can only be actuated
via a second device, such as a smartphone or tablet, registered
with the medical management system.
[0074] In some implementations, the location of the medical
dispensing device or the mobile device with which the medical
dispensing device can communicate may be monitored. In some
implementations, one or more location based policies can be
established to ensure additional security. For instance, the
medical dispensing device may be configured to only dispense the
medicine at predetermined locations, for example, a patient's home,
a patient's work location, a hospital or other medical care
provider's address, among others. In this way, if the device is
stolen or otherwise provided to an unauthorized user, the
unauthorized user may be unable to receive medication from the
medical dispensing device at locations different from the
predetermined locations. In addition, the medical dispensing device
may only transmit or receive data from the medical management
system at the predetermined locations to reduce security
breaches.
[0075] The medical dispensing device 302 also includes one or more
cartridges that contain medications to be dispensed. The cartridges
can be removable from the medical dispensing device 302. In some
implementations, the cartridges can be refilled. The cartridges can
be shaped and sized to match an opening in the medical dispensing
device and may include one or more identifying labels, tags, or
other readable or detectable information that the medical
dispensing device can read, identify or otherwise detect to ensure
the authenticity of the cartridge. This can be used to prevent
counterfeit medications or medications provided by unauthorized
medical providers. In some implementations, the pharmacy providing
the cartridge may include an RFID tag to the cartridge that is
encrypted. In some implementations, the cartridge can be tagged in
such a way that the cartridge's RFID tag can only be identified by
the medical dispensing device associated with the patient for which
the medication in the cartridge is prescribed. In some
implementations, the cartridge can be made tamper proof such that
if an unauthorized attempt to open or otherwise access or damage
the cartridge is made, the medication inside the cartridge is
destroyed or otherwise tainted or damaged that the medication loses
any monetary value to discourage the resale of the medication or
the abuse or unprescribed use of the medication. In some
implementations, an acid or other compound that destroys the
medication may be exposed to the medication.
[0076] The medical dispensing device can include one or more slots
or channels within which the cartridges are insertable. Each slot
can include a temperature controller 340 that is configured to
regulate the temperature of the cartridge inserted within the slot.
In some implementations, the temperature controller can include a
thermoelectric cooler or a heater that can be configured to
decrease or increase the temperature of the cartridge or the
contents of the cartridge.
[0077] The medical dispensing device 302 can include one or more
actuators 322a-322n that are configured to actuate a switch, valve
or other regulator that controls the amount of medication that is
dispensed from the respective cartridge. The actuators can be
configured to allow a certain amount of medication to be dispensed
on a per unit time basis. In some implementations, the amount of
medication dispensed per unit time may be altered based on various
factors, including a size of an opening, the configuration of the
actuator, and the amount of time the opening is kept open.
[0078] The actuators 332 of the medical dispensing device 302 can
be configured to be remotely controlled by the medical manager 220
of the medical management system 120. In some implementations, the
medical manager 220 can be configured to provide dosage
instructions to the medical dispensing device 302 and the processor
304 can be configured to cause the actuators of the corresponding
cartridges to be actuated in such a way that the amount of
medications dispensed from the cartridges is equivalent to the
desired dosage prescribed by the medical care provider. The
actuators can be electronically controlled. In some
implementations, the actuators can be powered via an on-board
battery. In some implementations, the on-board battery can be
rechargeable.
[0079] In some implementations, the medical dispensing device can
operate using batteries. In some implementations, the batteries may
be rechargeable or disposable. In some implementations in which the
batteries are rechargeable, the batteries may be charged via a USB
cable, via a power supply channel, or via wireless induction. In
some implementations, to implement wireless induction, the medical
dispensing device can be incorporated with a wireless charging
coil, for example, a wireless charging coil supplied by DIGIKEY and
manufactured by Wurth Electronics, Inc. In some implementations,
the wireless charging coil can be Part Number 76030811,
manufactured by Wurth Electronics, Inc. The shape, size and
position of the one or more wireless charging coils can be designed
to fit within the medical dispensing device.
[0080] The medical dispensing device 302 can include one or more
sensors for sensing or monitoring the amount of medication
dispensed from each of the cartridges. In some implementations, the
sensors can monitor a weight of medication dispensed or a weight of
medication remaining in the cartridge after medication is
dispensed. In some implementations, the sensors can count a number
of pills dispensed. In some implementations, the sensors can
monitor a time for which a valve is left open and a flow rate of
the medication flowing through the valve. The medical dispensing
device can include sensors measuring a quantity of medication
remaining in the medical dispensing device. In some
implementations, the medical dispensing device can determine an
amount of medication remaining in the medical dispensing device
based on the amount of medication included in a medicine cartridge
and an amount of medication already dispensed since the medicine
cartridge was first inserted. The medical dispensing device can be
configured to communicate medicine quantity levels to the medical
management system 120 such that the medical management system 120
can submit orders for refills to one or more pharmacies before the
medicine cartridge is completely empty.
[0081] The medical dispensing device 302, via the processor 304,
can maintain a monitoring log storing information related to the
monitoring of the medical dispensing device 302. The monitoring log
can store information related to communications received from the
medical management system 120. The log can store event related
information. Examples of events include a medicine dispensing
event, a medical care provider device or medical management system
establishing communications with the medical dispensing device, an
alarm triggering event (in the event of an attempt to tamper the
medical dispensing device), location changes of the medical
dispensing device, changes to ambient conditions of the medical
device, for example, when the medical dispensing device senses a
temperature below or above one or more predefined temperatures,
detecting low medication levels in one or more cartridges of the
medical dispensing device 302, among others. The activity logs can
identify a date and time at which medication was dispensed, a
dosage of medication dispensed as well as any other physiological
measurements, for example, temperature, pulse, heart rate, blood
pressure, sugar levels, among others, taken around the time the
medication was dispensed. In addition to medication dispensing
related activity, the activity logs can identify when a medical
care provider communicated with the medical dispensing device. In
some implementations, the activity logs can include information
related to dosage changes as well as changes in the time at which
medication is to be administered.
[0082] The medical dispensing device includes an outlet port or
opening 330 through which medications within the cartridges are
dispensed from the medical dispensing device. The outlet opening
330 can be configured to allow a patient to administer the
medication orally. In some implementations, the opening 330 can be
configured to allow medication to be dispensed in such a way that a
patient can apply the medication topically, subcutaneously,
pulmonary or intravenously, among others.
[0083] The patient device, otherwise referred to as a medical
dispensing device can be configured to allow a medical care
provider, for example, a doctor, the ability to remotely monitor,
regulate and manipulate medication administration to a patient
associated with the patient device. Through the medical dispensing
device, the medical care provider can adjust either the dosage of
medications or the time at which the medication is administered. In
some implementations, the medical care provider may receive
feedback through the medical dispensing device or other medical
device monitoring the patient and adjust the dosage or time at
which to administer medication based on the received feedback. The
medical dispensing device can be equipped with a communications
module that is configured to communicate with the medical
management system through which the medical care provider can
remotely communicate with the medical dispensing device. The
communications module can include both hardware and software
components that allow the medical dispensing device to receive and
transmit instructions and information. In some implementations, the
communications module can be configured to provide wireless
communications, for example, BLUETOOTH, WiFi, cellular
communications, among others. In some implementations, the
communications module can be configured to communicate with another
device, such as a smartphone, tablet, or other device that allows
the medical dispensing device to receive and execute instructions
received from the medical care provider.
[0084] In some implementations, the medical dispensing device can
include a temperature control module to control the temperature of
medication within the medical dispensing device. In this way, if
the medicine in the medical dispensing device is to be maintained
at a particular temperature, and the medical dispensing device is
in a location that has an ambient temperature much higher than the
temperature at which to maintain the medicine, the medical
dispensing device can provide cooling to the medication.
Conversely, the medical dispensing device can provide heating to
medications that are supposed to be stored or maintained at
temperatures higher than the ambient temperature at which the
medical dispensing device is located.
[0085] In some implementations, the medical dispensing device 302
can include a thermoelectric cooler, such as one manufactured by
CUSTOM THERMOELECTRIC of Bishopville, Md., USA. In some
implementations, the thermoelectric cooler can be Part
#03201-9G30-08RA manufactured by CUSTOM THERMOELECTRIC or other
similar thermoelectric cooler. In some implementations, the medical
dispensing device 302 can include one or more heat or cooling tanks
that may be positioned adjacent to or around one or more cartridges
of the medical dispensing device 302. In some implementations, the
heating or cooling mechanism can use convection, conduction or
radiation. In some implementations, a small convection system may
be used to carry air from the thermoelectric cooler to a top
portion of the medical dispensing device where the air will be
dispersed to the atmosphere. As such, the medical dispensing device
302 may include one or more vents through which air can enter and
exit the medical dispensing device.
[0086] In some implementations, the thermoelectric cooler can be
part of the medical dispensing device. In some implementations, the
thermoelectric cooler can be part of the cartridge that may be
removable from the medical dispensing device. In some
implementations in which the thermoelectric cooler is part of the
cartridge, the thermoelectric cooler can be positioned within the
cartridge in such a way that when the cartridge is inserted in the
medical dispensing device, the thermoelectric cooler can be coupled
to a power source of the medical dispensing device that can provide
power to the thermoelectric cooler. In some implementations in
which the thermoelectric cooler is part of the medical dispensing
device, the thermoelectric cooler can be configured or positioned
in such a way that the thermoelectric cooler can provide heating or
cooling to the cartridge and its contents.
[0087] In some implementations, the medical dispensing device can
utilize a fluid channel that includes a thermally conductive fluid,
such as alcohol. The fluid channel can be positioned to extend
along a side of the medical dispensing device. The fluid channel
can be configured to cause heat to dissipate from around the
cartridges. In some implementations, the fluid channel can be
configured to provide a cooling effect similar to how laptop
coolers dissipate heat generated by laptops.
[0088] In some implementations, a temperature sensor positioned
within, near or adjacent to the cartridges can detect the ambient
temperature around the cartridge. In some implementations, the
ambient temperature may be based on weather databases based on
location. In some implementations, the location of the medical
dispensing device 302 can be determined from a GPS module or
cellular module of the medical dispensing device 302. In some
implementations, the medical dispensing device 302 can be
configured or otherwise programmed to activate the cooling or
heating systems of the medical dispensing device to maintain the
temperature around the cartridges at temperatures suitable for
storing the medications.
[0089] In some implementations, the medical dispensing device 302
can include one or more audio output components, such as a speaker,
configured to emit alerts or transmit voice commands to the
patient. In some implementations, the medical dispensing device 302
can communicate with a wireless or wired headphone or speaker to
provide voice or audio notifications to the patient. In some
implementations, the medical dispensing device 302 can include a
microphone through which the patient can communicate with a medical
care provider. In this way, patients that had vision or hearing
impaired, may be able to locate the medical dispensing device 302
as well as receive instructions from a medical care provider
remotely. In some implementations, the medical dispensing device
302 can include a screen through which a patient who has impaired
hearing can receive instructions.
[0090] In some implementations, the medical dispensing device 302
can also be configured to include one or more input channels
through which the medical dispensing device can receive input data
from one or more wearable or portable measurement devices measuring
physiological and other metrics of the patient. The data received
from the measurement devices can be used by the medical dispensing
device 302 to administer medication to the patient. In some
implementations, the medical dispensing device 302 can utilize one
or more medicine administration policies according to which dosages
are administered. These policies can be established by a medical
care provider of the patient and provided to the medical dispensing
device 302 via the medical management system 120.
[0091] In some implementations, the medical dispensing device can
be configured to report the measured data to the medical management
system 120. The medical dispensing device can report the measured
data periodically or upon a detected triggering event (for example,
if the blood sugar level drops below a certain level, or a pulse
rate or breathing rate drops below or exceeds a predefined level).
The medical management system 120 can be configured to identify
triggering events based on the data received and may initiate a
communication with the medical care provider alerting the provider
of a medical condition.
[0092] The medical care provider, via the provider device 402, can
send instructions to the medical dispensing device to administer
medication to the patient. In some implementations, the provider
device 402 can modify a dosage regimen programmed for the medical
dispensing device by sending instructions to the medical dispensing
device 302 via the medical management system 120.
[0093] FIG. 4 is a block diagram depicting a provider device
configured to allow a medical care provider to manage medications
of patients receiving medication through the patient device of FIG.
3. The provider device 402 can include a processor 404, a memory
406, a dosage manager 408 and a user interface 410.
[0094] The dosage manager 408 can be configured to manage,
administer and monitor dosage information provided to each of the
medical dispensing devices 302 of patients of the medical care
provider of the provider device 402. The dosage manager 408 can
include hardware, software or a combination of both to communicate
with each of the medical dispensing devices 302 via the medical
management system 120. The dosage manager 408 can receive
instructions from the medical care provider via the user interface
410, which can be provided for display on a display of the provider
device 402. The provider can view patient related data on the user
interface, including but not limited to current dosage levels of
medications, the identity of medications loaded in the cartridges
of the medical dispensing device 302, as well as data from one or
more monitoring devices monitoring patient's vitals, physiological
metrics, among others. The provider can send instructions to
administer, modify or otherwise alter dosages to the medical
dispensing devices 302. The dosage manager 408 can receive these
instructions and provide instructions to the medical management
system 120 such that the correct dosage can be administered at the
medical dispensing device 302.
[0095] While the invention has been particularly shown and
described with reference to specific embodiments, it should be
understood by those skilled in the art that various changes in form
and detail may be made therein without departing from the spirit
and scope of the invention described in this disclosure.
[0096] While this specification contains many specific embodiment
details, these should not be construed as limitations on the scope
of any inventions or of what may be claimed, but rather as
descriptions of features specific to particular embodiments of
particular inventions. Certain features described in this
specification in the context of separate embodiments can also be
implemented in combination in a single embodiment. Conversely,
various features described in the context of a single embodiment
can also be implemented in multiple embodiments separately or in
any suitable subcombination. Moreover, although features may be
described above as acting in certain combinations and even
initially claimed as such, one or more features from a claimed
combination can in some cases be excised from the combination, and
the claimed combination may be directed to a subcombination or
variation of a subcombination.
[0097] Similarly, while operations are depicted in the drawings in
a particular order, this should not be understood as requiring that
such operations be performed in the particular order shown or in
sequential order, or that all illustrated operations be performed,
to achieve desirable results. In certain circumstances,
multitasking and parallel processing may be advantageous. Moreover,
the separation of various system components in the embodiments
described above should not be understood as requiring such
separation in all embodiments, and it should be understood that the
described program components and systems can generally be
integrated in a single software product or packaged into multiple
software products.
[0098] References to "or" may be construed as inclusive so that any
terms described using "or" may indicate any of a single, more than
one, and all of the described terms.
[0099] Thus, particular embodiments of the subject matter have been
described. Other embodiments are within the scope of the following
claims. In some cases, the actions recited in the claims can be
performed in a different order and still achieve desirable results.
In addition, the processes depicted in the accompanying figures do
not necessarily require the particular order shown, or sequential
order, to achieve desirable results. In certain embodiments,
multitasking and parallel processing may be advantageous.
* * * * *