U.S. patent application number 16/868267 was filed with the patent office on 2021-05-27 for state characterization based on multi-variate data fusion techniques.
The applicant listed for this patent is Proteus Digital Health, Inc.. Invention is credited to Yashar BEHZADI.
Application Number | 20210158927 16/868267 |
Document ID | / |
Family ID | 1000005381223 |
Filed Date | 2021-05-27 |
View All Diagrams
United States Patent
Application |
20210158927 |
Kind Code |
A1 |
BEHZADI; Yashar |
May 27, 2021 |
STATE CHARACTERIZATION BASED ON MULTI-VARIATE DATA FUSION
TECHNIQUES
Abstract
The ingestible event marker data framework provides a uniform,
comprehensive framework to enable various functions and utilities
related to ingestible event marker data (IEM data). Included are a
receiver adapted to be associated with a body of an individual, the
receiver configured to receive IEM data; a hub to receive the IEM
data; and at least one IEM data system to receive the data from the
hub. Among other information, behavioral data and predictive
inferences may be provided.
Inventors: |
BEHZADI; Yashar; (San
Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Proteus Digital Health, Inc. |
Redwood City |
CA |
US |
|
|
Family ID: |
1000005381223 |
Appl. No.: |
16/868267 |
Filed: |
May 6, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15469052 |
Mar 24, 2017 |
10682071 |
|
|
16868267 |
|
|
|
|
13844386 |
Mar 15, 2013 |
9603550 |
|
|
15469052 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
A61B 5/07 20130101; G16H
20/10 20180101; A61B 5/021 20130101; A61B 5/0022 20130101; G16H
20/60 20180101; G16H 40/67 20180101; G16H 20/30 20180101 |
International
Class: |
G16H 20/30 20060101
G16H020/30; G16H 20/10 20060101 G16H020/10; G16H 20/60 20060101
G16H020/60; A61B 5/07 20060101 A61B005/07; A61B 5/00 20060101
A61B005/00 |
Claims
1-16. (canceled)
17. An Ingestible Event Marker (IEM) data system, comprising: a
processor; a receiver configured to receive a signal comprising IEM
data, wherein the signal is transmitted from an IEM device within a
body of an individual; and a memory component configured to store
instructions that, when executed by the processor, cause the
processor to: determine a metric based, at least in part, on the
IEM data received from within the IEM device; and generate
predictive information associated with a state of the ingesting
patient based, at least in part, on the determined metric.
18. The IEM data system of claim 17, wherein the IEM data system
further comprises a transmitter, wherein the transmitter and
receiver are collectively configured to communicably couple the IEM
data system to a hub.
19. The IEM data system of claim 18, wherein the hub comprises a
software agent configured to aggregate the IEM data and additional
information associated with the individual.
20. The IEM data system of claim 19, wherein the additional
information comprises a time of ingestion or a biometric associated
with the individual.
21. The IEM data system of claim 19, further comprising a feedback
loop system, wherein the feedback loop system is configured to:
aggregate IEM data from the IEM data system and the second IEM data
system; analyze the aggregated IEM data; and generate feedback
information associated with the individual based, at least in part,
on the analysis of the aggregated IEM data.
22. The IEM data system of claim 21, wherein the software agent is
further configured to forward the aggregated IEM data and
additional information to the feedback loop system.
23. The IEM data system of claim 19, wherein the hub comprises a
mobile telephone associated with the individual.
24. The IEM data system of claim 17, wherein the IEM data system
further comprises a transmitter, wherein the transmitter and
receiver are collectively configured to communicably couple the IEM
data system to a second IEM data system, and wherein the processor
is configured to interoperate with the second IEM data system to
manage the IEM data.
25. The IEM data system of claim 24, wherein the second IEM data
system comprises a medical database, and wherein the IEM data
system is further configured to manage the IEM data based, at least
in part, medical data stored in the medical database.
26. The IEM data system of claim 19, wherein the processor is
further configured to manage an activity associated with the
individual based, at least in part, on the IEM data.
27. The IEM data system of claim 20, wherein the activity is
associated with a bill to be sent to the individual.
28. The IEM data system of claim 17, wherein the memory component
is further configured to store an analysis module, a metrics
module, and a predictive information module, wherein the analysis
module, the metrics module, and the predictive information module
are configured to collectively cause the processor to generate the
predictive information.
29. The IEM data system of claim 17, wherein the IEM data system is
built around predefined function, and wherein the IEM data system
is configured via an IEM data framework.
30. The IEM data system of claim 17, wherein the IEM data system is
built around a predefined business function and is enabled via an
IEM data framework comprising at least one of a hub, a second IEM
data system, and a feedback loop system, or combinations
thereof.
31. An Ingestible Event Marker (IEM) system comprising: an IEM data
collection system comprising: a processor; a receiver configured to
receive a signal comprising IEM data, wherein the signal is
transmitted from an IEM device within a body of an individual; and
a memory component configured to store instructions that, when
executed by the processor, cause the processor to: determine a
metric based, at least in part, on the IEM data received from
within the IEM device; and generate predictive information
associated with a state of the ingesting patient based, at least in
part, on the determined metric; and an IEM data aggregation system
communicably coupled to the IEM data collection system, wherein the
IEM data aggregation system is configured to aggregate the IEM data
from the IEM data collection system with additional information
from a secondary source.
32. The IEM data system of claim 31, wherein the IEM data
aggregation system comprises a feedback loop system, wherein the
feedback loop system is configured to: aggregate IEM data from the
IEM data system and the secondary source; analyze the aggregated
IEM data; and generate feedback information associated with the
individual based, at least in part, on the analysis of the
aggregated IEM data.
33. The IEM data system of claim 31, wherein the IEM data
aggregation system comprises a hub.
34. The IEM data system of claim 33, wherein the hub comprises a
software agent configured to aggregate the IEM data and additional
information associated with the individual.
35. The IEM data system of claim 33, wherein the hub comprises a
mobile telephone associated with the individual.
36. The IEM data system of claim 31, wherein the secondary source
comprises a medical database, and wherein the IEM data aggregation
system is configured to aggregate the IEM data from the IEM data
collection system with medical data stored in the medical
database.
37. The IEM data system of claim 36, wherein the IEM data system is
further configured to manage an activity associated with the
individual based, at least in part, on the IEM data.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent
application Ser. No. 12/522,249, filed on Jul. 6, 2009 and entitled
"Ingestible Event Marker Data Framework", published on Jan. 13,
2011 as US Publication No. US-2011-0009715, which application is a
371 application of PCT/US09/49618, filed on Jul. 2, 2009, which
application, pursuant to 35 U.S.C. .sctn. 119(e), claims priority
to the filing date of U.S. Provisional Patent Application Ser. No.
61/079,082, filed on Jul. 8, 2008, the disclosures of which
applications are herein incorporated by reference.
INTRODUCTION
[0002] The present invention relates generally to the technical
fields of ingestible devices and communications. More specifically,
and in various example embodiments, the present invention relates
to a method, article, and system of generating, collecting,
managing, distributing, and otherwise utilizing information
associated with ingestible events and responses to the ingestible
events
[0003] Information related to personal events is widely needed in
various pursuits. A personal event is an event that is specific to
an individual. Examples of personal events include onset of a
physiologic parameter of interest, ingestion of a therapeutic
agent, etc.
[0004] There are many instances where one may want to note a
personal event. Examples of such instances include onset of one or
more physiologic parameters of interest including appearance of
disease symptoms, administration of medication, ingestion of
certain types of foods, commencement of an exercise regimen,
ingestion of certain substance, etc.
[0005] A variety of different methods and technologies have been
developed to note a personal event. For example, techniques have
been developed in which individuals can manually record data in a
log or physically enter data via a computer device.
[0006] The accuracy of such notations may be dependent on the
accuracy of data input, the accuracy of proxies used as actual data
substitutions, etc. As a result, inaccuracies may occur.
[0007] In one example, an individual may suffer from one or
multiple health conditions that require therapy with multiple
medications. The multiple medications may be prescribed according
to an intricate dosing schedule. The complexities associated with
multiple health conditions, multiple medication therapies, and
intricate dosing schedules may confuse the patient, resulting in
inaccurate data capture.
[0008] In one example, the individual may have physical or
cognitive deficits which may result in difficulties inputting and
capturing data. The individual may forget to enter the data, or may
enter the data incorrectly.
[0009] In one example, the individual may not wish to be
inconvenienced and thus may intentionally refuse to enter the data.
Conversely, the individual may unintentionally or intentionally
enter/record data which is completely inaccurate. For example, the
individual may receive periodic, prescheduled reminders to take
some medication. The reminders are unable to take into account
actual ingestion of the medication. If the individual has already
taken the medication, the reminder is both moot and likely to
inconvenience the individual. If the medication has not been taken,
an inconvenient or unneeded reminder or alert may prompt the user
to enter data or send a message advising that the medication has
been taken just to quell the alarm while not actually taking the
medication. The individual may intentionally leave out portions of
the data.
[0010] In one example, proxies for data and information may also be
inaccurate. For example, "intelligent" medication containers may
contain microchips that sense opening of the medication container.
From the sensed act of opening the container, an inference may be
drawn that medication associated with the medication container has
been ingested. The inference may be inaccurate, however, as
medication is not necessarily ingested by virtue of opening a
medication container.
[0011] The above-instances may ripen into further issues if
particular parties besides the individual wish to use the
individual's personal event data. Examples of users and potential
users (sometimes collectively referred to herein as "party" or
"parties") of personal event data include family and professional
caregivers; communication companies; government agencies, e.g.,
agencies associated with government provided healthcare coverage;
private insurance providers; Food and Drug Administration (FDA);
Drug Enforcement Administration (DEA); US Bureau of Alcohol,
Tobacco, and Firearms (ATF); care providers; medical device
manufacturers; patients; clinicians; pharmaceutical manufacturers;
pharmacies; web communities; software providers; marketing and
financial analysts; and insurance companies.
[0012] Competing interests may exist between an individual's
privacy interests in personal event data and the acquisition and
appropriation of the personal event data by third parties.
[0013] Further, various parties may have a compelling interest in
receipt of accurate and comprehensive data, e.g., useful data,
either in isolated form (data germane to a particular individual)
or empirical form (aggregated data from various sources, various
individuals, various personal events of an individual, etc.)
[0014] In many circumstances, however, accurate personal event data
are not available. The party may have access to faulty data or a
crude approximation of the information sought, as discussed above.
Thus, the party must rely on such crude proxies to formulate a
conclusion. It follows, then, that such conclusions may themselves
be skewed or inaccurate. Actions taken in reliance on such
conclusions may prove misguided, error-prone, and/or harmful.
[0015] To illustrate, a healthcare provider or family member may
receive a message from a patient indicating that the patient has
taken the medication when, in fact, the patient is merely providing
the message without having actually ingested the medication. If the
healthcare provider notices changes in the patient's symptoms in
close temporal proximity to receipt of the flawed information
suggesting medication ingestion, the healthcare provider may
mistakenly conclude that the patient's symptoms are a result of the
medication ingestion. Based on the mistaken conclusion, the
healthcare provider may adjust the medication dosage in an attempt
to alleviate the symptoms, perhaps to the patient's detriment.
[0016] Of note, the more widely propagated and aggregated the
inaccurate data, the more prolific the spread of and reliance on
error-associated data and conclusions drawn therefrom.
[0017] In addition, recipients of the personal event data may wish
to timely receive and utilize such information via a user-friendly,
reliable and sophisticated means. The recipients may wish to
receive and/or utilize information in discrete areas, integrate the
personal event information with other data, and use the personal
event information for various purposes.
[0018] Examples of various purposes include refining and optimizing
data such as patient population data; incentivizing individuals or
groups based on personal event data, e.g., ingestible event marker
data ("IEM data"); corroborating and advancing decisions;
supporting stakeholders' decisions; using IEM data in personalized
products and services, e.g., user applications on a mobile
telephone; auto refilling prescription medications; managing
pharmaceutical life cycle systems and controlled substances;
compiling and delivering IP news and information feeds; accessing
open sources of anonymized patient population data; determining
eligibility and approval for refills, insurance coverage, etc.;
using patient tools; participating in social network systems;
analyzing aggregated data to derive and/or generate predictive
information; supporting and enabling financial transactions;
identifying direct and indirect causal failure points in treatment
and predict corrective action; and providing dynamic, accurate
calendaring/scheduling functions.
[0019] Finally, parties may also wish to access personal event data
in conjunction with existing systems, e.g., commercial systems such
as automated pharmacy systems, banking and financial systems,
etc.
[0020] As can be seen, methods and systems are needed to seamlessly
collect, manage, and distribute personal event data to various
parties and systems.
[0021] Therefore, there is a need for controlled collection,
management, and delivery of accurate personal event data to
multi-profile parties for various purposes.
BRIEF SUMMARY OF THE INVENTION
[0022] The ingestible event marker data framework provides a
uniform, comprehensive framework to enable various functions and
utilities related to ingestible event marker data (IEM data). The
functions and utilities include data and/or information having an
aspect of data derived from, collected by, aggregated by, or
otherwise associated with, an ingestion event. In one example, the
IEM data are generated via an ingested device. The term "ingested
device" includes any device, mechanism, structure, combined
structure, or object capable of ingestion by a human subject or a
non-human subject.
[0023] The IEM data framework is highly scalable and integratable
with various existing systems, e.g., systems having
computer-related component(s). Specific examples of such systems
include pharmacy systems, communication systems, financial and
banking systems, school systems, medical systems, government
agencies, web communities, and personal computer systems. Such
existing systems are herein collectively referred to as "commercial
systems".
[0024] The IEM data framework enables multiple and various types of
implementations. The implementations include various configurations
of hardware, software, communication components, and/or data. For
example, in one aspect, the IEM data framework is implemented with
a basic complement of core components; namely, ingestible event
marker data; a hub to receive the ingestible event marker data; and
at least one ingestible event marker data system to receive,
directly or indirectly, the ingestible event marker data from the
hub.
BRIEF DESCRIPTION OF THE FIGURES
[0025] FIG. 1 provides a diagrammatic representation of a
communication environment including an IEM data framework,
according to one embodiment.
[0026] FIG. 2 provides a diagrammatic representation of the IEM
data framework of FIG. 1, according to one embodiment.
[0027] FIG. 3 illustrates IEM data and an IEM data environment
associated with the IEM data framework of FIG. 2, according to one
embodiment.
[0028] FIG. 4 illustrates a hub associated with the IEM data
framework of FIG. 2, according to one embodiment.
[0029] FIG. 5 illustrates exemplary IEM data systems associated
with the IEM data framework of FIG. 2, according to one
embodiment.
[0030] FIG. 6 illustrates an exemplary IEM data framework having a
feedback loop system, according to one embodiment.
[0031] FIG. 7 illustrates an exemplary IEM data framework having a
decision support system, according to one embodiment.
[0032] FIG. 8 illustrates an exemplary IEM data framework having
auto refill system, according to one embodiment.
[0033] FIG. 9 illustrates an exemplary IEM data framework having
patient tools, according to one embodiment.
[0034] FIG. 10 illustrates an exemplary IEM data framework having a
behavioral medicine system, according to one embodiment.
[0035] FIG. 11 illustrates an exemplary IEM data framework having
an incentive system, according to one embodiment.
[0036] FIG. 12 illustrates an exemplary IEM data framework having a
personalized commercial products/services system, according to one
embodiment.
[0037] FIG. 13 illustrates an exemplary IEM data framework having
an auto billing system, according to one embodiment.
[0038] FIG. 14 illustrates an exemplary IEM data framework having a
tracking system, according to one embodiment.
[0039] FIG. 15 illustrates an exemplary IEM data framework having
an interdiction system, according to one embodiment.
[0040] FIG. 16 illustrates an exemplary IEM data framework having a
subscription system, according to one embodiment.
[0041] FIG. 17 illustrates an exemplary IEM data framework having
an ingestible event marker data collection system, according to one
embodiment.
[0042] FIG. 18 illustrates an exemplary IEM data framework having
an approval system, according to one embodiment.
[0043] FIG. 19 illustrates an exemplary IEM data framework having a
forecasting system, according to one embodiment.
[0044] FIG. 20 illustrates an exemplary IEM data framework having a
financial system, according to one embodiment.
[0045] FIG. 21 illustrates an exemplary IEM data framework having
an ingestible event marker data phone system, according to one
embodiment.
[0046] FIG. 22 illustrates an exemplary IEM data framework having a
social network system, according to one embodiment.
[0047] FIG. 23 illustrates exemplary modules of software of an
exemplary IEM data system.
[0048] FIGS. 24a and 24b illustrate sample IEM data and sample
metrics.
DETAILED DESCRIPTION
1.0 Overview
2.0 Ingestible Event Marker (IEM) Data Framework
[0049] 2.1 IEM Data
[0050] 2.1.1 IEM Data Environment [0051] 2.1.1.1 IEM Data Source
Devices [0052] 2.1.1.2 Products [0053] 2.1.1.3 Events [0054]
2.1.1.4 Patient Specific Parameters [0055] 2.1.1.5 IEM Data
Algorithms [0056] 2.1.1.6 Storage Repositories [0057] 2.1.1.7 Other
IEM Data Sources
[0058] 2.2 Hub
[0059] 2.3 IEM Data Systems [0060] 2.3.1 Feedback Loops [0061]
2.3.2 Decision Support Systems [0062] 2.3.3 Auto Refill Systems
[0063] 2.3.4 Patient Tools [0064] 2.3.5 Behavioral Medicine Systems
[0065] 2.3.6 Incentive Systems [0066] 2.3.7 Personalized Commercial
Products/Services [0067] 2.3.8 Auto Billing Systems [0068] 2.3.9
Tracking Systems [0069] 2.3.10 Interdiction Systems [0070] 2.3.11
Subscription Systems [0071] 2.3.12 IEM Data Collection Systems
[0072] 2.3.13 Approval Systems [0073] 2.3.14 Forecasting Systems
[0074] 2.3.15 Financial Systems [0075] 2.3.16 IEM Data Phone [0076]
2.3.17 Social Network System
3.0 IEM Data Framework Method
4.0 IEM Data Framework Article
5.0 IEM Data Framework System
6.0 IEM Data Framework Data Modeling and Prescriptive Outcomes
1.0 Overview
[0077] The ingestible event marker (IEM) data framework provides an
integrated, seamless solution to enable the collection, management,
distribution, and utilization of IEM data. The versatile IEM data
framework facilitates integration and implementation of the IEM
data with existing data and utilization of the IEM data with
existing systems, i.e., commercial systems. The information and
communication systems include discrete systems, cross-configured
systems, and hybrid systems.
[0078] Broadly, various aspects of the IEM data framework include a
basic complement of core components, e.g., IEM data; a hub; and at
least one IEM data system. Any one or a combination of these core
components is capable of interoperation, communication, and/or
integration with various components of other
information/communication systems. The terms "data" and
"information" are used interchangeably herein.
[0079] The IEM data include information about an ingestion event,
information about a response to the ingestion event, or both. The
information about an ingestion event may include, for example,
information about the ingestion event of a medication or set of
medications. The information about a response to the ingestion
event may include, for example, physiologic parameter(s) such as a
physiologic status or physiologic change event based on the
ingestion event. A physiologic status may be, for example, a heart
rate, blood pressure measure, etc., ascertained in close temporal
proximity to the time of ingestion of medication (and, therefore,
likely to be influenced by or a result of ingestion of the
medication.)
[0080] Examples of IEM data include data ingestion time(s) of
medication, identification of the type(s) of medication ingested at
a particular time, the dosage amounts of medication ingested at a
particular time, etc.
[0081] Typically, the IEM data may be generated and/or communicated
via an ingestible device such as an ingestible event marker (IEM),
which generates and communicates data associated the ingestion
event. The IEM may be associated, for example, with a receiver,
i.e., a device capable of receiving the IEM data on ingestion and
further capable of measuring additional IEM data on response to the
ingestion event(s). The IEM and the receiver are discussed in
detail hereinafter. In various aspects, the ingestible event data
may originate from multiple ingested event markers. In various
aspects, the IEM data may be communicated directly from the IEM to
a device other than the receiver, e.g., an IEM business system
adapted to receive the IEM data directly from the IEM via a
communication channel.
[0082] In various aspects, the IEM data may be associated with
other data, e.g., combined with data related to events other than
an ingestion event or response(s) to an ingestion event. Some
examples of other data are data associated with various medical
devices and data associated with consumer and personal devices such
as intelligent devices/appliances. All are discussed in greater
detail hereinafter.
[0083] In various aspects, the IEM data may be associated with an
IEM data environment and/or commercial systems.
[0084] In various aspects, the IEM data may be associated with a
unique identifier, e.g., sample data reflective of physiologic
patterns associated with a particular individual such as heart rate
variability, breathing rate, and/or heart rate (ECG) patterns. For
example, a portion or all of the IEM data may be compared with a
unique identifier generated by or stored on the receiver.
[0085] The hub includes any hardware device, software, and/or
communications component(s), as well as systems, subsystems, and
combinations of the same which generally function to communicate
the IEM data. Communication of the IEM data includes receiving,
storing, manipulating, displaying, processing, and/or transmitting
the IEM data.
[0086] In various aspects, the hub also functions to communicate,
e.g., receive and transmit, non-IEM data. Non-IEM data includes
non-IEM physiologic data. One example is cardiac data generated by
a separate cardiac-related device such as an implanted pacemaker
and communicated to the hub directly or indirectly, e.g., via the
receiver.
[0087] Broad categories of hubs include, for example, base
stations, personal communication devices, and mobile
telephones.
[0088] For example, the hub includes a software application
associated with a mobile telephone of a patient. The application
and mobile telephone function to receive IEM data from a receiver,
which, in turn, receives the IEM data from an ingestible device
ingested by the patient. The hub stores, manipulates, and/or
forwards the IEM data, alone or in combination with other data, to
an IEM data system.
[0089] The IEM data systems include any hardware device, software,
and/or communications component, as well as systems and subsystems
of the same, which generally function to provide a service or
activity related to the IEM data. The IEM data systems, for
example, collect, manipulate, calculate, transmit, receive, store,
and/or communicate at least a portion of the IEM data.
[0090] Each IEM data system may be built around predefined
function(s) or service(s) and may be enabled via the IEM data
framework.
[0091] One or more IEM data systems may be integrated,
interoperate, intercommunicate or otherwise share or further the
collection, management, distribution/dissemination, billing or
other activities related to IEM data. One example of an IEM data
system is a feedback loop system to refine and optimize IEM data
and other data, e.g., medical database data.
[0092] Various aspects of the IEM data framework provide on-demand,
accurate and efficient services with respect to provision and
utilization of IEM data, while reducing redundancies, errors, and
inaccuracies associated with personal event data that are sometimes
found in the prior art. Various aspects of the IEM data framework
further ensure generation and communication of accurate IEM data in
a timely manner.
[0093] Further, the IEM data framework is applicable to any
communication environment. Communication environments include any
environment having therein, or associated with, data or
communication of data.
[0094] Various aspects of the IEM data framework utilize the IEM
data, the hub, and one or more IEM data systems to enable useful,
secure, and efficient use of the IEM data among multi-profile
parties in one or various communication environments.
[0095] FIG. 1 provides a diagrammatic representation of
communication environment 100 including an IEM data framework 102,
according to one embodiment. The communication environment 100 may
further include, for example, an IEM data environment 104 and one
or more commercial systems 106.
[0096] Communication environment 100 includes any environment
having therein, or associated with, data or communication of data.
Communication includes any method, act, or vehicle of
communication, and/or combinations thereof. For example,
communication methods include manual, wired, and wireless, etc.
Wireless technologies include radio signals, such as x-rays,
ultraviolet light, the visible spectrum, infrared, microwaves, and
radio waves, etc. Wireless services include voice and messaging,
handheld and other Internet-enabled devices, data networking,
etc.
[0097] Vehicles of communication include the Internet, wired
channels, wireless channels, communication devices including
telephones, computers, wire, radio, optical or other
electromagnetic channels, and combinations thereof, including other
devices and/or components capable of/associated with communicating
data. For example, the communication environments include in-body
communications; various devices; various modes of communications
such as wireless communications, wired communications, and
combinations of the same, etc.
[0098] In-body communications include any communication of data or
information via the body, i.e., communication via or associated
with inter-body aspects, intra-body aspects, and a combination of
the same. For example, inter-body aspects include communications
associated with devices designed to attach to a body surface.
Intra-body aspects include communications associated with data
generated from within the body, e.g., by the body itself or by a
device implanted, ingested, or otherwise locatable in, or partially
in, the body.
[0099] Communications include and/or may be associated with
software, hardware, circuitry, various devices, and combinations
thereof.
[0100] The devices include devices associated with IEM data
generation, transmission, reception, communication, etc. The
devices further include various implantable, ingestible,
insertable, and/or attachable devices associated with the human
body or other living organisms. The devices further include
multimedia devices such as telephones, stereos, audio players,
PDA's, handheld devices, and multimedia players.
[0101] Wireless communication modes include any mode of
communication between points that utilizes, at least in part,
wireless technology including various protocols and combinations of
protocols associated with wireless transmission, data, and devices.
The points include, for example, wireless devices such as wireless
headsets; audio and multimedia devices and equipment, such as audio
players and multimedia players; telephones, including mobile
telephones and cordless telephones; and computers and
computer-related devices and components, such as printers.
[0102] Wired communication modes include any mode of communication
between points that utilizes wired technology including various
protocols and combinations of protocols associated with wired
transmission, data, and devices. The points include, for example,
devices such as audio and multimedia devices and equipment, such as
audio players and multimedia players; telephones, including mobile
telephones and cordless telephones; and computers and
computer-related devices and components, such as printers.
[0103] The IEM data framework 102 enables exchange, transmission,
receipt, manipulation, management, storage, and other activities
and events related to IEM data. Such activities and events may be
contained within the IEM data framework 102, partially integrated
with the IEM data framework 102, or associated with externalities,
e.g., activities, systems, components, and the like which are
external to the IEM data framework 102. Externalities include, for
example, the IEM data environment 104 and commercial systems 106,
either or both of which may also be integral to, or partially
integrated with, the IEM data framework 102.
[0104] The IEM data environment 104 includes any source of
information or data, including remote computer systems, local
computer devices, etc. The information or data may comprise IEM
data in whole or in part. The information or data may also be
independent of the IEM data, e.g., may be capable of aggregation
and/or integration with the IEM data.
[0105] The commercial systems 106 include various existing systems
that utilize one or various types of data to accomplish a
particular purpose. One example of a commercial system is a
computerized pharmacy system utilized in a pharmacy. The
computerized pharmacy system may function to automatically, e.g.,
electronically, receive prescriptions, verify patient and
prescription information, verify insurance coverage, process the
prescription order, and generate an invoice.
[0106] The IEM data framework 102, the IEM data environment 104,
and the commercial systems 106 are discussed in greater detail
hereinafter.
2.0 IEM Data Framework
[0107] FIG. 2 provides a diagrammatic representation of the IEM
data framework 102 of FIG. 1, according to one embodiment. The IEM
data framework 102 includes IEM data 200, hub 202, and one or more
IEM data systems 204.
[0108] The IEM data 200 include data associated with an ingestion
event, i.e., an act of ingestion. Additionally, the IEM data 200
may include, be included in, or be combined with data from other
systems or sources, e.g., medical devices, local or remote computer
devices and systems, etc. An example of the IEM data 200 is data
having an identification of the type of an ingested medication and
the time at which the medication was ingested.
[0109] The hub 202 includes any hardware, software, and/or
communications component(s) in any combination/configuration, which
generally function to communicate the IEM data 200. One example
includes communicating the IEM data 200 to the IEM data systems
204. For example, the hub 202 receives the IEM data 200 from an
ingested device and forwards the IEM data 200, alone or in
combination with other data from other sources, to an IEM data
system 204.
[0110] The IEM data systems 204 provide discrete services and/or
activities related to the IEM data 200. The discrete services
and/or activities include, for example, propagation of information,
data, etc., to a particular user, or group of users, via various
system component configurations, etc.
[0111] In one example, an auto refill system receives IEM data 200
from the hub 202. The IEM data 200 include an indication that the
last remaining pill of a prescription has been ingested. The auto
refill system uses this information to contact a local or remote
data resource having refill information, verify the refill
information, and automatically transmit a request to a pharmacy
system (commercial system) for refill of the prescription.
[0112] 2.1 IEM Data
[0113] The ingestible event marker (IEM) data 200 are associated
with at least one of an ingestion event and a response to the
ingestion event. The ingestion event may be associated with, for
example, data related to and/or gathered during transit through the
alimentary system, e.g., oral cavity, pharynx, esophagus, stomach,
small intestine, large intestine, anus, etc. Examples of IEM data
include an ingestion time, identification of ingested substance,
expiration date of an associated medication, dosage of an ingested
substance, etc. The information about an ingestion event may
include, for example, information about the ingestion event of a
medication or set of medications. The information about a response
to the ingestion event may include, for example, physiologic
parameter(s) such as a physiologic status or physiologic change
event based on the ingestion event. A physiologic status may be,
for example, a heart rate, blood pressure measure, etc.,
ascertained in close temporal proximity to the time of
ingestion.
[0114] In various aspects, the IEM data 200 typically may be
generated via one or more ingestible event markers (IEMs),
discussed hereinafter in detail. The generation of IEM data via
multiple IEMs ensures comprehensive data reporting, e.g., data
generated from multiple ingestion events of multiple IEMs over a
time interval, data generated from multiple IEMs ingested at
approximately the same time, etc. In this manner, comprehensive IEM
data may be provided.
[0115] In various aspects, the IEM data may be communicated to,
i.e., received by, a receiver. The receiver may be embodied in
various ways, including an implantable device, a semi-implantable
device such as a subcutaneous device, and an externally-applied
device such as a personal signal receiver. One example of a
personal signal receiver is a "patch" receiver which may be
removably affixed to the individual's person, apparel, etc.
[0116] In various aspects, the IEM data 200 can be associated with
other data, e.g., a personal event not associated with an ingestion
event or a response to an ingestion event. A personal event
includes any parameter or circumstance associated with a person,
e.g., any event associated with ingestion, inhalation, injection,
implantation, insertion, and/or imbibing of a device, substance,
liquid, etc. A personal event further includes any event associated
with personal data, e.g., a physiologic parameter such weight.
[0117] In various aspects, the IEM data may be associated with a
unique identifier, e.g., heart rate variability, breathing rate,
and/or heart rate (ECG) patterns associated with a particular
individual. The unique identifier may be variously embodied. One
example is a personal identifier assigned to an individual, e.g.,
an alphanumeric code, etc. Another example is a unique identifier
reflective of an individual trait, such as a physiologic
pattern.
[0118] To illustrate, a patient may ingest an IEM (discussed
hereinafter) integrated with medication. The IEM may communicate
IEM data to a receiver such as a patch receiver (discussed
hereinafter). The data may include, for example, a unique
identifier which may be compared to data associated with the
receiver for validation purposes.
[0119] In one scenario, the IEMs associated with medication
prescribed for a particular patient may each be encoded and
deployed with corresponding unique identifiers. The unique
identifier may be, for example, a predetermined physiologic data
sample associated the particular patient. Various physiologic data
samples include a data sample reflective of the particular
patient's heart rate variability, a data sample reflective of the
particular patient's breathing rate, a data sample reflective of
the particular patients heart rate (ECG) patterns, etc.
[0120] When the receiver is affixed or otherwise associated with an
individual, programming logic associated with the receiver may
receive actual data samples of the individual, e.g., from data
sources such as heart devices, etc. The receiver may communicate
the actual data samples received from the data sources and the
unique identifier(s) received from the IEM(s) to a computer-related
device, e.g., a server, which may compare the actual data samples
of the individual with the unique identifier to verify that the
medication was actually ingested by the particular patient for whom
it was prescribed. In various aspects, predetermined actions based
on the verification outcome may be taken, e.g., alerts may be sent
to a device associated with the prescribing physician, etc.
[0121] 2.1.1 IEM Data Environment
[0122] In various embodiments, IEM data 200 are generated,
received, gathered, etc., from one or a variety of sources and
comprise various structures, content, types, etc. The IEM data
environment includes at least one of an IEM data source device,
products, events, patient specific parameters, IEM data algorithms,
and storage repositories. The sources include, for example, various
devices, storage repositories, and systems capable of generating,
identifying, gathering or otherwise producing data related to
ingestion, the ingestion environment, e.g., the alimentary system
of a human subject or non-human subject and/or other personal
events. The types include, for example, raw data, processed data,
aggregated data, combined data, data from various sources, etc. The
processed data include, for example, data processed according to a
variety of methods, e.g., algorithms such as IEM data algorithms
discussed below.
[0123] FIG. 3 illustrates IEM data environment 104 associated with
the IEM data framework 102 of FIG. 2, according to one embodiment.
The IEM data environment 104 includes, for example, IEM data source
devices 300, products 302, events 304, patient specific parameters
306, IEM data algorithms 308, storage repositories 310, and other
sources 312.
[0124] 2.1.1.1 IEM Data Source Devices
[0125] The ingestible event marker (IEM) data source devices 300
include, for example, devices capable of gathering, collecting,
generating, receiving, storing and/or transmitting, etc., IEM data.
One example of such a device is a microchip capable of or otherwise
enabling or facilitating the collection, generation, receipt,
transmission, etc., of data. Such a microchip may be integrated or
associated with the IEM data source devices 300. The IEM data
source devices 300 may be embodied, for example, as ingestible
devices 300a, receivers 300b, and/or health devices 300c.
[0126] In various aspects, IEM data may be related to various
devices. For example, a device may be an ingestible device, an
inhalable device, an injectable device, an implantable device, an
insertable device, and an imbibable device. The foregoing may be
embodied, for example, as a microchip alone or in combination with
other structural components, each capable of at least one of
ingestion, inhalation, injection, implantation, insertion, and
imbibement by a human body or a non-human body.
[0127] The ingestible device may comprise, for example, a
microchip. The microchip may be independently deployed. The
microchip may also be attached to, embedded in, or otherwise
integrated with a medication, e.g., a pill (refer to IEM system,
infra).
[0128] The inhalable device may comprise, for example, a microchip.
The microchip may be independently deployed. The microchip may also
be attached to, embedded in, or otherwise integrated with a device.
The inhalable device is capable of ascertaining parameter(s)
associated with inhalation, e.g., measuring or tallying doses of an
inhalant. The inhalable device may also comprise, for example, an
inhalable microchip used to ascertain parameter(s), e.g.,
inhalation time, identify an inhaled substance, etc.
[0129] The injectable device may comprise, for example, a
microchip. The microchip may be independently deployed. The
microchip may also be attached to, embedded in, or otherwise
integrated with a device. The injectable device is capable of
ascertaining parameter(s) associated with injection, e.g., time of
injection, identification of an injected substance, etc. In various
aspects, the injectable device is capable of injection into a human
body or a non-human body, e.g., injection into the circulatory
system of a human body.
[0130] The implantable device may comprise, for example, a
microchip. The microchip may be independently deployed. The
microchip may also be attached to, embedded in, or otherwise
integrated with a device. The implantable device is capable of
ascertaining parameter(s) associated with implantation, e.g., time
of implantation, physiologic parameters such as heart rate, EKG
data, activity management data, temperature, galvanic skin response
data, respiratory data, fluid status data, heart rate variability,
etc.
[0131] In one aspect, the implantable device is embodied as an
implantable receiver, supra, for receiving various data. The
implantable receiver may also process, store, transmit, etc. the
data. Various other implantable devices include, for example, heart
monitors and the like having a microchip to ascertain parameter(s),
e.g., heart rate, heart pressure, etc.
[0132] The insertable device may comprise, for example, a
microchip. The microchip may be independently deployed. The
microchip may also be attached to, embedded in, or otherwise
integrated with a device. The insertable device is capable of
ascertaining parameter(s) associated with insertion, e.g., time of
insertion, physiologic parameters such environmental content/fluid
identification, etc. In one aspect, the insertable device is
embodied as a microchip mechanically associated with a suppository
for rectal insertion, vaginal insertion, etc.
[0133] The imbibable device may comprise, for example, a microchip.
The microchip may be independently deployed. The microchip may also
be attached to, embedded in, or otherwise integrated with a
substance, e.g., a potable solution or fluid such as a beverage,
etc. The imbibable device is capable of ascertaining parameter(s)
associated with imbibing, e.g., time of drinking, physiologic
parameters such as environmental content/fluid identification, etc.
In one aspect, the imbibable device is embodied as a microchip and
imbibed together with a beverage. The beverage may aid in
swallowing, may be used as a medication, etc.
[0134] Further, the IEM data may be associated with administration
of a therapeutic agent, etc. For example, administration includes,
but is not limited to, parenteral administration, i.e.,
administration in a manner other than through the alimentary
system, such as by intravenous or intramuscular injection or
inhalation.
[0135] In some aspects, the devices are capable of ingestion, i.e.,
entry into the alimentary system of a human body or a non-human;
inhalation (either the device or a substance associated with the
device, e.g., a nasal inhalant). In various aspects the devices are
capable of injection, insertion, implantation and/or imbibing,
etc., into/by a human body or a non-human body.
[0136] The ingestible devices 300a gather/collect/generate IEM data
via various methods, e.g., ingestion timing, contact with
alimentary system substances, sampling, etc. Further, various
ingestible event marker data source devices 300 communicate the IEM
data via various methods, e.g., wireless methods, conductive
methods via body tissue, etc. The following are examples of the
ingestible devices 300a.
[0137] A pharma-informatics system described in PCT/US2006/016370,
filed Apr. 28, 2006, includes compositions, systems and methods
that allow for the detection of the actual physical delivery of a
pharmaceutical agent to a body are provided. Embodiments of the
compositions include an identifier and an active agent.
[0138] An IEM system described in PCT/US2008/52845, filed Feb. 1,
2008, includes an ingestible event marker (IEM) and a personal
signal receiver. Aspects of the IEM include an identifier, which
may or may not be present in a physiologically acceptable carrier.
The identifier is characterized by being activated upon contact
with a target internal physiological site of a body, such as
digestive tract internal target site. The personal signal receiver
is configured to be associated with a physiological location, e.g.,
inside of or on the body, and to receive a signal of the IEM.
During use, the IEM broadcasts a signal which is received by the
personal signal receiver.
[0139] The IEM data associated with the IEM system include personal
data, e.g., physiologic data generated by the IEM. Examples are
derived metrics, e.g., processed physical data to derive various
metrics such as time of ingestion data; combined metrics, e.g.,
derived metrics combined with other derived metric data such as
time of ingestion data combined with data identifying the ingested
substance; and IEM data, e.g., derived metrics and/or combined
metrics aggregated with various physiologic data such as time of
ingestion data combined with data identifying the ingested
substance and physiologic data such as ECG data, temperature,
etc.
[0140] A controlled activation ingestible identifier described in
PCT/US07/82563, filed Oct. 17, 2007, includes ingestible
compositions such as pharma-informatics enabled compositions. The
controlled activation ingestible identifiers include a controlled
activation element that provides for activation of the identifier
in response to the presence of a predetermined stimulus at a target
site of interest.
[0141] A life cycle pharma informatics system described in U.S.
Patent Application Ser. No. 61/034,085, filed Mar. 5, 2008 includes
RFID and conductive communications technology combined with
medication and/or medication packaging such that the medication can
be tracked for the duration of its existence. The system further
allows in-body data transmissions while addressing the potential
privacy and signal degradation concerns associated with RFID
technology.
[0142] The IEM data receivers 300b include devices capable of
receipt of IEM data 200. Receipt may be, for example, via wireless
or wired channels, etc. The IEM data receiver 300b may also
transmit or otherwise forward data. In various aspects, the IEM
data receiver 300b may perform, facilitate, or enable various other
functionalities related to the IEM data 200 and/or other data. In
various aspects, the IEM data receiver 300b may be attachable,
implantable, semi-implantable or otherwise associated with a human
body or a non-human body.
[0143] The IEM data receiver 300b include personal signal receivers
such as patch receivers, e.g., removably attachable externally to a
human body or a non-human body; subcutaneous devices; implantable
devices; external devices, i.e., devices which are not designed for
attachment or other permanent or semi-permanent contact with the
body, e.g., a mobile telephone. The following are examples of the
IEM data receiver 300b.
[0144] The IEM system, PCT/US2008/52845, supra, includes an
ingestible event marker (IEM) and/or a personal signal
receiver.
[0145] An active signal processing personal health signal receiver
described in PCT/US07/24225, filed Nov. 19, 2007, includes a
receiver associated with a body, e.g., located inside or within
close proximity to a body, configured to receive and decode a
signal from an in vivo transmitter which is located inside the
body.
[0146] The health devices 300c include multiple devices (and
methods associated with the devices) associated with the IEM data
200. The health devices 300c, for example, may gather, collect,
aggregate, store, transmit, receive, or otherwise communicate data,
including the IEM data 200.
[0147] Communication may be, for example, via wireless or wired
channels, etc. The IEM data receiver may also transmit or otherwise
forward data. In various aspects, the IEM data receiver 300b may
perform, facilitate, or enable various other functions related to
the IEM data and/or other data. Examples include functions to store
data, process data, etc.
[0148] In various aspects, the health device 300c may be
attachable, implantable, semi-implantable or otherwise associated
with a human body or a non-human body. For example, "intelligent"
devices such as intelligent scales, intelligent blood pressure
cuffs, intelligent refrigerators, etc., may be integrated in
various configurations. As used herein, the term "intelligent
devices" refers to one or more devices capable of generating and/or
communicating data, e.g., wirelessly transmitted data, via a
communication channel to a destination.
[0149] 2.1.1.2 Products
[0150] IEM data 200 also includes IEM data related to products 302.
The products 302 include, for example, an ingestible
device/pharmaceutical product 302a. One example of an ingestible
device/pharmaceutical product 302a is an IEM mechanically
associated with medication. The IEM may be mechanically associated
with the medication in various ways, including externally affixed
to the medication, partially integrated with the medication, and
wholly integrated with the medication.
[0151] The IEM may be affixed via various means, e.g., with various
adhesive or formulated substances. The IEM may be associated with
the medication at various phases, e.g., during a medication
manufacturing process, at various points in time after a medication
manufacturing process, etc.
[0152] 2.1.1.3 Events
[0153] IEM data 200 further includes data related to events 304,
e.g., personal events, event parameters, etc. Further examples
include time of ingestion of a medication, dosage and identity of
medication taken at time of ingestion, etc. Events may include
physiologic events, e.g., respiration rate; environmental events,
e.g., time of day; usage events, e.g., ingestion of a medication,
use of a cardiac resuscitation device, etc.
[0154] 2.1.1.4 Patient Specific Parameters
[0155] IEM data 200 still further includes data related to patient
specific parameters 306, e.g., individualized patient data 306a
pertaining to an individual patient and multiple patient data 306b
pertaining to multiple patients. Examples of patient specific
parameters include physiologic data, etc. Multiple patient data
include aggregated patient data, patient population data, e.g.,
combined patient data which includes various predetermined aspects
of data regarding at least one patient and excludes data tending to
identify a particular patient or an aspect in which the patient has
a privacy interest, e.g., name, age, diagnosis and/or other data
which the patient wishes to retain as confidential and/or
undisclosed to the public.
[0156] 2.1.1.5 IEM Data Algorithms
[0157] IEM data 200 also includes data related to IEM data
algorithms 308, e.g., raw data, processed data, or a combination of
the same, which undergo processing. In one example, the IEM data
200 have one or more algorithms applied thereto, with processed
data as an output. The data, for example, includes individualized
patient data 306a and multiple patient data 306b, e.g., patient
population data.
[0158] The IEM data algorithms may be related to aspects such as
data processing associated with the IEM data 200 generated by one
or more ingestible devices, e.g., an IEM system.
[0159] With respect to IEM data processing associated with an
ingestible device, aspects include, for example, transmission of
the IEM data 200, IEM data processing associated with a receiver,
and IEM data post-processing aspects.
[0160] Transmission aspects of IEM data and algorithms may include,
for example, modulation schemes, coding, and error code
aspects.
[0161] The transmission aspects include, for example, analog,
digital, spread spectrum, combinatorial, and contention
avoidance.
[0162] The analog transmission aspects include, for example,
amplitude modulation, single sideband modulation, frequency
modulation, phase modulation, quadrature amplitude modulation, and
space modulation methods, etc.
[0163] The digital transmission aspects include on/off keying,
frequency-shift keying, amplitude-shift keying, phase-shift keying,
e.g., binary phase-shift keying, quadrature phase-shift keying,
higher order and differential encoded, quadrature amplitude
modulation, minimum shift keying, continuous phase modulation,
pulse-position modulation, trellis coded modulation, and orthogonal
frequency-division multiplexing.
[0164] The spread spectrum transmission aspects include, for
example, frequency hopping spread-spectrum and direct-sequence
spread spectrum.
[0165] The combinatorial transmission aspects include, for example,
binary phase shift-keying with carrier frequency modulation.
[0166] The contention avoidance transmission aspects include, for
example, duty-cycle modulation and carrier frequency
modulation.
[0167] The coding aspects include, for example, wake-up schemes,
preamble schemes, data packet schemes, and error code schemes.
[0168] The wake-up schemes include, for example, multi-tone schemes
and chirp schemes.
[0169] The preamble schemes include, for example, unique identifier
for packet start schemes.
[0170] The data packet schemes include, for example, data related
to pill type, pill expiration, manufacturer, lot number, amount,
prescribing physician, pharmacy, etc.
[0171] The error code schemes include, for example, repetition
schemes, parity schemes, checksums, cyclic redundancy checks,
hamming distance schemes, and forward error correction schemes,
e.g., Reed-Solomon codes, binary Golay codes, convolutional codes,
turbo codes, etc.
[0172] With respect to IEM data processing and the receiver,
considerations may be given to, for example, position, energy
conservation schemes, carrier identification, decoding and error
correcting.
[0173] The position of the receiver includes, for example, the
stomach, the side and the xiphoid.
[0174] The energy conservation schemes include schemes for a
periodic wake-up, e.g., to sense IEM wake-up such that energy,
e.g., battery resources, is conserved during non-awake periods.
[0175] The carrier identification aspects include, for example,
Fourier transform analysis, e.g., fast Fourier transform and
discrete Fourier transform, phase locked loop, filter bank, match
filter, and combinatorial such as use of previous knowledge about
frequency to tune-in.
[0176] The decoding aspects and error correcting aspects include,
for example, the above-iterated aspects.
[0177] With respect to IEM data post-processing, aspects include,
for example, pill detection, e.g., multiplicity of identification
and count in time aspects, adherence metrics, etc.
[0178] With respect to IEM data processing associated with
physiologic parameter metrics, aspects include, for example,
electrocardiogram (EKG or ECG), impedance, acceleration, optical,
pressure, temperature, sound, biochemical/biological, weight,
position, derived electromyography (EMG), and
electroencephalography (EEG).
[0179] IEM data processing related to EKGs includes, for example,
compression data, e.g., wavelet and ICA/PCA, R-wave detection such
as Hamilton-Tompkins, etc., heart-rate variability, e.g., SDNN,
standard deviation in a 24 hour period, standard deviation of
consecutive five minute periods, foot print heart rate versus
standard heart rate, distribution-based histogram, etc.,
arrhythmia, and respiration, e.g., principal axis modulation.
[0180] IEM data processing related to impedance includes, for
example, respiration, fluid status, Galvanic skin response, blood
flow, etc.
[0181] IEM data processing related to acceleration, includes, for
example, direct acceleration, which includes total activity and
derived acceleration, which further includes activity type.
[0182] IEM data processing related to optical includes, for
example, hematocrit, O2 saturation, pulse oximetry, etc.
[0183] IEM data processing related to temperature includes, for
example, body temperature, heat flux, etc.
[0184] IEM data processing related to sound includes, for example,
heart sounds, valvular events, etc.
[0185] IEM data processing related to biochemical/biological
includes, for example, lactose, glucose, antibody, biomarker,
bacterial, osmolarity, etc.
[0186] IEM data processing related to derived data include, for
example, sleep, total energy, etc.
[0187] 2.1.1.6 Storage Repositories
[0188] Ingestible event marker data also includes data related to
storage repositories 310, i.e., databases and/or other storage
implementations that temporarily and/or permanently retain, store,
etc., data related to IEM data, including data to be combined or
aggregated with ingestible event marker data.
[0189] Storage may be in any form or format, as is known or will be
known in the future. In various aspects, the storage repositories
310 may be independently embodied and/or may be partially or wholly
integrated with computer-related system(s). The storage
repositories 310, for example, may interoperate or otherwise be
associated with various computer systems, software, hardware,
communication components, etc. For example, the storage
repositories 310, may be part of a medical office computer system
and may contain IEM data 200 related to a particular's patient's
medication regimen. At various times, e.g., scheduled or ad hoc,
various IEM data 200 embodied as medical data may be communicated
to/from the storage repositories 310 and/or from/to various
points/components.
[0190] In another illustration, methods, systems and compositions
that allow for treating a patient according to a patient customized
therapeutic regimen are described in PCT/US2007/1068, filed May 2,
2007, which include obtaining dosage administration information
from a patient and using the same to tailor a therapeutic regimen
for the patient, as well as preparing and forwarding to the patient
physical pharmaceutical dosages based on the customized therapeutic
regimen. The dosage administration information from the patient may
be stored, for example, on the database 306. The IEM data 200
containing information about the ingestion time of a particular
medication can be combined with the dosage administration
information to customize the therapeutic regimen.
[0191] 2.1.1.7 Other IEM Data Sources
[0192] In various aspects, various other IEM data sources 312
are/can be included. Further, it is noted that data and/or IEM data
200 from multiple sources can be aggregated, integrated, refined,
etc. via a variety of methods. To illustrate, IEM data 200 such as
ingestion data related to ingestion of a medication are generated
from an IEM data source device 300 such as the IEM system. The
ingestion data are wirelessly transmitted to an IEM receiver.
[0193] Concurrently or in an alternative time period, physiologic
data such as cardiac parameters are generated by a health device
300c such as the system for monitoring and treating hemodynamic
parameters, supra, is generated and wirelessly transmitted to the
IEM data receiver 300b. The IEM data 200 and the cardiac
physiologic data are aggregated for onward communication to an IEM
data system such as an auto refill system.
[0194] To illustrate, cardiac data is derived via various methods
and systems. One example is continuous field tomography, e.g.,
electrical tomography (ET). One continuous field tomography method
is described in the U.S. Patent Application Ser. No. 60/797,403,
filed May 2, 2006. The cardiac data includes cardiac-related
parameters, as well as clinical data for clinical applications.
Using ET, various cardiac parameters are measured, such as stroke
volume, ejection fraction, dP/dt(max), strain rate(max), peak
systolic mitral annular velocity, end systolic volume, end
diastolic volume, and QRS length, etc. The cardiac measurements may
be used to derive or infer various performance and wellness
diagnostics/inferences. For example, an ejection fraction parameter
may be used as a basis to predict ventricular synchrony
performance.
[0195] The metrics generated from the continuous field tomography
include, for example, velocity, acceleration, and displacement.
[0196] The clinical data derived from the metrics include, for
example, left ventricle stiffness as well as ET proxies for other
physiologic parameters such as ejection fraction (EF) and
dP/dt.
[0197] In various aspects, the clinical data may be combined with
the IEM data to provide additional information. The information may
be useful, for example, in various diagnostic and analytical
pursuits. Comprehensive patient-related data displays having
clinical data and IEM data are described in the U.S. Patent
Application Ser. No. 61/076,577, filed Jun. 27, 2008, wherein
various ET physiologic parameters and derivations such as EF and
ventricle stiffness are displayed together with IEM data such as
medication ingestion time. From such a display, the efficacy of the
medication therapy may be gauged.
[0198] 2.2 Hub
[0199] The hub 202 includes any hardware device, software, and/or
communications component(s), as well as systems, subsystems, and
combinations of the same which generally function to communicate
the IEM data 200, including receiving, storing, manipulating,
displaying, processing, and/or transmitting the IEM data 200.
[0200] In various aspects, the hub 202 receives, generates,
communicates, and/or transmits, the IEM data 200, alone or in
combination with other data, i.e., non-IEM data from various
sources. Non-IEM data includes non-IEM physiologic data. Examples
of non-IEM data include heart rate, heart rate variability,
respiration, physical activity level, wake patterns, temperature,
etc.
[0201] Communication of the IEM data 200 to and from the hub 202
includes any transmission means or carriers, and combinations
thereof, including wireless, wired, RF, conductive, etc. as is
known in the art or as may become available in the future.
[0202] FIG. 4 illustrates the hub 202 associated with the IEM data
framework 102 of FIG. 2, according to one embodiment. The hub 202
comprises various categories of devices, e.g., personal
communication devices, base stations, and mobile telephones.
[0203] Personal communication devices include, for example, devices
having communication and computer functionality and typically
intended for individual use, e.g., mobile computers, sometimes
referred to as "handheld devices".
[0204] Base stations comprise any device or appliance capable of
receiving data such as IEM data. Examples include computers, such
as desktop computers and laptop computers, and intelligent
devices/appliances.
[0205] Intelligent devices/appliances include consumer and home
devices and appliances that are capable of receipt of data such as
IEM data. Intelligent devices/appliances may also perform other
data-related functions, e.g., transmit, display, store, and/or
process data. Examples of intelligent devices/appliances include
devices and appliances having refrigerators, weight scales,
toilets, televisions, door frame activity monitors, bedside
monitors, bed scales. Such devices and appliances may include
additional functionality such as sensing or monitoring various
physiologic parameters, e.g., weight, heart rate, etc.
[0206] Mobile telephones include telephonic communication devices
associated with various mobile technologies, e.g., cellular
networks.
[0207] In one aspect, the hub 202 includes an IEM data receiver
embodied, for example, as a receiver such as a patch receiver 400;
a personal communication devices such as a handheld device 402; a
base station 404; and a mobile telephone 406.
[0208] The patch receiver 400 includes, for example, devices
capable of at least receiving data, signals, etc. Patch receivers
400 may be attachable, e.g., permanently or removably attachable
externally to a human body or a non-human body. For example, the
patch receiver 400 may include a receiver and an adhesive layer to
provide for attachment to and removal from a region of skin.
Alternatively, the patch receiver 400 may be implantable or
semi-implantable, e.g., subcutaneous implantation. One such
removably attachable patch receiver 400 is the personal signal
receiver of the IEM system described in PCT/US2008/52845,
supra.
[0209] The handheld device 402, also referred to as a "mobile
computer", includes, for example, computing devices having
computer-related functionality, e.g., typically having a display
screen with touch input functionality, a miniature keyboard, etc.
Types of handheld devices include, for example, a personal digital
assistant (PDA) having the input and output combined into a
touch-screen interface; and enterprise digital assistants offering
integrated data capture devices like bar code, radio frequency
identification (RFID), and smart card readers, etc.
[0210] In various aspects, the handheld device 402 includes
software, e.g., a software agent/application, associated with the
IEM data 200. In various embodiments of the handheld device 402,
the software is preconfigured, i.e., configurable by the
manufacturer/retailer; configurable by the consumer, i.e.,
downloadable from a website; or a combination of the same.
[0211] One example of software is an auto refill application
related to or integrated with an auto refill system to facilitate
automated prescription refill functions.
[0212] The base station 404 includes systems, subsystems, devices,
and/or components that receive, transmit, and/or relay the IEM data
200. In various aspects, the base station communicably
interoperates with a receiver such as the patch receiver 400 and a
communications network such as the Internet. Examples of base
stations 404 are computers, e.g., servers, personal computers,
desktop computers, laptop computers, intelligent
devices/appliances, etc., as heretofore discussed.
[0213] In various aspects, the base station 404 may be embodied as
an integrated unit or as distributed components, e.g., a desktop
computer and a mobile telephone in communication with one another
and in communication with a patch receiver and the Internet.
[0214] In some aspects, the base station 404 includes the
functionality to wirelessly receive and/or wirelessly transmit
data, e.g., IEM data 200 received from and transmitted to the patch
receiver 400 and the Internet.
[0215] Further, in various aspects, the base station 404 may
incorporate and/or be associated with, e.g., communicate with,
various devices. Such devices may generate, receive, and/or
communicate data, e.g., IEM data 200. The devices include, for
example, clock radios, intelligent pill dispensers, pill managers,
e.g., devices capable of receiving various substances and producing
a combined substance, dose(s) of substances, etc., pharmaceutical
compounding devices, "intelligent" devices such as scales, blood
pressure measurement devices, exercise equipment, e.g., tread
mills. Further examples include body weight sensors, motion
sensors, position sensors, e.g., bed sensors, chair sensors,
portals in doorways, refrigerator and food devices, bathroom
facilities devices, etc.
[0216] The mobile telephone 406 includes, for example, devices such
as a short-range, portable electronic device used for mobile voice
or data communication over a network of specialized cell site base
stations. The mobile telephone 406 is sometimes known as or
referred to as "mobile", "wireless", "cellular phone", "cell
phone", or "hand phone (HP)".
[0217] In addition to the standard voice function of a telephone,
various embodiments of mobile telephones may support many
additional services and accessories such as short message service
(SMS) for text messaging, email, packet switching for access to the
Internet, java gaming, Bluetooth (short range data/voice
communications), infrared, camera with video recorder, and MMS for
sending and receiving photos and video. Some embodiments of mobile
telephones connect to a cellular network of base stations (cell
sites), which is, in turn, interconnected to the public switched
telephone network (PSTN) or satellite communications in the case of
satellite phones. Various embodiments of mobile telephones can
connect to the Internet, at least a portion of which can be
navigated using the mobile telephones.
[0218] In various aspects, the mobile telephone 406 includes
software, e.g., a software agent/application, associated with the
IEM data 200. One example is an auto refill application related to
or integrated with an auto refill system to facilitate automated
prescription refill functions. In various embodiments of the mobile
telephone 406, the software is preconfigured, i.e., configurable by
the manufacturer/retailer; configurable by the consumer, i.e.,
downloadable from a website; or a combination of the same.
[0219] Further, various embodiments of the hub ensure privacy
requirements via predetermined methods, e.g., an IEM data source
device 300 ingested by an individual transmits sensitive IEM data
200 via body tissues to an IEM data receiver 302 embodied in a
patch receiver 400 removably attached to the individual's body.
Signals associated with the sensitive IEM data 200 remain
undetectable beyond the individual's body. Once received by the
patch receiver 400, various computing components of the patch
receiver 400 cleanse and/or encrypt the IEM data 200 for onward
secure transmission. In this manner, breaches of sensitive data
transmissions and/or unauthorized access to the sensitive data are
avoided.
[0220] Further, various aspects of the hub include combinations of
devices. One such combination is an IEM data receiver 300b such as
the patch receiver 400 in communication with the handheld device
402 or the mobile telephone 406. Thus, for example, the patch
receiver 400 wirelessly transmits IEM data 200 to the mobile
telephone 406 having a receiver and a software agent available
thereon. The receiver of the mobile telephone 406 receives the IEM
data 200. A software agent, e.g., an application, processes the
ingested reported data 200 and displays various information related
to the IEM data 200 via, for example, a customized graphical user
interface (GUI). In some aspects, the software agent generates
displays with a predetermined "look and feel", i.e., recognizable
to a user as belonging to a predetermined group of software
programs, GUIs, source devices, communities, etc.
[0221] To illustrate the foregoing, the IEM data 200 may include
data about an ingested medication. Once received by the mobile
telephone 406, the software agent may compare the data about the
medication to a predetermined medication regimen. Upon verification
that the proper medication has been ingested at the proper time,
the software disables an audible alarm scheduled to alert the
individual to take the (already ingested) medication, thus averting
an unnecessary reminder and removing the annoyance associated
therewith. The software agent, via the GUI, displays a standard
message to the individual notifying of the medication ingested and
the time of the next dosage.
[0222] Additionally, the software agent may include functionality
to generate or facilitate a financial transaction. In one example,
upon occurrence of a certain event, such as verification that the
proper medication has been ingested at the proper time, the
software agent generates a predetermined charge for the ingested
medication, the verification service, or both. The charge is
transmitted to a financial system, e.g., the patient's cell phone
transmits the charge via an IEM data system to a computer system
associated with the patient's financial institution where the
charge is automatically applied against a financial account of the
patient.
[0223] In various other aspects, the transaction model may be based
on various parameters. In one example, a transaction is associated
with a time based model wherein use of a product or service is
charged according to the length of time the product or service is
used. In another example, a transaction is associated with a
measured value delivery, wherein the value of the product or
service is metered, measured, or otherwise valued and charged
according to the ascertained value at predetermined time intervals.
In still another example, a transaction is associated with therapy
delivery, i.e., delivery of a therapeutic substance, event,
service, etc. Examples of therapeutic substances include
medication. Examples of therapeutic events include cardiac
defibrillation acts and cardiac resynchronization acts. Examples of
therapeutic services include administration of therapeutics,
therapeutic consultations, etc.
[0224] 2.3 IEM Data Systems
[0225] The IEM data systems 204 include any hardware component,
software component, and/or communications component, as well as
networks, systems, and subsystems of the same, which generally
function to provide a service, function, activity, etc. related to
the IEM data 200. The IEM data systems, for example, collect,
manipulate, calculate, transmit, receive, store, and/or otherwise
communicate at least a portion of the IEM data.
[0226] Each IEM data system is built around a predefined business
function or service and is enabled via the IEM data framework. One
or more IEM data systems may be integrated, interoperate,
intercommunicate or otherwise share or further the collection,
management, distribution/dissemination, billing and/or other
activities related to IEM data.
[0227] Further, one or more IEM data systems may be associated with
one or more commercial systems. For example, one or more IEM data
systems may be integrated with, interoperate with, and/or
intercommunicate with one or more commercial systems. One or more
IEM data systems may otherwise share or further the IEM data
related activities with one or more commercial systems.
[0228] The IEM data systems 204 include at least one component,
e.g., hardware device, software, and/or communications component,
which generally function to provide a service or activity related
to the IEM data 200, e.g., a computer to receive IEM data 200 from
the hub 202 and display the IEM data 200 in conjunction with other
information.
[0229] Examples of components include a computer, a receiver, a
transmitter, an application, a software module, a data storage
medium, a processor, a memory component, a personal communication
device, software, a communication link, and a handheld device. It
is noted that two or more IEM data systems 204 can cooperatively or
independently use one or more of the same components. For example,
an auto refill system and an approval system can each access a data
storage medium having IEM data related to patients and
prescriptions and can each utilize the IEM data for predetermined
purpose(s).
[0230] FIG. 5 illustrates exemplary IEM data systems 204 associated
with the IEM data framework of FIG. 2, according to one embodiment.
The exemplary IEM data systems 204 include, for example, feedback
loop systems 204a, decision support systems 204b, auto refill
systems 204c, patient tools 204d, behavioral medicine systems 204e,
incentive systems 204f, personalized commercial products/services
204g, auto billing systems 204h, tracking systems 204i,
interdiction systems 204j, subscription systems 204k, IEM data
collections 204l, approval systems 204m, forecasting systems 204n,
financial systems 204o, an IEM data phone system 204p, and social
networks 204q.
[0231] 2.3.1 Feedback Loop Systems
[0232] Feedback loop systems aggregate various sources of data,
e.g., IEM data, analyze the aggregated data, and/or provide
feedback information to multiple profile recipients based on the
aggregation/analysis.
[0233] FIG. 6 illustrates an exemplary IEM data framework 102
including a feedback loop system 204a, according to one embodiment.
The feedback loop system 204a includes, for example, server 500
having application 504 and database 504. The IEM data framework 102
further includes IEM data 200 and the hub, embodied here as the
mobile telephone 406. In various aspects, the feedback loop system
204a may interoperate, or be otherwise associated with, one or more
IEM data systems 204 and/or one or more commercial systems 106.
[0234] In one scenario, a patient 506 ingests medication having an
ingestible device integrated therein. The ingestible device
generates IEM data 200 in the form of medication identification and
time of ingestion information. The ingestible device transmits the
information to a receiver. The receiver, in turn, communicates the
information to the hub 202 embodied as a mobile telephone 406
associated with the patient 506.
[0235] A software agent resident on the mobile telephone 406
aggregates the received medication identification and time of
ingestion information with the blood pressure measurement
information and forwards the aggregated data to the feedback loop
system 204a. The feedback loop system 204a, having server 500,
software 502, and database 504, receives the aggregated data from
the mobile telephone 406 and, via the software 502, compares the
aggregated data to patient information in the database 504 to
determine if the patient 506 took the most recent dose of
medication in a timely manner, if the patient 506 has consistently
taken the medication in a timely manner, and if the blood pressure
measurement coincides with an acceptable range of blood pressure
measurements.
[0236] Based on an analysis of the data, the feedback loop system
204a generates additional IEM data 200 in the form of a decision on
patient adherence and a decision on treatment efficacy. The IEM
data 200 decisions are stored in database 504 for future reference
and forwarded to a commercial system such as a healthcare system
106a associated with a medical center computer system and having
patient data such as physician's medication instructions, etc.
[0237] The healthcare system 106a facilitates automatic processing
and feedback, enables accessibility to the IEM data 200, e.g., by a
healthcare provider, enables data input, e.g., healthcare
instructions by the healthcare provider, etc.
[0238] For example, the healthcare system 106a compares the
decision data received from the feedback loop system 106a with
stored healthcare providers instructions, e.g., medication regimen
adherence is satisfactory and no action is needed at this time;
medication regimen adherence is not satisfactory and action is
needed at this time; medication regimen is satisfactory but action
is needed at this time, e.g., titration is needed, etc., and
generates the comparison result data for review by the healthcare
provider.
[0239] The healthcare provider utilizes the information to
advantageously adjust patient treatment parameters, e.g.,
prescription and dosage requirements. The healthcare provider
inputs data based on the comparison results, e.g., the adjusted
treatment parameters. The input data are processed by the
healthcare system 106a and forwarded to the feedback loop system
204a. The feedback loop system 204a receives the feedback loop
data, reconciles the feedback loop data with the patient
information resident in the database 504, and forwards the
notification to the mobile telephone 406 of the patient 506.
[0240] In various aspects, the feedback loop system 204a and/or the
healthcare system 106a interoperate, e.g., communicate with at
least one other IEM data system 204 and/or commercial system
106.
[0241] To continue the foregoing illustration, in addition to
forwarding the adjusted medication regimen instructions to the
patient's mobile telephone 406, either the feedback loop system
204a or the healthcare system 106a forwards the adjusted medication
regimen in the form of a prescription to a commercial system such
as a pharmacy system 106b for refill. The pharmacy system 106b
fills the prescription and communicates a message to the feedback
loop system 204a notifying of the same. The feedback loop system
204a updates the patient's data in database 504 to reflect the new
prescription and fulfillment of the prescription, and communicates
the notification to the patient's mobile telephone 406.
[0242] 2.3.2 Decision Support Systems
[0243] Decision support systems, e.g., personal wellness systems,
may generate, store, provide data, e.g., IEM data, which may be
used to inform and support decisions, e.g., stakeholders'
decisions. In one example, multiple instances of individualized
ingestible event marker data and physiologic data are gathered and
combined into anonymized patient population data. Pharmaceutical
research and development groups, universities, etc., utilize the
data for various purposes, e.g., information to formulate new
product lines, adjust existing therapies, etc. The data may be
accessed, for example, by subscription to population data feeds,
access to the database, etc.
[0244] FIG. 7 illustrates an exemplary IEM data framework 102
having a decision support system 204b, according to one embodiment.
The IEM data framework 102 further includes IEM data 200 and the
hub 202, shown here embodied as the mobile telephone 406. In
various aspects, the feedback loop system 204a may interoperate, or
be otherwise associated with, one or more IEM data systems 204
and/or one or more commercial systems 106.
[0245] In one scenario, IEM data, e.g., IEM data 200a and IEM data
200b, related to multiple individuals, e.g., patient 506a and
patient 506b, respectively, are communicated via the hubs, e.g.,
mobile telephone 406a and mobile telephone 406b, respectively, to
the decision support system 204b comprising, for example, server
500, software 502, and database 504. The IEM data 200a and 200b may
be encrypted. The decision support system 204b processes and stores
the received data. For example, software 502 anonymizes the patient
data, i.e., removes all aspects of the data tending to identify an
individual and removes, according to a predetermined scheme, all
aspects of the data designated as private, sensitive, confidential
in nature, etc. The software 502 may provide various other
functions such as integrating the anonymized patient data with
existing patient population data in the database 504.
[0246] The integrated data in database 504 may be accessed by,
delivered to, or otherwise utilized by multiple systems and
parties. Such systems include for example, commercial systems 104
such as pharmaceutic systems 106c and university systems 106d.
Parties associated with the pharmaceutic systems 106c may utilize
the patient population data, for example, for statistical analysis
and projective capabilities such as determining the efficacy, cost
efficiency, profit, etc. of a particular medication and projecting
from the determination new product line concepts/therapies, etc.
Parties associated with universities may utilize the patient
population data to research symptomatology, analyze medication
risks, etc.
[0247] In various aspects, the decision support system 204b, IEM
data system(s), and/or commercial system(s) interoperate, e.g.,
communicate, therebetween.
[0248] To continue the foregoing illustration, in addition to the
provision of decision support data such as patient population data,
the decision support system 204b communicates patient population
data to the feedback loop system 204a. The feedback loop system
204a communicates the patient population data to mobile telephone
406a of patient 506a.
[0249] In one scenario, the decision data derived from a patient
population such as medication efficacy may be correlated with an
individual's medication therapy, and communicated via marketing
system specifically targeted for that individual.
[0250] 2.3.3 Auto Refill Systems
[0251] Auto refill systems automatically fill or refill
prescriptions. In one example, IEM data identifying an ingested
medication are gathered and reconciled with current prescription
information to identify depleted prescription supplies. If the
supply is depleted, a refill order is automatically triggered to
the appropriate pharmacy. The pharmacy automatically refills the
order, generates a bill, and charges the appropriate account, e.g.,
via a real time, online financial transaction.
[0252] FIG. 8 illustrates an exemplary IEM data framework 102
having an auto refill system 204c, according to one embodiment. The
IEM data framework 102 further includes IEM data 200 and the hub
202, shown here embodied as the base station 404. In various
aspects, the auto refill system 204c may interoperate, or be
otherwise associated with, one or more IEM data systems 204 and/or
one or more commercial systems 106.
[0253] In one scenario, the patient 506 ingests prescription
medication in conjunction with an ingestible device. The ingestible
device identifies the medication type and dosage, and transmits the
IEM data 200 via, for example, conductive transmission to the patch
receiver 400, which may be removably attached to the patient 506.
The patch receiver 400 transmits the IEM data 200 to base station
404. The base station 400 forwards the IEM data 200 to the auto
refill system 204c. The software 502 of the auto refill system 204c
compares the medication type and dosage of the IEM data 200 against
prescription information stored in the database 504. The
prescription information, for example, may include the number of
tablets in the prescription at time of fill, the dosage
instructions, and a running total of the ingested tablets as per
previously received information. If the comparison indicates
depletion of the prescription medication, database 504 is checked
for the number of remaining refills. If refills are remaining, any
sensitive data of the IEM data 200 are cleansed, i.e., removed, and
a prescription refill request with pertinent information is
compiled and transmitted according to predetermined security
protocol and via predetermined channel(s) to a commercial system
106 such as the pharmacy system 106b. Upon receipt by the pharmacy
system 106b, the refill request is parsed and verified, and the
prescription is refilled.
[0254] Payment for refill can be effected, for example, via a
real-time, online transaction between the pharmacy system 106b and
an IEM data system 204 and/or commercial system, e.g., financial
transaction system 106e. The financial transaction system 106e, for
example, may receive the financial transaction, e.g., prescription
refill charge, via a predetermination communication channel. The
financial transaction system 106e verifies the patient account
information and completes the transaction, notifying the pharmacy
system 106b.
[0255] Notification of status of refill and payment for refill can
be provided via predetermined communication channel(s) to the base
station 300, e.g., an email for display on the laptop computer, a
text message to the patient's mobile telephone, etc.
[0256] 2.3.4 Patient Tools
[0257] Patient tools include any data, information, software,
websites, etc. that provide information or assist a particular
patient focus, e.g., tracking tools to assist a patient in cardiac
health management, patient personalization of their own data, etc.
Various users may be associated with the patient tools. Examples
include various users within a patient community, e.g., patients,
family caregivers, and professional caregivers such as
physicians.
[0258] FIG. 9 illustrates an exemplary IEM data framework 102
having a patient tools 204d, according to one embodiment. The IEM
data framework 102 further includes IEM data 200a-c and the hubs,
shown here embodied as the base station 404, the mobile telephone
406, and the handheld device 402. In various aspects, the patient
tools 204d may interoperate, or be otherwise associated with, one
or more IEM data systems 204 and/or one or more commercial systems
106.
[0259] In one scenario, multiple parties such as patients 506a-c
access the patient tools 204d, which may be embodied as the server
500 having the software 502 and the database 504 having IEM data
200 in the form of at least patient tools. Patients 506a-c may
access the patient tools 204d, for example, via the base station
404, the mobile telephone 406, and the handheld device 402,
respectively.
[0260] Patient 506b may search the database 504 for patient tools
related to mental illness management. The patient tools, for
example, may be provided in the form of downloadable
data/applications to assist in tracking, monitoring, diagnosing,
and notifying a patient of a relevant health issue, e.g.,
medication dosage schedule, etc. Patient 506b may download the
application onto, for example, the mobile telephone 406. Patient
506b may further communicate via, for example, the mobile telephone
406 with at least one commercial system such as the healthcare
system 106a, which may provide further medical data, instruction,
etc., relevant to the patient 506b's mental illness management
pursuit.
[0261] In various aspects the patient tools 204d may be configured
for and utilized by for various parties besides the patient, e.g.,
a patient community, family caregivers, and professional
caregivers.
[0262] 2.3.5 Behavioral Medicine Systems
[0263] Behavioral medicine systems may collect, track, and analyze
behavior-related data to identify causal failure points in
treatment and to predict corrective action by prescribing specific
behavior modifications. In various aspects, the behavioral medicine
systems may assist patients via questionnaires and patient profile
assessment on symptomatologic or therapeutic subjects, e.g., in
various decision processes by display a menu-guided series of
questions and receiving answer(s) from the patient.
[0264] FIG. 10 illustrates an exemplary IEM data framework 102
having a behavioral medicine system 204e, according to one
embodiment. The IEM data framework 102 further includes IEM data
200 and the hub, shown here embodied as the base station 404 and
the mobile telephone 406. In various aspects, the behavioral
medicine system 204e may interoperate, or be otherwise associated
with, one or more IEM data systems 204 and/or one or more
commercial systems 106.
[0265] In one scenario, the behavioral medicine system 204e, e.g.,
a software agent, may be located in whole or in part on a
patient-related device such as the mobile telephone 406. The
software agent may assist the patient in various endeavors, e.g.,
diet choices, smoking cessation, etc. The assistance may be
provided, by example, by generating for display on the mobile
telephone 406 question sets related to diet and smoking cessation.
The patient may answer the questions, e.g., select from various
answer options. Based on the patient's answers to the questions,
the software agent may categorize the patient according to
predetermined categories. The software agent may provide language
and menu choices based on the patient categorization.
[0266] In another scenario, patient behavior is tracked with
respect to various IEM data, e.g., patient parameters, sometimes
referred to herein as "sentinels for wellness". Examples of
sentinels for wellness include medication therapy adherence,
weight, blood pressure, etc. The sentinels for wellness may be
derived, for example, from various health devices 300c such as
intelligent scales, cardiac-related devices, etc.
[0267] To illustrate, patient 506 ingests medication according to
physician instructions. The IEM data 200 in the form of ingestion
information identifying the ingested medication and the time of
ingestion are captured via an ingestion device and communicated to
the patient's mobile telephone 406. Also captured via health
device(s) 300c at the time of medication ingestion are the
patient's blood pressure and weight. The timing of the foregoing
data captures may be synchronized via, for example, software
utilizing a reminder system to alert the patient to take the
medication at a particular time. Upon receiving the ingestion
information, e.g., confirmation of ingestion, the software
associated with the mobile telephone 406 communicably triggers
health device(s) 300c to determine blood pressure and weight, and
forwards such data to the mobile telephone 406 for aggregation with
the IEM data 200 in the form of the ingestion information.
[0268] The aggregated data may be forwarded to behavioral medicine
system 204e, which may be configured, for example, as the mobile
telephone and software 406, the server 500 including the software
502 and the database 504, and/or other configurations. Upon receipt
of the aggregated data, various processing may take place.
[0269] One example of processing is analysis of the IEM data 200 to
determine degree of patient adherence to medication regimen, i.e.,
determine if the patient ingested the prescribed medication in the
right dosage at the prescribed time interval(s).
[0270] Another example of processing is analysis of the IEM data
200 to determine if the blood pressure measurement is in line with
physician expectations. Thus, the notification of patient adherence
to the medication regimen and the blood pressure measurement may be
communicated to a physician system 106f for review by the patient's
physician. The physician, in turn, may update the IEM data 200,
e.g., determine an adjustment in the medication regimen is needed
and communicate, via the behavioral medicine system, the updated
medication regimen to the patient's mobile telephone 406 and to the
pharmacy system 106b for filling the updated prescription.
[0271] In cases of a nonadherence determination, the physician may
alert the patient, via the behavioral medicine system 204e, to make
an appointment for a physical review. In various aspects, the
behavioral medicine system 204e may generate and/or forward a
reminder to the hub, e.g., mobile telephone 406 of the patient 506.
The reminder, for example, may include the dosing schedule, a
reminder for the upcoming dose, instructions to follow in case of a
missed dose, etc.
[0272] In cases of underdosage/overdosage, the behavioral medicine
system 204e may interoperate with an alert system, e.g., the IEM
data phone system, infra, and compare current dosage information to
predetermined thresholds to determine if a critical status dosing
event exists, e.g., the patient is critically underdosed or
critically overdosed. If such a determination is made, the
appropriate system may generate an alert to appropriate parties,
e.g., generate a 911 emergency call for medical assistance,
generate an emergency alert to the physician system 106f, and
generate an alert to a family caregiver system 106g, e.g., a family
member's mobile telephone.
[0273] In still another scenario, analysis of the patient's
communication patterns/habits is performed to determine patient
parameters, indicated actions, etc. To illustrate, an application
such as software 502 resident on the mobile telephone 406 tracks
the patient's phone usage to determine communication patterns. For
example, the family caregivers, physician, etc., may selectively
configure tracking parameters of the application to determine
various patient communication thresholds, patterns, etc. The
software monitors communication from/to the selected device, e.g.,
the patient's mobile telephone 406. In various aspects, the
application mines mobile telephone records of the associated
carrier to determine calling and called parties, heavy volume call
time, no call times, etc. and builds a profile against the same.
The application monitors use of the mobile telephone 406 and
identifies significant, e.g., user selected, deviations from the
profile. Upon identification of a deviation, the application
initiates predetermined actions, e.g., communicates an alert to the
physician and/or family caregiver via the healthcare system 106a,
the physician system 106f, and/or the family caregiver system
106g.
[0274] Another example of processing is analysis of the IEM data
200 together with data from another source, e.g., aggregated data.
The aggregated data may be collected from various sources,
aggregated at various and/or multiple points, and/or communicated
via various channels to/from various devices.
[0275] To illustrate, cardiac data is derived via electrical
tomography, as heretofore discussed. The cardiac data is
communicated directly or indirectly, e.g., by the patch receiver
400, to a software application on the hub, e.g., the mobile
telephone 406. The software application on the mobile telephone 406
aggregates the cardiac data with the IEM data, e.g., pill
ingestion-related data, and displays the various data via a
graphical user interface (GUI).
[0276] Subsequent to enrollment, the behavioral medicine system
ascertains that the patient has neglected to take the medication at
the appropriate times. Reminder alerts for upcoming medication
dosing time(s) are sent to the patient via the mobile telephone.
Upon receiving the alerts, the patient timely ingests the
medication, resulting in a change in the sentinels for
wellness.
[0277] 2.3.6 Incentive Systems
[0278] Incentive systems provide incentives and rebates through
various programs. The incentives and rebates are based on, or
otherwise associated with, the IEM data. The IEM data may be
analyzed via, for example, an IEM data system 204 to determine if
certain criteria/thresholds/goals are evident. Based on the
determination, incentives tied to or associated with the
criteria/threshold/goals may be generated.
[0279] FIG. 11 illustrates an exemplary IEM data framework 102
having an incentive system 204f, according to one embodiment. The
IEM data framework 102 further includes IEM data 200 and the hub,
shown here embodied as the mobile telephone 406. In various
aspects, the incentive system 204f may interoperate, or be
otherwise associated with, one or more IEM data systems 204 and/or
one or more commercial systems 106.
[0280] In one scenario, patient adherence is tracked with respect
to various patient parameters, e.g., medication therapy and
adherence. Incentives may be awarded accordingly. For example,
patient 506 ingests medication according to physician instructions.
The IEM data 200 in the form of ingestion information identifying
the ingested medication and the time of ingestion are captured via
an ingestion device and communicated to the patient's mobile
telephone 406, and to the behavioral medicine system 204e. The
behavioral medicine system 204e verifies patient 506 adherence to
the prescribed medication regimen, and sends verification to the
incentive system 204f. The incentive system 204f, via the software
502 and the database 504, determines the price paid for the
medication, and issues a rebate or credit against the cost. For
example, the rebate may be issued and a financial transaction in
the amount of the rebate posted to the patient's financial account
via the financial transaction system 106e.
[0281] In another example, the rebate may be communicated and
applied to an account associated with the patient via the pharmacy
system 106b with, for example, a credit against the next refill for
the patient's prescription medication.
[0282] In another example, the patient's blood pressure and weight
may be captured via health device(s) 300c at time of medication
ingestion. The timing of the foregoing data captures may be
synchronized via software utilizing a reminder system to alert the
patient to take the medication at a particular time. Upon receiving
the ingestion information, e.g., confirmation of ingestion, the
software associated with the mobile telephone 406 may communicably
trigger health device(s) 300c to determine blood pressure and
weight, and forward such data to the mobile telephone 406 for
aggregation with the IEM data 200 in the form of the ingestion
information. The aggregated data may be communicated to the
incentive system 204f where the software 502 and/or database 504
may be utilized to determine if the patient's weight and blood
pressure meet acceptable predetermined thresholds. If, for example,
the weight exceeds an acceptable threshold, the incentive system
204f may generate an incentive in the form of a discount membership
offering at a local health club, etc. The offering may be
constructed using various data parameters and demographics, e.g.,
geographical location of the patient, amount of weight to be lost,
health assessment scoring based on individualized patient health
parameters, lists of participating health clubs, etc.
[0283] The incentive may be communicated to the patient 506 via,
for example, the patient's mobile telephone 506.
[0284] 2.3.7 Personalized Commercial Products/Services
[0285] Personalized commercial products/services provide
individualized products and services predicated on or related to
IEM data.
[0286] FIG. 12 illustrates an exemplary IEM data framework 102
having a personalized commercial products/services system 204g,
according to one embodiment. The IEM data framework 102 further
includes IEM data 200 and the hub 202. In various aspects, the
commercial products/services system 204g may be embodied as, for
example, an IEM data device, e.g., a patch receiver. In various
aspects, the commercial products/services system 204g may
interoperate, or be otherwise associated with, one or more IEM data
systems 204 and/or one or more commercial systems 106.
[0287] In one scenario, commercial products/services system 204g
include consumer-friendly receivers, such as patch receivers. The
receivers comprise various accessories and incorporate various
designs. For example, children's patch receivers may comprise
cartoon character appliques. Youths' patch receivers may comprise
tattoo-like design aspects. Further examples include IEM data
receivers embodied as/integrated into accessories, e.g., earrings,
naval rings, and other means of adornment, etc.
[0288] Commercial products/services system 204g further comprise
branded or "community" associated products and services.
[0289] 2.3.8 Auto Billing Systems
[0290] Auto billing systems receive, process, and/or facilitate
payment via a financial account. Auto billing applications
associated with the auto billing system and/or with financial
institution systems seamlessly interoperate to generate a bill,
verify accountholder information, charge an account, etc.
Statements are updated to reflect payment information. Similar
applications may be applied for prescriptions, consumer products,
information provision via personal devices, etc.
[0291] FIG. 13 illustrates an exemplary IEM data framework 102
having an auto billing system 204h, according to one embodiment.
The IEM data framework 102 further includes IEM data 200 and the
hub, shown here embodied as the handheld device 402. In various
aspects, the auto billing system 204h may interoperate, or be
otherwise associated with, one or more IEM data systems 204 and/or
one or more commercial systems 106.
[0292] In one scenario, various parties such as patient 506,
physicians, pharmaceutical companies, etc., subscribe to
information feeds/patient population data of IEM data 200 to
further business goals, manage health care, etc. The parties may
receive the information feeds/access population data, etc. via a
variety of devices. For example, patient 506 may receive an
information feed via hub 202 embodied as the handheld device 402,
which, via a software agent, may generate a financial transaction
in the form of an invoice for the information feed displayed for
the patient 506. Payment may be effected via automated methods.
[0293] In a patient selection method, for example, the patient
selects various payment options via the software agent resident on
the handheld device 402. A payment transaction is generated and
communicated to the financial transaction system 106e. The
financial transaction system 106e automatically charges an account
associated with the patient 506. Confirmation of the payment
together with digital, e.g., electronic, copies of the invoice are
provided to the software agent resident on the handheld device 402
for the patient 506 to view, etc.
[0294] In an automated method, for example, a bill and/or financial
transaction are automatically generated upon predetermined
criteria. The predetermined criteria include, for example, delivery
of information associated with an information feed or other source,
access to a data collection, e.g., patient population data stored
in a database, etc. The patient selects various payment options via
the software agent resident on the handheld device 402, and a
payment transaction is generated and communicated to the financial
transaction system 106e. The financial transaction system 106e
automatically charges an account associated with the patient 506.
Confirmation of the payment together with digital copies of the
invoice are provided to the software agent resident on the handheld
device 402 for the patient 506 to view, etc. For example, a
healthcare provider may access patient population data stored in
decision support system 204b via the healthcare system 106a.
Software of the decision support system 204b may cooperate with the
software 502 and the database 504 of the auto billing system 204h
to identify the party to be billed for the access. Upon
identification, the auto billing system 204h may automatically
generate a bill and/or financial transaction for the access via one
or more of the aforedescribed channels.
[0295] 2.3.9 Tracking Systems
[0296] Tracking systems track and integrate product movement data.
In one example, the life cycle of an ingestible device may be
tracked from manufacture to shipment, pharmacy inventory, delivery
to patient, ingestion and expulsion.
[0297] FIG. 14 illustrates an exemplary IEM data framework 102
having a tracking system 204i, according to one embodiment. The IEM
data framework 102 further includes the IEM data 200 and the hub,
shown here embodied as a scanner 1402. In various aspects, the
tracking system 204i, may interoperate, or be otherwise associated
with, one or more IEM data systems 204 and/or one or more
commercial systems 106.
[0298] In one scenario, a pharmaceutical manufacturer produces an
ingestible device 302a such as a particular medication having an
IEM system device therein. The IEM system device contains various
IEM data 200 such as medication identification, batch number, lot
number, and manufacturer identification. The scanner 1402 may be
utilized at various times/locations to scan the ingestible device
302a and capture the IEM data 200 associated therewith. The IEM
data 200 may then be stored, processed, etc., via, for example, the
software 502 and the database 504 of the tracking system 204i. For
example, the IEM data 200 may be read by the scanner at a shipping
point and when received by a pharmacy to ensure inventory control,
distribution integrity, and chain of custody for restricted
pharmaceuticals, etc.
[0299] The tracking information may be used, for example, by
regulatory agencies systems 106i to determine regulatory adherence,
etc.
[0300] 2.3.10 Interdiction Systems
[0301] Interdiction systems track, reconcile, and support
interdiction programs. The interdiction programs include, for
example, programs related to drug identification and use detection
by sworn personnel, search and seizure activities, etc.
[0302] FIG. 15 illustrates an exemplary IEM data framework 102
having an interdiction system 204j, according to one embodiment.
The IEM data framework 102 further includes IEM data 200 and hub,
shown here embodied as a scanner 1402. In various aspects, the
interdiction system 204j may interoperate, or be otherwise
associated with, one or more IEM data systems 204 and/or one or
more commercial systems 106.
[0303] In one scenario, a pharmaceutical manufacturer produces an
ingestible device 302a such as a particular medication having an
IEM system device therein. The IEM system device contains various
IEM data 200 such as medication identification, batch number, lot
number, and manufacturer identification. The scanner 1402 may be
utilized at various times/locations to scan the ingestible device
302a and capture the IEM data 200 associated therewith. The IEM
data 200 may then be communicated to, for example, the software 502
and the database 504 of the interdiction system 204j, where the IEM
data 200 may be accessed by and communicated to regulatory agency
systems 106i to facilitate various regulatory and enforcement
functions, to locate missing controlled substances, to intercept
contraband, to identify unknown substances, and to otherwise
support agency and regulatory activities.
[0304] In various aspects, the IEM data 200 may be communicated
to/from, for example the interdiction system 204j from/to the
tracking system 204i, for processing, storage, etc. For example,
the IEM data 200 may be read by the scanner at a shipping point and
read by a pharmacy to ensure inventory control, distribution
integrity, and chain of custody for restricted pharmaceuticals,
etc. The scanned (read) IEM data 200 may be reconciled between the
interdiction system 204j and the tracking system 204i to ensure
complete shipment, to track shipments through various
jurisdictions, etc. In one example, the IEM data 200 such as the
identifier data, shipment data, patient information, recipient
information, and commercial activities are tracked and reconciled
to intercept contraband and otherwise support agency and regulatory
activities.
[0305] 2.3.11 Subscription Systems
[0306] Subscription systems enable subscription to various IR
information feeds and data/knowledge collections, e.g., IEM data
collection system. For example, patients subscribe to IEM data
information feeds and/or IEM data collections, which aggregate
various sources of data and fuse the data into integrated,
individualized information based on the subscriber's requirements.
The information fusion may include, for example, personalized
medication regimens and alert applications, individual social
community information, music, etc. The information may be
automatically billed, for example, under a single point of charge
model on a recurring basis. The agent may be provided as part of an
embedded device, e.g., standard application on a mobile telephone,
etc.
[0307] FIG. 16 illustrates an exemplary IEM data framework 102
having a subscription system 204k, according to one embodiment. The
IEM data framework 102 further includes IEM data 200 and the hub,
shown here embodied as a mobile telephone 406. In various aspects,
the subscription system 204k may interoperate, or be otherwise
associated with, one or more IEM data systems 204 and/or one or
more commercial systems 106.
[0308] In one scenario, the patient 506 subscribes to various
information feed(s) and/or IEM data collections, discussed
hereinafter in detail. The information feed(s) include, for
example, structured and non-structured information on a variety of
topics generated or delivered from various sources, e.g., websites,
blogs, etc. The IEM data collections include storage repositories
having IEM data. The storage repositories may be associated, e.g.,
integral to or remote from, the subscription system 204k. For
example, an IEM data collection may be resident in part or wholly
in database 504 of the subscription system 204k.
[0309] In one scenario, IEM data 200 are communicated from a
subscription source to a subscriber, e.g., a subscriber's device.
The subscription source includes, for example, IEM data systems
204, e.g., the database 504 of the subscription system 204k,
feedback loop system 204a, patient tools 204d, and decision support
system 204b; commercial systems 106b, e.g., online medical and
business information/newsfeed sources, healthcare system 106a; and
other sources, e.g., devices associated with the patient 506, the
hub, etc. The subscriber includes, for example, a person, group, or
resource, e.g., a database, a computer system, server, network,
etc.
[0310] In various aspects, subscription services may be initiated
via, for example, a software agent resident on the hub or
communication with a local or remote system such as the healthcare
system 106a.
[0311] In various aspects, the subscriptions services may be billed
and paid via, for example, the subscription system 204k and the
financial transaction system 106e.
[0312] In various aspects, the subscription newsfeeds/data may be
combined or integrated into a single or multiple newsfeeds, e.g.,
the software 502 and/or the database 504 of the subscription system
204k may enable data aggregation, etc.
[0313] To illustrate, the patient 506 subscribes to a healthcare
newsfeed and a pharmacy newsfeed, one or more having IEM data 200,
via the subscription system 204k. The patient subscribes by
selecting an application, e.g., software agent resident on the hub,
illustratively embodied here as the mobile telephone 406. Once the
patient has selected the subscription options, the order is
communicated to the subscription system 204k, which, via the
software 502 and the database 504, confirms, processes, stores, and
bills the order. The subscriber's financial account may be
automatically charged, for example, by communicating invoice
information to a financial transaction system 106e associated with
the subscriber's account. Confirmation of the charge may be
communicated from the financial transaction system 106e to the
subscriber via the subscription system 204k and/or the mobile
telephone 406.
[0314] Based on the subscription parameters, the subscription
system 204k receives the healthcare newsfeed information and the
pharmacy newsfeed information. The software 502 of the subscription
system compares subscriber data of the patient 506 in the database
504 against subscriber data found in the pharmacy newsfeed, e.g.,
patients who are prescribed medications for cardiac therapy. Based
on the comparison, software 502 separates the data of the pharmacy
newsfeeds relevant to the subscriber, combines the relevant data
with the healthcare newsfeed information and communicates the
combined newsfeed information to the mobile telephone 406 for
access and display.
[0315] 2.3.12 IEM Data Collection System
[0316] The IEM data collection system provides/facilitates access
to/storage of the IEM data. Examples of the IEM data include
patient population data and electronic medical records. In various
aspects, IEM data collections may include functionality related to
the collection, management, manipulation, storage, dissemination,
and billing of IEM data.
[0317] FIG. 17 illustrates an exemplary IEM data framework 102
having an IEM data collection system 204l, according to one
embodiment. The IEM data framework 102 further includes IEM data
200 and the hub, shown here embodied as a handheld device 402. In
various aspects, the IEM data collection system 204l, may
interoperate, or be otherwise associated with, one or more IEM data
systems 204 and/or one or more commercial systems 106.
[0318] In one scenario, patient population data, e.g., anonymized,
empirical patient data, is stored in one or more repositories,
e.g., the database 504 of the IEM data collection system 204l. The
patient population data may be received from various sources, e.g.,
the IEM data 200 associated with one or more patient 506, IEM data
systems 204 such as behavioral medicine systems 204e, subscription
systems 204k, patient tools 204d, etc., and commercial systems such
as healthcare systems 106a, pharmaceutic systems 106c, university
systems 106d, etc.
[0319] In various aspects, the IEM data collection system 204l may
be consolidated in a single physical and/or logical location, e.g.,
the database 504 of the server 500 of the IEM data collection
system 204l, or distributed across two or more systems or
locations, e.g., remotely distributed on multiple IEM data systems
204, associated with commercial systems 106, and/or distributed
between the IEM data collection system 204l and other
systems/locations.
[0320] Multiprofile users may access, utilize, and/or contribute to
the IEM data collection system 204l. Multiprofile users include,
for example, individuals or groups using various methods/devices
for access, utilization, and/or contribution. Examples of
multiprofile users include patient 506, family members and family
caregivers, professionals, academics, corporates, etc. The
methods/devices include the hub devices such as a mobile telephone,
base station, handheld device, etc., as well as system components
associated with IEM data systems and commercial systems, e.g.,
laptop computer associated with a university network, a desktop
computer associated with the family caregiver system 106g, etc.
[0321] To continue the foregoing illustration, a researcher, using
the university system 106d, accesses the IEM data collection system
204l via the Internet, etc. and submits queries against the patient
population data, extracts various data, etc.
[0322] In various aspects, the IEM data collection system 204l
includes privacy assurance, authentication, and validation
mechanisms with respect to financial, medical, and other privacy
information. For example, the software 502 may authenticate users.
The software 502 may cleanse/verify data to ensure predetermined
privacy thresholds are met.
[0323] 2.3.13 Approval Systems
[0324] Approval systems aggregate and/or analyze various data to
enable an informed approval decision.
[0325] FIG. 18 illustrates an exemplary IEM data framework 102
having an approval system 204m, according to one embodiment. The
IEM data framework 102 further includes IEM data 200, the hub,
shown here embodied as a handheld device 402, and an associated
intelligent pill dispenser 1802. In various aspects, the approval
system 204m, may interoperate, or be otherwise associated with, one
or more IEM data systems 204 and/or one or more commercial systems
106.
[0326] In one scenario, the patient 506 opens an intelligent pill
dispenser 1802, e.g., a pill dispenser having a microchip and
communication abilities. The patient 506 removes a pill having an
IEM system from the intelligent pill dispenser 1802. The
intelligent pill dispenser 1802, via its microchip, senses the
removal of the pill, receives a signal from an IEM system that the
patient 506 has ingested the pill, and determines the remaining
quantity. If the remaining quantity is fewer than a predetermined
threshold quantity, the intelligent pill dispenser 1802
communicates a refill request to the approval system 204m. The
approval system 204m via, for example, the software 502 and the
database 504, verify information associated with the patient 506,
e.g., patient name, prescription identification, medication
ingestion verification, refill timing, etc. The approval system
204m may interoperate with, e.g., communicate with, various IEM
data systems 204 and/or commercial systems 106 to obtain/validate
information. For example, data provided to/resident in the approval
system 204m may be reconciled with medical records of healthcare
system 106, the refill request approved by approval system 204m,
and a refill communicated to the pharmacy system 106b.
[0327] 2.3.14 Forecasting Systems
[0328] Forecasting systems aggregate data and/or facilitate
analysis of the aggregated data/data collections to derive/generate
predictive information.
[0329] FIG. 19 illustrates an exemplary IEM data framework 102
having a forecasting system 204n, according to one embodiment. The
IEM data framework 102 further includes IEM data 200 and the hub,
shown here embodied as a base station 404. In various aspects, the
forecasting system 204n, may interoperate, or be otherwise
associated with, one or more IEM data systems 204 and/or one or
more commercial systems 106.
[0330] In one scenario, for example, IEM data 200 are received by
the base station 404 from ingestible devices associated with
patients 506a-c. The base station 404 communicates the IEM data 200
to the IEM data collection system 204l, which anonymizes the IEM
data 200 and aggregates the anonymized IEM data 200 with patient
population data.
[0331] The IEM data collection system 204l communicates all or a
portion of the patient population data to the forecasting system
204n, where the software 502, e.g., one or more applications,
processes the patient population data to derive various statistics,
conclusions, forecasts, etc., according to predetermined
requirements, objectives, etc. For example, the software 502
processes the patient population data and correlates various data
such as blood pressure readings over a predetermined period of time
versus medication taken versus adherence to medication regimen to
determine overall efficacy of medication regimen and to forecast
titrated patient dosing based on the overall efficacy findings.
[0332] Multiple profile parties, e.g., analysts using the
pharamceutic systems 106e, agents using the regulatory agency
systems 106i, and researchers using the university systems 106d,
access the forecasting system 204n. The multiple profile parties
utilize various tools, e.g., the software 502, to run analytical
and forecasting applications again the patient population data and
to access various forecasting data available in connection with the
forecasting system 204n.
[0333] 2.3.15 Financial Systems
[0334] Financial systems support and enable financial transactions
associated with IEM data. In various aspects, the financial systems
are communicably interoperable with existing automated banking
systems and networks, etc.
[0335] FIG. 20 illustrates an exemplary IEM data framework 102
having a financial system 204o, according to one embodiment. The
IEM data framework 102 further includes IEM data 200 and the hub,
shown here embodied as a mobile telephone 406. In various aspects,
the financial system 204o, may interoperate, or be otherwise
associated with, one or more IEM data systems 204 and/or one or
more commercial systems 106.
[0336] In one scenario, the patient 506, via the mobile telephone
406, places an order for a product/service, e.g., a newsfeed
service from the subscription system 204k. The subscription system
204k, via its software, interoperates with the financial system
204o. The subscription system 204k, for example, securely
communicates encrypted patient financial information such as
account number and subscription information. The financial system
204o authenticates the patient information and securely
interoperates with the patient's financial institution, e.g., via a
commercial system 106 such as the financial transaction system 106e
to charge the patient's account and provide charge
information/confirmation to the patient 506 via, for example, the
mobile telephone 406.
[0337] 2.3.16 IEM Data Phone
[0338] The IEM data phone enables IEM data-related applications.
For example, application(s) include pill regimen scheduling
applications, alert reminder applications, auto refill for
medication applications, patient tool applications, social
networking applications, incentive tracker applications, auto
billing applications, subscription applications, approval
applications, and financial transaction applications. The
applications may be integrated with, associated with, or
independent of one another. The applications may further be
manufacturer-installable on the IEM data phone, downloadable or
otherwise installable by a wholesaler, retailer, user, etc.
Installation may be independent or bundled with other software,
products, etc. In various aspects, the applications are
user-configurable, downloadable, upgradeable, etc.
[0339] In various aspects, the IEM data phone and/or its
applications may share common features, e.g., a common graphical
user interface (GUI); branding, i.e., a collection of images and
ideas representing an economic producer such as concrete symbols
embodied as a name, logo, slogan, design scheme, etc. The IEM data
phone may also include various connectivity schemes, e.g., Internet
and cellular; may provide multimedia capabilities; and may embody
various hardware and software configurations. The IEM data phone
may be embodied in a variety of devices, e.g., the mobile telephone
406, the handheld device 402, etc.
[0340] FIG. 21 illustrates an exemplary IEM data framework 102
having an IEM data phone 204p, according to one embodiment. The IEM
data phone 204p may serve as the hub, for example. IEM data
framework 102 further includes IEM data 200. In various aspects,
the IEM data phone 204p, may interoperate, or be otherwise
associated with, one or more IEM data systems 204 and/or one or
more commercial systems 106.
[0341] In one scenario, the IEM data phone 204p includes the
software 502, e.g., a portfolio of branded applications such as
pill regimen scheduling, alert reminders, auto refills, patient
tools, social networking, incentive trackers, auto billing,
subscriptions, approvals, and financial applications.
[0342] The pill regimen scheduling application may accept,
reconcile, calendar, and manage contraindications and interactions
of medication regimen(s). For example, the patient 506 may input
information related to one or more prescriptions, including the
pharmaceutical name and dosage. The pill regimen scheduling
application may check the input information against existing
information stored on the IEM data phone 204p, e.g., in the
database 504, or elsewhere, e.g., the pharmacy 106b. The pill
regimen scheduling application may provide information regarding
contraindicated medications, side effects, precautionary
instructions. The pill regimen scheduling application may calendar
the dosing information and generate alerts, e.g., reminders
generated at appropriate times alerting the patient to ingest the
medication. The alerts may be audible, visual, email, text message,
etc. and may be integrated with, or independent of, alert reminder
application(s).
[0343] The alert reminder application may accept or access various
data associated with scheduling, including IEM data 200, and
generate alerts at appropriate times. The alerts may be audible,
visual, email, text message, etc. and may be integrated with or
independent of alert reminder application(s). The alert application
may be user-configurable, e.g., type of alert, repetition of alert,
interval of repetition, receivers of alert. The alerts may be
associated with various devices of the patient, family caregivers,
friends, etc. In one example, the patient 506 may schedule
reminders to be sent to the user's device, e.g., the IEM data phone
204p, the handheld device 402, the base station 404, the mobile
telephone 406, etc.
[0344] The alert reminder application may be integrated with other
applications/systems. To illustrate an IEM system associated with
the patient 506 that may, for example, detect medication ingestion
event(s) and communicate the IEM data 200 associated with the
medication ingestion event(s) to the alert reminder application via
the IEM data phone 204p. The alert reminder application may
interoperate with the pill regimen scheduling application and
perform various checks, e.g., the ingested medication was actually
prescribed for the person that ingested it; the ingested medication
was ingested in the correct dosage; the ingested medication was
ingested at the prescribed time interval; etc.
[0345] Predetermined criteria may be used to determine if/when the
alert reminders application generates an alert, reminder, etc. To
continue with the foregoing illustration, upon a determination that
the ingested medication was not prescribed for the person ingesting
it or the wrong dosage was ingested, the alert reminder system
generates alert(s) to a predetermined destination, e.g., alerts in
the form of text messages to mobile telephones associated with the
family caregiver system 106g, alerts in the form of email/text
messages to the healthcare system 106a and the physician system
106f. If the event is deemed critical, e.g., ingestion of
non-prescribed medication, overdosage, etc., the alert reminder
application may generate a call from the IEM data phone 204p to the
emergency assistance system, e.g., place a 911 call. The call
(prerecorded audio, text message, etc.) may contain information
such as the patient's name, the nature of the emergency, the
ingestion details, physician and family caregiver information, and
the physical location of the person ingesting the medication.
[0346] The auto refill application may facilitate automatic refill
of a prescription medication via interoperation with, for example,
the pharmacy system 106b, etc.
[0347] The patient tool application may be provided on or
accessible from the IEM data phone 204p. For example, software
tools for tracking dietary and physiologic symptoms may facilitate
user entry of dietary intake and symptoms, collection of
device-associated physiologic parameters such as blood pressure,
heart rate, etc., correlation/analysis of the data, and feedback
based on the correlation/analysis. The patient tool application may
provide data, e.g., the feedback, for display on the IEM data phone
204p, the IEM data system(s) 204, and/or the commercial system(s)
106.
[0348] The social networking application may facilitate social
networking functionality. For example, the social networking
application may retain various links to selected profiles of
various social networks, receive data related to the selected
profiles, e.g., updates to the profiles, facilitate messaging and
other communication, update the user's profile, etc., communicate
with the IEM data systems(s) 204, and/or the commercial system(s)
106, such as the patient tools/social network 204d and the web
communities 106h.
[0349] The incentive tracker application may collect, manage,
track, update, etc. incentive information. For example, the
incentive tracker application may reconcile data associated with
IEM data collection systems 204l and wholesaler/retailer systems
106j to determine incentive eligibility, e.g., a patient rebate.
The incentive tracker application may further tally points under
various reward systems, notify the patient 506 of milestones,
goals, award of incentive, etc.
[0350] The auto billing application may facilitate billing for
various transactions. The auto billing application may interoperate
with various applications/systems, including the IEM data system(s)
204 and/or the commercial system(s) 106, such as the billing for an
auto refill via the pharmacy system, etc.
[0351] The subscription application facilitates ordering, receipt,
management, etc. of various subscriptions, e.g., newsfeeds, access
to various data collections on a subscription basis, etc. The
subscriptions application may interoperate with various
applications/systems, including the IEM data system(s) 204 and/or
the commercial system(s) 106, such as the subscription system 204k,
the IEM data collection system 204l, etc.
[0352] The approval application aggregates and/or analyzes various
sources of data to enable an informed approval decision. The
approvals application may interoperate with various
applications/systems, including the IEM data system(s) 204 and/or
the commercial system(s) 106, such as the auto refill system 204c,
the subscription system 204f, the financial systems 204o, the
pharmacy systems 106b, the wholesaler/retailer systems 106j,
etc.
[0353] The financial application supports and enables financial
transactions associated with IEM data 200. The financial
application may interoperate with various applications/systems,
including the IEM data system(s) 204 and/or the commercial
system(s) 106, such as the auto refill system 204c, the incentive
system 204f, the subscription system 204k, the approval system
204m, the financial systems 204o, the pharmacy system 106b, the
wholesaler/retailer systems 106j.
[0354] 2.3.17 Social Network System
[0355] Social networks are a social structure made of one or more
nodes, e.g., components such as websites, accessed by individuals
or organizations. The social network is typically tied by one or
more specific types of interdependency, such as epidemiology,
therapeutic regimen, healthcare management, etc., and thus may
attract the interest of otherwise unrelated individuals and groups
having in common an interest in the interdependencies. Social
networks may be built around various communities, e.g., family
caregivers, patients, medical conditions, etc.
[0356] One example of a social network is a patient information
community that provides information related to a particular medical
condition, treatments, medications, regimens, and side effects
based on both provider and anecdotal data. The availability of such
data may provide benchmark-type services, e.g., facilitate
self-assessment of personal progress and adjustment in therapies
and behaviors by comparing and contrasting an individual's progress
with the particulars of others having the same condition, similar
therapies, etc.
[0357] FIG. 22 illustrates an exemplary IEM data framework 102
having a social network system 204q, according to one embodiment.
The IEM data framework 102 further includes IEM data 200, and the
hub, shown here embodied as the base station 404. In various
aspects, the social network system 204q may interoperate, or be
otherwise associated with, one or more IEM data systems 204 and/or
one or more commercial systems 106.
[0358] In one scenario, patient 506 suffers from a cardiac
condition. The patient 506 accesses the social network system 204q,
which may be embodied as the server 500 having the software 502 and
the database 504 having IEM data 200. Patient 506 may access the
social network system 204q, for example, via the base station 404.
The patient 506a searches the database 504 for patient profiles
also having cardiac conditions similar to that of patient 506. The
social network system 204q provides multiple profiles of patients
having similar conditions. The profiles include various data
pertinent to each patient such as medication therapies, personal
behavior histories, etc. The patient 506 requests a comparison of
his medication therapy, medication therapy adherence, and behavior
to that listed in the profiled. The social network system 204q
provides the requested comparative data in the form of a graphical
display. From the display, the patient 506 is able to determine the
profiles having the most favorable treatment outcomes. From such
profiles, the patient 506 and/or social network system 204q analyze
the differences between his medication, medication therapy
adherence, behavior, etc. and the corresponding interdependencies
of the profiles having the most favorable treatment outcomes. The
analysis may contrast the differences found in various areas, as
well as generate prescriptive advice, e.g., in which areas the
patient 506 may want to adjust and specific adjustments based on
the analysis. The patient 506 may adopt the prescriptive advice,
i.e., adjust accordingly, to improve his own personal outcome.
Further, the patient 506 may update the social network system 204q
with the adjustment data, which may be used in the future for
tracking personal improvement as well as benchmarking purposes by
other individuals. In various aspects, the social network system
204q may be communicably associated with other web communities
106h, e.g., youth communities, business communities, etc.
3.0 IEM Data Framework Method
[0359] One aspect comprises, for example, receiving, via a hub,
ingestible event data that originates from multiple ingested event
markers; and communicating, via the hub, at least a portion of the
ingestible event marker data to at least one ingestible event
marker data system.
4.0 IEM Data Framework Article
[0360] One aspect comprises, for example, a storage medium having
instructions, that when executed by a computing platform, result in
execution of a method of utilizing ingestible event marker data,
comprising: receiving, via a hub, the ingestible event data that
originates from multiple ingested event markers; and communicating,
via the hub, at least a portion of the ingestible event marker data
to at least one ingestible event marker data system.
5.0 IEM Data Framework System
[0361] One aspect comprises, for example, a receive module to
receive, via a hub, ingestible event data that originates from
multiple ingested event markers; and a communicate module to
communicate, via the hub, at least a portion of the ingestible
event marker data to at least one ingestible event marker data
system.
6.0 IEM Data Framework Data Modeling and Prescriptive Outcomes
[0362] In various aspects of the present invention, various
techniques, e.g., state characterization based on multi-variate
data fusion techniques, may be employed to generate various output,
e.g., analyses, metrics, predictive information, etc. For example,
an aspect may include data captured and processed to create metrics
that are descriptive and/or predictive of an impending health event
such as a stroke or an indicator of future behavioral choices,
e.g., whether a person will adhere to a medication regimen if such
medication is prescribed in the future.
[0363] To illustrate with reference to FIG. 23, there are shown
exemplary software modules 510a-c of exemplary software 502 of
exemplary IEM data system 204. More particularly, and with
continuing reference to the figures herein, IEM data 200 may be a
predetermined set of data. In one example, the IEM data 200 are
data gathered by a patch receiver 400 and, optionally, a data
logger 2302. The IEM data are provided to an IEM data system 204
such as the forecasting system 204n?. The IEM data system 204
includes software modules 510 having one or more of an analysis
module 510a, a metrics module 510b, and a predictive information
module 510c.
[0364] To continue the illustration, sensors and data loggers
capture longitudinal data. In one example, the patch receiver 400
gathers physiologic data such as positional data associated with
the user of the patch receiver 400 and provides the receiver data
200a to the analysis module 510a. In one example, positional X, Y,
Z data of the use is captured at a predetermined rate or schedule.
Data logger 2302 gathers data logger data 200b such as quality of
sleep, etc., and provides the data logger data 200b to the analysis
module 510a. The analysis module 510a analyzes the positional data
and the data logger data 200b and provides analysis data to the
metrics module 510b for metric generation. In one example, the
captured positional data are analyzed by at least time-normalizing
and interpolating to generate a fixed time of day grid. This
information is provided to the metrics module 510b to generate
various metrics such as the average diurnal pattern, the standard
deviation across days, and the overall variability. From the
metrics, the predictive information module 510c generates
predictive information. For example, the metrics may be analyzed to
predict that the user is very likely to adhere to a medication
regimen. Alternatively, the medication adherence data may be
tracked, e.g., via IEM event data collected from an ingestible
sensor such as an IEM or RFID device, etc., and, when analyzed
alone or with other data, the predictive information module 510c
may generate a characterization of patent stability while on the
medication regimen or other therapy.
[0365] One skilled in the art will recognize that the software
modules 510a, 510b, and 510c may be centrally associated with a
single system component, e.g., the IEM data system 204, or may be
distributed across and/or associated with various system
components, e.g., the patch receiver 400, the hub 202, and/or one
or more IEM data systems 204. In the foregoing examples and in
various aspects of the present invention, calculation and analyses
may be accomplished via one or more modules, or combinations
thereof, and/or with other software.
[0366] Additional examples are set out in Table 1, entitled
"Examples" hereinafter.
TABLE-US-00001 TABLE 1 "Examples" Predictive Analysis Metrics
Information IEM Data 200 Module 510a Module 510b Module 510c
Example 1: IEM data are Data are time- The average Circadian
Patient 1 derived from the normalized and diurnal pattern rhythm
patch receiver. interpolated to a is calculated. regularity The IEM
data fix time of day The standard comparable to include grid.
deviation this patient accelerometer across days is indicates
strong data associated then calculated. likelihood with the patch
The overall adherence to a receiver. variability is medication The
accelerometer the calculated regimen. data are leverage as the
average to capture X, Y, Z of the standard position. 15 deviation.
seconds of data In subject 1, is captured every this is +-13.6
minute and the degrees. mean x, y, z data Taking are reported as
adherence was the positional 95.8% and timing vector. adherence (%
X, Y, Z data are meds taken +-1 turned into hour of dosing postural
angle by time) was 91.3% calculating the angle of each point
measurement from a reference vector of the patient in the supine
state. Example 3: IEM data are Data analyzed Metric used for
Predictive Patient 2 derived from an according to a
characterization information may ingestible sensor predetermined
may include be generated (dose type of formula to blood pressure,
showing medicine, dose) generate patient blood pressure predicted
future and derived from characterization increase over health event
of patch receiver time, blood a stroke and (dosing times, pressure
prediction for physiologic data increase occurrence of such as
heart compared to stroke within rate, heart rate dosing and one
month if variability) dose type), none of the lifestyle based
variables are on sleep and changed, e.g., activity data dosing
type, dosage, lifestyle, activity, etc. Example 4 Other data Data
is time- Calculate Characterization available from normalized and
descriptive of patient receiver: interpolated to a statistics of
stability on Skin temperature fix time of day residual therapy.
Heart-rate grid. distributions Characterization Activity levels
Transformations (mean, std, of patient state. Step-rate that can be
kurtosis, Specifically in Activity class applied to skewness,
neuropsychiatric Other wearable characterize entropy) applications
one devices: patterns Intrinsic can classify Mood (GSR)
differently: dimensionality individuals in Caloric Fourier, based
on stable of manic expenditure Wavelet, number of states. (GSR,
heat-flux) Harlett, dominant Can be used to Pulse Ox principal/
modes more effectively Data available independent (principal,
triage patients from the mobile: components independent based on
Location (GPS) Low-pass components) stability Environment filtering
measures. (wi-fi networks Calculate daily Can be used to in
proximity) residual from understand the Sociability dominant mode
risk profile of a (messaging (average day or population and (email,
SMS, principal better allocate social media) component) health
resources. utilization, proximity to other devices via Bluetooth
.RTM. devices in proximity)
[0367] With continuing reference to Table 1 and with reference to
FIGS. 24a and 24b, which illustrate sample IEM data and sample
metrics as previously discussed, in example 1, analysis modules and
metrics are used to assess the regularity and stability of the
circadian (diurnal) pattern of the individual. These metrics are
then used as surrogate markers of patient stability regularity and
may be descriptive and/or predictive of patient pill taking
behavior.
[0368] Sensor(s), data logger, and/or other IEM data sources may be
used to capture time-stamped data pertaining to an individual. The
data may related to the individual's physiology, e.g. heart-rate,
activity, sleep, body/skin temperature, etc., behavior, e.g.,
mobility, sociability, engagement, technology use, etc., cognitive
state, e.g., mood, stress, emotional state, etc., and/or
environment, e.g. location, temperature, ambient light and sound,
etc. The sensors may be active, i.e., worn and/or carried by
individual, etc., or passive in nature, i.e., found in the
individual's environment.
[0369] The analysis module applies algorithms to one or more data
sources to visualize and characterize the circadian (diurnal)
pattern. Pre-processing may include time normalization and
interpolation of data samples to a fixed time of day to
characterize regularity of daily pattern. Various filters or
transformations may be applied to accentuate time-series features
prior to metric calculation. Metrics related to variability of the
daily pattern include standard deviation calculated across days,
the intrinsic dimensionality calculated as number of significant
principal components in the data series, the daily deviation in the
average pattern and/or other time-series descriptive
statistics.
[0370] The example provided in FIG. 24b relates to variability of
the circadian rhythm to adherence to a medication regimen. Patient
1 has a regular, stable circadian pattern and demonstrates a
high-rate of medication adherence while Patient 2 demonstrates both
irregular circadian patterns and pill taking behavior.
[0371] The heat-maps represent the daily pattern of posture and
pill taking behavior captured over multiple days. Patient 1 has a
regular circadian pattern with relatively low standard deviation
across twelve days of data capture. The individual also
demonstrated high pill taking and timing adherence as reflected in
the regularity of dose number and timing.
[0372] In contrast, Patient 2 has a more irregular pattern with
relatively high levels of temporal standard deviation with respect
to his average daily pattern. Irregularity in transition from
standing to supine postural position is also evident in the
longitudinal postural data. The individual also shows an irregular
pill taking behavior, taking different number of pills per day and
less controlled times within the day.
[0373] Further, any of the embodiments disclosed herein may be
performed in a data processing system. To illustrate, a
diagrammatic system comprises, for example, a processor, a main
memory, a static memory, a bus, a video display, an alpha-numeric
input device, a cursor control device, a drive unit, a signal
generation device, a network interface device, a machine readable
medium, instructions and a network, according to one
embodiment.
[0374] The diagrammatic system may indicate a personal computer
and/or a data processing system in which one or more operations
disclosed herein may be performed. The processor may be a
microprocessor, a state machine, an application-specific integrated
circuit, a field programmable gate array, etc. The main memory may
be a dynamic random access memory and/or a primary memory of a
computer system. The static memory may be a hard drive, a flash
drive, and/or other memory information associated with the data
processing system.
[0375] The bus may be an interconnection between various circuits
and/or structures of the data processing system. The video display
may provide graphical representation of information on the data
processing system. The alpha-numeric input device may be a keypad,
a keyboard and/or any other input device of text, e.g., a special
device to aid the physically challenged. The cursor control device
may be a pointing device such as a mouse. The drive unit may be a
hard drive, a storage system, and/or other longer term storage
subsystem. The signal generation device may be a bios and/or a
functional operating system of the data processing system. The
network interface device may be a device that may perform interface
functions such as code conversion, protocol conversion and/or
buffering required for communication to and from the network. The
machine readable medium may provide instructions on which any of
the methods disclosed herein may be performed. The instructions may
provide source code and/or data code to the processor to enable any
one/or more operations disclosed herein.
[0376] Although the present embodiments have been described with
reference to specific example embodiments, it will be evident that
various modifications and changes may be made to these embodiments
without departing from the broader spirit and scope of the various
embodiments. For example, the various devices, modules, etc.
described herein may be enabled and operated using hardware
circuitry, e.g., CMOS based logic circuitry, firmware, software
and/or any combination of hardware, firmware, and/or software,
e.g., embodied in a machine readable medium.
[0377] For example, the various electrical structure and methods
may be embodied using transistors, logic gates, and electrical
circuits, e.g., Application Specific Integrated circuitry (ASIC)
and/or in Digital Signal Processor (DSP) circuitry. For example,
the receive module and the communicate module and other modules may
be enabled using one or more of the technologies described
herein.
[0378] In addition, it will be appreciated that the various
operations, processes, and methods disclosed herein may be embodied
in a machine-readable medium and/or a machine accessible medium
compatible with a data processing system, e.g., a computer system,
and may be performed in any order. Accordingly, the specification
and drawings are to be regarded in an illustrative rather than a
restrictive sense.
[0379] Any or all data associated with the aforementioned devices
and methods, for example, may be used alone or in combination with
other data to constitute IEM data, i.e., data having an IEM data
aspect.
[0380] In certain embodiments, the system and/or method steps
further includes/utilizes an element for storing data, i.e., a data
storage element, where this element is present on an external
device, such as a bedside monitor, PDA, smart phone, computer
server, etc. Typically, the data storage element is a computer
readable medium. The term "computer readable medium" as used herein
refers to any storage or transmission medium that participates in
providing instructions and/or data to a computer for execution
and/or processing. Examples of storage media include floppy disks,
magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated
circuit, a magneto-optical disk, or a computer readable card such
as a PCMCIA card and the like, whether or not such devices are
internal or external to the computer. A file containing information
may be "stored" on a computer readable medium, where "storing"
means recording information such that it is accessible and
retrievable at a later data by a computer and/or computer-related
component. With respect to computer readable media, "permanent
memory" refers to memory that is permanent. Permanent memory is not
erased by termination of the electrical supply to a computer of
processor. Computer hard-drive ROM, i.e., not used as virtual
memory, CD-ROM, floppy disk and DVD are all examples of permanent
memory. Random Access Memory (RAM) is an example of non-permanent
memory. A file in permanent memory may be editable and
re-writable.
[0381] Also provided are computer executable instructions, i.e.,
programming, for performing the above methods, e.g., for
programming the IEM, receiver, and other components of the system.
The computer executable instructions are present on a computer
readable medium. Accordingly, various aspects provide a computer
readable medium containing programming for use in providing
ingestible event marker data.
[0382] As such, in certain embodiments the systems include one or
more of: a data storage element, a data processing element, a data
display element, a data transmission element, a notification
mechanism, and a user interface. These elements may be present or
otherwise associated with at least one of the ingestible event
marker data, the hub, and the IEM data systems.
[0383] One of the above-described systems is reviewed in terms of a
receive module and a communicate module. The aspects, however, are
not so limited. In a broader sense, the systems are composed of two
or more different modules that communicate with each other, e.g.,
using the hub functionalities as reviewed above, e.g., using the
IEM data in the communication, e.g., using the IEM data systems'
functionalities.
[0384] It is to be understood that this invention is not limited to
particular embodiments described, and as such may vary. It is also
to be understood that the terminology used herein is for the
purpose of describing particular embodiments only, and is not
intended to be limiting, since the scope of the present invention
will be limited only by the appended claims.
[0385] Where a range of values is provided, it is understood that
each intervening value, to the tenth of the unit of the lower limit
unless the context clearly dictates otherwise, between the upper
and lower limit of that range and any other stated or intervening
value in that stated range, is encompassed within the invention.
The upper and lower limits of these smaller ranges may
independently be included in the smaller ranges and are also
encompassed within the invention, subject to any specifically
excluded limit in the stated range. Where the stated range includes
one or both of the limits, ranges excluding either or both of those
included limits are also included in the invention.
[0386] Unless defined otherwise, all technical and scientific terms
used herein have the same meaning as commonly understood by one of
ordinary skill in the art to which this invention belongs. Although
any methods and materials similar or equivalent to those described
herein can also be used in the practice or testing of the present
invention, representative illustrative methods and materials are
now described.
[0387] All publications and patents cited in this specification are
herein incorporated by reference as if each individual publication
or patent were specifically and individually indicated to be
incorporated by reference and are incorporated herein by reference
to disclose and describe the methods and/or materials in connection
with which the publications are cited. The citation of any
publication is for its disclosure prior to the filing date and
should not be construed as an admission that the present invention
is not entitled to antedate such publication by virtue of prior
invention. Further, the dates of publication provided may be
different from the actual publication dates which may need to be
independently confirmed.
[0388] It is noted that, as used herein and in the appended claims,
the singular forms "a", "an", and "the" include plural referents
unless the context clearly dictates otherwise. It is further noted
that the claims may be drafted to exclude any optional element. As
such, this statement is intended to serve as antecedent basis for
use of such exclusive terminology as "solely," "only" and the like
in connection with the recitation of claim elements, or use of a
"negative" limitation.
[0389] As will be apparent to those of skill in the art upon
reading this disclosure, each of the individual embodiments
described and illustrated herein has discrete components and
features which may be readily separated from or combined with the
features of any of the other several embodiments without departing
from the scope or spirit of the present invention. Any recited
method can be carried out in the order of events recited or in any
other order which is logically possible.
[0390] Although the foregoing invention has been described in some
detail by way of illustration and example for purposes of clarity
of understanding, it is readily apparent to those of ordinary skill
in the art in light of the teachings of this invention that certain
changes and modifications may be made thereto without departing
from the spirit or scope of the appended claims.
[0391] Accordingly, the preceding merely illustrates the principles
of the invention. 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 the principles of the
invention and are included within its spirit and scope.
Furthermore, all examples and conditional language recited herein
are principally intended to aid the reader in understanding the
principles of the invention and the concepts contributed by the
inventors to furthering the art, and are to be construed as being
without limitation to such specifically recited examples and
conditions. Moreover, all statements herein reciting principles,
aspects, and embodiments of the invention as well as specific
examples thereof, are intended to encompass both structural and
functional equivalents thereof. Additionally, it is intended that
such equivalents include both currently known equivalents and
equivalents developed in the future, i.e., any elements developed
that perform the same function, regardless of structure. The scope
of the present invention, therefore, is not intended to be limited
to the exemplary embodiments shown and described herein. Rather,
the scope and spirit of present invention is embodied by the
appended claims.
* * * * *