U.S. patent application number 15/240894 was filed with the patent office on 2017-02-23 for management and prioritization of the delivery of glycemic insight messages.
The applicant listed for this patent is MEDTRONIC MINIMED, INC.. Invention is credited to Pratik Agrawal, Louis Dias, Boyi Jiang, Francine R. Kaufman, Chantal M. McMahon, Michael P. Stone, Yuxiang Zhong.
Application Number | 20170053552 15/240894 |
Document ID | / |
Family ID | 58157162 |
Filed Date | 2017-02-23 |
United States Patent
Application |
20170053552 |
Kind Code |
A1 |
Zhong; Yuxiang ; et
al. |
February 23, 2017 |
MANAGEMENT AND PRIORITIZATION OF THE DELIVERY OF GLYCEMIC INSIGHT
MESSAGES
Abstract
A computer-implemented system and related method of managing use
of a diabetes management device are presented here. An embodiment
of the method obtains a number of glycemic insight messages for
delivery to a user device associated with a user of the diabetes
management device, each of the glycemic insight messages conveying
information regarding a relationship between an insight event
derived from patient-specific historical input data and a glycemic
outcome. The glycemic insight messages are culled and prioritized
to identify a group of insight messages intended for delivery. The
method continues by queuing the group of insight messages based on
the culling and prioritizing, and communicating at least one of the
queued insight messages to the user device.
Inventors: |
Zhong; Yuxiang; (Arcadia,
CA) ; McMahon; Chantal M.; (Los Angeles, CA) ;
Agrawal; Pratik; (Sherman Oaks, CA) ; Jiang;
Boyi; (Northridge, CA) ; Stone; Michael P.;
(Lakewood, CA) ; Kaufman; Francine R.; (Los
Angeles, CA) ; Dias; Louis; (Northridge, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MEDTRONIC MINIMED, INC. |
Northridge |
CA |
US |
|
|
Family ID: |
58157162 |
Appl. No.: |
15/240894 |
Filed: |
August 18, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62208479 |
Aug 21, 2015 |
|
|
|
62266820 |
Dec 14, 2015 |
|
|
|
62286828 |
Jan 25, 2016 |
|
|
|
62304605 |
Mar 7, 2016 |
|
|
|
62304609 |
Mar 7, 2016 |
|
|
|
62304615 |
Mar 7, 2016 |
|
|
|
62304618 |
Mar 7, 2016 |
|
|
|
62329021 |
Apr 28, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
A61B 5/4848 20130101;
G06F 19/324 20130101; A61M 2205/3584 20130101; A61M 5/003 20130101;
A61B 5/14532 20130101; G16H 70/00 20180101; A61B 5/14542 20130101;
G16H 40/63 20180101; G16H 40/67 20180101; A61B 5/486 20130101; G09B
5/125 20130101; A61M 2205/18 20130101; A61B 5/743 20130101; A61M
2005/1402 20130101; A61B 5/0022 20130101; A61M 5/1723 20130101;
G16H 70/60 20180101; G06Q 10/109 20130101; G06F 19/3418 20130101;
G09B 19/0092 20130101; A61B 5/742 20130101; A61B 5/746 20130101;
A61M 2205/502 20130101; A61M 2205/52 20130101; A61B 5/7405
20130101; A61M 5/142 20130101; G16H 50/20 20180101; G16H 80/00
20180101; A61B 5/7282 20130101; A61B 5/7275 20130101 |
International
Class: |
G09B 19/00 20060101
G09B019/00; A61B 5/00 20060101 A61B005/00; G09B 5/12 20060101
G09B005/12; A61B 5/145 20060101 A61B005/145 |
Claims
1. A method of managing use of a diabetes management device, the
method comprising: obtaining a number of glycemic insight messages
for delivery to a user device associated with a user of the
diabetes management device, each of the glycemic insight messages
conveying information regarding a relationship between an insight
event derived from patient-specific historical input data and a
glycemic outcome; culling and prioritizing the number of glycemic
insight messages to identify a group of insight messages intended
for delivery; queuing the group of insight messages based on the
culling and prioritizing; and communicating at least one of the
queued insight messages to the user device.
2. The method of claim 1, wherein the obtaining step comprises:
fetching the number of glycemic insight messages from an insight
reservoir that holds generated glycemic insight messages prior to
delivery, wherein the fetching is based on satisfaction of
real-time trigger conditions.
3. The method of claim 2, wherein satisfaction of the real-time
trigger conditions is based on data provided by the diabetes
management device.
4. The method of claim 2, wherein satisfaction of the real-time
trigger conditions is based on real-time input information provided
by the user device.
5. The method of claim 1, wherein the culling and prioritizing step
comprises: subjecting each of the glycemic insight messages to a
hierarchical delivery layer structure comprising a plurality of
filtering sublayers.
6. The method of claim 5, wherein each of the plurality of
filtering sublayers processes a candidate glycemic insight message
by: (1) passing the candidate glycemic insight message to a lower
layer in the hierarchical delivery layer structure; (2) sending the
candidate glycemic insight message back to an insight reservoir
that holds generated glycemic insight messages prior to delivery;
or (3) discarding the candidate glycemic insight message.
7. The method of claim 5, wherein the hierarchical delivery layer
structure comprises at least one reduction layer, at least one user
related layer, at least one weight based layer, and an accumulator
layer arranged in hierarchical order.
8. The method of claim 1, wherein the culling and prioritizing step
removes redundant and conflicting glycemic insight messages from
the number of glycemic insight messages.
9. The method of claim 1, wherein the culling and prioritizing step
influences delivery of the number of glycemic insight messages in
accordance with user feedback collected from a response to the
previously delivered glycemic insight messages.
10. The method of claim 1, wherein the culling and prioritizing
step prioritizes the number of glycemic insight messages in
accordance with their glycemic outcomes.
11. The method of claim 1, further comprising: limiting a total
number of glycemic insight messages delivered over a designated
period of time.
12. The method of claim 1, wherein the communicating step
comprises: controlling delivery times of the at least one of the
queued insight messages.
13. A computer-implemented glycemic insights system comprising: at
least one processor device; and a non-transitory processor-readable
medium operatively associated with the at least one processor
device, the processor-readable medium comprising executable
instructions configurable to cause the at least one processor
device to perform a method comprising: obtaining a number of
glycemic insight messages for delivery to a user device associated
with a user of a diabetes management device, each of the glycemic
insight messages conveying information regarding a relationship
between an insight event derived from patient-specific historical
input data and a glycemic outcome; culling and prioritizing the
number of glycemic insight messages to identify a group of insight
messages intended for delivery; queuing the group of insight
messages based on the culling and prioritizing; and communicating
at least one of the queued insight messages to the user device.
14. The system of claim 13, wherein the obtaining step comprises:
fetching the number of glycemic insight messages from an insight
reservoir that holds generated glycemic insight messages prior to
delivery, wherein the fetching is based on satisfaction of
real-time trigger conditions.
15. The system of claim 13, wherein the culling and prioritizing
step comprises: subjecting each of the glycemic insight messages to
a hierarchical delivery layer structure comprising a plurality of
filtering sublayers.
16. The system of claim 13, wherein the culling and prioritizing
step: removes redundant and conflicting glycemic insight messages
from the number of glycemic insight messages; influences delivery
of the number of glycemic insight messages in accordance with user
feedback related to previously delivered glycemic insight messages;
and prioritizes the number of glycemic insight messages in
accordance with a severity of the glycemic outcomes.
17. A computer-implemented glycemic insights system comprising: a
database system to store and maintain historical event/outcome
combinations for a user of a diabetes management device, each of
the event/outcome combinations comprising insight event data
indicative of a glycemic event and a glycemic outcome corresponding
to the insight event data; a processor-based insight generation
engine to generate glycemic insight messages for delivery to a user
device associated with the user, each of the glycemic insight
messages conveying information regarding a relationship between an
insight event derived from patient-specific historical input data
and a glycemic outcome; and a processor-based insight delivery
engine to cull and prioritize a number of generated glycemic
insight messages to identify a group of insight messages intended
for delivery, queue the group of insight messages based on the
culling and prioritizing, and deliver at least one of the queued
insight messages to the user device.
18. The system of claim 17, wherein the insight delivery engine
fetches the number of generated glycemic insight messages from an
insight reservoir that holds glycemic insight messages prior to
delivery, wherein the fetching is based on satisfaction of
real-time trigger conditions.
19. The system of claim 17, wherein the insight delivery engine
culls and prioritizes the number of generated insight messages by
subjecting each of the generated glycemic insight messages to a
hierarchical delivery layer structure comprising a plurality of
filtering sublayers.
20. The system of claim 17, wherein the insight delivery engine
culls and prioritizes the number of generated insight messages by:
removing redundant and conflicting glycemic insight messages from
the number of generated glycemic insight messages; influencing
delivery of the number of generated glycemic insight messages in
accordance with user feedback related to previously delivered
glycemic insight messages; and prioritizing the number of generated
glycemic insight messages in accordance with a severity of the
glycemic outcomes.
Description
CROSS-REFERENCE TO RELATED APPLICATION(S)
[0001] This application claims the benefit of U.S. provisional
patent application No. 62/208,479, filed Aug. 21, 2015. This
application also claims the benefit of U.S. provisional patent
application No. 62/266,820, filed Dec. 14, 2015. This application
also claims the benefit of U.S. provisional patent application No.
62/286,828, filed Jan. 25, 2016. This application also claims the
benefit of U.S. provisional patent application No. 62/304,605,
filed Mar. 7, 2016. This application also claims the benefit of
U.S. provisional patent application No. 62/304,609, filed Mar. 7,
2016. This application also claims the benefit of U.S. provisional
patent application No. 62/304,615, filed Mar. 7, 2016. This
application also claims the benefit of U.S. provisional patent
application No. 62/304,618 filed Mar. 7, 2016. This application
also claims the benefit of U.S. provisional patent application No.
62/329,021, filed Apr. 28, 2016.
TECHNICAL FIELD
[0002] Embodiments of the subject matter described herein relate
generally to systems and methods for diabetes therapy management.
More particularly, embodiments of the described subject matter
relate to the generation, management, and delivery of insight
messages and glucose management recommendations to mobile devices
and other electronic devices owned or operated by patients.
BACKGROUND
[0003] Portable medical devices are useful for patients that have
conditions that must be monitored on a continuous or frequent
basis. For example, diabetics are usually required to modify and
monitor their daily lifestyle to keep their blood glucose (BG) in
balance. Individuals with Type 1 diabetes and some individuals with
Type 2 diabetes use insulin to control their BG levels. To do so,
diabetics are advised to routinely keep strict schedules, including
ingesting timely nutritious meals, partaking in exercise,
monitoring BG levels daily, and adjusting and administering insulin
dosages accordingly.
[0004] The prior art includes a number of fluid infusion devices
and insulin pump systems that are designed to deliver accurate and
measured doses of insulin via infusion sets (an infusion set
delivers the insulin through a small diameter tube that terminates
at, e.g., a cannula inserted under the patient's skin). In lieu of
a syringe, the patient can simply activate the insulin pump to
administer an insulin bolus as needed, for example, in response to
the patient's high BG level. A patient can monitor BG levels using
a BG meter or measurement device and by using a continuous glucose
sensor if so desired.
[0005] In practice, many processes and behaviors result in
fluctuations in BG levels. Commonly recognized processes and
factors impacting BG levels include food, exercise, disease (acute
or chronic), medication (insulin, oral, etc.), and stress and sleep
patterns, among others. Furthermore, behavioral and environmental
factors such as the time of the day, attentiveness to therapy, and
insulin pump maintenance, can provide additional quantitative
indications of the underlying factors impacting glucose control.
Current reporting tools available to diabetes patients and their
caregivers do not provide correlative analyses that can pinpoint
specific and personalized behaviors that are associated with a
patient's particular glycemic outcomes. Moreover, current reporting
mechanisms do not deliver the relevant analyses intelligently at a
time most suitable for the users' maximal awareness.
[0006] Accordingly, it is desirable to have a system and related
methodologies that support enhanced and more intelligent reporting
to diabetes patients using an insulin infusion system. In addition,
it is desirable to have a mobile application platform that
facilitates the delivery of intelligent messages and notifications
to diabetes patients. Furthermore, other desirable features and
characteristics will become apparent from the subsequent detailed
description and the appended claims, taken in conjunction with the
accompanying drawings and the foregoing technical field and
background.
BRIEF SUMMARY
[0007] In accordance with certain embodiments, a personalized
diabetes management assistant system utilizes information from
various sources to identify and correlate associations to typical
glycemic outcomes (hypoglycemia, hyperglycemia, glucose
fluctuations). The system can be implemented on various computing
platforms (computers, smartphones, tablets, mobile devices, and
diabetes management devices such as an insulin infusion device, a
continuous glucose sensor device, a continuous glucose monitoring
system, or the like) to identify correlations between patient
behavior patterns and glycemic outcomes based on retrospective
data. Embodiments of the system described herein can prevent or
reduce unnecessary user interaction and input, and supplement
predictive analytics of glucose trends based on real time data.
[0008] A method of managing use of a diabetes management device is
disclosed here. An embodiment of the method obtains input data for
a user of the diabetes management device, and compares the input
data against historical event/outcome combinations maintained for
the user. Each of the event/outcome combinations includes insight
event data indicative of a glycemic event and a glycemic outcome
corresponding to the insight event data. The method continues by
determining, based on the comparing, a correlation between the
input data and a glycemic outcome. In response to the determining,
the method generates a glycemic insight message for delivery to the
user. The glycemic insight message includes information regarding a
relationship between at least some of the input data and the
glycemic outcome.
[0009] A computer-implemented glycemic insights system is also
disclosed here. An embodiment of the system includes at least one
processor device and a non-transitory processor-readable medium
operatively associated with the at least one processor device. The
processor-readable medium stores executable instructions that are
configurable to cause the at least one processor device to perform
a method that obtains input data for a user of a diabetes
management device, and compares the input data against historical
event/outcome combinations maintained for the user. Each of the
event/outcome combinations includes insight event data indicative
of a glycemic event and a glycemic outcome corresponding to the
insight event data. The method determines, based on the comparing,
a correlation between the input data and a particular glycemic
outcome. In response to the determining, the method generates a
glycemic insight message for delivery to the user. The glycemic
insight message includes information regarding a relationship
between at least some of the input data and the glycemic
outcome.
[0010] A computer-implemented glycemic insights system is also
disclosed here. An embodiment of the system includes a database
system to store and maintain historical event/outcome combinations
for a user of a diabetes management device, each of the
event/outcome combinations including insight event data indicative
of a glycemic event and a glycemic outcome corresponding to the
insight event data. The system also includes a processor-based
insight generation engine to obtain input data for the user,
compare the obtained input data against historical event/outcome
combinations maintained by the database system for the user,
determine a correlation between the obtained input data and a
glycemic outcome, and generate a glycemic insight message. The
glycemic insight message includes information regarding a
relationship between at least some of the obtained input data and
the glycemic outcome. The system also includes a processor-based
insight delivery engine to regulate and schedule delivery of the
generated glycemic insight message to a user device operated by the
user.
[0011] Another method of managing use of a diabetes management
device is also disclosed here. An embodiment of the method obtains
a number of glycemic insight messages for delivery to a user device
associated with a user of the diabetes management device, each of
the glycemic insight messages conveying information regarding a
relationship between an insight event derived from patient-specific
historical input data and a glycemic outcome. The method continues
by culling and prioritizing the number of glycemic insight messages
to identify a group of insight messages intended for delivery,
queuing the group of insight messages based on the culling and
prioritizing, and communicating at least one of the queued insight
messages to the user device.
[0012] Another computer-implemented glycemic insights system is
also disclosed here. An embodiment of the system includes at least
one processor device and a non-transitory processor-readable medium
operatively associated with the at least one processor device. The
processor-readable medium stores executable instructions that are
configurable to cause the at least one processor device to perform
a method that obtains a number of glycemic insight messages for
delivery to a user device associated with a user of a diabetes
management device, each of the glycemic insight messages conveying
information regarding a relationship between an insight event
derived from patient-specific historical input data and a glycemic
outcome. The method continues by culling and prioritizing the
number of glycemic insight messages to identify a group of insight
messages intended for delivery, queuing the group of insight
messages based on the culling and prioritizing, and communicating
at least one of the queued insight messages to the user device.
[0013] Another computer-implemented glycemic insights system is
also disclosed here. An embodiment of the system includes a
database system to store and maintain historical event/outcome
combinations for a user of a diabetes management device. Each of
the event/outcome combinations includes insight event data
indicative of a glycemic event and a glycemic outcome corresponding
to the insight event data. The system also includes a
processor-based insight generation engine to generate glycemic
insight messages for delivery to a user device associated with the
user, each of the glycemic insight messages conveying information
regarding a relationship between an insight event derived from
patient-specific historical input data and a glycemic outcome. A
processor-based insight delivery engine is used to cull and
prioritize a number of generated glycemic insight messages to
identify a group of insight messages intended for delivery, queue
the group of insight messages based on the culling and
prioritizing, and deliver at least one of the queued insight
messages to the user device.
[0014] A method of reporting glucose information for a user of a
diabetes management device is also disclosed here. An embodiment of
the method obtains input data for the user of the diabetes
management device, identifies a glycemic response event based on an
analysis of the obtained input data, generates a graphical
representation of a glucose response to the glycemic response
event, and delivers the generated graphical representation of the
glucose response to a user device operated by the user.
[0015] A computer-implemented glucose reporting system is also
disclosed here. An embodiment of the reporting system includes at
least one processor device and a non-transitory processor-readable
medium operatively associated with the at least one processor
device. The processor-readable medium stores executable
instructions that are configurable to cause the at least one
processor device to perform a method that obtains input data for a
user of a diabetes management device, identifies a glycemic
response event based on an analysis of the obtained input data,
generates a graphical representation of a glucose response to the
glycemic response event, and delivers the generated graphical
representation of the glucose response to a user device operated by
the user.
[0016] Another method of reporting glucose information for a user
of a diabetes management device is also disclosed here. An
embodiment of the method obtains input data for the user of the
diabetes management device, identifies a glycemic response event,
and calculates one or more recommended glycemic control parameters
based on an analysis of the obtained input data. The one or more
glycemic control parameters are calculated to extend a time period
during which the user remains within a target glucose range
following the glycemic response event. The method continues by
generating an output message that includes at least some of the
recommended glycemic control parameters, and delivering the
generated output message to a user device operated by the user of
the diabetes management device.
[0017] Another computer-implemented glucose reporting system is
also disclosed here. An embodiment of the system includes at least
one processor device and a non-transitory processor-readable medium
operatively associated with the at least one processor device. The
processor-readable medium stores executable instructions that are
configurable to cause the at least one processor device to perform
a method that obtains input data for a user of a diabetes
management device, identifies a glycemic response event, and
calculates one or more recommended glycemic control parameters
based on an analysis of the obtained input data. The one or more
glycemic control parameters are calculated to extend a time period
during which the user remains within a target glucose range
following the glycemic response event. The method continues by
generating an output message that includes at least some of the
recommended glycemic control parameters, and delivering the
generated output message to a user device operated by the user of
the diabetes management device.
[0018] This summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the detailed description. This summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used as an aid in determining the scope of
the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] A more complete understanding of the subject matter may be
derived by referring to the detailed description and claims when
considered in conjunction with the following figures, wherein like
reference numbers refer to similar elements throughout the
figures.
[0020] FIG. 1 is a simplified block diagram representation of an
exemplary embodiment of a glycemic insights delivery system;
[0021] FIG. 2 is a simplified block diagram representation of an
exemplary embodiment of a computer-based or processor-based device
suitable for deployment in the system shown in FIG. 1;
[0022] FIG. 3 is a simplified block diagram representation of an
exemplary embodiment of a glycemic insights delivery system in
cooperation with a patient's mobile device;
[0023] FIG. 4 is a graph of sensor glucose, which represents a
graphical element of a glycemic insight message;
[0024] FIG. 5 is a diagram that depicts how glycemic insight
messages can be provided on a patient's glucose profile;
[0025] FIG. 6 is a graphical representation of a map having
glycemic insight information rendered therewith;
[0026] FIG. 7 is a graphical representation of a displayed screen
of a calendar app having glycemic insight information rendered
therewith;
[0027] FIG. 8 is a flow chart that illustrates an exemplary
embodiment of a process for generating and delivering glycemic
insights;
[0028] FIG. 9 is a flow chart that illustrates an exemplary
embodiment of an insights generation process;
[0029] FIG. 10 is a schematic block diagram of a layered structure
suitable for use with the insight delivery engine shown in FIG.
3;
[0030] FIG. 11 is part one of an exemplary lookup table suitable
for use in resolving internal conflicting glycemic outcomes
[0031] FIG. 12 is part two of the exemplary lookup table depicted
in FIG. 11;
[0032] FIG. 13 is part one of an exemplary lookup table suitable
for use in resolving external conflicting glycemic outcomes;
[0033] FIG. 14 is part two of the exemplary lookup table depicted
in FIG. 13;
[0034] FIG. 15 is a graph that depicts delivery curves that
influence insight message delivery timing;
[0035] FIG. 16 is an exemplary graph of overlaid glucose sensor
traces as tethered to a particular event;
[0036] FIG. 17 is an exemplary graph of an individual glucose
sensor trace curve surrounding the time of a specific event;
[0037] FIG. 18 is another exemplary graph of an individual glucose
sensor trace curve surrounding the time of a specific event;
[0038] FIG. 19 is a flow chart that illustrates an exemplary
embodiment of a glucose information reporting process; and
[0039] FIG. 20 is a flow chart that illustrates an exemplary
embodiment of a glycemic outcome optimization process.
DETAILED DESCRIPTION
[0040] The following detailed description is merely illustrative in
nature and is not intended to limit the embodiments of the subject
matter or the application and uses of such embodiments. As used
herein, the word "exemplary" means "serving as an example,
instance, or illustration." Any implementation described herein as
exemplary is not necessarily to be construed as preferred or
advantageous over other implementations. Furthermore, there is no
intention to be bound by any expressed or implied theory presented
in the preceding technical field, background, brief summary or the
following detailed description.
[0041] Techniques and technologies may be described herein in terms
of functional and/or logical block components, and with reference
to symbolic representations of operations, processing tasks, and
functions that may be performed by various computing components or
devices. Such operations, tasks, and functions are sometimes
referred to as being computer-executed, computerized,
software-implemented, or computer-implemented. It should be
appreciated that the various block components shown in the figures
may be realized by any number of hardware, software, and/or
firmware components configured to perform the specified functions.
For example, an embodiment of a system or a component may employ
various integrated circuit components, e.g., memory elements,
digital signal processing elements, logic elements, look-up tables,
or the like, which may carry out a variety of functions under the
control of one or more microprocessors or other control
devices.
[0042] When implemented in software, firmware, or
processor-readable instructions, various elements of the systems
described herein are essentially the code segments or instructions
that perform the various tasks. In certain embodiments, the program
or code segments are stored in a tangible processor-readable
medium, which may include any medium that can store or transfer
information. Examples of a non-transitory and processor-readable
medium include an electronic circuit, a semiconductor memory
device, a ROM, a flash memory, an erasable ROM (EROM), a floppy
diskette, a CD-ROM, an optical disk, a hard disk, or the like.
[0043] The following description relates to a diabetes patient
support system that generates and delivers insight messages to
patients. The exemplary embodiment disclosed herein is a
cloud-based architecture in that most of the processor-intensive
tasks are performed by one or more server systems that communicate
with remote mobile client devices (e.g., smartphones), portable
insulin infusion devices, sources of data, and possibly other
remote devices. The disclosed system obtains and processes
patient-specific data from various sources, including insulin
infusion devices, continuous glucose sensor devices, and mobile
client devices. The patient-specific data is processed and analyzed
to generate glycemic insights and glucose management
recommendations that can help patients manage their diabetes
therapy.
[0044] For the sake of brevity, conventional features and
functionality related to infusion systems, insulin pumps, infusion
sets, and fluid reservoirs may not be described in detail here.
Examples of infusion pumps and/or related pump drive systems used
to administer insulin and other medications may be of the type
described in, but not limited to, U.S. Pat. Nos. 5,505,709;
6,485,465; 6,554,798; 6,558,351; 6,659,980; 6,752,787; 6,817,990;
6,932,584; and 7,621,893; which are herein incorporated by
reference.
[0045] As used herein, an "outcome" is a patient-related result
having some correlation to an insight event. For the exemplary
embodiment described herein, a "glycemic outcome" is a
patient-related result that is associated with the patient's
glycemic state, diabetes therapy, insulin status, condition of the
insulin infusion device, or the like. More specifically, a glycemic
outcome can correspond to a status of blood sugar levels, such as
high, low, variable, in range, etc. The glycemic insights delivery
system described herein considers a predetermined number of
glycemic outcomes, and maps insight events to the glycemic
outcomes.
[0046] As used herein, a "glycemic insight" is a statistically
derived association between an action/event (or a collection of
actions/events) and a corresponding outcome as measured by glucose
readings.
[0047] As used herein, a "glycemic insight message" is any
notification, a display, an interactive GUI, a graphical report, or
other suitably formatted item that can be communicated to a
patient, and that conveys information associated with a glycemic
insight. A glycemic insight message conveys the content of at least
one glycemic insight in a manner that can be understood and
interpreted by the patient. For example, a glycemic insight message
will include at least some information related to a triggering
glycemic event, along with some information related to the cause
and the outcome surrounding the event.
[0048] As used herein, an "event feature" is any notable occurrence
that can reasonably be detected from available data sources that
may have an influence on or be affiliated with resulting glucose
levels. Stated another way, an "event feature" is a characteristic
or attribute of a notable occurrence that may influence or be
affiliated with a glucose outcome.
[0049] As used herein, an "insight event" can be a single event
feature or a combination of multiple event features. At any
particular time, the glycemic insights delivery system described
herein considers a predetermined set or universe of insight events
of interest. For example, the set of insight events can be selected
in a way that focuses on realistic, clinically feasible, or
relevant glycemic events that have some relationship to patient
outcomes. Thus, the system need not consider or analyze all of the
event features and all possible combinations of event features.
[0050] As used herein, an "event/outcome combination" refers to an
association between one insight event and one outcome. An
event/outcome combination may include or be associated with:
insight event data indicative of a glycemic event; and a glycemic
outcome corresponding to the insight event data.
[0051] As used herein, a "trigger" refers to an insight event, a
detectable status or condition, or a combination thereof that
initiates an action. In this regard, a trigger can initiate the
generation of a glycemic insight message, initiate the processing
of generated insight messages for delivery, initiate the actual
delivery of a particular insight message, or the like.
[0052] System Overview
[0053] Turning now to the drawings, FIG. 1 is a simplified block
diagram representation of an exemplary embodiment of a glycemic
insights delivery system 100 that is suitably configured to support
the techniques and methodologies described in more detail below.
The system 100 supports users of insulin infusion devices, and
performs various techniques and methods to help users (patients,
caregivers, healthcare providers, parents, etc.) manage the use of
insulin infusion devices. It should be appreciated that FIG. 1
depicts one possible implementation of a glycemic insights delivery
system, and that other arrangements, architectures, and deployments
can be provided if so desired. The system 100 (which has been
simplified for purposes of illustration) generally includes or
cooperates with the following components, without limitation: a
cloud-based glycemic insights system 102; a mobile device 104; an
insulin infusion device 106; a blood glucose meter 108; and a
continuous glucose sensor 110. The mobile device 104 is a client
device that is owned or operated by the user, i.e., a diabetic
patient. The insulin infusion device 106, the blood glucose meter
108, and the glucose sensor 110 are components of an insulin
infusion system that is used by the patient to treat diabetes. The
system 100 may also include or cooperate with an optional data
uploader component 112. It should be appreciated that the insulin
infusion device 106 can be an optional component in some
applications (for example, for Type 2 diabetes patients). For such
applications, another diabetes management device and/or the mobile
device 104 can function in an equivalent manner to support the
system 100.
[0054] The glycemic insights system 102 and the mobile device 104
are communicatively coupled to a network 114. In certain
embodiments, the insulin infusion device 106, the blood glucose
meter 108, and/or the continuous glucose sensor 110 are also
communicatively coupled to the network 114 to facilitate the
uploading of relevant data to the glycemic insights system 102.
Alternatively, or additionally, the insulin infusion device 106,
the blood glucose meter 108, and the continuous glucose sensor 110
provide relevant data to the data uploader component 112, which in
turn uploads the data to the glycemic insights system 102 via the
network 114.
[0055] FIG. 1 depicts the network 114 in a simplified manner. In
practice, the system 100 may cooperate with and leverage any number
of wireless and any number of wired data communication networks
maintained or operated by various entities and providers.
Accordingly, communication between the various components of the
system 100 may involve multiple network links and different data
communication protocols. In this regard, the network 114 can
include or cooperate with any of the following, without limitation:
a local area network; a wide area network; the Internet; a personal
area network; a cellular communication network; a satellite
communication network; a video services or television broadcasting
network; a network onboard a vehicle; or the like. The components
of the system may be suitably configured to support a variety of
wireless and wired data communication protocols, technologies, and
techniques as needed for compatibility with the network 114.
[0056] In accordance with certain exemplary embodiments, the
glycemic insights system 102 is implemented as at least one
computer-based or processor-based component. For simplicity and
ease of illustration, FIG. 1 depicts the glycemic insights system
102 as a single block--it should be appreciated that any number of
distinct hardware components can be utilized to implement the
glycemic insights system 102. An exemplary embodiment of a device
suitable for implementing the glycemic insights system 102 is
described below with reference to FIG. 2.
[0057] The glycemic insights system 102 can be considered the
"heart" of the glycemic insights delivery system 100. The glycemic
insights system 102 includes or cooperates with a database system
116 (which is realized using one or more components) that supports
the functionality and operation of the glycemic insights delivery
system 100. The glycemic insights system 102 collects and analyzes
input data for each patient (the input data can originate from
various sources, including an insulin infusion device and/or a
source other than the insulin infusion device, such as: a glucose
sensor or meter, a mobile device operated by a user of the insulin
infusion device, a computing device, etc.), generates relevant and
timely glycemic insights as needed, and manages the delivery of the
generated glycemic insights to the patients. The glycemic insights
system 102 and the related database system 116 are described in
more detail below.
[0058] In certain embodiments, some or all of the functionality and
processing intelligence of the glycemic insights system 102 can
reside at the mobile device 104. In other words, the glycemic
insights delivery system 100 need not rely on a network-based or a
cloud-based server arrangement, although such a deployment might be
the most efficient and economical implementation. In other
embodiments, some or all of the functionality and processing
intelligence of the glycemic insights system 102 can reside at the
insulin infusion device 106 and/or at other components or computing
devices that are compatible with the system 100. These and other
alternative arrangements are contemplated by this disclosure. To
this end, some embodiments of the system 100 may include additional
devices and components that serve as data sources, data processing
units, and/or glycemic insight delivery mechanisms. For example,
the system 100 may include any or all of the following elements,
without limitation: computer devices or systems; patient monitors;
healthcare provider systems; data communication devices; and the
like.
[0059] The mobile device 104 can be realized using a variety of
different device platforms. For example, the mobile device 104 can
be implemented as any of the following, without limitation: a
cellular telephone or smartphone; a portable computer (e.g., a
laptop, a tablet, or a netbook computer); a portable media player;
a portable video game device; a portable medical device; a
navigation device such as a global positioning system (GPS) device;
a wearable computing device; an electronic toy or game; etc. In
accordance with certain exemplary embodiments, each mobile device
104 supported by the system 100 is implemented as a computer-based
or processor-based component. For simplicity and ease of
illustration, FIG. 1 depicts only one mobile device 104. In
practice, however, the system 100 is suitably configured to support
a plurality of mobile devices 104, wherein each patient or user
owns or operates at least one of the supported mobile devices 104.
An exemplary embodiment of a device suitable for implementing the
mobile device 104 is described below with reference to FIG. 2.
[0060] The remainder of this description assumes that the mobile
device 104 is a smartphone used by the particular patient. To this
end, the configuration and general functionality of the mobile
device 104 can be substantially consistent with conventional
smartphone design. In this regard, a suitably designed "glycemic
insights" mobile app is installed on the mobile device 104 to allow
the patient to receive, view, and interact with insight messages
and notifications provided by the glycemic insights system 102. The
mobile app installed on the mobile device 104 can also be utilized
to provide relevant data to the glycemic insights system 102 for
storage and analysis. For example, the mobile app can manage and
upload the following information, without limitation: calendar data
(time of day, day of the week, month, season, etc.); user profile
data; GPS data that indicates the geographic position of the mobile
device 104; map or navigation data associated with operation of the
mobile device 104; user-entered meal consumption, food content,
and/or food ingredient data; user-entered carbohydrate data;
user-entered exercise related data; user-entered medication related
data; user response data associated with the receipt of glycemic
insight messages; user feedback related to glycemic insight
messages; accelerometer data; contacts list information; web
browser data; consumer purchasing data; and the like.
[0061] In certain embodiments, the insulin infusion device 106 is a
portable patient-worn or patient-carried component that is operated
to deliver insulin into the body of the patient via, for example,
an infusion set. In accordance with certain exemplary embodiments,
each insulin infusion device 106 supported by the system 100 is
implemented as a computer-based or processor-based component. For
simplicity and ease of illustration, FIG. 1 depicts only one
insulin infusion device 106. In practice, however, the system 100
is suitably configured to support a plurality of insulin infusion
device 106, wherein each patient or user owns or operates at least
one of the insulin infusion devices 106. An exemplary embodiment of
a device suitable for implementing the insulin infusion device 106
is described below with reference to FIG. 2.
[0062] The system 100 obtains input data from one or more sources,
which may include various diabetes management devices (an insulin
infusion device, a continuous glucose monitoring device, a glucose
sensor, a monitor device, or the like). In this regard, the insulin
infusion device 106 represents a source of input data for the
system 100. In certain embodiments, the insulin infusion device 106
provides data that is associated with its operation, status,
insulin delivery events, and the like. As mentioned previously,
relevant data generated or collected by the insulin infusion device
106 can be transmitted directly to the glycemic insights system 102
or indirectly by way of the data uploader component 112, depending
on the particular implementation of the system 100. The particular
type of data provided by the insulin infusion device 106 is
described in more detail below.
[0063] For the sake of simplicity, FIG. 1 depicts only one blood
glucose meter 108. In practice, however, the system 100 is suitably
configured to support a plurality of blood glucose meters 108,
wherein each patient or user owns or operates at least one of the
blood glucose meters 108. The blood glucose meter 108 is configured
to measure the blood glucose level of a user by analyzing a blood
sample. For example, the blood glucose meter 108 may include a
receptacle for receiving a blood sample test strip. In this regard,
the user inserts a test strip into the blood glucose meter 108,
which analyzes the sample and displays a blood glucose level
corresponding to the test strip sample. The blood glucose meter 108
may be configured to communicate the measured blood glucose level
to the insulin infusion device 106 for storage and processing,
directly to the glycemic insights system 102, or to the data
uploader component 112. In some scenarios, the patient is
responsible for entering each blood glucose measurement into the
insulin infusion device 106. Ultimately, the measured blood glucose
data is provided to the glycemic insights system 102 for
analysis.
[0064] For the sake of simplicity, FIG. 1 depicts only one glucose
sensor 110. In practice, however, the system 100 is suitably
configured to support a plurality of glucose sensors 110, wherein
each patient or user owns or operates at least one of the glucose
sensors 110. The glucose sensor 110 is suitably configured to
measure a glucose level (interstitial) of the patient in real time.
The glucose sensor 110 may include a wireless transmitter that
facilitates transmission of the sensor glucose data to other
devices, such as the insulin infusion device 106 or the data
uploader component 112. In some implementations, the glucose sensor
110 can provide the sensor glucose data directly to the glycemic
insights system 102. Ultimately, the sensor glucose data is
received by the glycemic insights system 102 for processing.
[0065] Depending on the particular embodiment and application, the
system 100 can include or cooperate with other devices, systems,
and sources of input data. For example, in certain embodiments the
system 100 includes one or more sources of contextual information
or data, which may include, without limitation: activity tracker
devices; meal logging devices or apps; mood tracking devices or
apps; and the like.
[0066] As mentioned above, the glycemic insights delivery system
100 includes or cooperates with computer-based and/or
processor-based components having suitably configured hardware and
software written to perform the functions and methods needed to
support the features described herein. For example, the glycemic
insights system 102, each mobile device 104, and each insulin
infusion device 106 can be realized as an electronic
processor-based component. Moreover, each blood glucose meter 108
and each data uploader component 112 can also be realized as a
processor-based component. In this regard, FIG. 2 is a simplified
block diagram representation of an exemplary embodiment of a
computer-based or processor-based device 200 that is suitable for
deployment in the system shown in FIG. 1.
[0067] The illustrated embodiment of the device 200 is intended to
be a high-level and generic representation of one suitable
platform. In this regard, any of the computer-based or
processor-based components of the system 100 can utilize the
architecture of the device 200. The illustrated embodiment of the
device 200 generally includes, without limitation: at least one
processor 202; a suitable amount of memory 204; device-specific
hardware, software, firmware, and/or features 206; a user interface
208; a communication module 210; and a display element 212. Of
course, an implementation of the device 200 may include additional
elements, components, modules, and functionality configured to
support various features that are unrelated to the subject matter
described here. For example, the device 200 may include certain
features and elements to support conventional functions that might
be related to the particular implementation and deployment of the
device 200. In practice, the elements of the device 200 may be
coupled together via a bus or any suitable interconnection
architecture 214.
[0068] The processor 202 may be implemented or performed with a
general purpose processor, a content addressable memory, a digital
signal processor, an application specific integrated circuit, a
field programmable gate array, any suitable programmable logic
device, discrete gate or transistor logic, discrete hardware
components, or any combination designed to perform the functions
described here. Moreover, the processor 202 may be implemented as a
combination of computing devices, e.g., a combination of a digital
signal processor and a microprocessor, a plurality of
microprocessors, one or more microprocessors in conjunction with a
digital signal processor core, or any other such configuration.
[0069] The memory 204 may be realized as RAM memory, flash memory,
EPROM memory, EEPROM memory, registers, a hard disk, a removable
disk, a CD-ROM, or any other form of storage medium known in the
art. In this regard, the memory 204 can be coupled to the processor
202 such that the processor 202 can read information from, and
write information to, the memory 204. In the alternative, the
memory 204 may be integral to the processor 202. As an example, the
processor 202 and the memory 204 may reside in an ASIC. At least a
portion of the memory 204 can be realized as a computer storage
medium, e.g., a tangible computer-readable medium having
computer-executable instructions stored thereon. The
computer-executable instructions, when read and executed by the
processor 202, cause the device 200 to perform certain tasks,
operations, functions, and processes that are specific to the
particular embodiment. In this regard, the memory 204 may represent
one suitable implementation of such computer-readable media.
Alternatively or additionally, the device 200 could receive and
cooperate with computer-readable media (not separately shown) that
is realized as a portable or mobile component or platform, e.g., a
portable hard drive, a USB flash drive, an optical disc, or the
like.
[0070] The device-specific hardware, software, firmware, and
features 206 may vary from one embodiment of the device 200 to
another. For example, the device-specific hardware, software,
firmware, and features 206 will support: smartphone functions and
features when the device 200 is realized as a mobile telephone;
conventional personal computer functions and features if the device
200 is realized as a laptop or tablet computer; insulin pump
operations when the device 200 is realized as an insulin infusion
device; etc. In practice, certain portions or aspects of the
device-specific hardware, software, firmware, and features 206 may
be implemented in one or more of the other blocks depicted in FIG.
2.
[0071] The user interface 208 may include or cooperate with various
features to allow a user to interact with the device 200.
Accordingly, the user interface 208 may include various
human-to-machine interfaces, e.g., a keypad, keys, a keyboard,
buttons, switches, knobs, a touchpad, a joystick, a pointing
device, a virtual writing tablet, a touch screen, a microphone, or
any device, component, or function that enables the user to select
options, input information, or otherwise control the operation of
the device 200. The user interface 208 may include one or more
graphical user interface (GUI) control elements that enable a user
to manipulate or otherwise interact with an application via the
display element 212.
[0072] The communication module 210 facilitates data communication
between the device 200 and other components as needed during the
operation of the device 200. In the context of this description,
the communication module 210 can be employed to transmit or stream
device-related control data, patient-related data, device-related
status or operational data, glycemic insight messages and
notifications, and the like. It should be appreciated that the
particular configuration and functionality of the communication
module 210 can vary depending on the hardware platform and specific
implementation of the device 200. Accordingly, with reference to
FIG. 1, the communication module of the glycemic insights system
102 is utilized to obtain input data from various sources, and to
send glycemic insight messages and notifications to the mobile
device 104. Moreover, the communication module of the insulin
infusion device 106 can be used to receive sensor glucose data from
the glucose sensor 110, and to send input data to the glycemic
insights system 102. In practice, an embodiment of the device 200
may support wireless data communication and/or wired data
communication, using various data communication protocols. For
example, the communication module 210 could support one or more
wireless data communication protocols, techniques, or
methodologies, including, without limitation: RF; IrDA (infrared);
Bluetooth; ZigBee (and other variants of the IEEE 802.15 protocol);
IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other
variation); Direct Sequence Spread Spectrum; Frequency Hopping
Spread Spectrum; cellular/wireless/cordless telecommunication
protocols; wireless home network communication protocols; paging
network protocols; magnetic induction; satellite data communication
protocols; wireless hospital or health care facility network
protocols such as those operating in the WMTS bands; GPRS; and
proprietary wireless data communication protocols such as variants
of Wireless USB. Moreover, the communication module 210 could
support one or more wired/cabled data communication protocols,
including, without limitation: Ethernet; powerline; home network
communication protocols; USB; IEEE 1394 (Firewire); hospital
network communication protocols; and proprietary data communication
protocols.
[0073] The display element 212 is suitably configured to enable the
device 200 to render and display various screens, insight messages,
notifications, GUIs, GUI control elements, drop down menus,
auto-fill fields, text entry fields, message fields, or the like.
Of course, the display element 212 may also be utilized for the
display of other information during the operation of the device
200, as is well understood. Notably, the specific configuration,
operating characteristics, size, resolution, and functionality of
the display element 210 can vary depending upon the practical
implementation of the device 200. For example, if the device 200 is
a laptop computer, then the display element 212 may be a relatively
large monitor. Alternatively, if the device 200 is a cellular
telephone device, then the display element 212 may be a relatively
small integrated display screen, such as a touch-sensitive
screen.
[0074] Glycemic Insights
[0075] The glycemic insights delivery system 100 provides useful
information and messages to diabetes patients so that the patients
can better understand how certain situations lead to predictable
outcomes. Many processes and behaviors result in fluctuations in
blood glucose levels. Commonly recognized processes impacting blood
glucose levels include food, exercise, disease (acute or chronic),
medication (insulin, oral, and other types), stress and sleep
patterns, and the like. Furthermore, behavioral factors such as the
time of the day, attentiveness to therapy, and the proper use and
maintenance of the insulin infusion system can provide additional
quantitative indications of the underlying factors impacting
glucose control. Current reporting systems and schemes available to
diabetes patients and their caregivers do not provide correlative
analyses that can pinpoint the specific, personalized behaviors
that are associated with a patient's glycemic outcomes. Moreover,
current reporting mechanisms do not always provide reports and
notifications in accordance with an intelligent delivery timing
scheme that attempts to maximize user awareness.
[0076] The glycemic insights delivery system 100 represents a
personalized diabetes management assistant system that utilizes
information and data collected from various sources to identify the
associations to typical glycemic outcomes (such as hypoglycemia,
hyperglycemia, and control in the range). The system 100 considers
combinations or patterns of input data that are based on clinical
research, wherein such combinations or patterns are typically
correlated to the glycemic outcomes of interest. As explained above
with reference to FIG. 1 and FIG. 2, the system 100 can be
implemented on various computing platforms (computers, smartphones,
tablets, and insulin infusion devices) to identify certain
correlations between patient behaviors and glycemic outcomes based
on retrospective data. The system 100 can also be utilized to
reduce or prevent unnecessary user interaction, and to input and
supplement predictive analytics of glucose prediction based on real
time data. In an exemplary embodiment, the system 100 employs a
cloud-based server architecture and related processing power to
generate glycemic insights by identifying trends and associations
between glycemic outcomes (both short and long term) and the
behavior of the patients. The system 100 is suitably configured and
operated to optimize the delivery time of glycemic insight messages
to patients, caregivers, and healthcare providers to increase the
likelihood that the messages will be opened or read, understood,
and acted upon (if needed). In addition to increasing the
likelihood of messages being read, the intelligent insight message
delivery scheme presented here also strives to time delivery of
insight messages at appropriate times, e.g., when an insight
message is actionable, to enhance positive results.
[0077] In practice, the system 100 requires a minimum amount of
input data per patient before it can generate intelligent and
accurate glycemic insights. For example, it may be necessary to
collect input data for at least one full day. Going forward,
however, the glycemic insights generated by the system 100 will
progressively become more sophisticated and accurate as more and
more input data is collected and analyzed for a given patient. The
glycemic outcome assessment techniques and insight generation
methodologies described herein assume that the sources of input
data (such as glucose sensors, blood glucose meters, physiological
sensors, and the like) are operating within an acceptable range of
accuracy.
[0078] FIG. 3 is a simplified block diagram representation of an
exemplary embodiment of a glycemic insights delivery system 300 in
cooperation with a patient's mobile device 302. Certain aspects of
the system 300 are similar to that described above for the system
100 (see FIG. 1), and common features and functions will not be
redundantly described here. The embodiment of the system 300 shown
in FIG. 3 generally includes, without limitation: an insight
generation engine 304; an insight delivery engine 306; and a
database system 308 (which may correspond to the database system
116 described above). The insight generation engine 304 and the
insight delivery engine 306 are suitably implemented as
processor-based functional modules that are designed to perform the
various functions and methods described in detail herein. The
insight generation engine 304 receives and processes new input data
310 as it becomes available from various data sources. New input
data 310 can be filtered or otherwise managed, stored, and
maintained in the database system 308 as needed for purposes of
ongoing use as historical data in the future. Any amount of the new
input data 310 can be compared against historical event/outcome
combinations maintained by the database system 308 for purposes of
determining whether or not to generate a glycemic insight for the
patient.
[0079] In certain embodiments, the insight generation engine 304
also obtains some input data in the form of mobile device data 312
from the patient's mobile device 302. The mobile device data 312
can include any type of data or information generated by the mobile
device 302, forwarded by the mobile device 302, entered at the
mobile device 302, detected by the mobile device 302, or the like.
For example, and without limitation, the mobile device data 312 can
include time stamp data, calendar data, mobile app data, status
information related to the operation of the mobile device 302,
and/or sensor data generated by sensors or detectors onboard the
mobile device 302 (such as an accelerometer, a gyroscope, a light
sensor, a camera, a thermometer, a biometric scanner, etc.). The
insight generation engine 304 can forward any or all of the mobile
device data 312 to the database system 308 for processing,
indexing, and storing as historical data. Moreover, the insight
generation engine 304 can use any or all of the mobile device data
312 to determine whether or not to generate a glycemic insight for
the patient.
[0080] The insight delivery engine 306 handles the scheduling and
delivery of generated insights to the patient's mobile device 302
(or to any system, device, or platform that is suitably configured
to receive and present generated insights to the patient). Thus,
the insight delivery engine 306 cooperates with the insight
generation engine 304 to receive, process, and regulate the
delivery of glycemic insights. In certain embodiments, the insight
delivery engine 306 cooperates with the patient's mobile device 302
to obtain user feedback 314 regarding glycemic insights that have
been received at the mobile device 302. The user feedback 314 can
be obtained via a suitable mobile app that is loaded on the mobile
device 302, wherein the mobile app is utilized to generate and
present the glycemic insights to the patient. The mobile device
data 312 can also include user feedback information for use by the
insight generation engine 304 if so desired. The user feedback 314
is helpful to influence the manner in which generated insights are
prioritized and delivered (if at all) going forward, to enhance the
patient experience and to increase the value of the insights to
each particular patient.
[0081] Data Inputs
[0082] There are many factors that can influence a patient's blood
glucose levels. Various factors may also influence how best to
control and manage the patient's blood glucose. The glycemic
insights methodology presented here is based on the collection and
analysis of data, which need not be specifically related to BG
meter measurements, glucose sensor readings, or insulin delivery
information. Although the system 100, 300 obtains and analyzes such
data, it also obtains and considers additional data, including
information collected and provided by the mobile app resident on
the patient's mobile device. The system 100, 300 may also process
data received directly or indirectly from other physiological
sensors, devices, or equipment. For example, an embodiment of the
system 100, 300 can be suitably configured to analyze respiratory
data, electrocardiogram data, body temperature data, heartrate
information, and the like.
[0083] The glycemic insights delivery system 100, 300 is suitably
configured to receive and process a variety of input data from
multiple sources. Moreover, the system 100, 300 is designed to be
flexible and scalable to accommodate additional input data types as
needed. The number of input data sources and the amount of input
data handled by the system 100, 300 may vary from one embodiment to
another, depending on the particular implementation and intended
application. In accordance with the embodiment described here, some
or all of the following input data can be used for purposes of
triggering the generation of glycemic insights, prioritizing the
delivery of generated glycemic insights, maintaining actionable
event/outcome combinations, generating glucose management
recommendations, and the like. The following summary of specific
input data types is not intended to be exhaustive or otherwise
limiting, and alternative or additional input data can be
considered in an embodiment of the system 100, 300.
[0084] Carbohydrate amount--this refers to the carbohydrate amount
that one Unit of insulin can compensate to maintain the current
glucose level. The carbohydrate amount is usually expressed in
grams or milligrams. The patient's mobile device will usually be
the source of this data.
[0085] Bolus information--the bolus information includes the bolus
dosage amount (in Units of insulin), the date/time of delivery
(time of day and calendar data), and the bolus type (normal,
square, or dual). The insulin infusion device will usually be the
source of this data.
[0086] Insulin to carbohydrate ratio--this is a patient-specific
parameter that relates to how much insulin the patient needs to
compensate for a designated unit (e.g., one gram) of carbohydrate.
The insulin to carbohydrate ratio is expressed in grams/Unit. The
insulin infusion device will usually be the source of this
data.
[0087] Insulin sensitivity factor--this is a patient-specific
parameter that relates to the reduction in blood glucose in
response to one Unit of insulin. The particular manner in which the
insulin sensitivity factor is calculated is determined by the
specific pumping protocol. The insulin sensitivity factor is
expressed in mg/dL/U (milligrams per deciliter per Unit). The
insulin infusion device will usually be the source of this
data.
[0088] Active insulin amount--this refers to how much insulin is
still active in the body of the patient from previous bolus doses.
This quantity is expressed in Units of insulin. The insulin
infusion device will usually be the source of this data.
[0089] Time of day--this refers to timestamp and/or date stamp
information, which may be associated with or appended to any other
piece of input data to provide a time reference.
[0090] Basal rate--this is a patient-specific parameter that
indicates the basal rate of insulin delivery, which is usually
expressed in Units/hour. The insulin infusion device will usually
be the source of this data.
[0091] Temporary basal use--this refers to an occurrence during
which the patient temporarily "overrides" the nominal or usual
basal rate of insulin. The system employs a boolean value that
indicates the activation of the temporary basal mode, and also
indicates the temporary basal rate value. The insulin infusion
device will usually be the source of this data.
[0092] Consecutive boluses--this refers to an occurrence of
back-to-back insulin boluses, which are delivered within a
designated period of time. The system employs a boolean value that
indicates the occurrence of consecutive boluses, and also indicates
the total volume of the boluses delivered during the designated
period of time. The insulin infusion device will usually be the
source of this data.
[0093] Insulin suspension--this refers to a period of time during
which the insulin infusion device has been temporarily suspended
(insulin delivery is temporarily halted). The data related to
insulin suspension can include some or all of the following,
without limitation: threshold setting; suspension duration; active
insulin before the suspension; sensor rate of change around the
suspension; carbohydrate intake around the suspension; time (day of
week, time of day) of the suspension; how the suspension recovered;
and user response to the suspension. The insulin infusion device
will usually be the source of this data.
[0094] Reservoir rewind and priming time--this refers to activities
associated with the installation of a new insulin reservoir into
the insulin infusion device. This requires a rewind action to
retract the reservoir actuator, which facilitates removal of the
used reservoir. After installing the new reservoir, the fluid flow
path is primed for insulin delivery. The insulin infusion device
will usually be the source of this data.
[0095] Pump alarms and associated alarm times--pump alarms can be
generated by the insulin infusion device for various reasons. Pump
alarm data indicates the type of alarm and the corresponding alarm
time. The insulin infusion device will usually be the source of
this data.
[0096] Sensor alerts and alert times--sensor alerts can be
generated by the insulin infusion device and/or the glucose sensor
for various reasons. Sensor alert data indicates the type of sensor
alert and the corresponding alert time. The insulin infusion device
and/or the glucose sensor can be the source of this data.
[0097] Blood glucose readings and measurement times--blood glucose
readings are usually expressed in mg/dl, and are obtained from a
blood glucose meter. The insulin infusion device, the blood glucose
meter, or the patient's mobile device can be the source of this
data.
[0098] User demographic information--this data may include, without
limitation, the patient's age, number of years using insulin,
medical diagnosis, age at the onset of diabetes, sex, medication
types, and the like. User demographic information can be provided
by the patient's mobile device, the insulin infusion device, a
webpage user interface, or the like.
[0099] Meal time and content--this data relates to the timing of
meal consumption and the type and amount of food consumed. The
patient's mobile device will usually be the source of this data. In
this regard, a suitably configured mobile app can include a feature
or functionality that allows the patient to specify meal times and
to estimate the type and amount of food consumed at each meal. In
certain scenarios, this data can be imported from a third party
(partner) database directly, rather than having patients
redundantly enter the information into the mobile app.
[0100] Exercise time and content--this data relates to the timing
of exercise and the type, duration, and amount of exercise
performed by the patient. The patient's mobile device will usually
be the source of this data. In this regard, a suitably configured
mobile app can include a feature or functionality that allows the
patient to specify exercise times and to estimate the type and
amount of exercise. In certain scenarios, this data can be imported
from a third party (partner) database directly, rather than having
patients redundantly enter the information into the mobile app.
[0101] Medication type, dosage, and time--this data relates to
instances when the patient takes medication (other than insulin),
and the data indicates the type of medication, the dosage taken,
and the time that the medication was taken. The patient's mobile
device will usually be the source of this data. In some scenarios,
a smart insulin pen or other type of smart insulin delivery device
can be the source of this data. In this regard, a suitably
configured mobile app can include a feature or functionality that
allows the patient to record information associated with taking
medication.
[0102] Sleep time and quality--this data indicates sleeping
periods, and information related to the quality or type of sleep
experienced by the patient. The sleep-related information can be
provided by a patient monitor or, in certain embodiments, the
sleep-related information is provided by a suitably configured
mobile app running on the patient's mobile device. In such an
embodiment, the mobile app allows the patient to enter the relevant
sleep-related information. In accordance with some embodiments,
sleep related information can be calculated using accelerometer
data, heartrate data, ambient lighting measurements, glucose
levels, etc.
[0103] Stress time--this data indicates periods of stress
experienced by the patient. The stress-related information can be
derived from physiological factors and/or measurable data such as
heart rate, blood pressure, skin conductance, body temperature, or
the like. Additionally or alternatively, the stress-related
information can be based on user input. Accordingly, the patient's
mobile device can be the source of this data. A suitably configured
mobile app can include a feature or functionality that allows the
patient to record information associated with periods of
stress.
[0104] Electronic medical records and lab test data--this data can
be provided by healthcare providers, medical facilities, insurance
companies, or the like. In certain scenarios, this data can be
imported from a third party (partner) database directly, rather
than having patients redundantly enter the information into the
mobile app.
[0105] User reaction to delivered insights--this data represents
user feedback, and it may be considered to be a form of input data.
The patient's mobile device will usually be the source of this
data. In this regard, a suitably configured mobile app can include
a feature or functionality that allows the patient to provide user
feedback related to glycemic insights delivered to the patient.
[0106] User behavior change to delivered insights--this data is
associated with actions taken by the patent in response to glycemic
insights delivered by the system. User behavior change is measured
by the percent of change of the occurrence of those events that
were communicated to users as glycemic insights. It indicates
whether the insight messages provide any impact on user's behavior
and whether the behavior change leads to significant outcome
improvement.
[0107] The data source of the data includes almost all data sources
mentioned before
Glycemic Outcomes
[0108] As explained above, the system 100, 300 analyzes collected
input data to identify occurrences of insight events and to
determine whether or not identified insight events are associated
with or otherwise linked to specific glycemic outcomes. The
particular glycemic outcomes of interest can vary from one
embodiment of the system 100, 300 to another, and perhaps from one
patient to another. The exemplary embodiment of the system 100, 300
described herein utilizes ten defined glycemic outcomes. Five of
the glycemic outcomes are standalone (or direct) outcomes, and five
of the glycemic outcomes are "differential" outcomes. In this
context, a direct glycemic outcome relates to a comparison between
the patient's current glucose values to a static well-established
commonly-used threshold, such as hypoglycemia and hyperglycemia. In
this regard, a glycemic outcome can be a simple threshold-based
outcome that is binary in nature. In contrast, a differential
glycemic outcome is a comparison between a patient's current
glucose values to statistics of the patient's own historical
glucose values.
[0109] The exemplary embodiment of the system 100, 300 employs the
five direct glycemic outcomes listed here: (1) Hypoglycemia, based
on a specified threshold such as "less than 70 mg/dl"; (2) Severe
Hypoglycemia, based on a specified threshold such as "less than 50
mg/dl"; (3) Hyperglycemia, based on a specified threshold such as
"greater than 240 mg/dl"; (4) Severe Hyperglycemia, based on a
specified threshold such as "greater than 300 mg/dl"; and (5) Good
Control. The first four glycemic outcomes listed above are
self-explanatory. The "Good Control" outcome indicates that the
patient has experienced good glycemic control or management that
satisfies certain quantifiable criteria. For example, if the
patient's measured or sensed glucose levels were within the target
range for more than 20 hours during the last day, then the "Good
Control" outcome can be indicated. As another example, if the
patient's measured or sensed glucose levels are within the target
range for at least 80% of the time during the last week, then the
"Good Control" outcome can be indicated.
[0110] The exemplary embodiment of the system 100, 300 employs the
five differential glycemic outcomes listed here: (1) Percentage of
Time: Hypoglycemia; (2) Percentage of Time: Severe Hypoglycemia;
(3) Percentage of Time: Hyperglycemia; (4) Percentage of Time:
Severe Hyperglycemia; and (5) Percentage of Time: Good Control.
Each of the differential glycemic outcomes listed above is
associated with a defined window of time, and each outcome
represents a calculated percentage against corresponding thresholds
based on values within the defined window of time. For example, if
the window of time is the period between 8:00 PM and 10:00 PM, and
the input data for the patient indicates hyperglycemia for 30
minutes during that window, then the "Percentage of Time:
Hyperglycemia" metric will be 25%. In contrast to direct glycemic
outcomes (which are binary in nature), each differential glycemic
outcome can have a range of possible states or values (i.e., a
range of percentages) and thus requires further conversion
processing to convert the values into binary states. The conversion
process compares the value of the differential glycemic outcome
against a statistical measure from the same user's historical
values, such as an average, and determines whether the outcome
value is higher or lower. The system 100, 300 handles differential
glycemic outcomes in this manner to remove potential patient bias,
which facilitates a comparison of each insight event against the
patient baseline rather than a fixed threshold or fixed criteria.
As explained in more detail below, the handling of differential
glycemic outcomes is associated with an analysis of the patient's
average or typical outcomes, such that glycemic insights are
generated when an insight event under investigation is strongly
correlated to a differential outcome.
[0111] Additional or alternative glycemic outcomes utilized by the
system 100, 300 may include any or all of the following, without
limitation: glycemic variability during a designated period of
time, such as the last hour, the previous day, the last week, or
the last month; a variable event with a sensor glucose rate of
change greater than a specified threshold; or sensor glucose within
a defined range of values within a specified period of time. It
should be appreciated that the system 100, 300 can be modified or
updated as needed to contemplate different glycemic outcomes that
may be of interest.
[0112] Data Analysis: Generation of Glycemic Insights
[0113] In accordance with certain embodiments of the system 100,
300, glycemic insights are generated at certain times and/or in
response to the occurrence of certain insight events, by looking at
historical data for associations between specific situations and
particular glucose patterns. Thus, glycemic insights may be
generated at specified times of the day, on certain days of the
week, or the like. Alternatively or additionally, glycemic insights
can be generated in response to insight events related to the
operation of the insulin infusion device, such as any of the
following, without limitation: delivery of a bolus; a specific
sensor glucose level; alarms or alerts; or the changing of the
infusion set. Historical data maintained by the database system
116, 308 may include glucose information for occurrences of an
insight event, such that the system 100, 300 can review the
historical data to find "matching" occurrences that correspond to a
currently detected insight event occurrence. In practice, the
amount of historical data that is considered can be limited or
otherwise regulated based on the particular insight event of
interest and/or the particular situation being evaluated. For
example, very old and dated historical data need not be reviewed
under most circumstances. The specific situations and particular
glucose patterns evaluated by the system 100, 300 are based on the
complete set of input data that is available for analysis. As
mentioned above, any combination of one or more event features can
be considered for purposes of generating glycemic insights. To this
end, the system 100, 300 can leverage any number of machine
learning, pattern recognition, or data analytics techniques and
methodologies to determine whether there is any statistical
correlation between the different situations (insight events) and
the evaluated glucose patterns.
[0114] In practice, the system 100, 300 contemplates hundreds of
different possible patient behavior patterns. The exemplary
embodiment described here considers more than 600 different
patterns, wherein a pattern can be a combination of lower level
patterns, individual event features, or specific insight events
(such as eating food, taking a bolus, starting to exercise). As
mentioned above, the exemplary embodiment of the system 100, 300
handles ten different outcomes. Thus, the mapping of 600+ patterns
to one or more outcomes represents the number of possible glycemic
insights that can be produced by the system 100, 300. The system
100, 300 is expandable in that additional event features, "low
level" data patterns, or insight events can be introduced as
needed.
[0115] In certain implementations, the generation of a glycemic
insight message can be influenced by any of the following types of
insight events, without limitation: insulin related; time related;
sensor glucose related; blood glucose related; calibration (of the
insulin infusion device) related; alarm related; meal or nutrition
related; geography related; calendar related; career, job, or work
related; physical exercise related; sleep related; disease or
health related; mental state or mood related; or doctor visit
related. Of course, other categories and types of insight events
can be considered by the system, and various glycemic outcomes can
be associated with one or more of the insight events.
[0116] Insulin related insight events include, without limitation:
bolus type; abnormal change of time intervals between boluses;
suspend pump operation; significant change in total daily dose
(TDD) based on long term data; abrupt change of basal pattern;
substantial change of average basal rate; and change of active
insulin delaying curve (derived from rate of change in insulin on
board). Time related insight events include, without limitation:
time of day; day of week; day of month; holiday, fasting, or
festival days; and long time period of time since the last data
upload. Sensor glucose related insight events include, without
limitation: very good accuracy; high rate of change (ROC); high ROC
of ROC; low and high thresholds; response to hyper event; response
to hypo event; recent glucose changes; temporary sensor glucose
data packets missing; sensor glucose artifacts; and age of glucose
sensor (e.g., number of days used). Blood glucose insight events
include, without limitation: low and high thresholds; and adherence
changes. Calibration related insight events include, without
limitation: the amount of time since the last calibration. Alarm
related insight events include, without limitation: use of the
bolus calculator feature; insulin pump rewind; no insulin delivery;
motor error alarm; low/high sensor glucose alerts; sensor start;
sensor end; and sensor errors. Meal or nutrition related insight
events include, without limitation: specific food and patient
response to food (delayed absorption); specific carbohydrate count;
missed meals; extra meals; extra food count for one meal; less food
count for one meal; snack before bedtime; snack before exercise;
snacking in general; and fasting periods (long term missing meal
pattern versus short term). Geography related insight events
include, without limitation: presence in a certain restaurant; no
restaurants located within a defined radius of the user's current
position; at home; at work; on vacation; close to a body of water
(important if the infusion device is not waterproof); proximity to
a hospital, care facility, or pharmacy (access to medical care);
socioeconomic status of the location; indication of user habits and
hobbies (outdoor activities, etc.); indication of support networks
(e.g., frequently visited houses, businesses, or locations); and
presence in a gym or exercise facility. Calendar related insight
events include, without limitation: movie; flight; meeting;
menstrual cycle; and days on medication. Career job, or work
related insight events include, without limitation: job type or
position; work schedule; and hours worked per week. Physical
exercise related insight events include, without limitation:
exercise start and end times, which can be automatically detected
using electronic fitness measurement devices; abnormal amount of
exercise; and unusual exercise timing (missed a normal exercise
time, more exercise than usual, etc.). Sleep related insight events
include, without limitation: start and end times; and dawn
phenomena. Disease or health related insight events include,
without limitation: onset of an acute disease or condition, such as
a cold, an allergy attack, or the flu; and end of an acute disease
or condition. Mental state or mood related insight events include,
without limitation: fright; excitement; anger; happiness;
depression; despair; hope; sadness; etc. Doctor visit related
insight events include, without limitation: recent doctor visit;
unusual doctor visit pattern; and increased frequency of doctor
visits.
[0117] The correlation between patterns and outcomes is patient
specific. The system 100, 300 continuously learns and trains itself
to generate the patient-specific glycemic insights. In practice,
many of the data patterns will rarely (if ever) be detected for a
given patient. Nonetheless, the system 100, 300 continues to
monitor the input data and check all possible combinations, for
safe measure. Note that there could be a scenario where one of the
ten outcomes is under consideration, but the system 100, 300 has
not yet identified a strong enough correlation to an associated
data pattern. Statistically, this scenario will resolve itself over
time and the system 100, 300 will detect a correlation between an
insight event and that particular outcome if one exists.
Conversely, there can be a situation where there isn't a
predictable or repeatable data pattern that causes the outcome. In
that case, the system 100, 300 will not generate a glycemic insight
message.
[0118] The glycemic insights can be considered to be the output of
the system 100, 300, wherein the output is generated in response to
the most current input data and at least some of the historical
data maintained at the database system 116, 308. Each glycemic
insight message includes information that is easy for the patient
to understand. In accordance with certain embodiments, each
glycemic insight message provides information to the user regarding
at least the following: the trigger(s) to the insight; the factors
associated with the glycemic outcome; and historical outcomes. The
factors can be filtered according to their importance, as
determined through clinical guidance, medical research, or the
like.
[0119] In accordance with some embodiments, the insight generation
engine 304 (see FIG. 3) finds similar insight event instances using
an approach that is similar to the "shingling" process that gauges
the similarity of two unique "shingles" (contiguous subsequences of
tokens in a document). For a given shingle size, the degree to
which two events A and B resemble each other can be expressed as
the ratio of the magnitudes of their shingling intersection and
union:
r ( A , B ) = S ( A ) S ( B ) S ( A ) S ( B ) Eq . 1
##EQU00001##
where the resemblance (r) is a number in the range of [0 1], where
one indicates that the two events are identical.
[0120] In accordance with some embodiments, the insight generation
engine 304 finds similar insight event instances using a Euclidean
distance approach. In this approach, the Euclidean distance is the
"ordinary" or "straight-line" distance between two events in
Euclidean space. The norm of the n-dimensional Euclidean distance
(Equation 2 below) can be used to determine the similarity of two
events.
d ( p , q ) = ( p 1 - q 1 ) 2 + ( p 2 - q 2 ) 2 + + ( p i - q i ) 2
+ + ( p n - q n ) 2 Eq . 2 ##EQU00002##
[0121] In accordance with some embodiments, the insight generation
engine 304 finds the most influential glycemic insight triggering
feature (i.e., a data pattern or an insight event that includes one
or more event features) using an approach that is based on machine
learning models. In this regard, many predictive models have
built-in or intrinsic measurements of predictor importance. For
example, multivariate adaptive regression splines (MARS) and many
tree-based models monitor the increase in performance that occurs
when adding each predictor to the model. Others, such as linear
regression or logistic regression can use quantifications based on
the model coefficients or statistical measures (such as
T-statistics). These and similar techniques can be leveraged by the
system 100, 300 if so desired.
[0122] In accordance with some embodiments, the insight generation
engine 304 finds the most influential glycemic insight triggering
feature using feature importance measuring techniques. In this
regard, there are many approaches that can be used to quantify each
relationship with an outcome, based on a simple correlation
statistic such as linear regression. The system 100, 300 can
utilize such a technique to roughly estimate the relationship
between the input data and glycemic outcomes. For complex
relationships where correlation isn't linear, techniques such as a
locally weighted regression model can be used. This technique is
based on a series of polynomial regressions that model the data in
small neighborhoods. The insight generation engine 304 can also
utilize an approach that is based on maximal information
coefficient or other similar methods. These and similar techniques
can be leveraged by the system 100, 300 to generate glycemic
insights if so desired.
[0123] In accordance with some embodiments, the insight generation
engine 304 finds the most influential glycemic insight triggering
feature using domain knowledge based association. To this end, some
research based knowledge can be used to create static relationships
between the input data and the glycemic outcomes, such as lack of
sleep and bad glycemic control. This and similar techniques can be
leveraged by the system 100, 300 to generate glycemic insights if
so desired.
[0124] Glycemic insights can be used to describe or identify
glycemic management patterns for patients. The information conveyed
in a glycemic insight can include any of the following, without
limitation: associations between meal bolus amount and type, and
post-meal glucose profiles; associations between temporary basal
use and post-exercise glucose variability; and associations between
insulin pump suspension and rebound hyperglycemia. The concepts
described herein can be extended to find correlations and causality
between food intake and diabetes management. The concepts can also
be used in decision support algorithms for clinicians to understand
patient behaviors.
[0125] In accordance with certain embodiments, a glycemic insight
message includes content from four primary categories: insight
events or times; historical data; specific situations; and
particular glucose patterns. In this regard, glycemic insights are
generated at certain INSIGHT EVENTS OR TIMES by looking at
HISTORICAL DATA for associations between SPECIFIC SITUATIONS and
PARTICULAR GLUCOSE PATTERNS. The system 100, 300 can utilize a
predefined set of selectable message content for one or more of
these primary categories if so desired. For example, the system
100, 300 can maintain a list of different insight events or times
that are of interest for purposes of triggering the generation of
glycemic insights. As another example, the system 100, 300 can
maintain a predefined list of particular glucose patterns that are
commonly experienced by diabetes patients. As explained above, the
exemplary embodiment of the system 100, 300 contemplates ten
different glycemic outcomes.
[0126] A number of glycemic insight examples are provided below in
the context of typical patient scenarios. It should be appreciated
that the specific content, wording, formatting, use of graphics,
and arrangement of a glycemic insight can vary from that presented
below.
[0127] Glycemic Insight Example 1
[0128] Focus: Bolus
[0129] Trigger: Shortly following the bolus delivery
[0130] Scenario: William (a Type I diabetes patient) is going to
have lunch. To prepare for his lunch he gives himself an insulin
bolus of 2.0 Units. Immediately after the bolus is delivered (which
is indicated by an increase in the amount of insulin on board) a
glycemic insight message is delivered from William's mobile app.
The glycemic insight message includes the following information:
"2.0 Units of bolus with carbohydrate<20 grams have been
commonly found to result in a low glucose pattern in your history."
In addition, the glycemic insight message includes a glucose
profile plot of aggregated historical sensor traces following a
bolus of 2.0 Units and <20 grams of carbohydrates that
graphically depict the instances of low blood sugar.
[0131] Ending: William is now aware of his common trend of low
blood sugar in association with a 2.0 Unit bolus and 20 grams of
carbohydrates.
[0132] Glycemic Insight Example 2
[0133] User Scenario: Timmy (an eight year old Type I diabetes
patient) was diagnosed at age six, has been on insulin for two
years, and is a new pump user.
[0134] Insight Event: When Timmy takes a bolus followed by another
bolus.
[0135] Historical Data: The system reviews glucose trends for all
boluses delivered in the last seven days.
[0136] Specific Situation or Glucose Pattern: The system finds that
boluses that were followed by another bolus within two hours (i.e.,
stacked boluses) usually result in a hypoglycemic pattern.
[0137] Glycemic Insight Message Content: "Timmy, in the past seven
days, boluses when stacked were commonly found to result in a low
glucose pattern." The insight message may also include a graphical
element (a graph or a plot) that depicts the historical data, the
corresponding glycemic outcome, or both.
[0138] Glycemic Insight Example 3
[0139] User Scenario: Steve (an 18 year old Type I diabetes
patient) was diagnosed at age 14, has been on insulin for four
years, and has been using an insulin pump for one year.
[0140] Insight Event: When Steve takes a bolus.
[0141] Historical Data: The system reviews glucose trends for all
boluses delivered in the last 30 days.
[0142] Specific Situation or Glucose Pattern: The system finds that
boluses with rapidly rising rate of change (ROC) of sensor glucose
usually result in a hyperglycemic pattern.
[0143] Glycemic Insight Message Content: "Steve, in the past 30
days, boluses with rapidly rising ROC of sensor glucose were
commonly found to result in a high glucose pattern." The insight
message may also include a graphical element (a graph or a plot)
that depicts the historical data, the corresponding glycemic
outcome, or both.
[0144] Glycemic Insight Example 4
[0145] User Scenario: Joanne (a 36 year old Type 2 diabetes
patient) was diagnosed at age 30, has been on insulin for one year,
and has been using an insulin pump for six months.
[0146] Insight Event: Monday morning at 10:00 AM when no boluses
are found.
[0147] Historical Data: The system reviews glucose trends for the
last 90 days.
[0148] Specific Situation or Glucose Pattern: The system finds that
mornings with no carbohydrate entry usually result in a
hypoglycemic pattern.
[0149] Glycemic Insight Message Content: "Joanne, in the past 90
days, mornings without a carb entry were commonly found to result
in a low glucose pattern." The insight message may also include a
graphical element (a graph or a plot) that depicts the historical
data, the corresponding glycemic outcome, or both.
[0150] Glycemic Insight Example 5
[0151] User Scenario: Ed (a 62 year old Type I diabetes patient)
was diagnosed at age 26, has been on insulin for 34 years, and has
been using an insulin pump for three years.
[0152] Insight Event: Sunday night at 10:00 PM.
[0153] Historical Data: The system reviews glucose trends for the
last 90 days.
[0154] Specific Situation or Glucose Pattern: The system finds that
Sunday nights with a rapidly rising rate of change in sensor
glucose and without a carb entry usually result in a hyperglycemic
pattern.
[0155] Glycemic Insight Message Content: "Ed, in the past 90 days,
nights with a rapidly rising ROC of sensor glucose without a carb
entry were commonly found to result in a high glucose pattern." The
insight message may also include a graphical element (a graph or a
plot) that depicts the historical data, the corresponding glycemic
outcome, or both.
[0156] Glycemic Insight Example 6
[0157] User Scenario: Mary (an 18 year old Type I diabetes patient)
was diagnosed at age 11, has been on insulin for seven years, and
has been using an insulin pump for only two weeks.
[0158] Insight Event: When Mary takes a bolus.
[0159] Historical Data: The system reviews glucose trends for all
boluses delivered in the last two weeks.
[0160] Specific Situation or Glucose Pattern: The system finds that
boluses for carbohydrate intake of less than 20 grams usually
result in a hypoglycemic pattern.
[0161] Glycemic Insight Message Content: "Mary, in the past two
weeks, boluses with carbs<20 grams were commonly found to result
in a low glucose pattern." The insight message may also include a
graphical element (a graph or a plot) that depicts the historical
data, the corresponding glycemic outcome, or both.
[0162] Glycemic Insight Example 7
[0163] User Scenario: Maxwell (a 25 year old Type I diabetes
patient) was diagnosed at age four, has been on insulin for 21
years, and has been using an insulin pump for two years.
[0164] Insight Event: When Maxwell takes a bolus.
[0165] Historical Data: The system reviews glucose trends for all
boluses delivered in the last seven days.
[0166] Specific Situation or Glucose Pattern: The system finds that
boluses that were followed by another bolus within two hours (i.e.,
stacked boluses) usually result in a hypoglycemic pattern.
[0167] Glycemic Insight Message Content: "Maxwell, in the past
seven days, boluses when stacked were commonly found to result in a
low glucose pattern." The insight message may also include a
graphical element (a graph or a plot) that depicts the historical
data, the corresponding glycemic outcome, or both.
[0168] Insight Delivery Timing
[0169] Referring again to FIG. 3, the insight delivery engine 306
is responsible for regulating the delivery, queuing, and discarding
(if needed) of glycemic insight messages that have been generated
by the insight generation engine 304. The insight delivery engine
306 controls the timing of when glycemic insight messages are
delivered to the patients, and prioritizes the order of delivery
for each patient. In contrast, current reporting mechanisms do not
deliver patient-related analyses intelligently at a time most
suitable for the users (e.g., at a time when users are likely to be
attentive, are likely to read the insight messages, are likely to
take appropriate action in response to the insight messages, etc.).
The functionality of the insight delivery engine 306 enables the
system 100, 300 to order and delivery the glycemic insight messages
in an intelligent manner to increase the value and benefits for the
patients.
[0170] In accordance with a bolus related example, when an insight
is generated pertaining to a patient having hypoglycemic episodes
after a bolus amount of 5-6 Units, the insight message is delivered
within five minutes of a bolus taken on the next day, and three
times a week following the event. This example can also be extended
to delivering insight messages at specific times based on user
behavior or habits using probabilistic models or machine learning
techniques. For example, a patient having hypoglycemic episodes
usually after a meal bolus can be alerted with an insight message
in advance, based on models that calculate the meal time. The
insight message can be delivered an hour before the predicted meal
time.
[0171] In accordance with an example related to the day of the
week, when an insight message is generated pertaining to a patient
having more time in hyperglycemia on Fridays, the insight message
is delivered at 8:00 AM (or after the first infusion pump action)
and at 8:00 PM (or after the last infusion pump action) every
Friday following the event. This example can also be extended to
the time of day, wherein the insight message can be delivered at
the beginning of the hour pertaining to the insight, to be
delivered three times a week or on a specific day depending upon
the content of the insight message.
[0172] In accordance with an example related to a high rate of
change (ROC) of sensor glucose, when an insight message is
generated pertaining to a patient having hypoglycemia after fast
glucose changes for 45 mins, the insight message is delivered at
the end of the high ROC period.
[0173] In accordance with an example related to a hyperglycemic
event, when an insight message is generated pertaining to a patient
having prolonged hyperglycemia followed by hypoglycemia, the
insight message is delivered within five minutes of a detected
hyperglycemia event. This example can also be extended to
delivering the insight message an hour before the event based on a
prediction of the hypoglycemia event or the hyperglycemia event,
thereby enabling the patient to proactively monitor his glycemic
outcome.
[0174] Additional information that can be used to manage, regulate,
or otherwise control the delivery of insight messages are
nutritional data and location data. In this regard, the user's
location combined with routine meal time gathered from
retrospective data can be used to provide insights on frequently
visited places for lunch, frequent food intake, and how it relates
to the user's glycemic outcome. For example, the insight messages
can be delivered an hour before an approximate meal time, when the
user is within 500 feet of a frequently visited restaurant or
location that is otherwise associated with meal consumption, or the
like.
[0175] Insight messages can also be delivered intelligently based
on a consideration of patient activity tracking data. For example,
an insight message can be delivered five minutes after a user
finishes his routine workout or daily walk, after a threshold
number of steps has been recorded, in response to a detected
heartrate value, or the like. As another example, an insight
message can be delivered if a patient remains stationary or
sedentary for a long period of time (for hyperglycemia events
triggered by sedentary lifestyle).
[0176] It should be appreciated that the above and other practical
scenarios can influence the timing of insight message delivery. In
this regard, the system 100, 300 can control the timing of insight
message delivery based on one or more of the following, without
limitation: triggered by static time; triggered by insight events;
triggered by a glucose profile; triggered by a patient profile; or
triggered by user request.
[0177] Triggering delivery based on static time refers to the
delivery of an insight message based on a time of day, day of the
week, week, month, year, holidays, or the like (as determined or
defined by the system 100, 300 or as configured by a user). For
example, insight messages about a certain consistent blood glucose
excursion can be delivered at a specified time. As another example,
insight messages regarding overeating during the holidays can be
delivered on the morning of each holiday of interest, such as
Easter, Christmas, Thanksgiving, and birthdays.
[0178] Triggering delivery based on insight events can involve any
piece of available input data. A number of examples are provided
below.
[0179] (1) Infusion pump alarms, sensor alerts, and other infusion
system notifications can trigger delivery of an insight message.
For example, insight messages about the best practice of threshold
suspension can be delivered after generation or delivery of a
threshold suspension alarm.
[0180] (2) Alarm and time triggered. For example, insight messages
warning about how sweating will increase interference with the pump
transmitter can be delivered in response to the generation of a
"Lost Sensor" alarm during hot days.
[0181] (3) Location triggered. For example, insight messages about
the glycemic outcome for certain food on a menu can be delivered
when the user enters a restaurant.
[0182] (4) Location and time triggered. For example, insight
messages about hypoglycemia occurrence can be delivered when the
patient leaves the office, while in the parking lot at night.
[0183] (5) Activity triggered (exercise, sleep, meal). For example,
insight messages about benefit of sleep early can be delivered when
the patient sleeps late.
[0184] (6) Activity and time triggered. For example, insight
messages having a warning that eating snacks before sleep can cause
dawn phenomenon can be delivered at night after the patient eats
something.
[0185] (7) Calendar triggered (meetings, vacations, appointments,
social activities). For example, insight messages related to how
many insulin vials the patient should bring for a planned trip can
be delivered a day before the trip. In certain embodiments, this
type of insight message can be formatted and provided such that it
appears on the patient's calendar app or desktop user
interface.
[0186] (8) Disease triggered (from the user, medical staff, a
prescription, etc.). For example, insight messages related to how
certain diseases can impact the blood glucose control can be
delivered when the patient or a caregiver identifies a specific
disease, condition, or ailment, or when a prescription is
filled.
[0187] Triggering delivery of insight messages can also be
influenced by the patient's glucose profile characteristics. A few
examples are provided below.
[0188] (1) Continuous glucose profile (worsen control, excursion
event). For example, an insight message including a reminder about
an abnormal recent glucose profile can be delivered when the
abnormality is detected.
[0189] (2) Discrete glucose profile (large difference between a
meter BG entry). For example, if a user's usual glucose profile is
120.+-.30 mg/dL on Tuesday afternoon, but today the user logged in
a value at 400 mg/dL, an insight message can be delivered at this
point (discussing what could happen following such abrupt
event).
[0190] (3) Abrupt change from history. For example, an insight
message can be delivered in response to an improvement or
deterioration in the patient's glucose profile over the past week,
month, or year. Such an insight message can be triggered as soon as
the change in the glucose profile is detected.
[0191] Triggering delivery of insight messages can also be
influenced by the patient's user profile. For example, a general
blood glucose distribution from users who have a similar (age,
gender, years using an insulin infusion pump, etc.) can be
generated as an insight message for a new user who just registered
his profile into the system. This type of insight message can be
used as a benchmark for patients who want to know how they are
doing compared against similarly situated patients.
[0192] Triggering delivery of insight messages can also be
influenced by user requests (by the patient, a caregiver, a
healthcare provider, etc.). For example, the patient, a parent, a
physician, or a nurse practitioner can request the delivery of
insights as needed.
[0193] Triggering delivery of generated insight messages can also
be influenced by preferred timing for the individual user, wherein
the timing can be based on detected trends, user input, user
feedback, or the like. In this context, insight messages can be
delivered at a time that is best suited for the particular
individual. For example, if the user is in the habit of browsing
news websites on his mobile device every morning at 6:15, then the
system can assume that the best time for daily insight message
delivery will be at or near 6:15 AM.
[0194] Insight Delivery Timing Optimization
[0195] The timing of insight message delivery can also be optimized
gradually based on feedback from users, as mentioned above. The
user feedback can include any or all of the following, without
limitation: (1) the amount of time it takes for the user to
actually view the insight message on the device platform (tablet,
phone, etc.); (2) the user's response to the insight messages (if
any), such as "like" or "dislike" or "don't show this again"; (3)
the user's corrective activity following delivery and viewing of an
insight message; (4) the user's glucose outcome after delivery of
an insight message; and (5) the user's engagement based on
responsiveness and time spent viewing an insight message. The
insight delivery engine 306 can be dynamically updated and
configured as needed to react to such user feedback in a way that
enhanced the delivery timing of subsequent insight messages.
[0196] Insight Delivery Method--Visualization
[0197] A glycemic insight message can be generated and provided in
any desired format, although preferably formatted in an easy to
read, easy to understand, and intuitive manner. The specific
format, content, appearance, and functionality of an insight
message can vary depending on the type of insight being conveyed,
the user's device platform, user preference settings, and the like.
For example, the format and/or font size of an insight message can
be adjusted to accommodate users with poor eyesight. Enhanced ways
of delivering insight messages can be superior to traditional
text-based statements in terms of patient adherence and glycemic
outcome. Several examples are presented below; these examples are
not intended to be exhaustive or limiting in any way.
[0198] (1) Overlapped Glucose Swoosh Curve--The patient's sensor
glucose data can be graphically presented using multiple swoosh
curves with a highlighted line that indicates the median or mean,
and side bands that indicate interquartile range. Thus, one or more
glucose profile plots for the user of the insulin infusion device
can be rendered in association with a glycemic insight message.
General percentiles or outliers can be overlaid to show good versus
bad outcomes corresponding to different variable(s). As an example,
FIG. 4 is a graph 400 of sensor glucose, which can serve as a
graphical element of a glycemic insight message. The graph 400
indicates time relative to a suspend event for the insulin infusion
device. The plot 402 indicates the suspend OFF median, and the plot
404 indicates the median associated with a Predictive Low Glucose
Management (PLGM) output. The zone 406 bounded by dashed lines
indicates the suspend OFF interquartile range (IQR), and the zone
408 bounded by solid lines indicates the PLGM IQR. For this
embodiment, the band defined between the plot 402 and the plot 404
represents the median plus IQR. Note that sections of the zone 406
overlap with sections of the zone 408. A visualization of the type
shown in FIG. 4 can be provided with an insight message as
needed.
[0199] (2) Annotated Glucose Profile--Insights (e.g., references to
and/or active links to insight messages) can be directly annotated
on the patient's glucose profile to emphasize when and where
certain triggering events happened. The context of the insight
messages can influence where on the glucose profile the reference
or link appears. As an example, FIG. 5 is a diagram 420 that
depicts how glycemic insight messages can be delivered on a
patient's glucose profile. In FIG. 5, the numbered circles that
appear on the plots indicate glycemic insights corresponding to the
explanatory legend 422 that appears on the right side of the
diagram 420. The positioning of the numbered circles correspond to
the insight events that trigger or otherwise influence the
generation of the insight messages. See, for example, the glucose
plot 424 at the bottom of the diagram 420, where multiple insights
are located at different points along the timeline. In certain
embodiments, the numbered circles (or whatever label, icon, or
identifier graphically represents the glycemic insights) are active
elements that can be selected by the user to display or otherwise
present additional details related to the selected insight.
[0200] (3) Annotated Map--Insights (e.g., references to and/or
active links to insight messages) can be rendered on a geographical
map, beside the map, or otherwise generated in association with the
map to provide an amount of geographical context to the insight
messages. For example, meal or food related glycemic insights can
be associated with particular restaurants, locations, addresses, or
the like, and a map can utilized to identify the locations that
correspond to those insights. As an example, FIG. 6 is a graphical
representation of a map 440 having glycemic insight information
rendered therewith. The map 440 includes insight markers 442
(rendered as colored circles overlying the geographical features of
the map 440). Each insight marker 442 corresponds to a glycemic
insight. For this example, each insight marker 442 is associated
with additional descriptive content 444, which appears on the left
side of FIG. 6. The descriptive content 444 may include information
related to the geographical location, such as "phone book"
information, the name of the business, user reviews or ratings,
pictures, and the like. For this particular embodiment, the
descriptive content 444 also includes a color coded message that
matches the color of the associated insight marker 442. For
example, the message "Glucose was well controlled" can be rendered
in green, and the message "Glucose was poorly controlled" can be
rendered in orange. Important or critical messages can be rendered
in red, or in a highlighted font, etc. These colors are preferably
used in a consistent manner for the insight markers 442, such that
the user can quickly identify geographic locations where glucose
was well controlled, poorly controlled, out of range, and the like.
In certain embodiments, the insight markers 442 and/or the
descriptive content 444 are active elements that can be selected by
the user to display or otherwise present additional details related
to the selected glycemic insight.
[0201] (4) Annotated Calendar--Insights (e.g., references to and/or
active links to insight messages) can be rendered in or otherwise
generated in association with a user's calendar app to link the
insight messages to certain calendar events. Ideally,
calendar-linked glycemic insight messages are predictive in nature,
and they appear before the start of the associated calendar event.
For example, glycemic insights that are related to certain days of
the week, travel to specific cities or events, vacations, sporting
events, or any scheduled event can be displayed as a calendar entry
or as a note or annotation of a calendar entry. As an example, FIG.
7 is a graphical representation of a displayed screen 460 of a
calendar app having glycemic insight information rendered
therewith. For the illustrated example, the user's calendar app
includes an entry 462 for an extended business travel event. A
glycemic insight message 464 is rendered in association with the
entry 462, wherein the glycemic insight message 464 is contextually
related to the entry 462. In this regard, the insight message 464
includes a reminder regarding the medical supplies that the patient
needs to pack for the business trip. It should be appreciated that
the particular content of calendar-linked insight messages will
vary depending upon the calendared event (if any), the date or
time, and the like. In certain embodiments, the insight message 464
(or portions thereof) includes one or more active elements that can
be selected by the user to display or otherwise present additional
details related to the calendar-linked glycemic insight.
[0202] FIG. 8 is a flow chart that illustrates an exemplary
embodiment of a process 500 for generating and delivering glycemic
insights, and FIG. 9 is a flow chart that illustrates an exemplary
embodiment of an insights generation process 530. The various tasks
performed in connection with a process described herein may be
performed by software, hardware, firmware, or any combination
thereof. For illustrative purposes, the following description may
refer to elements mentioned above in connection with FIGS. 1-7. In
practice, portions of a described process may be performed by
different elements of the described system or by a processing
module of a system element. It should be appreciated that a process
described herein may include any number of additional or
alternative tasks, the tasks shown in a figure need not be
performed in the illustrated order, and a described process may be
incorporated into a more comprehensive procedure or process having
additional functionality not described in detail herein. Moreover,
one or more of the tasks shown in a figure could be omitted from an
embodiment of the process as long as the intended overall
functionality remains intact.
[0203] In practice, the system 100, 300 collects and analyzes data
for multiple patients. Indeed, the centralized cloud-based
deployment of the system 100, 300 allows it to be scalable to
accommodate a large number of patients. Thus, the techniques and
methodologies described herein related to the generation and
delivery of glycemic insight messages can be performed at any time
for different patients. For the sake of brevity and simplicity, the
processes 500, 530 are described with reference to only one
user/patient. It should be appreciated that an embodiment of the
system 100, 300 will expand the processes 500, 530 in a way that
accommodates a plurality of different users/patients.
[0204] The process 500 begins by obtaining and processing relevant
input data collected from one or more sources (task 502). As
explained above, the input data sources will typically be a mobile
app executing on the user's device, and at least one medical device
that provides data related to the operation of the user's insulin
infusion device. This example assumes that the system 100, 300 has
already been deployed for at least a baseline period of time during
which relevant input data has been gathered and stored for purposes
of making intelligent and meaningful comparisons against newly
received input data. In other words, it is assumed that the
database system 116, 308 has already been populated with historical
entries that associate monitored events with outcomes. That said,
if the system does not have enough historical data for a patient
for purposes of generating personalized glycemic insights, it can
still generate an insight if there is a strong correlation between
a monitored event and an outcome seen in different patients with
user profiles that are similar to the profile of the patient under
investigation.
[0205] As a simple example, assume that there are only three event
features of interest and only four possible outcomes. Also assume
that an insight event can be defined as any combination of one or
more event features. For this example, there are seven insight
events (corresponding to all possible combinations of one, two, or
all three event features). Each historical entry in the database
system 116, 308 identifies or includes one of the insight events,
along with outcome data for each of the four possible outcomes.
Conceptually, each historical entry can be visualized as a row in
an event/outcome table, wherein the row identifies the particular
insight event of interest (e.g., columns that include the data for
each event feature) along with information related to the different
possible outcomes (e.g., columns that include the outcome data).
For example, a historical entry may identify an insight event that
includes a combination of two event features, Yes/No identifiers
for non-differential outcomes, and specific values for differential
outcomes. As time progresses, the database system 116, 308 will
become populated with ongoing occurrences of the insight events,
along with the corresponding outcome data.
[0206] In certain embodiments, task 502 identifies a current set of
input data for a particular user, and compares the user input data
against historical user-specific data combinations maintained for
the particular user. Each of the historical user-specific data
combinations includes insight event data that is indicative of a
glycemic event, and a glycemic outcome corresponding to the insight
event data. Stated another way, the insight events indicated by the
newly received input data are compared against the insight events
contained in the historical data maintained in the database system
116, 308. This allows the system 100, 300 to compare newly received
input data against historical data to determine whether or not
there exists a significant correlation between an insight event and
one or more glycemic outcomes.
[0207] The process 500 analyzes the input data and the data
combinations to generate patient-specific glycemic insights as
needed (task 504). In this regard, the system determines a
correlation between the current set of user input data and a
particular glycemic outcome and, in response to the determination,
generates a glycemic insight message that is intended for delivery
to the user. The glycemic insight message includes information
regarding a relationship between at least some of the current set
of input data and the particular glycemic outcome. This description
assumes that the process 500 queues the generated insight messages
as they are generated (task 506).
[0208] The process 500 continues by selecting and prioritizing the
queued insights according to a desired delivery prioritization
scheme (task 508). In practice, the system can receive and process
real time and other data that influences certain insight message
delivery decisions (task 510). If the process 500 determines that
it is time to deliver a specific insight message to the user (the
"Yes" branch of query task 512), then the insight message is
delivered to the user's mobile device (task 514). It should be
appreciated that the process 500 may alternatively or additionally
send the insight message to the patient's insulin infusion device,
to a non-mobile computing device, to an electronic device operated
by a non-patient user or caregiver, or the like. Although not
always applicable, this example assumes that the process 500
obtains user feedback related to the delivered insight message
(task 516). In response to the obtained user feedback, the process
500 updates appropriate modules of the glycemic insights delivery
system (as needed) in an attempt to optimize future insight
delivery operations.
[0209] FIG. 9 depicts one exemplary approach for generating a
glycemic insight. Accordingly, the process 530 can be performed
during task 504 of the process 500. The process 530 assumes that
new input data has been obtained and collected for an identified
user, such that the system can check whether or not any glycemic
insights should be generated in response to the new input data
(task 532). The new input data is compared against the historical
data that is maintained for the identified user (task 534). More
specifically, the input data obtained for the user is compared
against historical event/outcome combinations maintained for that
user, to determine whether the current or new input data indicates
a matching condition. To make the comparison easier and more
efficient, the system may discretize the values of continuous event
features (i.e., event features having a variable range of input
data values, such as sensor glucose readings). In this regard, the
exemplary embodiment described here discretizes values of
continuous event features into ten ranges or bins, such that the
bin numbers (bins 1 to 10) can serve as indices for the process
500. Similarly, the system may translate event feature values into
numerical form or into any format that is easier to handle. For
example, the event feature "Day of the Week" can be expressed in
numerical form such that Sunday is represented by the number 1,
Monday is represented by the number 2, and so on.
[0210] The comparison is performed to determine whether there is
any matching or correlation between the new input data and glycemic
outcomes. As explained above, the system can handle differential
outcomes and non-differential (direct) outcomes. Thus, if an
outcome under investigation is a differential outcome (the "Yes"
branch of query task 536), then the process 530 performs
differential outcome processing (task 538). Otherwise, the process
530 continues by confirming that the insight generation criteria is
satisfied for the outcome under investigation (task 540). This
description assumes that the insight generation criteria is
satisfied and, therefore, that the process 530 generates and queues
an appropriate glycemic insight message for delivery (task
542).
[0211] The particular insight generation criteria used by the
process 530 may vary from one embodiment to another. In accordance
with the exemplary embodiment presented here, the process 530
analyzes the historical event/outcome combinations to count the
number of times that the insight event of interest has occurred in
the designated historical window of time (e.g., the last month, the
last three months, the last year, etc.). The number of occurrences
is then compared against a predetermined threshold number. If the
total number of occurrences during the designated window of time
does not exceed the threshold, then the process 530 refrains from
generating a glycemic insight for that particular insight event.
The threshold number can vary depending on the insight event being
analyzed and/or depending on the outcome being analyzed. If the
total number of occurrences exceeds the threshold, then the process
530 continues by checking the different glycemic outcomes recorded
for the historical instances of the insight event. Thus, for this
described embodiment, the process 530 confirms that the insight
generation criteria is satisfied only when the total number exceeds
the threshold, even though additional criteria may apply. If a
given outcome occurs at a high enough frequency (for the particular
insight event), then the process 530 assumes that there is a strong
correlation between that insight event and the given outcome, and
generates a glycemic insight for that particular event/outcome
combination. For example, if the given outcome occurred more than
80% of the time (or more than any desired threshold percentage
value) for recorded instances of the particular insight event, then
the insight generation criteria is satisfied. If not, then the
process 530 refrains from generating a glycemic insight for that
particular insight event. It should be understood that the process
530 can analyze each of the different outcomes to determine whether
or not any of them is strongly correlated to the event under
investigation.
[0212] The process 530 handles differential outcomes in a slightly
different manner. As mentioned above, the exemplary embodiment of
the system 100, 300 contemplates a total of ten glycemic outcomes:
five "direct" or non-differential outcomes, and five differential
outcomes. A non-differential outcome is binary in that it will have
one of two possible states, such as Yes/No, High/Low, On/Off, or
Active/Inactive. In contrast, a differential outcome is an outcome
having a variable range. Thus task 538 is used to convert the
variable range from a differential outcome to binary values (e.g.,
the differential outcome "percent time in hypo" is converted to
binary values such as: whether current percent time in hypo is more
than the average percent time in hypo in the history). Following
the task 538, task 540 can be applied to the converted outcome in
the same manner as a non-differential outcome.
[0213] Task 538 can analyze the differential outcomes contained in
historical data using any desired methodology, algorithm, or
approach. The exemplary embodiment presented here calculates the
mean outcome value for the insight event of interest, as recorded
during the time window of interest (e.g., the last month, the last
three months, or the last week). The standard deviation is also
calculated, and a percentage of the standard deviation is added to
the calculated mean. For this example, half of the standard
deviation is added to the calculated mean to obtain a baseline
value for the differential outcome under analysis. Next, the
exemplary methodology checks whether the value of the differential
outcome under analysis is greater than the baseline value. This
check is performed to determine whether the differential outcome
under analysis is likely to be the result of the insight event of
interest. If the value of the differential outcome is greater than
the baseline value, the process 530 outputs "Yes". If the value is
less than the baseline value, the process 530 outputs "No". All of
the converted Yes and No outputs are then passed into task 540 to
be treated in the same manner as a non-differential outcome, to
compare against the insight generation criteria.
[0214] In practice, the approach described here can be repeated for
all of the differential outcome values that are associated with an
insight event of interest. After considering all of the recorded
differential outcome values, the process 530 can identify which one
(if any) has a strong correlation with the insight event of
interest.
[0215] The differential outcome processing of task 538 is intended
to remove "patient bias" to allow the system 100, 300 to compare
each insight event against the individual patient baseline
characteristics rather than any fixed threshold outcome value.
Thus, the process 530 considers the patient's average glycemic
outcome and generates a related glycemic insight message only if
the insight event under analysis is actually correlated to a
differential outcome that appears to be somewhat of an "outlier"
relative to the average patient response.
[0216] Insights Curation
[0217] As mentioned briefly above, the timing of insight message
delivery is an important aspect of the system 100, 300. In
preferred implementations, glycemic insight messages are delivered
to the patients in an intelligent manner that is designed to
increase the likelihood of actual viewing and follow up action by
the patients. The manner in which the system 100, 300 handles the
culling, prioritization, and delivery timing of glycemic insights
is described in more detail in this section.
[0218] Managing the delivery of glycemic insight messages is needed
due to the large volume of insight messages that can be generated
over time for each patient. Due to the 600+ different data patterns
that are considered, along with different possible glycemic
outcomes, redundant or similar glycemic insight messages (i.e.,
insights having the same or equivalent content) can be generated.
Moreover, in certain situations "conflicting" glycemic insight
messages can be generated. For example, one insight message can say
that it is easier to experience a hypoglycemic episode while
another insight message can say that a hyperglycemic episode is
more likely during the same time window. Managing the delivery of
insight messages is also desirable to accommodate the personal
preferences of the end users, and to reduce the occurrence of
annoying messages and notifications.
[0219] Referring again to FIG. 3, the insight delivery engine 306
is suitably configured to manage the delivery of glycemic insight
messages to the patient's mobile device 302. In certain
embodiments, the insight delivery engine 306 employs a plurality of
processing layers, wherein each layer handles a particular
function. The layers of the insight delivery engine 306 are
expandable, customizable, and independent. In this regard, FIG. 10
is a schematic block diagram of a layered structure 600 suitable
for use with the insight delivery engine shown in FIG. 3. The
layered structure 600 generally includes a trigger layer 602, an
insight reservoir 604, and a delivery layer 606. These elements
cooperate in the manner described below handle the processing of
new glycemic insights 608 as they are generated.
[0220] Insight Reservoir
[0221] The insight reservoir 604 obtains, collects, and sluices the
glycemic insights upon triggers. The insight reservoir 604 includes
all insight messages generated for a given patient. Conceptually,
the insight reservoir 604 is initially empty with no insight
messages contained therein. Over time, however, the insight
reservoir 604 gets populated with insight messages as they are
generated; the insight reservoir 604 holds the generated insight
messages prior to delivery. The insight reservoir 604 includes a
controller 610 associated therewith, and the controller 610
monitors and listens to the incoming triggers (e.g., real-time
trigger conditions) from the trigger layer 602. Whenever a new
bundle of triggers is received, the controller 610 performs the
following operations: (1) gathers the new insights 608 and the
remaining insights 612 from the previous delivery; (2) removes any
insights that have been residing in the insight reservoir 604 for
more than a designated period of time, which is one month for the
exemplary embodiment; and (3) fetches the insights matching the
received trigger conditions; and (4) sends the matching insights to
the delivery layer 606. The trashcan icon 614 in FIG. 10 indicates
the destination for the "expired" insights that are removed at Step
(2) of the process outlined above.
[0222] Trigger Layer
[0223] The trigger layer 602 determines when to trigger the
delivery of generated glycemic insights, such that the insights can
be pushed out to the user. Triggering in this context means
activating delivery for an insight message, removing it from the
insight reservoir 604, and sending it to the delivery layer 606.
This can be important for handling certain glycemic insight
messages that are related to time sensitive or condition sensitive
factors. For example, if an insight relates to high glucose trends
that occur on Mondays, then that particular insight can be
triggered on Monday morning or Sunday evening. As another example,
if an insight message relates to a rapid change in sensor glucose,
then the trigger layer 602 can monitor for such a rapid change
occurring in real time before triggering delivery of that
particular insight message.
[0224] The embodiment of the trigger layer 602 described here
utilizes the following as input information, which is used to
calculate the triggers: (a) sensor glucose readings (in mg/dl) at
five minute intervals; (b) active insulin measurements (in Units of
insulin) at five minute intervals; and (c) the current time. In
FIG. 10, the real time signal 615 represents the input information
for the trigger layer 602, which is reviewed to determine whether
or not certain real-time trigger conditions have been satisfied.
The sensor glucose readings and the active insulin measurements can
be provided by the mobile app that is resident on the patient's
mobile device 104, 302. Alternatively or additionally, some of the
real-time input information (trigger data) can be provided by the
patient's insulin infusion device. The output of the trigger layer
602 includes triggers that are sent to the insight reservoir 604.
In accordance with certain embodiments, the trigger layer 602
includes a pre-processing layer, trigger generators, and a trigger
collector. These elements of the trigger layer 602 cooperate to
generate the output triggers in response to the input
information.
[0225] Different real time triggers can be utilized to trigger the
delivery of corresponding types of glycemic insights. In accordance
with certain embodiments, one or more of the following categories
of triggers can be considered: bolus; day; time of day; threshold
suspend; hyperglycemia; sensor glucose ROC; and meal (based on
nutrition). Each of these triggers can have one or more insight
conditions associated therewith, and each insight condition is
associated with particular content that is conveyed in the
respective glycemic insight message.
[0226] The following insight conditions can be associated with a
bolus related trigger: bolus amount; type of bolus (square, dual,
normal); has stacked bolus; has stacked correction bolus; active
insulin amount; bolus type obtained from bolus calculator (Meal,
Correction); carb amount obtained from bolus calculator; correction
amount obtained from bolus calculator; carb ratio setting obtained
from bolus calculator; dual wave bolus; insulin sensitivity setting
obtained from bolus calculator; override from bolus calculator;
underride from bolus calculator; sensor glucose ROC at bolus; mean
sensor glucose in the previous 15 minutes; time since previous
bolus; basal pattern; time of day; and day of week (weekday or
weekend).
[0227] The following insight conditions can be associated with a
day related trigger: days since infusion change; day of week
(weekday or weekend); holiday; basal patterns; time in range, hypo
or hyper on previous day; sensor glucose at the start of the day
(first infusion pump action); sensor glucose at the end of the
previous day (last infusion pump action); TDD; TDD compared to
daily average; blood glucose measurement frequency; blood glucose
measurement frequency compared to daily average; number of meals;
number of meals compared to daily average; number of boluses;
number of boluses compared to daily average; number of food
boluses; number of food boluses compared to daily average; number
of correction boluses; number of correction boluses compared to
daily average; total daily carbohydrate amount; average
carbohydrate amount compared to daily average; total daily bolus;
total daily basal; basal bolus ratio; basal bolus ratio compared to
daily average; dawn; morning first bolus unusually early; morning
first bolus unusually late.
[0228] The following insight conditions can be associated with a
time of day related trigger: time block (morning, breakfast, lunch,
dinner, before sleep); day of week (weekday or weekend); basal
pattern; bolus time; bolus count during the time period; total
bolus count compared to daily average; total carbohydrate in the
time bucket; total daily carbohydrate amount compared to daily
average; number of food boluses; number of food boluses compared to
daily average; number of correction boluses; number of correction
boluses compared to daily average; blood glucose measurement
frequency; blood glucose measurement frequency compared to daily
average; time in range, hypo or hyper in previous time bucket; and
time in range, hypo or hyper compared to daily average.
[0229] The following insight conditions can be associated with a
threshold suspend related trigger: threshold suspend setting;
suspend duration; user response (suspend response time); active
insulin; sensor glucose ROC in previous 30 minutes; time until
first carbohydrate intake; time until first bolus; sensor glucose
end value before resuming manually; time of day; day of week
(weekday or weekend).
[0230] The following insight conditions can be associated with a
hyperglycemia related trigger: duration; user action during
hyperglycemia (bolus, correction, meal, temporary basal); peak
point; time of day; and day of week.
[0231] The following insight conditions can be associated with a
sensor glucose ROC related trigger: mean sensor glucose in previous
15 minutes; time since previous bolus; whether the carbohydrate
amount is within [-30, 0] minutes of the high ROC period; whether
the bolus amount is bolus amount within [-30, 0] minutes of the
high ROC period; time of day; day of week; and duration.
[0232] The following insight conditions can be associated with a
meal related trigger: carbohydrate amount; food type; nutrient
amounts; bolus amount; bolus type (square, normal); time of day;
and day of week.
[0233] The pre-processing layer of the trigger layer 602 cleanses
the time series. In this regard, common issues with the input
information include, without limitation: out of range values; data
artifacts; overlapping data; and inaccurate data. The
pre-processing layer can serve as a filter that improves the
quality and accuracy of the trigger layer 602.
[0234] The trigger generators of the trigger layer 602 generate the
triggers based on the pre-processed signals from the pre-processing
layer. For the embodiment described herein, each trigger generator
is independent, in that the operation of each trigger generator
does not depend on the operation or processing performed by any of
the other trigger generators. The number of trigger generators
utilized by the trigger layer 602 is flexible and expandable; there
is no limitation on the amount of trigger generators used by the
system 100, 300. The trigger generators are customizable in that
they can be modified to consider additional input information, such
as user actions.
[0235] The trigger collector of the trigger layer 602 bundles all
of the generated triggers and sends them out according to an
internal scheduler. The scheduler controls the how frequent the
triggers are sent to the insight reservoir 604. The scheduler may
utilize a static schedule or a dynamic schedule, as needed. In
accordance with a static schedule, the trigger collector sends out
the triggers at fixed time intervals (for example, every 15
minutes). In accordance with a dynamic schedule, the trigger
collector sends out the triggers using a variable timing scheme
(for example, shorter intervals during the day and longer intervals
in the evening).
[0236] Delivery Layer
[0237] The delivery layer 606 cleanses, organizes, culls, and
prioritizes the triggered insights and pushes them to the users.
The delivery layer 606 can filter or otherwise regulate the number
of triggered insight messages in an appropriate manner to identify
a smaller group of insight messages that are intended for delivery
to the user device. The delivery layer 606 is arranged as a
hierarchical structure having multiple sublayers. The sublayers
function as filtering sublayers wherein upper layers can filter a
group of candidate insight messages as needed before passing at
least some of the group to the next lowest sublayer. For the
exemplary embodiment presented here, each of the sublayers
processes a candidate glycemic insight message by doing one of the
following: passing the candidate glycemic insight message to a
lower layer in the hierarchical delivery layer structure; sending
the candidate glycemic insight message back to the insight
reservoir 604; or discarding the candidate glycemic insight
message. The sublayers of the delivery layer 606 can be categorized
or organized as follows: reduction layers; user related layers;
weight based layers; and an accumulator layer 618, arranged in
hierarchical order with the reduction layers at the top of the
hierarchy and the accumulator layer 618 at the bottom. For this
particular example: the reduction layers include a unique check
layer 620, a parents and siblings layer 622, and a conflicting
outcome check layer 624; the user related layers include a user
feedback layer 626 and a user fatigue layer 628; and the weight
based layers include a customized insights layer 630, an advanced
insights layer 632, and an outcome based layer 634.
[0238] Each layer of the delivery layer 606 uses the output from
the preceding (upper) layer as an input and categorizes it into one
of three groups: downstream insights that serve as the input to the
next lowest layer; remaining insights that are not ready or
suitable for delivery during the current processing iteration and
are sent back to the insight reservoir 604 for the next iteration;
or dumped (discarded) insights that are no longer useful. The
trashcan icon 640 in FIG. 10 represents the destination for these
dumped insights. The uppermost layer of the delivery layer 606
(i.e., the unique check layer 620 for this example) uses the output
of the insight reservoir as its input.
[0239] The reduction layers compare the set of triggered insight
messages to each other, and function to remove redundant and
conflicting glycemic insights such that they do not "clog" the
insight delivery feed to the user. For example, the unique check
layer 620 reviews the current batch of glycemic insights to
identify identical insights. If the unique check layer 620 finds
repeated instances of the same insight, then it determines which of
the repeated insights represents the most current version (the most
recently generated insight). The most recently generated instance
of the insight is provided to the next layer, and the redundant
instances are discarded as "dumped insights".
[0240] The parents and siblings layer 622 handles glycemic insights
having some form of hierarchical relationship with other glycemic
insights (i.e., a parent-child relationship or a sibling
relationship), wherein insights with such a hierarchical
relationship might be triggered simultaneously. For example, the
following glycemic insights are related to one another for purposes
of the parents and siblings layer 622: "On Saturdays the patient
spent more time below the range"; and "On Saturdays with total
daily insulin between 51-62 Units, the patient spent more time
below the range". The parents and siblings layer 622 determines
which insights are to be prioritized according to some hierarchy.
For example, insights having the following structure can be
identified by the parents and siblings layer 622 as a child
insight: Type+FeatureA+FeatureB+Outcome. For each insight having
this structure, the parents and siblings layer 622 checks for
parent insights having the structure: Type+FeatureA+Outcome; or
Type+FeatureB+Outcome. Parent insights are sent to the next layer
of the delivery layer 606, and child insights are sent back to the
insight reservoir 604. If a child insight does not have a
corresponding parent insight, then that child insight is sent to
the next layer in the stack.
[0241] The conflicting outcome check layer 624 handles the presence
of insights having conflicting outcomes. The conflicting outcome
check layer 624 can check for internal conflicts and/or external
conflicts. Internal conflicts can happen only between the insights
that reside in the current layer; external conflicts can happen
only between the insights in the current layer and the delivered
insights. For internal conflicts, the conflicting outcome check
layer 624 filters out insights with conflicting outcomes by
comparing the first insight (N1) against all of the remaining
insights, one by one. If the outcome time horizon of the two
insights being compared against one another overlaps by more than a
designated amount of time (such as two hours), then appropriate
action is taken to resolve the potential conflict. If not, then a
conflict is not declared and the candidate insight messages are
passed on. If the action requires N1 to be sent to the insight
reservoir 604, then further comparisons with N1 are halted and the
next insight (N2) is compared against the other insights, as
described above. After all of the comparisons are made, the
"non-conflicting" insights are sent to the next layer in the
stack.
[0242] For the embodiment presented herein, the conflicting outcome
check layer 624 resolves internal conflicts in accordance with a
predetermined methodology. In this regard, FIG. 11 and FIG. 12
together form an exemplary lookup table 644 suitable for use in
resolving internal conflicting glycemic outcomes. The lookup table
644 summarizes the manner in which internal conflicts are resolved.
The lookup table 644 includes three columns, labeled Spear, Shield,
and Action. The items listed in the Spear column represent a
selected insight message to be compared against the remaining
insight messages (the selected insight message is the "Spear" in
this context). In contrast, the items listed in the Shield column
represent the remaining insight messages to which the Spear is
compared. Each item listed in the Action column represents the
action taken by the conflicting outcome check layer 624 when faced
with a particular Spear/Shield combination. For example, the
combination of "Has severe hyper" and "Has severe hypo" (see the
entry 646 in FIG. 11) results in the following Action: "Send Spear
to remaining insights". As another example, the combination of
"Time in control better" and "Control in range above eighty" (see
the entry 648 in FIG. 12) results in the following Action: "Keep
both". Note that the lookup table 644 includes a list of all
possible combinations; if the Spear is identical to the Shield,
then there is no conflict.
[0243] For external conflicts, the conflicting outcome check layer
624 filters out insights that conflict within an overlapped window
by fetching all insights delivered within the last six hours (or
any desired window of time). In this regard, the insights can be
fetched from a delivered insights database 654 (see FIG. 10). Each
insight from the previous layer is compared against the fetched
insights. If the outcome time horizon of the two insights being
compared against one another overlaps by more than a designated
amount of time (such as two hours), then appropriate action is
taken to resolve the potential conflict. If not, then no conflict
is declared and the candidate insight messages are passed on.
[0244] For the embodiment presented herein, the conflicting outcome
check layer 624 resolves external conflicts in accordance with a
predetermined methodology. In this regard, FIG. 13 and FIG. 14
together form an exemplary lookup table 658 suitable for use in
resolving external conflicting glycemic outcomes. The lookup table
658 summarizes the manner in which external conflicts are resolved.
The lookup table 658 includes three columns, labeled Spear,
Delivered, and Action. The items listed in the Spear column
represent a selected insight message to be compared against the
Delivered insight messages (the selected insight message is the
"Spear" in this context). In contrast, the items listed in the
Delivered column represent the insight messages to which the Spear
is compared. Each item listed in the Action column represents the
Action taken by the conflicting outcome check layer 624 when faced
with a particular Spear/Delivered combination. For example, the
combination of "Has hyper" and "Has hypo" (see the entry 660 in
FIG. 13) results in the following Action: "Send Spear to remaining
insights". As another example, the combination of "Time in hyper
worse" and "Has severe hypo" (see the entry 662 in FIG. 14) results
in the following Action: "Send Spear to the next layer". Note that
the lookup table 658 includes a list of all possible combinations;
if the Spear is identical to the Delivered insight message, then
there is no conflict.
[0245] As mentioned above, the user related layers of the delivery
layer 606 include the user feedback layer 626 and the user fatigue
layer 628. The user related layers are associated with user
interaction and the gathering of user feedback on previously
delivered insight messages. For example, the user feedback layer
626 allows the insight delivery engine to accommodate user
preferences. The user feedback layer 626 adjusts or otherwise
influences the delivery of insights based on historical feedback
obtained from the users. As shown in FIG. 10, a user feedback
database 666 obtains user feedback data 668 from a user device 670
(e.g., the patient's mobile device). The user feedback database 666
is considered to be an external source from the perspective of the
delivery layer 606. The user feedback layer 626 considers the
insight type, insight event combination, and outcome and finds a
matching insight type in the user feedback database 666. Next, the
user feedback layer 626 fetches the last three values in the
"preference" field (i.e., whether the user liked or disliked the
insight) and takes appropriate action. For example, if all three
preference values are "dislike", then the insight under review is
discarded, otherwise, the insight is sent to the next layer.
[0246] The user feedback database 666 maintains multiple tables,
wherein each table corresponds to one type of insight. A table is
updated every time the user provides feedback regarding an insight
that was delivered. Each table in the user feedback database 666
has three primary fields: Timestamp; Preference; and Delivery
Curve. The Timestamp field indicates the time when the user
provided feedback. The Preference field indicates the content of
the feedback, e.g., "like" or "dislike". The Delivery Curve field
indicates a dynamic state (A, B, or C for this particular
embodiment) as determined by the preference data. The Delivery
Curve status for a given insight can dynamically change as the user
provides feedback. The exemplary embodiment described here updates
the Delivery Curve status according to the following update logic:
(1) if the current Delivery Curve is A, then a new "dislike" from
the user changes the Delivery Curve to B; (2) if the current
Delivery Curve is A, then a new "like" from the user results in no
change to the Delivery Curve; (3) if the current Delivery Curve is
B, then a new "dislike" from the user changes the Delivery Curve to
C; (4) if the current Delivery Curve is B, then a new "like" from
the user changes the Delivery Curve to A; (5) if the current
Delivery Curve is C, then a new "dislike" from the user results in
no change to the Delivery Curve; (6) if the current Delivery Curve
is C, then a new "like" from the user changes the Delivery Curve to
B.
[0247] The user fatigue layer 628 contemplates potential user
fatigue, wherein users may grow tired or inattentive if they
receive the same insight message too often. The user fatigue layer
628 regulates the delivery of certain insight messages, such that
they are not repeatedly delivered too frequently. More
specifically, the user fatigue layer 628 queries the user feedback
database 666 to obtain the applicable Delivery Curve for the
insight message, and uses the current time to compute the number of
days since the patient began using the system (e.g., how long the
patient has been using the mobile app on the patient's user device
670). The Delivery Curve and the number of days are used to
determine the time interval for delivery of the insight message.
Next, the delivered insights database 654 is queried to obtain the
last delivery time (Ta), which is used to compute the time elapsed
since the last delivery of the insight message. More particularly,
the lapsed time is calculated as the difference between the current
time and the last delivery time (Ta). If the lapsed time is greater
than or equal to the determined time interval for delivery, then
the insight message is sent to the next layer, otherwise, it is
designated as a remaining insight 612 and is sent to the insight
reservoir 604. Simply put, the user fatigue layer 628 ensures that
a long enough time has passed before resending the same insight
message again.
[0248] The delivered insights database 654 keeps track of all
insight messages that have been sent to the user. The database 654
is updated whenever an insight message is delivered to the user. In
certain embodiments, each insight message that is delivered can be
identified by a unique identifier, code, or string. The delivered
insights database 654 can also record a timestamp for each
delivered insight, and record a global insight index.
[0249] As mentioned above, the delivery layer 606 employs three
delivery curves that influence the timing of insight message
delivery. Delivery Curve A is the default active delivery curve
that is used when the user starts to use the system. Every time the
user provides feedback on an insight message, the system checks
whether to change the active delivery curve in the manner described
in more detail above. Although the specific formula utilized for
each delivery curve may vary from one embodiment to another, the
following delivery curves are used in the exemplary embodiment
described here:
Delivery Curve A : y = 40 .times. x 0.75 ( 500 + x ) 0.75
##EQU00003## Delivery Curve B : y = 40 .times. x 0.75 ( 80 + x )
0.75 ##EQU00003.2## Delivery Curve C : y = 40 .times. x 0.75 ( 30 +
x ) 0.75 ##EQU00003.3##
[0250] FIG. 15 is a graph 674 that depicts delivery curves that
influence insight message delivery timing. The y-axis corresponds
to the time interval for delivery of an insight message, and the
x-axis corresponds to the number of days that the user has been
using the system (e.g., using the mobile app). The graph 674
includes a plot 676 corresponding to Delivery Curve A, a plot 678
corresponding to Delivery Curve B, and a plot 680 corresponding to
Delivery Curve C. The vertical arrows in the graph 674 show how the
system transitions between delivery curves, depending on whether
the user provides "like" or "dislike" feedback on insight messages
that have been delivered.
[0251] As mentioned above, the weight based layers include a
customized insights layer 630, an advanced insights layer 632, and
an outcome based layer 634. These weight based layers prioritize
the insight messages based on certain defined preferences,
criteria, and factors (e.g., some insight messages are deemed more
important than others and, therefore, are "weighted" or prioritized
accordingly). Thus, insight messages with severe hypoglycemia and
severe hyperglycemia outcomes are treated with special priority to
bypass this group of layers. The bypass path 682 schematically
shows how these special types of insight messages are delivered in
a prioritized manner by default. The other insight messages
(obtained from the upper/previous layer) are prioritized by desired
criteria, and are then delivered to the user in a manner that is
limited by a threshold set in the accumulator layer 618. For the
embodiment presented here, the threshold corresponds to three
insight messages (not including severe hypoglycemia and severe
hyperglycemia insights) per 24 hours. Thus, the accumulator layer
618 keeps count of the number of delivered insights. If more than
three have accumulated, then the excess can be moved back to the
reservoir 604 for the next iteration.
[0252] The customized insights layer 630 supports user-entered
changes in the prioritization scheme applied to certain categories
of glycemic insights. In other words, the customized insights layer
630 can be utilized to prioritize the insight message delivery
according to user preferences. In practice, the customized insights
layer 630 uses a variable to identify the type, category, or class
of each insight message (e.g., an identifier, a code, a string tag,
or the like). The customized insights layer 630 queries an app
settings database 684 to obtain the user's preferred or customized
list of prioritized insight messages. If the identifying variable
of the insight message of interest is found in the user's list,
then the customized insights layer 630 prioritizes the insight
message in the delivery queue. Otherwise, the insight message is
handled as usual and is passed to the next layer in the stack.
[0253] The advanced insights layer 632 is deployed to handle
certain types of insights that are linked to user behavior. For
example, if a given user frequently changes her insulin pump
settings, then the advanced insight layer 632 contemplates that
behavior to influence the delivery of insight messages. In other
words, the advanced insights layer 632 can be utilized to
prioritize the insight message delivery in accordance with the
user's behavior. For example, if the patient has recently changed
the basal rate, then the system assumes that the patient will be
interested in glycemic insight messages that are related to basal
rate and adjusts the priority of such insight messages. In
practice, the advanced insights layer 632 uses a variable (e.g., an
identifier, a code, a string tag, or the like). The advanced
insights layer 632 also considers the changes to certain infusion
device settings, such as: basal setting; carbohydrate ratio (CR)
setting; and threshold suspension setting, which relates to
suspension of basal insulin delivery if low blood glucose is
observed (the threshold suspension setting refers to programmed
values of the glucose threshold and time period for suspending
delivery).
[0254] For this particular example, there are four types of
advanced tags (which are all strings): Basal Setting; CR Setting;
ISF Setting; and threshold suspension (TS) Setting. If the insight
message can be associated with any of them, then one of the
advanced tag strings will be assigned to the advanced tag variable
for that particular insight message. For example, if there is an
insight message referring to a threshold suspension event, the
system knows that it can be linked to the TS pump setting,
therefore "TS setting" is assigned as the advanced tag. In
practice, there can be a considerable amount of insight messages
that cannot be associated with any of the four types of advanced
tag settings; these are not labeled as "advanced" insight messages.
In real time, the system keeps checking the user behavior for
purposes of prioritization. Thus, if the system determines that the
user changes the basal setting often, it can prioritize insight
messages with the advanced tag equal to "Basal Setting" in the
advanced insights layer 632.
[0255] The outcome based layer 634 is used to prioritize insight
messages related to hypoglycemia outcomes higher than insight
messages related to hyperglycemia outcomes. Thus, the system can
prioritize the insight messages in accordance with their respective
glycemic outcomes. For this particular example, the outcome based
layer 634 prioritizes certain insight messages in accordance with a
predetermined sequence or order that reflects the typical level of
importance of the associated outcomes. The specific prioritization
scheme may vary from one embodiment to another. That said, the
exemplary embodiment utilizes the following prioritization scheme:
has hypo>time in hypo worse>time in hyper worse>time in
control better>control in range above eighty percent>has
hyper. In accordance with this scheme, the outcome "has hypo" has
the highest relative priority, and the outcome "has hyper" has the
lowest relative priority. Insight messages having outcomes that are
not contemplated by the prioritization scheme will not be affected
by the outcome based layer 634.
[0256] The accumulator layer 618 represents the last layer in the
stack of the delivery layer 606. The accumulator layer 618 imposes
an upper bound on the total number of insight messages delivered
over a designated period of time, such as the last 24 hours. For
the exemplary embodiment presented here, the accumulator layer 618
limits insight message delivery to a maximum of three for any 24
hour period. The accumulator layer 618 sends insight messages to
the user device 670 based on the queue from the previous layer, and
accumulates the number of delivered insight messages for the last
24 hours. Once the total reaches the limit (which is only three for
this example), any other insight messages in the queue are
designated as remaining insights 612, and are sent back to the
insight reservoir 604.
[0257] Glycemic Insights--Additional Features and Functions
[0258] The quantification and delivery of personalized information
on the most frequent and impactful therapy behaviors on glycemic
control can be applied to more than a patient focused mobile
application or a web-based platform. For example, the
quantification process can be expanded beyond glycemic control to
the effect of therapy behaviors on the quality of life, or other
medical comorbidities, etc. In other words, the "outcomes"
considered by the system 100, 300 can be extended beyond those
normally associated with diabetes, e.g., the patient's emotional
state; the patient's energy level; neurological conditions; cardiac
symptoms; or kidney conditions. As another example, the optimized
time of delivery of insight messages as determined through machine
learning techniques can also be expanded to determine the best way
(wording of messaging, look of the message, arrangement of message
content, and the like) to convey the message to derive the most
benefit to the patient. As another example, the delivery platform
can be expanded to medical devices tailored to improve therapy
related behaviors such as an insulin pump or other medication
adherence applications. Although the exemplary embodiments
described herein concentrate on the delivery of insight messages to
patients, the insight messages can also be provided to healthcare
providers, clinics, care partners, and other recipients as needed
in order to optimize the communication within a patient's care
team. Moreover, aggregated analyses from anonymized glycemic
insights can also be used to adapt future models of glycemic
insights and explore the optimization of delivery, end-user
selection, delivery platforms, etc.
[0259] Retrospective Insights for Patient Engagement and
Wellbeing
[0260] Managing diabetes for patients with the disease can be an
all-encompassing effort with the primary goal of improving the
quality of life, reducing complications, and improving glycemic
control. The intelligently generated insight messages (as described
above) correlate behaviors to glycemic outcomes in a predictive or
retrospective fashion. Other forms of analytics and messaging can
improve patient engagement, education of disease state, and best
practices in disease management (adherence measures), especially
when delivered to patients through a mobile application or
web-based service platform.
[0261] Conventional reporting mechanisms do not always deliver
notifications and messages intelligently at a time most suitable
for the users' maximal awareness. Accordingly, certain embodiments
employ a personalized diabetes management assistant system that
utilizes the information from various sources to identify the
associations to typical diabetes management behaviors and emotions
to improve patient engagement and wellbeing. This system can be
implemented on various computing platforms (computers, smartphones,
tablets, and the like). The goal is to optimize patient engagement,
motivation, and wellbeing during diabetes management by identifying
and rewarding patterns associated with best disease management
practices, providing positive reinforcement, and providing helpful
educational tips and reminders, etc., while not increasing the
daily management burden.
[0262] The baseline methodologies described above can be utilized
to generate and deliver insight messages that are intended to
encourage, reward, motivate, or congratulate the patient, or to
otherwise provide positive reinforcement in a timely and meaningful
manner. Insight messages of this type can include, without
limitation: motivational insight messages; adherence insight
messages; and reminder insight messages.
[0263] Motivational insight messages can be triggered by certain
conditions, such as: longer periods of time within the patient's
target glucose range; shorter periods of hypoglycemia; shorter
periods of hyperglycemia; fewer hypoglycemic episodes; or fewer
hyperglycemic episodes. Examples of appropriate motivational
insight messages include the following, without limitation:
[0264] "On average you spent 15 hours per day in your target
glucose range last month. During the last seven days, you spent 18
hours per day in your target glucose range. Well done!"
[0265] "Great job! You had no low glucose episodes this week!"
[0266] "Keep it up! This month you spent 10% less time in a high
glucose state compared to last month."
[0267] "On average, you spend 50 minutes per night in your low
glucose range. This week, however, you only spent ten minutes per
night in your low glucose range. Way to go!"
[0268] "Superb! You had no low glucose episodes after lunch this
week!"
[0269] "Congratulations! This month you received 10% fewer high
glucose alerts compared to last month."
[0270] Adherence insight messages can be triggered by certain
conditions, states, or requirements. For example, an adherence
insight message can be associated with any of the following,
without limitation: infusion set change; frequency of blood glucose
meter readings; glucose sensor usage; bolus calculator usage; or
dual wave bolus usage. Examples of appropriate adherence insight
messages include the following, without limitation:
[0271] "In the last 30 days, an infusion site change was found
every five days on average. Consider changing the frequency more
often to meet labelled goals."
[0272] "In the last week, we found only two blood glucose
measurements per day. Consider checking it more frequently to
increase glucose awareness."
[0273] "In the last 30 days, glucose sensor wear was detected on 12
days. Consider wearing the sensor more often to increase glucose
awareness."
[0274] "In the last 30 days, your bolus calculator was not used for
25% of the detected boluses. Consider using the bolus calculator
more often to optimize bolus dosages."
[0275] Reminder insight messages can be triggered by certain
conditions, states, or requirements. For example, a reminder
insight message can be associated with any of the following,
without limitation: infusion set change; meal entries; blood
glucose meter readings; or glucose sensor usage. Examples of
appropriate reminder insight messages include the following,
without limitation:
[0276] "Reminder: it has been four days since your last infusion
set change."
[0277] "Reminder: it looks like you had a bolus. What's for
breakfast?"
[0278] "Reminder: it has been six hours since your last blood
glucose measurement. Plan for a new measurement soon."
[0279] "In the last 30 days, a dual wave bolus was not used.
Consider using a dual wave bolus for meals with high fat
content."
[0280] The manner in which the motivational, adherence, and
reminder insight messages are triggered, generated, queued, and
delivered can be consistent with that described in more detail
above. Accordingly, the associated triggering mechanisms, input
data types, insight generation methodologies, and insight delivery
methodologies will not be redundantly described here.
[0281] Automatic Patient Therapy Reminders
[0282] Diabetes therapy management requires patients to consider
meal content, daily exercise, sickness, stress, and medication
regimen. Moreover, patients must follow a number of guidelines to
optimize their therapies on an insulin pump. In this regard, there
are a number of recommended behavioral checks and therapy checks
that patients and health care providers can assess before adjusting
or changing settings of an insulin infusion pump. Behavioral checks
can include any of the following, without limitation:
[0283] Are there three or more boluses per day?
[0284] Are there four or more blood glucose measurements per
day?
[0285] Is the onboard bolus calculator feature being used?
[0286] Is the infusion set being changed every two to three
days?
[0287] Is the pump suspended less than one hour per day?
[0288] Does the patient use a temporary basal rate for
exercise?
[0289] Does the patient initiate a bolus before meals?
[0290] Is the patient disconnecting appropriately?
Therapy checks can include any of the following, without
limitation:
[0291] Verify pump settings
[0292] Verify that the basal percent is less than 50% of the total
daily dose (TDD)
[0293] Evaluate overnight control (basal)
[0294] Evaluate pre-meal control (basal)
[0295] Evaluate post-meal control (carbohydrate ratio)
[0296] Does the patient experience significant excursions?
[0297] In order to ease the burden of constantly remembering the
recommendations listed above and/or other recommendations, insight
messages (as described above) can be generated and delivered to the
patient's mobile device at an appropriate time. For example, an
easily accessible message delivered to a smartphone, computer,
tablet, or other device can provide appropriate time based or
outcome based notifications related to: adherence measures and
pumping protocols; patient, health care provider, and care provider
reminders; and adherence measures that have historically resulted
in poor glycemic control.
[0298] The baseline methodologies described above can be utilized
to generate and deliver timely insight messages to remind the
patient that it is time to perform a behavior for best practices in
diabetes therapy management. Such reminder messages can be
triggered following a countdown of time since the last
auto-detected behavior of interest, or following a prevalence of
poor glycemic outcomes and associated time since the last
auto-detected behavior of interest. In certain embodiments, a
reminder can be delivered to the patient at a predetermined
stopwatch time countdown, or when intelligently associated with
poor glycemic outcomes as guided by the pumping protocol best
practices. Reminder guidance may be obtained from healthcare
providers, academic medical literature, or other respected sources
of medical information.
[0299] As one example, a reminder message can be generated and
delivered to the patient's mobile device to let the patient know
that it is time to change the infusion set, wherein the reminder
message is triggered following a countdown of three days after the
last auto-detected pump rewind action (which indicates the
installation of a new insulin reservoir). As another example, a
reminder message can be generated and delivered to the patient's
mobile device to let the patient know that it is time to change the
infusion set, wherein the reminder message is triggered following a
prevalence of hyperglycemia and a lack of pump rewind in the last
three days.
[0300] The manner in which these reminder insight messages are
triggered, generated, queued, and delivered can be consistent with
that described in more detail above. Accordingly, the associated
triggering mechanisms, input data types, insight generation
methodologies, and insight delivery methodologies will not be
redundantly described here.
[0301] Adherence Reports
[0302] In accordance with certain embodiments, patient-specific
data can be used to generate personalized adherence reports, which
can be generated and delivered as a type of insight message to the
patient's smartphone, computer, tablet, or mobile device. An
exemplary adherence report may contain reminders, recommendations,
and checks as described in the previous section titled Automatic
Patient Therapy Reminders. In order to ease the burden of
constantly remembering recommendations related to insulin therapy
and infusion system use, an adherence report can document the
relevant guidelines for patient adherence (and provide active links
to educational recommendations). The adherence report may also
include a comparison of the patient's behaviors, as reflected by
the captured and analyzed personal data, to recommended ranges of
behaviors. Adherence reports can be delivered in a timely manner as
chosen by the patient and/or as determined by the insights delivery
methodology, to allow the patient to conveniently review the
recommended behaviors and their personal standing. An adherence
report can be delivered to the patient as a static page or
notification, or as a dynamically searchable graphical user
interface having an interactive menu with links to educational
materials associated with the adherence recommendation.
[0303] An adherence report may indicate certain ranges of
recommended behaviors, as provided by the pumping protocol. The
content of an adherence report may also be expanded to include
customized adherence recommendations from healthcare providers,
approved medical literature, and/or other established guidelines
for diabetes therapy management.
[0304] Moreover, adherence reminders/reports can be tailored or
customized as needed for stricter guidelines. For example, stricter
guidelines are typically recommended for pregnant patients and for
cases of gestational diabetes. The adherence reminders/reports can
also be tailored or customized to contemplate post-hospital
discharge periods, where the path to recovery may include looser
guidelines.
[0305] Glucose Assist System
[0306] Referring again to FIG. 1, the system 100 may also be
suitably configured to support an intelligent and enhanced approach
for providing and reporting glucose-related information to the
patient. In this regard, the same mobile app (residing on the
patient's mobile device 104) that supports the delivery of glycemic
insight messages can be utilized to support the exemplary glucose
assist system described in more detail below. Some or all of the
input data described above in the context of the system 100, 300
can also be leveraged by the glucose assist system presented here.
The glucose assist system processes much of the same input data to
provide decision support using glucose responses to events that
potentially impact the patient's glucose levels. In contrast to the
glycemic insights delivery system, the glucose assist system
focuses on sensor glucose data, meal and nutrition information, and
possibly other input data that might influence the patient's
glucose level.
[0307] Glucose Assist System Overview
[0308] Many processes and behaviors impact blood glucose levels.
Commonly recognized processes impacting blood glucose levels
include food, exercise, disease (acute or chronic), medication
(insulin, oral, etc.), stress patterns, sleep patterns, and the
like. Furthermore, behavioral factors such as the time of the day,
attentiveness to therapy, purchasing patterns, and other patient
behaviors can provide additional quantitative indications of the
underlying factors impacting glucose control. Current reports
available to diabetes patients and their caregivers do not provide
comprehensive results of the aggregated events of interest. One
desired goal of the glucose assist system is to provide better,
more relevant, and more practical information and guidance to the
patient regarding glucose control. Rather than a simple piece of
information such as "your glucose will be going low (or high) in
the next three hours", the glucose assist system can provide
additional information that links glucose data to the occurrence of
other events, additional data, and various inputs that are
collected by the system. As one specific example, the glucose
assist system can predict the patient's glucose response after the
patient eats a cheeseburger, takes a bolus, and exercises by
contemplating a variety of event-specific and patient-specific
data. In accordance with certain scenarios, the glucose assist
system can generate animated output, such as animated glucose
traces that are animated in the order of retrospective responses to
an event followed by projections into future traces based on
optimized settings.
[0309] As used herein, a "glycemic response curve" refers to a
continuous glucose sensor output for a designated period of time
following a particular event (see below for a list of potential
events of interest, such as meal time, yoga workout, and metformin
ingestion). This response curve can also be extended to include
blood glucose values from a blood glucose meter, e.g., a finger
stick measurement device. Results of the event response segregation
are aimed to optimize medication and therapy regimen in the form of
personalized decision support. The glucose assist system provides
methods and weights to optimal and suboptimal therapy changes per
outcomes.
[0310] The functionality of the glucose assist system can be
implemented as a mobile app, a software program, or an executable
module on various computing and electronic device platforms
(computers, smartphones, tablet computers, portable medical
devices, smart wearables, and the like) to educate patients on
historical glycemic patterns. The personal glucose assist system
may also be fine-tuned to the outcomes and/or behaviors that the
patients and healthcare professionals deem the most important for
that individual's stage of diabetes management. These
prioritizations can be captured based on explicit and implicit
feedback from the computing platform.
[0311] Data Inputs and Model Feature Sets
[0312] The glucose assist system considers a number of glycemic
response events that may have some relationship to the patient's
glucose response and/or glucose management scheme. A glycemic
response event can be conveyed in, identified by, or otherwise
associated with input data obtained for the patient. Although the
number and type of data inputs can vary from one embodiment to
another, the exemplary embodiment considers the following, without
limitation: (1) meal time and nutritional content; (2) exercise
time, type, and intensity; (3) medication type, dosage, dosage
time; (4) sleep time and quality; (5) stress time (based on
physiological factors such as heart rate, blood pressure, skin
conductance, or user input); (6) time of day and/or day of week
(weekday vs weekend); (7) carbohydrate amount; (8) bolus dosage
amount (in Units), time of bolus (time and/or calendar data), and
bolus type (normal, square, dual); (9) active insulin amount; (10)
basal rate of insulin; (11) temporary basal use; (12) consecutive
boluses; (13) insulin suspension or infusion pump suspend mode;
(14) insulin reservoir rewind and priming time; (15) insulin pump
alarms and alarm times; (16) sensor alerts and alert times.
[0313] Methodologies
[0314] The sensor glucose and bolus data following a specific set
of events can be displayed as-is for a default or current scale
(mg/dL or mmol/L), or the data can be transformed into a z-score
(x-mean/standard deviation) in order to normalize the trace for an
individual. Glucose outcomes for the events are evaluated within
the retrospective data. Instances leading to the best glucose
outcomes are recognized and displayed to the user. Evaluation of
the outcomes can be performed by machine learning algorithms, such
as feature selection by maximum likelihood estimation via
regression analysis, neural networks, support vector machines,
logistic regression, decision trees, and the like. Regardless of
the particular implementation, the glucose assist system can define
feature importance and optimal glycemic response events.
[0315] This multivariate combination of independent variables is
also useful to iterate through a combination of simultaneously
occurring events. An extension of this concept relates to a
combination of ingredients in a meal. This level of detail in a
model can extract the ranges of medication, behaviors, or
ingredients that can result in the optimal outcome for the patient
based on historical data. Moreover, the system can use the model to
predict the ranges of events that may not have occurred yet, but
might result in optimal outcomes.
[0316] The specific methodology employed by the glucose assist
system to calculate the patient's glucose profile can vary from one
implementation to another, as appropriate for the particular
embodiment. The following examples relate to different methods that
can be used to evaluate the resulting sensor glucose data in
connection with a particular food or action in the presence of
additional covariates. It should be appreciated that additional or
alternative techniques can be deployed by an embodiment of the
glucose assist system.
[0317] Method 1: Independent Components Analysis for Single Food
Glucose Response
[0318] Independent components analysis (ICA) can be used to denoise
a signal, or extract source data from linear combinations of
multiple concurrent signals. See, for example, the approach that is
published online at www.wikipedia.org, and the approach described
in Independent Component Analysis: A Tutorial, by Hyvarinen and Oja
(April 1999), the content of which is incorporated by reference
herein. Current applications of ICA include voice recognition by
identifying the speech of individuals in a room of talking people.
In the same way that a particular voice may be detected in a room
with multiple speakers, a person's glucose profile associated with
eating a peach can be separated from the glucose profile associated
with eating yogurt (assuming that person ate a peach parfait with
peaches and yogurt as the primary ingredients). ICA assumes that
the inputs, however, are linearly independent, and this assumption
may not always be accurate in the context of human metabolism.
[0319] Thus, if the patient eats a cheeseburger, the system can
identify and isolate the glucose profile impact of the individual
ingredients (or at least the primary ingredients that have a
significant effect on the glucose profile). In certain embodiments,
the system relies on user-entered data that indicates the food that
was (or will be) consumed, and perhaps the main ingredients of that
food. Thus, the system can generate a predicted glucose plot
corresponding to each individual ingredient, which in turn allows
the system or the patient to identify any potentially troublesome
ingredient, i.e., an ingredient that causes an undesirable change
in the patient's glucose profile. As an extension of this concept,
the system can be suitably configured to individually consider the
nutritional content of consumed food rather than the specific
ingredients. In this regard, the system can break down the consumed
food by the amount of fat consumed, the amount of simple
carbohydrates consumed, the amount of complex carbohydrates
consumed, and the amount of protein consumed, and generate
corresponding glucose response plots for those individual
components.
[0320] Method 2: Principal Component Analysis and Sensor Trace
Categorization for Food Glucose Response Surrogate from
Macronutrient Composition
[0321] Principal Component Analysis (PCA) is a statistical
procedure that uses an orthogonal transformation to convert a set
of observations of possibly correlated variables into a set of
values of linearly uncorrelated variables called principal
components. In this regard, another way to predict glucose
responses to combinations of concurrent inputs is to characterize
sensor glucose data by clusters identified by minimization of the
Mahanolobis distance of the centroid from the first three principal
components of the sensor glucose data. Once the glucose sensor data
has been categorized (for example, into five clusters), the cluster
category can be used as the independent variable to the dependent
variables associated with each sensor glucose trace. In this case,
the dependent variables could be carbohydrate amount, fat amount,
protein amount, and calorie amount aggregated from a single meal,
as well as the amount of insulin taken at the meal, the starting
sensor glucose value and the sensor glucose rate of change for 30
minutes before the meal. From these combinations of inputs, the
model can be trained to predict a resulting glucose response curve.
The relationship to meal content for deployment into the mobile app
can occur by applying the meal macronutrients to a particular food
item (with the details of the insulin and sensor glucose) and
displaying the resulting predicted sensor glucose trace as
calculated by the average of all of the traces that form the
categorized cluster.
[0322] Method 3: Machine Learning for Optimal Insulin
Administration Per Meal Content to Result in Best Outcome (Time in
Range)
[0323] This methodology predicts a time range during which the
patient's glucose will be within a designated target range of
values. This type of feedback can be useful to the patient because
one desired goal is to maximize the time period during which the
patient's glucose is well controlled. Thus, if the user indicates
that she wants to eat ice cream, the system calculates the desired
portion size, the best time to eat the ice cream, the bolus dosage,
the best time to administer the bolus, and the like. This
information is provided to the patient in an effort to optimize the
amount of time that the patient will stay within her target glucose
range (assuming that she will actually eat the ice cream and follow
the recommendations). The information delivered to the patient goes
well beyond a simple warning or a status message.
[0324] As an example, using the same dependent variables listed
above, the output of the machine learning technique will instead be
the percent time in range from 70-180 mg/dL for the four hours
following a meal ingestion. From this information, the insulin
administration can be altered to ensure that the resulting outcome
will be in range. An alternative to this approach may be a binary
indication beyond a particular time in range threshold (80%, for
example, but the specific percentage can be changed according to
the patient's history and control, and can be adapted over
time).
[0325] These outcomes are available for the user either on demand
or displayed to the user intelligently when the system detects a
high probability of the event occurrence.
[0326] Data Outputs
[0327] In accordance with the exemplary embodiment presented here,
the output of the glucose analysis provides information to the user
in a desired format. The output may include any or all of the
following, without limitation: (1) each individual glucose response
trace; (2) each individual insulin trace; (3) the average glucose
response trace; (4) the average insulin trace; (5) the variation of
all response traces; and (6) the best and worst outcomes as
determined by the outputs (1)-(5).
[0328] Model Result
[0329] The model provides the behaviors/medications and dosage
ranges necessary to provide the best outcomes as defined by the
patient and healthcare provider. This can include the most time
within a range, the least time in low blood sugar, the least amount
of glycemic variability, and the like. Furthermore, the model
provides weights of importance of each feature to the desired (and
undesired) outcomes.
[0330] Applications and Model Extensions
[0331] The glycemic response curve can be used to describe glycemic
management patterns in the daily life of patients. Examples of this
include, without limitation:
[0332] (1) The patient's own physiological response to particular
behaviors, medications, events, etc.
[0333] (2) The change in the patient's physiological response over
time.
[0334] (3) It can also be used to inform predictive analytics in
the form of a comparative measure on the individual patient level
or the aggregated cohort level. For example, comparative responses
for medication adjustment, comparative responses for food
recommendations, comparative responses for optimal exercise
regimen, comparative responses for optimal sleep habits, etc.
[0335] (4) These response curves can also be used to perform
epidemiological studies of the ranges of glycemic responses to
certain stimuli and studied according to particular demographic
information such as duration of diabetes, sex, age, race/ethnicity,
etc.
[0336] (5) Features from the glycemic response curve (the area
under the curve, the rate of change, etc.) to food can be used to
calculate the glycemic index and glycemic load of a food to an
individual.
[0337] Graphical Support of the Glucose Assist System
[0338] The glucose assist system can generate graphs, plots, and
other visual output formatted in a suitable manner. For example,
FIG. 16 is an exemplary graph 700 of overlaid glucose sensor traces
as tethered to a particular event. The tethered event can be any of
the glycemic response events listed above, such as medication time,
exercise time, meal time, or the like. The horizontal axis
represents time relative to the time of the event under analysis
(which corresponds to the origin). The vertical axis represents
glucose measurement values. The graph 700 depicts multiple events
(for example, the patient takes a yoga class), along with an
average plot 702. The average plot 702 indicates the average
glucose response for the yoga class event. In addition to the
average, additional statistical measurements (such as median,
standard deviation, or interquartile range) can also be
overlaid.
[0339] FIG. 17 is an exemplary graph 720 of an individual glucose
sensor trace curve surrounding the time of a specific event (eating
a chicken taco). The graph 720 includes an individual glucose plot
722 that spans the time surrounding the event, wherein the vertical
line 724 corresponds to the event time. The graph 720 also includes
graphical indications 726 of the amount of medication (insulin)
administered to accommodate the meal. Additional information
displayed in the graph 720 includes a timestamp of the event, the
serving amount in the consumed meal item, the amount of
carbohydrates consumed as part of the meal item, additional
carbohydrates consumed with that meal item and the patient's target
glucose range for good glycemic control.
[0340] FIG. 18 is another exemplary graph 740 of an individual
glucose sensor trace curve surrounding the time of a specific event
(eating a chicken taco). The graph 740 is similar to the graph 720
shown in FIG. 17, but the date is different, the amount of
additional carbohydrates consumed is 25 grams rather than 10 grams,
and the size and timing of the second bolus is different. More
specifically, the second bolus is 2.0 Units rather than only 1.5
Units, and the time between the event time and the second bolus is
longer in the graph 740, relative to that shown in the graph 720.
Notably, these differences result in a noticeably different glucose
plot 742.
[0341] The type of graphs shown in FIGS. 16-18 (and possibly other
visualizations) can be generated and delivered to the patient at
any desired time. The output information can be used to better
understand the relationship between the patient's glucose response,
the type and amount of food consumed, and the size and timing of
boluses administered in association with the meal.
[0342] FIG. 19 is a flow chart that illustrates an exemplary
embodiment of a glucose information reporting process 760. The
process 760 and variations thereof can be performed by the system
100, 300 described above, or by a glucose assist system that is
functionally incorporated into the system 100, 300. The process 760
begins by obtaining the relevant input data collected from one or
more sources (task 762). As mentioned previously, the glucose
assist system preferably utilizes the same input data (historical
data) collected for use with the glycemic insight generation and
delivery feature. Accordingly, the foregoing description of
exemplary input data types and data sources used in connection with
the system 100, 300 also applies to the process 760. The process
760 analyzes the input data to provide glucose related information
to the user (e.g., actual or predicted glucose plots, which may be
based on sensor glucose readings, blood glucose meter measurements,
or both). The process 760 also analyzes the input data to provide
additional information that can be helpful to the user.
[0343] The process 760 identifies at least one glycemic response
event of interest (task 764). A number of exemplary glycemic
response events were described above, and any of those glycemic
response events can be identified at task 764. For ease of
understanding, this example assumes that only one glycemic response
event has been identified. For instance, the identified glycemic
response event might be the ingestion of a meal, physical exercise,
or the onset of an illness. Notably, the identified glycemic
response event can be associated or otherwise linked to the
patient's glucose response profile. Although not always necessary
or desirable, the process 760 can filter, condition, or otherwise
pre-process the input data or a portion thereof (task 766). For
example, task 766 can be performed to identify and remove obviously
erroneous or outlier data, to remove "noise" from raw glucose data,
and/or to eliminate input data that is unrelated to or has little
to no relationship with the identified glycemic response event.
[0344] The process 760 continues by generating at least one
graphical representation of the patient's glucose response to the
identified event of interest (task 768). Consistent with the
description of FIGS. 16-18, the graphical representation generated
at task 768 can indicate sensor glucose readings and/or blood
glucose measurements for the patient. As depicted in FIG. 16, the
graphical representation generated at task 768 can include
superimposed or overlying glucose plots or traces that correspond
to different occurrences of the identified event of interest (the
timing of which corresponds to the origin of the horizontal axis).
Alternatively, as depicted in FIG. 17 and FIG. 18, the graphical
representation generated at task 768 can include only one glucose
plot, such as the patient's glucose response following the most
recent occurrence of the identified event of interest.
[0345] If the identified event of interest includes the ingestion
of a meal, a piece of food, a beverage, or something of nutritional
value, then the graphical representation generated at task 768 may
include a plot/trace that indicates the patient's overall glucose
response to the meal, item of food, beverage, etc. Alternatively or
additionally, the graphical representation generated at task 768
may include individual plots/traces (rendered in a distinct manner
or combined with one another) that indicate the patient's glucose
response to the ingredients or nutritional components contained in
the ingested meal. In this context, each of the individual plots
indicates a constituent glucose response to an ingredient,
nutritional component (fat, carbohydrate, protein), chemical
composition, or element contained in the meal. For example, if the
patient eats a salad, then the graphical representation might
include one plot that shows the glucose response attributable to
the green vegetation component, another plot that shows the glucose
response attributable to the cheese component, and a third plot
that shows the glucose response attributable to the dressing
component. Methodologies that can be applied to break down the raw
glucose data into constituent parts corresponding to the
food/nutritional components were described above (e.g., the ICA
approach and characterization using Mahanolobis distance).
[0346] In certain embodiments, the graphical representation
generated at task 768 includes or conveys additional useful
information above and beyond the glucose profile data. For example,
the graphical representation may include or identify any or all of
the following, without limitation: timestamp data for the event of
interest; a marker that identifies the timing of the event of
interest, e.g., the start time, the end time, or both; an element
that indicates the timing and size of an insulin bolus or other
amount of insulin administered to accommodate the ingestion of the
meal; a descriptor, an icon, or some type of descriptive
information regarding the content of the meal, such as text or a
label that identifies the particular food, ingredients, or
nutritional components (fat, carbohydrates, calories, protein)
consumed by the patient; and the like.
[0347] The process 760 delivers the generated graphical
representation (or more than one if applicable) to the user's
mobile device at an appropriate time (task 770). The native
processing and display capabilities of the mobile device are used
to present the graphical representation to the user.
[0348] FIG. 20 is a flow chart that illustrates an exemplary
embodiment of a glycemic outcome optimization process 780. The
process 780 can be considered to be another exemplary embodiment of
a method of reporting glucose information for a user of an insulin
infusion device. The process 780 and variations thereof can be
performed by the system 100, 300 described above, or by a glucose
assist system that is functionally incorporated into the system
100, 300. The process 780 begins by obtaining the relevant input
data collected from one or more sources (task 782). As mentioned
previously, the glucose assist system preferably utilizes the same
input data (historical data) collected for use with the glycemic
insight generation and delivery feature. Accordingly, the foregoing
description of exemplary input data types and data sources used in
connection with the system 100, 300 also applies to the process
780. The process 780 analyzes the input data to provide
recommendations to the user, wherein the recommendations are
intended to extend, maximize, or optimize a period of time during
which the patient's glucose is well-controlled.
[0349] The process 780 identifies at least one tracked, planned, or
desired glycemic response event of interest (task 784). In certain
embodiments, task 784 obtains user-entered information that is
indicative of the tracked event of interest. A number of exemplary
glycemic response events were described above, and any of those
glycemic response events can be identified at task 784. For ease of
understanding, this example assumes that only one glycemic response
event is tracked. For instance, the tracked glycemic response event
might be "eating a scoop of ice cream" or "eating two slices of
cheese pizza and drinking a pint of beer" or "running for 45
minutes". Although not always necessary or desirable, the process
780 can filter, condition, or otherwise pre-process the input data
or a portion thereof (task 786). For example, task 786 can be
performed to identify and remove obviously erroneous or outlier
data, to remove "noise" from raw glucose data, and/or to eliminate
input data that is unrelated to or has little to no relationship
with the tracked glycemic response event.
[0350] The system analyzes current and historical input data in
view of the tracked glycemic response event to calculate one or
more recommended glycemic control parameters (task 788). The
recommended parameters are intended to extend the "within target
glucose range" time period that follows the event of interest,
assuming that the tracked glycemic response event will actually
occur. In certain embodiments, the system strives to maximize the
amount of time that the patient's sensor glucose or blood glucose
will remain in the desired target range during the next four hours
after the tracked event. The overall time window of four hours is
merely exemplary, and the window may be longer or shorter,
depending on the particular embodiment. The process 780 calculates
the recommended glycemic control parameters with this goal in mind.
A glycemic control parameter in this context can be any variable or
factor that influences the patient's glycemic response going
forward. As used here, the recommended glycemic control parameters
may include any of the following, without limitation: information
related to ingestion of meals (e.g., the type of food, the portion
size, the nutritional content, the ingredients); information
related to the timing of meals; information related to insulin
delivery (e.g., insulin bolus size, timing of insulin boluses, type
of bolus, basal rate); physical activity data; medication data;
sleep related data; and the like.
[0351] The process 780 continues by generating an output message
that includes at least some of the recommended glycemic control
parameters, and possibly other information if so desired (task
790). The output can include: a text-based message; graphics; video
content; audio content; etc. The output provides tips, guidance, or
suggestions for the patient to consider if the tracked event is
actually carried out. For example, if the patient plans to eat a
scoop of ice cream, then the output may include recommendations
related to the portion size, when to eat the ice cream, the insulin
bolus size, and when to take the bolus. Thus, rather than providing
a simple warning or reminder to the user, the process 780 generates
recommendations that, if followed, should optimize the patient's
glucose profile for the time period immediately following the
tracked event.
[0352] The process 780 delivers the output message to the user
device in an appropriate format, at an appropriate time, and using
a suitable delivery mechanism (task 792). In certain situations,
the output message is delivered at a time prior to an occurrence of
the tracked glycemic response event. This is desirable to allow the
patient to take appropriate action to address the tracked event.
The native processing and display capabilities of the user device
are used to present the output message to the user.
[0353] While at least one exemplary embodiment has been presented
in the foregoing detailed description, it should be appreciated
that a vast number of variations exist. It should also be
appreciated that the exemplary embodiment or embodiments described
herein are not intended to limit the scope, applicability, or
configuration of the claimed subject matter in any way. Rather, the
foregoing detailed description will provide those skilled in the
art with a convenient road map for implementing the described
embodiment or embodiments. It should be understood that various
changes can be made in the function and arrangement of elements
without departing from the scope defined by the claims, which
includes known equivalents and foreseeable equivalents at the time
of filing this patent application.
* * * * *
References