Note: Descriptions are shown in the official language in which they were submitted.
CA 02938541 2016-08-09
TITLE
DIABETES THERAPY MANAGEMENT SYSTEM
FIELD OF THE INVENTION
[0002] Embodiments of the present invention are directed to systems and
methods for diabetes therapy management. Specifically, embodiments of the
present
invention are directed to systems and methods for analyzing patient
information to
generate reports to assist in the management of diabetes therapy.
BACKGROUND OF THE INVENTION
[0003] The pancreas of a normal healthy person produces and releases
insulin
into the blood stream in response to elevated blood plasma glucose levels.
Beta cells
(13-cells), which reside in the pancreas, produce and secrete the insulin into
the blood
stream, as it is needed. If 13-cells become incapacitated or die, a condition
known as
CA 02938541 2016-08-09
. .
,
,
Type I diabetes mellitus (or in some cases if p-cells produce insufficient
quantities of
insulin, Type II diabetes), then insulin must be provided to the body from
another
source. Diabetes affects approximately eight percent of the total population
in the
United States alone.
[0004] Traditionally, since insulin cannot be taken orally,
insulin has been injected
with a syringe. More recently, use of infusion pump therapy has been
increasing,
especially for delivering insulin for diabetics. For example, external
infusion pumps are
worn on a belt, in a pocket, or the like, and deliver insulin into the body
via an infusion
tube with a percutaneous needle or a cannula placed in the subcutaneous
tissue.
[0005] As of 1995, less than 5% of Type I diabetics in the United
States were
using infusion pump therapy. Presently, about 10% of the more than 1.5 million
Type I
diabetics in the U.S. are using infusion pump therapy. And the percentage of
Type I
diabetics that use an infusion pump is growing at an absolute rate of over 2%
each
year. Moreover, the number of Type I diabetics is growing at 3% or more per
year. In
addition, growing numbers of insulin-using Type II diabetics are also using
infusion
pumps. Physicians have recognized that continuous infusion provides greater
control of
a diabetic's condition, and are also increasingly prescribing it for patients.
Although
offering control, pump therapy can suffer from several complications that make
use of
traditional external infusion pumps less desirable for the user.
SUMMARY OF THE INVENTION
[0006] Embodiments of the present invention are directed to
systems and
methods of diabetes analysis. A plurality of glucose level readings for a user
is
2
CA 02938541 2016-08-09
received. A common event occurrence in at least two of the glucose level
readings is
determined. The at least two glucose level readings from the common event
occurrence onwards in time for a time period is analyzed. A glucose level
pattern
formed by the at least two glucose level readings having a similar shape is
determined.
At least one anomalous glucose level reading having the similar shape and not
conforming to the glucose level pattern is analyzed. The at least one
anomalous
glucose level reading is adapted to the pattern to form an adapted glucose
level pattern.
An insulin dosage for the time period beginning at the common event occurrence
is
calculated based on the adapted glucose level pattern. Embodiments of the
present
invention may perform these steps on a computer, or any other suitable system.
[0007] In particular embodiments, the glucose level readings are at least a
portion of a 24-hour period. An average glucose level reading may be
calculated from
the adapted glucose level pattern, and the insulin dosage may be calculated
based on
the average glucose level reading. The common event occurrence may be, for
example, breakfast, lunch, dinner, a meal bolus, a correction bolus, or a
bedtime (to
analyze an overnight period). The plurality of glucose level readings may
represent
glucose levels over time. The insulin dosage may be for a basal insulin
dosage. The at
least one anomalous glucose level reading having the similar shape may have at
least
one of: a greater or lesser magnitude, and a higher or lower basal glucose
level than
the at least two glucose level readings forming the glucose level pattern. The
at least
one anomalous glucose level reading having the similar shape may be compressed
or
stretched in time compared to the at least two glucose level readings forming
the
glucose level pattern. The at least one anomalous glucose level reading having
the
3
CA 02938541 2016-08-09
similar shape may occur differently from the common event occurrence of the at
least
two glucose level readings forming the glucose level pattern. Moreover, the
glucose
level readings may exclude those from the most recent days, especially if a
user is
learning a new behavior. Glucose level readings may be automatically or
manually
removed from analysis due to transient events in a user's life. Additionally,
only those
glucose level readings selected from days where the user has a periodic or
transient
condition (e.g., menstruation, illness, having a cold, being on a particular
medication,
stress and anxiety, etc.) may be selected for analysis.
[0008] Embodiments of the present invention are directed to systems and
methods of diabetes analysis. Average glucose level information for a time
period over
a plurality of days is determined. A current event occurrence is determined.
An event
occurrence in the average glucose level information within the time period
corresponding to the current event occurrence is determined, where the current
event
occurrence is at a different time of day than the event occurrence. The
average glucose
level information starting in time from the event occurrence within the time
period is
analyzed. A notification event in the average glucose level information
starting in time
from the event occurrence within the time period is determined. A current
notification
event in time from the current event occurrence based on a time span from the
event
occurrence to the notification event in the average glucose level information
is
predicted. An action is initiated in advance of the predicted current
notification event.
Embodiments of the present invention may perform these steps on a computer, or
any
other suitable system.
4
CA 02938541 2016-08-09
[0009] In particular embodiments, the current event occurrence and event
occurrence may be, for example, breakfast, lunch, or dinner. The notification
event may
include, for example, hyperglycemia, hypoglycemia, a sharp glucose level
spike, or a
sharp glucose level drop. The action may include at least one of notifying a
user of the
predicted current notification event (which may utilize an auditory, visual,
or vibrational
alarm), recommending a bolus dosage to the user, automatically delivering a
bolus of
insulin, and automatically suspending delivery of insulin. The current event
occurrence
may be earlier or later than the event occurrence in the average glucose level
information.
[0010] Embodiments of the present invention are directed to a method of
providing bolus dosage recommendations for diabetics. A plurality of
representative
foods is presented to a user. The user's response to estimate a carbohydrate
value for
each one of the plurality of representative foods is received. An input is
received from
the user indicating a food to be consumed and an estimated carbohydrate value
for the
food to be consumed. A bolus dosage recommendation is calculated based on the
input from the user and the user's response to estimate the carbohydrate value
for at
least one of the plurality of representative foods. Embodiments of the present
invention
may perform these steps on a computer, or any other suitable system.
[0011] In particular embodiments, the bolus dosage recommendation is
increased if the user's response to estimate the carbohydrate value for the at
least one
of the plurality of representative foods corresponding to the food to be
consumed is
lower than a true carbohydrate value for the at least one of the plurality of
representative foods corresponding to the food to be consumed, and the bolus
dosage
CA 02938541 2016-08-09
. ,
,
recommendation is decreased if the user's response to estimate the
carbohydrate value
for the at least one of the plurality of representative foods corresponding to
the food to
be consumed is higher than a true carbohydrate value for the at least one of
the plurality
of representative foods corresponding to the food to be consumed. The
plurality of
representative foods may include a plurality of food types, and the plurality
of food types
may include: grains, vegetables, fruits, dairy products, and meats.
[0012] Embodiments of the present invention are directed to a
method of
diabetes analysis. A plurality of glucose level readings for a user is
received. The
plurality of blood glucose level readings are analyzed to generate a report.
The report
includes a first chart along a 24-hour timeline indicating the plurality of
glucose level
readings, and a second chart having at least one of infusion device settings
and active
insulin levels corresponding to the 24-hour timeline of the first chart.
[0013] In particular embodiments, the plurality of glucose level
readings may be
blood glucose level readings taken from a blood glucose meter. The plurality
of glucose
level readings may be continuous blood glucose level readings received from a
continuous glucose monitor sensor. The second chart further may include an
interpretation report. The infusion device settings may include at least one
of basal
rate, insulin sensitivity, and carbohydrate ratio. The second chart further
may include
basal rate information corresponding to the 24-hour timeline of the first
chart.
[0014] Embodiments of the present invention are directed to an
article of
manufacture containing code for diabetes analysis, comprising a computer-
usable
medium including at least one embedded computer program that is capable of
causing
at least one computer to perform receiving a plurality of glucose level
readings for a
6
CA 02938541 2016-08-09
. .
=
user, and analyzing the plurality of blood glucose level readings to generate
a report.
The report includes a first chart along a 24-hour timeline indicating the
plurality of
glucose level readings, and a second chart having at least one of infusion
device
settings and active insulin levels corresponding to the 24-hour timeline of
the first chart.
[0015] In particular embodiments, the plurality of glucose level
readings may be
blood glucose level readings taken from a blood glucose meter. The plurality
of glucose
level readings may be continuous blood glucose level readings received from a
continuous glucose monitor sensor. The second chart further may include an
interpretation report. The infusion device settings may include at least one
of basal
rate, insulin sensitivity, and carbohydrate ratio. The second chart further
may include
basal rate information corresponding to the 24-hour timeline of the first
chart.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 illustrates a computing device including a display
housing a
diabetes data management system according to embodiments of the present
invention;
[0017] FIG. 2A illustrates a sample report displaying sensor
readings according
to embodiments of the present invention
[0018] FIG. 2B illustrates a sample report displaying sensor
readings according
to embodiments of the present invention;
[0019] FIG. 2C illustrates an adapted time-shifted sample report
displaying
sensor readings from FIG. 2B according to embodiments of the present
invention;
[0020] FIG. 2D illustrates a sample report displaying sensor
readings according
to embodiments of the present invention;
7
CA 02938541 2016-08-09
. ,
,
[0021] FIG. 2E illustrates an adapted glucose-level-compressed
sample report
displaying sensor readings from FIG. 2D according to embodiments of the
present
invention;
[0022] FIG. 2F illustrates a sample report displaying sensor
readings according to
embodiments of the present invention;
[0023] FIG. 2G illustrates an adapted time-stretched sample report
displaying
sensor readings from FIG. 2F according to embodiments of the present
invention;
[0024] FIG. 2H illustrates a sample report displaying sensor
readings according
to embodiments of the present invention;
[0025] FIG. 21 illustrates an adapted glucose-level-shifted sample
report
displaying sensor readings from FIG. 2H according to embodiments of the
present
invention;
[0026] FIG. 2J illustrates an adapted time-shifted sample report
displaying sensor
readings from FIG. 2C utilizing a relative time line according to embodiments
of the
present invention;
[0027] FIG. 2K illustrates a report showing an average glucose
level reading,
standard deviation, and high-low lines of the adapted time-shifted sample
report of FIG.
20 according to embodiments of the present invention;
[0028] FIG. 3 illustrates a flowchart for applying pattern
recognition and filtering
algorithms for diabetes analysis according to embodiments of the present
invention;
[0029] FIG. 4 illustrates a flowchart for diabetes analysis
according to
embodiments of the present invention; and
8
CA 02938541 2016-08-09
[0030] FIG. 5 illustrates a flowchart for providing bolus dosage
recommendations
for diabetics according to embodiments of the present invention.
[0031] FIGS. 6A and 6B illustrate Interpretation Reports according to
embodiments of the present invention.
[0032] FIG. 7A illustrates a Therapy Management Dashboard according to
embodiments of the present invention, and FIG. 7B illustrates an Episode
Summary
according to embodiments of the present invention.
DETAILED DESCRIPTION
[0033] Embodiments of the invention are described below with reference to
flowchart and menu illustrations of methods, apparatus, and computer program
products. It will be understood that each block of the flowchart
illustrations, and
combinations of blocks in the flowchart illustrations, can be implemented by
computer
program instructions (as can any menu screens described in the Figures). These
computer program instructions may be loaded onto a computer or other
programmable
data processing apparatus to produce a machine, such that the instructions
which
execute on the computer (or other programmable data processing apparatus)
create
instructions for implementing the functions specified in the flowchart block
or blocks.
These computer program instructions may also be stored in a computer-readable
memory that can direct a computer (or other programmable data processing
apparatus)
to function in a particular manner, such that the instructions stored in the
computer-
readable memory produce an article of manufacture including instructions which
implement the function specified in the flowchart block or blocks. The
computer
9
CA 02938541 2016-08-09
program instructions may also be loaded onto a computer or other programmable
data
processing apparatus to cause a series of operational steps to be performed on
the
computer or other programmable apparatus to produce a computer implemented
process such that the instructions which execute on the computer or other
programmable apparatus provide steps for implementing the functions specified
in the
flowchart block or blocks, and/or menus presented herein.
[0034] FIG. 1 illustrates a computing device including a display housing a
diabetes data management system according to embodiments of the present
invention.
The diabetes data management system (DDMS) may be referred to as the Medtronic
MiniMed CARELINKTM system or as a medical data management system (MDMS) in
some embodiments of the invention. The DDMS may be housed on a server or a
plurality of servers which a user or a health care professional may access via
a
communications network via the Internet or the World Wide Web. This model of
the
DDMS, which is described as an MOMS is described in U.S. Pat. App. Pub. No.
2006/0031094, published Feb. 9, 2006, to Cohen et al., and is entitled,
"Medical Data
Management System and Process"
[0035] While description of embodiments of the invention below are made in
regard to monitoring medical or biological conditions for subjects having
diabetes, the
systems and processes below are applicable to monitoring medical or biological
conditions for cardiac subjects, cancer subjects, HIV subjects, subjects with
other
disease, infection, or controllable conditions, or various combinations
thereof.
CA 02938541 2016-08-09
[0036] In embodiments of the invention, the DDMS may be installed in a
computing device in a health care provider's office, such as a doctor's
office, a nurse's
office, a clinic, an emergency room, an urgent care office. Health care
providers may
be reluctant to utilize a system where their confidential patient data is to
be stored in a
computing device such as a server on the Internet.
[0037] The DDMS may be installed on a computing device 100. The computing
device 100 may be coupled to a display 33. In embodiments of the invention,
the
computing device 100 may be in a physical device separate from the display
(such as in
a personal computer, a mini-computer, etc.) In embodiments of the invention,
the
computing device 100 may be in a single physical enclosure or device with the
display
33 such as a laptop where the display 33 is integrated into the computing
device. In
embodiments of the invention, the computing device 100 hosting the DDMS may
be, but
is not limited to, a desktop computer, a laptop computer, a server, a network
computer,
a personal digital assistant (PDA), a portable telephone including computer
functions, a
pager with a large visible display, an insulin pump including a display, a
glucose sensor
including a display, a glucose meter including a display, and/or a combination
insulin
pump/glucose sensor having a display. The computing device may also be an
insulin
pump coupled to a display, a glucose meter coupled to a display, or a glucose
sensor
coupled to a display. The computing device 100 may also be a server located on
the
Internet that is accessible via a browser installed on a laptop computer,
desktop
computer, a network computer, or a PDA. The computing device 100 may also be a
server located in a doctor's office that is accessible via a browser installed
on a portable
computing device, e.g., laptop, PDA, network computer, portable phone, which
has
11
CA 02938541 2016-08-09
wireless capabilities and can communicate via one of the wireless
communication
protocols such as Bluetooth and IEEE 802.11 protocols.
[0038] In the embodiment shown in FIG. 1, the data management system 16
comprises a group of interrelated software modules or layers that specialize
in different
tasks. The system software includes a device communication layer 24, a data
parsing
layer 26, a database layer 28, database storage devices 29, a reporting layer
30, a
graph display layer 31, and a user interface layer 32. The diabetes data
management
system may communicate with a plurality of subject support devices 12, two of
which
are illustrated in FIG. 1. Although the different reference numerals refer to
a number of
layers, (e.g., a device communication layer, a data parsing layer, a database
layer),
each layer may include a single software module or a plurality of software
modules. For
example, the device communications layer 24 may include a number of
interacting
software modules, libraries, etc. In embodiments of the invention, the data
management system 16 may be installed onto a non-volatile storage area (memory
such as flash memory, hard disk, removable hard, DVD-RW, CD-RW) of the
computing
device 100. If the data management system 16 is selected or initiated, the
system 16
may be loaded into a volatile storage (memory such as DRAM, SRAM, RAM, DDRAM)
for execution.
[0039] The device communication layer 24 is responsible for interfacing
with at
least one, and, in further embodiments, to a plurality of different types of
subject support
devices 12, such as, for example, blood glucose meters, glucose
sensors/monitors, or
an infusion pump. In one embodiment, the device communication layer 24 may be
configured to communicate with a single type of subject support device 12.
However, in
12
CA 02938541 2016-08-09
more comprehensive embodiments, the device communication layer 24 is
configured to
communicate with multiple different types of subject support devices 12, such
as
devices made from multiple different manufacturers, multiple different models
from a
particular manufacturer and/or multiple different devices that provide
different functions
(such as infusion functions, sensing functions, metering functions,
communication
functions, user interface functions, or combinations thereof). As described in
more
detail below, by providing an ability to interface with multiple different
types of subject
support devices 12, the diabetes data management system 16 may collect data
from a
significantly greater number of discrete sources. Such embodiments may provide
expanded and improved data analysis capabilities by including a greater number
of
subjects and groups of subjects in statistical or other forms of analysis that
can benefit
from larger amounts of sample data and/or greater diversity in sample data,
and,
thereby, improve capabilities of determining appropriate treatment parameters,
diagnostics, or the like.
[0040] The device communication layer 24 allows the DDMS 16 to receive
information from and transmit information to or from each subject support
device 12 in
the system 16. Depending upon the embodiment and context of use, the type of
information that may be communicated between the system 16 and device 12 may
include, but is not limited to, data, programs, updated software, education
materials,
warning messages, notifications, device settings, therapy parameters, or the
like. The
device communication layer 24 may include suitable routines for detecting the
type of
subject support device 12 in communication with the system 16 and implementing
appropriate communication protocols for that type of device 12. Alternatively
or in
13
CA 02938541 2016-08-09
=
addition, the subject support device 12 may communicate information in packets
or
other data arrangements, where the communication includes a preamble or other
portion that includes device identification information for identifying the
type of the
subject support device. Alternatively, or in addition, the subject support
device 12 may
include suitable user-operable interfaces for allowing a user to enter
information, such
as by selecting an optional icon or text or other device identifier, that
corresponds to the
type of subject support device used by that user. Such information may be
communicated to the system 16, through a network connection. In yet further
embodiments, the system 16 may detect the type of subject support device 12 it
is
communicating with in the manner described above and then may send a message
requiring the user to verify that the system 16 properly detected the type of
subject
support device being used by the user. For systems 16 that are capable of
communicating with multiple different types of subject support devices 12, the
device
communication layer 24 may be capable of implementing multiple different
communication protocols and selects a protocol that is appropriate for the
detected type
of subject support device.
[0041] The data-parsing layer 26 is responsible for validating the
integrity of
device data received and for inputting it correctly into a database 29. A
cyclic
redundancy check CRC process for checking the integrity of the received data
may be
employed. Alternatively, or in addition, data may be received in packets or
other data
arrangements, where preambles or other portions of the data include device
type
identification information. Such preambles or other portions of the received
data may
further include device serial numbers or other identification information that
may be
14
CA 02938541 2016-08-09
used for validating the authenticity of the received information. In such
embodiments,
the system 16 may compare received identification information with pre-stored
information to evaluate whether the received information is from a valid
source.
[0042] The database layer 28 may include a centralized database repository
that
is responsible for warehousing and archiving stored data in an organized
format for later
access, and retrieval. The database layer 28 operates with one or more data
storage
device(s) 29 suitable for storing and providing access to data in the manner
described
herein. Such data storage device(s) 29 may comprise, for example, one or more
hard
discs, optical discs, tapes, digital libraries or other suitable digital or
analog storage
media and associated drive devices, drive arrays or the like.
[0043] Data may be stored and archived for various purposes, depending upon
the embodiment and environment of use. As described below, information
regarding
specific subjects and patient support devices may be stored and archived and
made
available to those specific subjects, their authorized healthcare providers
and/or
authorized healthcare payor entities for analyzing the subject's condition.
Also, certain
information regarding groups of subjects or groups of subject support devices
may be
made available more generally for healthcare providers, subjects, personnel of
the
entity administering the system 16 or other entities, for analyzing group data
or other
forms of conglomerate data.
[0044] Embodiments of the database layer 28 and other components of the
system 16 may employ suitable data security measures for securing personal
medical
information of subjects, while also allowing non-personal medical information
to be more
generally available for analysis. Embodiments may be configured for compliance
with
CA 02938541 2016-08-09
=
suitable government regulations, industry standards, policies or the like,
including, but
not limited to the Health Insurance Portability and Accountability Act of 1996
(HIPAA).
[0045] The database layer 28 may be configured to limit access of
each user to
types of information pre-authorized for that user. For example, a subject may
be
allowed access to his or her individual medical information (with individual
identifiers)
stored by the database layer 28, but not allowed access to other subject's
individual
medical information (with individual identifiers). Similarly, a subject's
authorized
healthcare provider or payor entity may be provided access to some or all of
the
subject's individual medical information (with individual identifiers) stored
by the
database layer 28, but not allowed access to another individual's personal
information.
Also, an operator or administrator-user (on a separate computer communicating
with
the computing device 100) may be provided access to some or all subject
information,
depending upon the role of the operator or administrator. On the other hand, a
subject,
healthcare provider, operator, administrator or other entity, may be
authorized to access
general information of unidentified individuals, groups or conglomerates
(without
individual identifiers) stored by the database layer 28 in the data storage
devices 29.
[0046] In embodiments of the invention, the database layer 28 may
store
preference profiles. In the database layer 28, for example, each user may
store
information regarding specific parameters that correspond to the user.
Illustratively,
these parameters could include target blood glucose or sensor glucose levels,
what
type of equipment the users utilize (insulin pump, glucose sensor, blood
glucose meter,
etc.) and could be stored in a record, a file, or a memory location in the
data storage
16
CA 02938541 2016-08-09
. .
,
device(s) 29 in the database layer. Illustratively, these parameters could
also include
analysis times for each of the meal events.
[0047] The DDMS 16 may measure, analyze, and track either blood
glucose (BG)
or sensor glucose (SG) readings for a user. In embodiments of the invention,
the
medical data management system may measure, track, or analyze both BG and SG
readings for the user. Accordingly, although certain reports may mention or
illustrate
BG or SG only, the reports may monitor and display results for the other one
of the
glucose readings or for both of the glucose readings.
[0048] The reporting layer 30 may include a report wizard program
that pulls data
from selected locations in the database 28 and generates report information
from the
desired parameters of interest. The reporting layer 30 may be configured to
generate
multiple different types of reports, each having different information and/or
showing
information in different formats (arrangements or styles), where the type of
report may
be selectable by the user. A plurality of pre-set types of report (with pre-
defined types
of content and format) may be available and selectable by a user. At least
some of the
pre-set types of reports may be common, industry standard report types with
which
many healthcare providers should be familiar.
[0049] In embodiments of the invention, the database layer 28 may
calculate
values for various medical information that is to be displayed on the reports
generated
by the report or reporting layer 30. For example, the database layer 28, may
calculate
average blood glucose or sensor glucose readings for specified timeframes. In
embodiments of the invention, the reporting layer 30 may calculate values for
medical or
physical information that is to be displayed on the reports. For example, a
user may
17
CA 02938541 2016-08-09
select parameters which are then utilized by the reporting layer 30 to
generate medical
information values corresponding to the selected parameters. In other
embodiments of
the invention, the user may select a parameter profile that previously existed
in the
database layer 28.
[0050]
Alternatively, or in addition, the report wizard may allow a user to design a
custom type of report. For example, the report wizard may allow a user to
define and
input parameters (such as parameters specifying the type of content data, the
time
period of such data, the format of the report, or the like) and may select
data from the
database and arrange the data in a printable or displayable arrangement, based
on the
user-defined parameters. In further embodiments, the report wizard may
interface with
or provide data for use by other programs that may be available to users, such
as
common report generating, formatting or statistical analysis programs such as,
but not
limited to, EXCELTM or the like. In this manner, users may import data from
the system
16 into further reporting tools familiar to the user. The reporting layer 30
may generate
reports in displayable form to allow a user to view reports on a standard
display device,
printable form to allow a user to print reports on standard printers, or other
suitable
forms for access by a user. Embodiments may operate with conventional file
format
schemes for simplifying storing, printing and transmitting functions,
including, but not
limited to PDF, JPEG, or the like. Illustratively, a user may select a type of
report and
parameters for the report and the reporting layer 30 may create the report in
a PDF
format. A PDF plug-in may be initiated to help create the report and also to
allow the
user to view the report. Under these operating conditions, the user may print
the report
utilizing the PDF plug-in. In certain embodiments in which security measures
are
18
CA 02938541 2016-08-09
implemented, for example, to meet government regulations, industry standards
or
policies that restrict communication of subject's personal information, some
or all reports
may be generated in a form (or with suitable software controls) to inhibit
printing, or
electronic transfer (such as a non-printable and/or non-capable format). In
yet further
embodiments, the system 16 may allow a user generating a report to designate
the
report as non-printable and/or non-transferable, whereby the system 16 will
provide the
report in a form that inhibits printing and/or electronic transfer.
[0051] The reporting layer 30 may transfer selected reports to the graph
display
layer 31. The graph display layer 31 receives information regarding the
selected reports
and converts the data into a format that can be displayed or shown on a
display 33.
[0052] In embodiments of the invention, the reporting layer 30 may store a
number of the user's parameters. Illustratively, the reporting layer 30 may
store the type
of carbohydrate units, a blood glucose movement or sensor glucose reading, a
carbohydrate conversion factor, and timeframes for specific types of reports.
These
examples are meant to be illustrative and not limiting.
[0053] Data analysis and presentations of the reported information may be
employed to develop and support diagnostic and therapeutic parameters. Where
information on the report relates to an individual subject, the diagnostic and
therapeutic
parameters may be used to assess the health status and relative well being of
that
subject, assess the subject's compliance to a therapy, as well as to develop
or modify
treatment for the subject and assess the subject's behaviors that affect
his/her therapy.
Where information on the report relates to groups of subjects or conglomerates
of data,
the diagnostic and therapeutic parameters may be used to assess the health
status and
19
CA 02938541 2016-08-09
,
relative well being of groups of subjects with similar medical conditions,
such as, but not
limited to, diabetic subjects, cardiac subjects, diabetic subjects having a
particular type
of diabetes or cardiac condition, subjects of a particular age, sex or other
demographic
group, subjects with conditions that influence therapeutic decisions such as
but not
limited to pregnancy, obesity, hypoglycemic unawareness, learning disorders,
limited
ability to care for self, various levels of insulin resistance, combinations
thereof, or the
like.
[0054] The user interface layer 32 supports interactions with the
end user, for
example, for user login and data access, software navigation, data input, user
selection
of desired report types and the display of selected information. Users may
also input
parameters to be utilized in the selected reports via the user interface layer
32.
Examples of users include but are not limited to: healthcare providers,
healthcare payer
entities, system operators or administrators, researchers, business entities,
healthcare
institutions and organizations, or the like, depending upon the service being
provided by
the system and depending upon the invention embodiment. More comprehensive
embodiments are capable of interacting with some or all of the above-noted
types of
users, wherein different types of users have access to different services or
data or
different levels of services or data.
[0055] In an example embodiment, the user interface layer 32
provides one or
more websites accessible by users on the Internet. The user interface layer
may
include or operate with at least one (or multiple) suitable network server(s)
to provide
the website(s) over the Internet and to allow access, world-wide, from
Internet-
connected computers using standard Internet browser software. The website(s)
may be
CA 02938541 2016-08-09
accessed by various types of users, including but not limited to subjects,
healthcare
providers, researchers, business entities, healthcare institutions and
organizations,
payor entities, pharmaceutical partners or other sources of pharmaceuticals or
medical
equipment, and/or support personnel or other personnel running the system 16,
depending upon the embodiment of use.
[0056] In another example embodiment, where the DDMS 16 is located on one
computing device 100, the user interface layer 32 provides a number of menus
to the
user to navigate through the DDMS. These menus may be created utilizing any
menu
format, including but not limited to HTML, XML, or Active Server pages. A user
may
access the DDMS 16 to perform one or more of a variety of tasks, such as
accessing
general information made available on a website to all subjects or groups of
subjects.
The user interface layer 32 of the DDMS 16 may allow a user to access specific
information or to generate reports regarding that subject's medical condition
or that
subject's medical device(s) 12, to transfer data or other information from
that subject's
support device(s) 12 to the system 16, to transfer data, programs, program
updates or
other information from the system 16 to the subject's support device(s) 12, to
manually
enter information into the system 16, to engage in a remote consultation
exchange with
a healthcare provider, or to modify the custom settings in a subject's
supported device
and/or in a subject's DDMS/MDMS data file.
[0057] The system 16 may provide access to different optional resources or
activities (including accessing different information items and services) to
different users
and to different types or groups of users, such that each user may have a
customized
experience and/or each type or group of user (e.g., all users, diabetic users,
cardio
21
CA 02938541 2016-08-09
users, healthcare provider-user or payor-user, or the like) may have a
different set of
information items or services available on the system. The system 16 may
include or
employ one or more suitable resource provisioning program or system for
allocating
appropriate resources to each user or type of user, based on a pre-defined
authorization plan. Resource provisioning systems are well known in connection
with
provisioning of electronic office resources (email, software programs under
license,
sensitive data, etc.) in an office environment, for example, in a local area
network LAN
for an office, company or firm. In one example embodiment, such resource
provisioning
systems is adapted to control access to medical information and services on
the DDMS
16, based on the type of user and/or the identity of the user.
[0058] Upon entering successful verification of the user's identification
information and password, the user may be provided access to secure,
personalized
information stored on the DDMS 16. For example, the user may be provided
access to
a secure, personalized location in the DDMS 16 which has been assigned to the
subject. This personalized location may be referred to as a personalized
screen, a
home screen, a home menu, a personalized page, etc. The personalized location
may
provide a personalized home screen to the subject, including selectable icons
or menu
items for selecting optional activities, including, for example, an option to
transfer device
data from a subject's supported device 12 to the system 16, manually enter
additional
data into the system 16, modify the subject's custom settings, and/or view and
print
reports. Reports may include data specific to the subject's condition,
including but not
limited to, data obtained from the subject's subject support device(s) 12,
data manually
entered, data from medical libraries or other networked therapy management
systems,
22
CA 02938541 2016-08-09
data from the subjects or groups of subjects, or the like. Where the reports
include
subject-specific information and subject identification information, the
reports may be
generated from some or all subject data stored in a secure storage area (e.g.,
storage
devices 29) employed by the database layer 28.
[0059] The user may select an option to transfer (send) device data to the
medical data management system 16. If the system 16 receives a user's request
to
transfer device data to the system, the system 16 may provide the user with
step-by-
step instructions on how to transfer data from the subject's supported
device(s) 12. For
example, the DDMS 16 may have a plurality of different stored instruction sets
for
instructing users how to download data from different types of subject support
devices,
where each instruction set relates to a particular type of subject supported
device (e.g.,
pump, sensor, meter, or the like), a particular manufacturer's version of a
type of subject
support device, or the like. Registration information received from the user
during
registration may include information regarding the type of subject support
device(s) 12
used by the subject. The system 16 employs that information to select the
stored
instruction set(s) associated with the particular subject's support device(s)
12 for display
to the user.
[0060] Other activities or resources available to the user on the system 16
may
include an option for manually entering information to the DDMS/MDMS 16. For
example, from the user's personalized menu or location, the user may select an
option
to manually enter additional information into the system 16.
[0061] Further optional activities or resources may be available to the
user on the
DDMS 16. For example, from the user's personalized menu, the user may select
an
23
CA 02938541 2016-08-09
option to receive data, software, software updates, treatment recommendations
or other
information from the system 16 on the subject's support device(s) 12. If the
system 16
receives a request from a user to receive data, software, software updates,
treatment
recommendations or other information, the system 16 may provide the user with
a list or
other arrangement of multiple selectable icons or other indicia representing
available
data, software, software updates or other information available to the user.
[0062] Yet further optional activities or resources may be available to the
user on
the medical data management system 16 including, for example, an option for
the user
to customize or otherwise further personalize the user's personalized location
or menu.
In particular, from the user's personalized location, the user may select an
option to
customize parameters for the user. In addition, the user may create profiles
of
customizable parameters. When the system 16 receives such a request from a
user,
the system 16 may provide the user with a list or other arrangement of
multiple
selectable icons or other indicia representing parameters that may be modified
to
accommodate the user's preferences. When a user selects one or more of the
icons or
other indicia, the system 16 may receive the user's request and makes the
requested
modification.
[0063] Further descriptions of the DDMS/MDMS may be found in U.S. Pat. App.
Pub. No. 2007/0033074, published Feb. 8, 2007, to Nitzan et al. and is
entitled,
'Therapy Management Systemr
[0064] FIG. 2A illustrates a report displaying sensor readings according to
embodiments of the present invention. The report illustrated in FIG. 2A is a
24-Hour
24
CA 02938541 2016-08-09
. .
Glucose Overlay report 200, which may be generated by, for example, the
DDMS/MDMS 16 of FIG. 1, or any other suitable system. One particular example
of a
suitable system is a computer executing Medtronic MiniMed's CARELINKTM Therapy
Management Software, available at carelink.minimed.com. The sample overlay
report
200 illustrates the overlaying of readings and averages of glucose values from
a user
for a 28-day period. In alternative embodiments, longer or shorter periods may
be used,
such as, but not limited to three days, one week, two weeks, three weeks, one
month,
two months, one quarter, six months, one year, or the life of a patient, with
the choice
being made to select a data set that provides a useful period of interest. The
report 200
may also show the readings and averages for less than 24-hours at a time, too.
[0065] Because many people have regular schedules where event
occurrences
such as breakfast, lunch, dinner, afternoon naps, tea times, coffee breaks,
watching the
morning or evening TV news, going to bed for the night (bedtime), etc., occur
each day
and generally occur around the same time of day (or each day during the work
week,
work days only, weekends only, Sundays only, workout days only, etc.),
patterns may
develop based on this regular schedule. Additionally, patterns also may be
analyzed
based on only periodic events/conditions such as but not limited to,
menstruation, non-
work/school days, when administering periodic therapy, exercise, and the like;
and
transient events/conditions such as but not limited to, a temporary illness,
having a cold,
being on a particular medication, stress and anxiety, physical exertion,
vacation days,
holidays, etc.
[0066] By analyzing the average glucose level patterns, trends may
be spotted
that occur for a user relative to specific events in that user's life (e.g.,
breakfast, lunch,
CA 02938541 2016-08-09
. .
dinner, watching the evening news, etc.). For example, referring to the report
200 of
FIG. 2A, we note that for this representative 28-day period, when the user has
lunch at
Noon shown at line 210, this user tends to experience on average a rise in
glucose
levels peaking around 3 PM shown at line 220, three hours after the start of
lunch.
Although average glucose level values are used in connection with FIG. 2A,
according
to embodiments of the present invention, other calculations and data sets such
as
standard deviations, high values, low values, etc. for a period (days, weeks,
months,
quarters, years, etc.), or periodic blocks of time (e.g., every fourth week,
four weeks of
work days, five weekends, non-working days, etc.) may be utilized as well. It
is noted
that glucose patterns often change during menstruation, and patterns for work
days
tend to be different from patterns on non-working days.
[0067] Based on this average pattern and trend, this information
may be passed
along to a doctor or a user, and/or to a DDMS/MDMS, an infusion pump, a
controller/programmer, or any other suitable device, for example, which may
take
proactive measures in recommending and/or automatically delivering a bolus of
insulin
in advance of this predicted rise and peak shown at line 220 (e.g., a
notification event
that the user should be made aware of, and/or to take appropriate action) if a
rise in
glucose levels begins to occur, e.g., an hour after lunch. If the user
normally takes
lunch at Noon but one day is caught in a meeting that runs longer, and the
user takes
lunch at 1 PM instead, the infusion pump (or any other suitable device), for
example,
may make a prediction as to the upcoming rise and peak shown at line 220 based
on
the average glucose level pattern derived from the report 200 of FIG. 2A and
time-shift
the pattern one-hour later, such that it will predict a rise and peak at 4 PM
instead of 3
26
CA 02938541 2016-08-09
. .
PM, and take proactive measures in recommending and/or delivering a bolus in
advance of this predicted rise and peak if it starts to notice a rise in
glucose levels an
hour after taking lunch at 1 PM. Alternatively, the basal rate of insulin
delivery may be
temporarily increased to match this rise and peak following lunch taken at 1
PM, an
hour later than usual (e.g., a "lunch time" basal rate pattern, a "dinner
time" basal rate
pattern, etc.). Further description of an insulin infusion device having the
capability to
deliver time-shifted basal insulin may be found in U.S. Pat. App. Pub. No.
2007/0112298, published May 17, 2007, to Mueller et al. and entitled "External
Infusion
Device with Programmable Capabilities to Time-Shift Basal Insulin and Method
of Using
the Same".
[0068] By predicting the occurrence of a notification event
(e.g., a rise and/or
peak), more accurate treatment and delivery of insulin may be accomplished to
better
keep a user within a preferred glucose level range, but additionally,
occurrences of
severe adverse events (SAEs) may be minimized. Typically, a particular pattern
occurs
just before an SAE occurs, and if the DDMS/MDMS, infusion pump, or other
suitable
device, recognizes the pre-SAE pattern developing, the user may be alerted of
a
potential SAE occurring and preventive measures may be taken to minimize or
eliminate the occurrence of the SAE, even automatically without user input, if
necessary
according to embodiments of the present invention.
[0069] Although an average glucose level pattern for a 24-hour
period may be
used, the 24-hour pattern may be partitioned into multiple patterns anchored
around
triggering events (event occurrences) as reference points, e.g., a pattern for
breakfast to
lunch (morning pattern), a pattern from lunch to dinner (afternoon pattern),
and a pattern
27
CA 02938541 2016-08-09
from dinner to breakfast (evening pattern), for time shifting. Meal times and
meal
boluses (including correction boluses) serve as good triggering events, but
any other
suitable event occurrence (especially those events that occur regularly in a
user's life
around the same time each day) may be utilized as well for the purposes of
establishing
common points of reference for the time-shifting of a pattern. Alarms, for
example, are
often followed by a bolus event, and high glucose level alarms may serve as a
triggering
event occurrence, too. According to embodiments of the present invention, the
patterns
also may be sorted by weekdays only, weekends only, a particular day only
(e.g.,
Wednesdays only), sick days only, exercise/workout days only, etc.
[0070]
Accordingly to embodiments of the present invention, the user may inform
the DDMS/MDMS, infusion pump, controller/programmer, or any other suitable
device,
that he/she is about to have lunch, and the infusion pump, for example, may
acknowledge and record the occurrence of this triggering event to perform any
time-
shifting of a pattern as necessary. Alternatively, the DDMS/MDMS, infusion
pump,
controller/programmer, or any other suitable device may deduce when a meal is
about
to be taken based on a user initiated bolus delivery and the time it occurred
(e.g.,
around 7 AM for breakfast, or around Noon for lunch, etc.). Knowing how much
insulin
was delivered for a meal may be as relevant as knowing the type of meal, for
example,
breakfast, lunch, or dinner, consumed. Moreover, the type of bolus selected
and
administered by the user (e.g., a normal, square wave, dual wave, a correction
bolus,
etc.) along with the type of food ingested at that time may also permit the
DDMS/MDMS, infusion pump, controller/programmer, or any other suitable device
to
deduce that the user may have certain issues with particular foods (e.g.,
fatty foods).
28
CA 02938541 2016-08-09
. .
[0071] By identifying and performing time-shifting of patterns, we
may make
better predictions as to the glucose levels of a diabetic and allow a doctor
to take
proactive measures to provide more accurate treatment to keep more stable
glucose
levels within the desired range. Severe adverse events (SAEs) may be minimized
or
eliminated by recognizing the pre-SAE pattern leading up to SAEs in the past.
The use
of Al c testing may further assist in determining whether glucose levels have
been within
desirable ranges for a longer period of time (e.g., about three months).
According to
embodiments of the present invention, alarms may be set up on an infusion pump
to
match a typical user SAE pattern, and the alarm may sound when such a SAE
pattern is
observed.
[0072] To make a pattern more accurate, anomalous data may be
removed or
filtered from the data points making up the pattern ("clipping"), as the
anomalous data
may not be representative of a person's typical day. For example, referring to
the report
200 of FIG. 2A, if the user had a few days where his/her schedule was
completely
atypical of a regular work day (perhaps flying cross-country on a business
trip), we may
exclude the glucose level readings for these non-routine days as they are not
typical of
a "regular" work day (it is likely that the user had a meal or two during the
business trip,
but, these meals may not have occurred at the same usual times the user
typically has
these meals, and/or the meals may be of different types, portions, etc. that
the user
typically has). That is, rare events and anomalous data generally should not
dictate the
direction of therapy based on patterns. According to embodiments of the
present
invention, the data also may be filtered by a particular day of the week
(e.g., remove all
Wednesday data), a day each month (e.g., remove all data on the 15th), a type
of day
29
CA 02938541 2016-08-09
(e.g., remove all data on exercise/workout days), by particular time of day
(e.g., remove
all data from 12 AM to 3 AM), by a particular week, month, etc., or any
combination
thereof.
[0073] Conversely, there are situations where investigating
outlying/anomalous
events may assist in determining behavioral issues that may have an impact on
the
course of therapy, and determining causes of an outlying event may be helpful
in
reducing these anomalous occurrences that may be detrimental to therapy.
According
to embodiments of the present invention, the data set may also be filtered
such that all
glucose level readings falling into one or more patterns is removed, leaving
only the
anomalous data for analysis.
[0074] The reports/charts illustrated in FIGS. 2B-2K may be representative
of
snapshot screens displayed on a DDMS/MDMS executing, for example, Medtronic
MiniMed's CARELINKTM Therapy Management Software, or any other suitable
software, as described in connection with FIG. 1 above, to assist a doctor in
planning a
course of treatment (and in some instances, accessible to a user, too).
Although the
charts illustrated in FIGS. 2B-2I and 2K show the glucose readings from 11 AM
to 9 PM,
longer or shorter periods may be displayed according to embodiments of the
present
invention. The charts in FIGS. 2B-2I and 2K, as illustrated, may be portions
of the 24-
hour report illustrated in FIG. 2A. For instance, in other embodiments, a 1-
hour, 2-hour,
3-hour, 4-hour, 5-hour, 6-hour, 7-hour, 8-hour, 9-hour, 10-hour, 11-hour, or
12-hour
portions of a 24-hour day report may be used, and 2 days, 3 days, 4 days, 5
days, 6
days, a week, 2 weeks, 3 weeks, 4 weeks, a month, a quarter, or the like
reports may
be used as well.
CA 02938541 2016-08-09
[0075] Although only four representative glucose reading lines are
illustrated in
each of FIGS. 2B-2J, an actual chart viewed by a doctor often displays many
more lines
(20 to 30, or more), and while only four lines are represented in FIGS. 26-2J
to simplify
and make the charts easier to read for illustrative purposes, according to
embodiments
of the present invention, any number of lines may be overlaid on the charts.
Lines 252,
254, 256, and 258 in FIG. 2B (and similarly for the corresponding lines in
FIGS. 2C-2J)
may each represent raw glucose level readings for a day, filtered, smoothed,
etc.
readings for a day, several days, weeks, months, etc., or any combination
thereof. A
chart including the average value of the raw glucose level readings, standard
deviation
(once the average has been determined), high-low lines, etc., for example, as
illustrated
in FIG. 2K and discussed in further detail below, also may be generated.
[0076] According to embodiments of the present invention, additional data
may
be further shown in the charts of FIGS. 2B-2K as well, for example, a basal
insulin
profile and a bolus delivery graph. Moreover, a doctor or user may select any
one of
the readings (e.g., lines 252, 254, 256, 258 in FIG. 213) displayed on the
charts by the
DDMS/MDMS to obtain further data associated with the selected reading (e.g.,
high/low
values, averages, standard deviation, number of meter reads, total insulin,
number of
boluses, prime volume, time in temporary basal, time in suspension, etc.),
which may be
displayed on a separate screen. Further description of data that may be
displayed on a
screen by the DDMS/MDMS may be found in U.S. Pat. App. Pub. No. 2002/0193679,
published Dec. 19, 2002, to Malave et al. and entitled "Communication Station
and
Software for Interfacing with an Infusion Pump, Analyte Monitor, Analyte
Meter, or the
Like".
31
CA 02938541 2016-08-09
[0077] Generally speaking, the more data that is available to a doctor, the
more
accurate and better the treatment may be planned for a user. However, the more
data
that is displayed on a screen at once (e.g., daily 24-hour glucose sensor
readings for a
three-month period will have over 90 lines moving up and down the chart), the
more
difficult it is for a doctor or other viewer to read and comprehend,
especially if the data
does not readily appear to convey any trends or patterns on which a doctor may
base a
course of treatment. Having more data available also increases the chances
that more
"noise" data will be introduced into the overall data set. In particular, a
doctor using a
DDMS/MDMS displaying a glucose readings overlay report (e.g., as in FIG. 2A)
may
have data spanning a period of days, weeks, months, and/or years for a single
patient.
This amount of data displayed on a screen all at once is overwhelming,
confusing, and
difficult to read and understand without some filtering and organization. This
raw data
becomes not particularly useful on its face without further analysis. No
meaningful
treatment plan may be formulated based on a chart of numerous glucose
readings,
such as shown in FIG. 2A, that seemingly has no relation to each other. If the
numerous glucose level readings displayed may be sorted, for example, by
similar like
patterns, and/or around particular event occurrences (e.g., breakfast, lunch,
or dinner),
the doctor will have a more meaningful chart where certain glucose level
patterns may
be perceived on which he/she may develop a course of treatment.
[0078] As discussed above, many people have regular schedules where event
occurrences such as breakfast, lunch, dinner, afternoon naps, tea times,
coffee breaks,
watching the morning or evening TV news, going to sleeping/bedtime, waking up,
etc.,
that tend to occur each day and generally around the same time of day (or each
day
32
CA 02938541 2016-08-09
during the work week, work days only, weekends only, Sundays only, workout
days
only, etc.). Knowing when these events occur is particularly helpful in
analyzing the raw
data. Using these events (e.g., breakfast, lunch, dinner, watching the evening
news,
etc.) as markers and reference/anchoring points in time (e.g., starting
points, mid-points,
end points) to adjust or filter the glucose level readings amongst all of the
readings
relative to each common event occurrence will allow an analysis where trends
and
patterns may be perceived. In one representative example according to
embodiments
of the present invention, the glucose level readings may be lined up starting
from when
the user initiates a lunch time meal bolus, a correction bolus, a particular
bolus type
(e.g., normal, square wave, dual wave), etc., and the DDMS/MDMS may analyze
the
glucose level readings from the start of the meal bolus (e.g., up to the start
of the next
common event occurrence of, e.g., a dinner time meal bolus) to determine
whether
patterns exist, take an average reading, etc. The glucose level readings also
may be
lined up based on any suitable event occurrence, including but not limited to
meal
boluses, correction boluses, meal times, bedtimes, exercise, intake of
medications, etc.
The readings may be shifted and lined up on an existing time scale, for
example, as
illustrated in FIG. 2C, or according to embodiments of the present invention,
using a
relative time scale zeroed to the start of a particular event occurrence, for
example, as
illustrated in FIG. 2J and discussed in further detail below.
[0079] The DDMS/MDMS may generate a variety of patterns from the glucose
level readings anchored around particular event occurrence(s). Glucose level
readings
that seem to fall outside of any particular pattern (e.g., anomalous readings)
may be
further analyzed, or filtered out and discarded. Alternatively, only the
anomalous
33
CA 02938541 2016-08-09
,
readings may be shown. Suitable pattern recognition algorithms (e.g., utilized
in
defense/weapon systems, astronomy, computer science, etc.) may be modified to
be
used to analyze the plurality of glucose level readings for a user, and
according to
embodiments of the present invention, to analyze the readings after each
common
event occurrence amongst all or most of the readings to determine whether any
patterns or trends exist.
[0080] The pattern recognition algorithm may recognize a seemingly
"anomalous"
glucose level reading that fits a particular pattern or shape formed by a
plurality of other
glucose level readings around a particular event occurrence (e.g., a pattern
formed by
the readings starting when the user takes lunch each day). This anomalous
reading
may appear to be, for example: (1) skewed a couple hours ahead of or behind
the
particular pattern, (2) having a greater positive and/or negative magnitude
than the
particular pattern, (3) compressed or stretched in time than the particular
pattern, (4)
skewed upwards or downwards from the basal glucose level of the particular
pattern, or
any combination thereof. By recognizing a potential glucose level reading
falling "out-
of-pattern" from a particular pattern formed by the other glucose level
readings, this out-
of-pattern reading may be adapted to fit with the rest of the glucose level
readings
forming the pattern by making adjustments to the out-of-pattern glucose level
reading,
thus preserving that glucose level reading for analysis.
[0081] Alternatively, the out-of-pattern glucose level reading may be
analyzed on
its own merits to determine potential causes of such an out-of-pattern reading
and any
other potential issues associated therewith, which may be helpful in learning
the
behavior of a user and in making any adjustments to his/her therapy as
necessary to
34
CA 02938541 2016-08-09
minimize further out-of-pattern readings. Moreover, the patterns may be in
themselves
further sorted and filtered by the types of readings forming the patterns, for
example, a
"weekday only" pattern (formed from weekday only readings), a "weekend only"
pattern
(formed from weekend only readings), "Wednesdays" pattern (formed from
Wednesdays only readings), etc.
[0082] Although the existence of an event occurrence as a marker for a
glucose
level reading is helpful in establishing a reference point for the pattern
recognition
software to analyze for patterns, an event occurrence is not always necessary
for the
pattern recognition software and may not always be available for each glucose
level
reading. It is possible that a meal/correction bolus event occurrence was not
recorded
by, for example, the infusion device or controller/programmer, because the
user self-
administered a bolus with a manual shot via a needle and syringe. Secondly,
the user
may have forgotten to enter an exercise event occurrence marker when the user
exercised. Thirdly, the user may have just missed administering a bolus,
leaving no
event occurrence marker of one, or the bolus may have been administered but
was not
recorded. The administered bolus may have been the wrong type, too much, too
little,
etc., such that it makes the event occurrence marker corresponding to that
administered
bolus unhelpful for purposes of analysis.
[0083] Even absent an event occurrence marker in the glucose level
readings,
the pattern recognition software may still analyze a glucose level reading,
for example,
by determining whether there is a match in the rising/falling slope of the
reading, in the
overall shape of the reading, the overall size/magnitude of the reading, etc.,
with other
CA 02938541 2016-08-09
glucose level readings, with or without event occurrence markers, forming a
particular
pattern.
[0084] As illustrated in the simplified representative glucose overlay
chart of FIG.
2B, four representative glucose level reading lines 252, 254, 256, 258 are
shown. By
analyzing the data in the chart of FIG. 2B, the DDMS/MDMS may determine that a
pattern of two small successive dips followed by a large rise in glucose
levels exist for
lines 252, 254, 256, and 258. This particular pattern of dips and rises is
merely an
illustrative example, and according to embodiments of the present invention,
any other
patterns and types of patterns may be analyzed. Line 258 appears to be an
anomaly
such that its two small successive dips followed by a rise occur a couple
hours later
than at lines 252, 254, 256, but otherwise follows a similar shape as the
pattern formed
by lines 252, 254, 256.
[0085] To use as much of the available data as possible, the DDMS/MDMS may
try to adapt or "fit" the anomalous data to an existing pattern(s). By
recognizing the
general pattern formed by lines 252, 254, 256 and that of anomalous line 258,
the
DDMS/MDMS may determine that by shifting the anomalous line 258 back two hours
in
time (to match the data obtained when the user typically takes lunch), as
illustrated in
FIG. 2C, the reading of line 258 generally conforms with the pattern
established by lines
252, 254, 256, especially from the period of Noon to 7 PM. The time-shifting
may be
performed, for example, if we knew that the user took lunch two hours later at
2 PM
than his/her usual time at Noon when the reading for line 258 was taken
(discussed in
further detail below). By time-shifting line 258, an additional set of data
may be utilized
for analysis. The doctor may see that the user tends to rise and peak around 3
PM, and
36
CA 02938541 2016-08-09
a course of treatment may be tailored towards this trend and attempt to reduce
this
spike and keep the glucose levels more stable and within the desired range.
[0086] The DDMS/MDMS may automatically attempt to conform data sets (e.g.,
each glucose level reading) to an entire 24-hour period, or any portion
thereof, e.g., to
generate a "morning" pattern, "afternoon" pattern, "evening" pattern, or the
like. The
patterns are more robust if more data is available, and by conforming
anomalous data
to existing data sets for a pattern, the therapy may be more accurate. In a
perfect
situation (but not likely), every glucose level reading falls into at least
one pattern, with
or without adjustment of the glucose level readings by the DDMS/MDMS. Having a
chart of organized patterns for all or most of the data greatly assists the
doctor in
observing trends and preparing the best course of treatment for the user.
However, if
anomalous data cannot be properly conformed, that is, it does not appear to
fit any of
the patterns, the anomalous data may be filtered out and not utilized in the
analysis.
For example, the adapted time-shifted pattern in the chart of FIG. 2C may be
utilized to
generate an average "afternoon" pattern for analysis by a doctor to help the
user in
keeping stable glucose levels and within the desired range. Additionally,
general trends
or ideal patterns may be overlaid onto an existing report to show how close
the user is
to such ideal or population average levels, and to highlight areas where the
user may
want to make changes affecting his/her glucose levels.
[0087] Moreover, according to embodiments of the present invention, a
doctor or
user may select the criteria and parameters to filter and analyze the glucose
level
readings. A doctor or user may also select whether a particular pattern should
be
included or excluded from analysis. According to embodiments of the present
invention
37
CA 02938541 2016-08-09
and as discussed above, a doctor or user may click on any one of the glucose
level
readings (e.g., lines 252, 254, 256, 258 in FIG. 2B) and obtain further data
relating to
this selected reading, and enter notes or comments regarding this selected
reading that
may be stored by the DDMS/MDMS (e.g., indicating an unmarked event,
explanation of
a particular behavior, etc.). Alternatively, a doctor or user may select/click
one or more
of the displayed lines and delete them for the purposes of not including the
selected
lines in the analysis (e.g., to generate the average, standard deviations,
etc.). For
example, the clinician may realize that some days have very unusual data due
to
unusual circumstances in the patient's life, such as, e.g., stress due to a
car accident,
an emotional event, unusual physical exertion, unusual meals due to a
celebration or
travel, and the like. By eliminating these unusual data sets, the usual data
sets remain,
which the clinician may use to analyze and plan a course of therapy.
[0088] The
glucose level analysis may be further enhanced if we know, by direct
user input (e.g., setting a "lunch" event occurrence marker) or inferred from
a user
action (e.g., administering a meal bolus in the afternoon to have lunch), that
the user
took lunch at Noon on the days (weeks, months, etc.) that lines 252, 254, 256
were
read; and that for line 258, the user took lunch a couple hours later around 2
PM versus
at Noon. Additionally, the DDMS/MDMS may recognize that line 258 follows a
particular pattern and/or shape that falls within a "lunch time" pattern, and
a start time of
when the user took lunch for that particular line 258 may also be inferred and
calculated
based on pattern recognition algorithms according to embodiments of the
present
invention. This type of information would further strengthen the pattern
recognition and
filtering scheme performed by the DDMS/MDMS in generating an "afternoon"
pattern
38
CA 02938541 2016-08-09
anchored around when the user takes lunch. For example, an understanding or
analysis may be developed to reduce the rise and peak that occurs about two
hours
after the user eats in the afternoon, whether it is always at Noon, or at
another time, for
example, by setting a temporary basal rate to be utilized when taking lunch to
reduce
the observed rise and peak.
[0089] FIG. 2J illustrates an adapted time-shifted sample report displaying
sensor
readings from FIG. 20 utilizing a relative time line according to embodiments
of the
present invention. A relative time line chart, fixed at, for example, an event
occurrence
such as a meal bolus, start of lunch (line 210), etc., may be generated by the
DDMS/MDMS for analysis by a doctor. A notification event occurring after a
time span
from an event occurrence, and anomalies, are more readily discernible using a
relative
time line chart as in FIG. 2J. Any time increments other than one hour (e.g.,
2-hours,
minute(s), day(s), week(s), month(s), quarter(s), year(s), etc.) and for any
period in time
may be utilized, too. According to embodiments of the present invention, the
relative
time line chart of FIG. 2J may be equally applicable to any of the charts
illustrated in
FIGS. 2A-2I and 2K.
[0090] FIG. 2K illustrates a report showing an average glucose level
reading,
standard deviation, and high-low lines for the adapted time-shifted report of
FIG. 20
according to embodiments of the present invention. The DDMS/MDMS may generate
a
chart displaying an average glucose reading 292 based on the adapted glucose
level
readings 252, 254, 256, 258 of FIG. 20. Once an average is determined, the
DDMS/MDMS may also present the standard deviation lines 294, 296 as
illustrated in
FIG. 2K according to embodiments of the present invention. Furthermore, high-
low
39
CA 02938541 2016-08-09
lines 298 of the adapted glucose level readings of lines 252, 254, 256, 258 of
FIG. 20
also may be generated. Any other types of data calculations other than those
discussed above also may be performed by the DDMS/MDMS and displayed for
review
by a doctor or user. According to embodiments of the present invention, the
display of
average glucose level readings, standard deviation, and high-low lines, as in
the chart
of FIG. 2K, independently, combined, or with other data calculations may be
equally
applicable to any of the charts illustrated in FIGS. 2A-2J. For example, an
average of a
group of lines may be calculated, and then the error for each line compared to
the
average may be calculated. One method of calculation involves calculating the
average
line using all but one of the lines, and then calculate the error between the
average and
the line that was ignored; this process is repeated for all the groups of
lines, and then
the lines with the greatest errors may be determined. If a particular line or
group of lines
have significantly greater errors compared to the average, then the average
may be
recalculated by omitting these lines that have greater errors compared to the
average.
These lines having greater errors may be automatically removed from analysis,
or they
may be highlighted such that a clinician may elect to keep or remove them from
analysis. Analysis on only the lines having greater errors may be also
performed, too.
[0091] FIG. 2D illustrates a sample report displaying sensor readings
according
to embodiments of the present invention. Similar to the chart of FIG. 2B
above, the
chart of FIG. 2D shows three representative lines 262, 264, 266 forming a
general
pattern, with anomalous line 268 showing an extremely high rise and peak at
around 3
PM and a long downward crash towards 8 PM. By analyzing the data in the chart
of
FIG. 2D, the DDMS/MDMS may determine that anomalous line 268 exhibits a
similar
CA 02938541 2016-08-09
pattern as formed by lines 262, 264, 266, except that the glucose level
readings of line
268 are more acute and severe in the magnitude of the rise and fall of the
glucose
levels. Due to any set of events for the particular day (week, month, etc.)
that the
reading for line 268 was taken, the user may have been particularly sensitive
to foods
ingested, the user administered a different meal bolus dosage, etc., and
caused the
anomalous reading of line 268. Alternatively, the anomalous reading of line
268 may
have been caused by a hardware issue, for example, by a bias or an overly-
sensitive
sensor, or by improper operation by the user that exaggerated the readings, or
the
sensor was mis-calibrated by the user. A hardware issue may be identified, for
example, if a set of readings obtained from when the sensor was placed on the
user all
exhibited similar increased magnitudes, or if there is a known sensitivity
with a particular
sensor lot number.
[0092] One way of determining whether a sensor may be overly sensitive or
whether there might have been a calibration issue is to analyze the raw
electrical
current signal values (lsig) received from the sensor (typically, the higher
the Lig value,
the higher levels of glucose detected). These values may be stored by, for
example,
the DDMS/MDMS or any other suitable system. For example, if the Isig values
from
which the anomalous reading of line 268 was derived was consistent with and
matches
the range of the Lig values for lines 262, 264, 266, a mis-calibrated sensor
may be at
issue. But if the Isig values for anomalous line 268 are not consistent with
the Lig values
for lines 262, 264, 266, for example, if the Isig values for line 268 also
share the
increased magnitudes like line 268 relative to the Lig values for lines 262,
264, 266, then
it is possible that the sensor hardware has a bias or is overly sensitive.
41
CA 02938541 2016-08-09
[0093] By recognizing the general pattern formed by lines 262, 264, 266 and
that
of anomalous line 268, the DDMS/MDMS may determine that by compressing the
anomalous line 268 towards the center target range of desired glucose levels
(70 mg/dL
to 140 mg/dL), as illustrated in FIG. 2E, the reading of line 268 generally
conforms to
the pattern formed by lines 262, 264, 266, especially from the period of Noon
to 7 PM.
For example, if it is determined that the sensor used to obtain the anomalous
reading of
line 268 was overly sensitive and was providing exaggerated readings in
magnitude,
compressing anomalous line 268 would normalize this reading to one that would
have
been obtained had a normally sensitive sensor been used. By compressing line
268 in
both directions inwards towards the desired glucose level range, an additional
set of
data, which was previously considered anomalous and potentially filtered out
and
excluded, may be included for analysis.
[0094] As discussed above with respect to FIGS. 2B and 2C, the analysis may
be
further enhanced if we know, by direct user input (e.g., setting a "lunch"
event
occurrence marker) or inferred from a user action (e.g., administering a meal
bolus in
the afternoon to have lunch), that the user took lunch at Noon on the days
(weeks,
months, etc.) that lines 262, 264, 266, 268 were read. This type of
information would
further strengthen the pattern recognition and filtering scheme performed by
the
DDMS/MDMS in knowing that the reading of line 268 was consistent in time with
when
the user typically took lunch and that time-shifting in this instance may be
unnecessary
in the present example (see, e.g., FIG. 2D, that the user may have been just
particularly
sensitive to foods ingested when the reading of line 268 was taken,
underestimated the
insulin bolus required for a meal, delayed a bolus of insulin until the
glucose level was
42
CA 02938541 2016-08-09
,
already increasing, or that an overly sensitive, improperly operated, or mis-
calibrated
sensor was used), in generating the adapted glucose-level-compressed chart of
FIG.
2D.
[0095] FIG. 2F illustrates a sample report displaying sensor readings
according to
embodiments of the present invention. Similar to the charts of FIGS. 2B and 2D
above,
the chart of FIG. 2F shows three representative lines 272, 274, 276 forming a
general
pattern, with anomalous line 278 showing a rise and peak within about an
hour's time,
as opposed to about two hours for lines 272, 274, 276. By analyzing the data
in the
chart of FIG. 2F, the DDMS/MDMS may determine that anomalous line 278 exhibits
a
similar pattern as formed by lines 272, 274, 276, except that the readings of
line 278
appear to have the glucose levels rise and fall at a more rapid rate. Due to
any set of
events for the particular day (week, month, etc.) that the reading for line
278 was taken,
the user experienced a more rapid rise and fall of glucose levels (e.g., eaten
lunch in a
quarter of the time as usual, ate a different portion and/or type of food,
etc.) in the
afternoon that caused the anomalous reading of line 278.
[0096] By recognizing the general pattern formed by lines 272, 274, 276
and that
of anomalous line 278, the DDMS/MDMS may determine that by stretching the
anomalous line 278 in time, as illustrated in FIG. 2G, the reading of line 278
generally
conforms to the pattern formed by lines 272, 274, 276, especially from the
period of
Noon to 7 PM. According to embodiments of the present invention, we are
interested
analyzing a "typical" lunch pattern in the present example, and the time-
stretching of line
278 would normalize this reading to one that would have been obtained had a
typical
lunch been taken. Alternatively, a separate analysis may be performed on the
43
CA 02938541 2016-08-09
. ,
anomalous line 278 itself, or in combination with other readings. By time-
stretching line
278, an additional data set, which was previously considered anomalous and
potentially
filtered out and excluded, may be included for analysis.
[0097] FIG. 2H illustrates a sample report displaying sensor
readings according
to embodiments of the present invention. Similar to the charts of FIGS. 2B,
2D, and 2F,
the chart of FIG. 2H shows three representative lines 282, 284, 286 forming a
general
pattern, with anomalous line 288 having generally skewed high glucose levels.
By
analyzing the data in the chart of FIG. 2H, the DDMS/MDMS may determine that
anomalous line 288 exhibits a similar pattern as formed by lines 282, 284,
286, except
that the readings of line 288 are mostly above the desired glucose levels for
the entire
period illustrated in the chart of FIG. 2H. Due to any set of events for the
particular day
(week, month, etc.) that the reading for line 288 was taken, the user was
having high
glucose baseline levels that caused the anomalous reading of line 288. For
example,
the user may have set a lower basal insulin rate/pattern, which caused all of
the glucose
level readings to skew upwards on the higher end since the user made the basal
insulin
rate/pattern change.
[0098] Alternatively, according to embodiments of the present
invention, the
DDMS/MDMS may detect that the glucose level readings for the past few days
have
been skewed on the high side, which may infer that there may be a problem with
the
sensor (e.g., the sensor may be overly sensitive, improperly operated, mis-
calibrated,
etc.), and the user may be alerted to check the sensor to make sure that it is
functioning
properly. Any suitable techniques to diagnose a potentially overly sensitive
or
44
CA 02938541 2016-08-09
improperly operated sensor, or identify a mis-calibration, including analyzing
the Lig
values as discussed above with respect to FIGS. 2D and 2E, may be utilized.
[0099] By utilizing pattern recognition algorithms to determine the general
pattern
formed by lines 282, 284, 286 and that of anomalous line 288, the DDMS/MDMS
may
determine that by shifting downwards the anomalous line 288 towards the center
target
range of desired glucose levels (as the user was "running high" due to being
ill or under
stress, or perhaps due to an overly sensitive, improperly operated, or mis-
calibrated
sensor, or a lowered basal insulin rate, etc.), as illustrated in FIG. 21, the
reading of line
288 generally conforms to the pattern formed by lines 282, 284, 286,
especially from the
period of Noon to 7 PM. By shifting downwards line 288, an additional data
set, which
was previously considered anomalous and potentially filtered out and excluded,
may be
included in the analysis.
[00100] Although the anomalous lines 258, 268, 278, 288 in FIGS. 2B and 2C,
2D
and 2E, 2F and 2G, and 2H and 21, respectively, were adapted by the DDMS/MDMS
by
making a single adjustment (i.e., time-shift, compress by glucose level,
stretch by time,
shift by glucose level) to the anomalous lines 258, 268, 278, 288, according
to
embodiments of the present invention, the DDMS/MDMS may make more than a
single
adjustment (e.g., time-shift and compress by glucose level, stretch by time
and shift by
glucose level, etc., or any combination thereof), and/or make other types of
adjustments
than those discussed above, to one or more of the lines as appropriate.
Moreover,
these adjustments may be made for glucose level readings in any other time
period
other than from 11 AM to 9 PM, as illustrated in FIGS. 2B-2I and 2K, too. An
anomalous reading not adapted to a pattern by the DDMS/MDMS may be filtered
out
CA 02938541 2016-08-09
and excluded from analysis, or analyzed separately, independently or with
other
readings.
[00101] FIG. 3 illustrates a flowchart for applying pattern recognition and
filtering
algorithms for diabetes analysis according to embodiments of the present
invention.
According to embodiments of the present invention, a method of diabetes
analysis
includes, at step 310, receiving a plurality of glucose level readings for a
user. The
glucose level readings (e.g., daily 24-hour glucose level readings for a
plurality of days
as in FIG. 2A) may be obtained via a DDMS/MDMS system as discussed with
respect
to FIG. 1 above, or by any other suitable methods and means. According to
embodiments of the present invention, the data used for analysis may exclude
data
from the most recent days. For example, if a user is learning a new behavior,
then the
most recent days may not generate the same patterns as previously, and data
from a
more consistent time in a user's life may generate more useful patterns for
analysis and
treatment planning. At step 320, a common event occurrence in at least two of
the
glucose level readings is determined. These common event occurrences may be
used
as reference/anchoring points in time (e.g., starting points, mid-points, end
points) to
analyze the glucose level readings amongst all of the readings relative to
each common
event occurrence, and trends and patterns may be perceived as to certain
tendencies
that may occur for a user relative to these specific event occurrences in that
user's life
(e.g., breakfast, lunch, dinner, watching the evening news, delivering a meal
or
correction bolus, etc.).
[00102] At step 330, the at least two glucose level readings from the
common
event occurrence onwards in time for a time period is analyzed to determine,
at step
46
CA 02938541 2016-08-09
. .
,
,
340, whether there is at least one glucose level pattern formed by the at
least two
glucose level readings having a similar shape. By analyzing the data, for
example, in
the representative charts illustrated in FIGS. 2B-2K, the DDMS/MDMS may
determine
that a pattern having a similar shape of two small successive dips followed by
a large
rise in glucose levels exist for several of the glucose level readings. This
particular
pattern of dips and rises is merely an illustrative example, and according to
embodiments of the present invention, any other patterns and types of patterns
may be
analyzed.
[00103] At step 350, at least one anomalous glucose level reading
having the
similar shape and not conforming to the glucose level pattern is analyzed. For
example,
referring to FIGS. 2B-2J, glucose level reading lines 258, 268, 278, 288
appear to be
anomalies such that they generally share the similar shape and slopes as with
the
remaining glucose level readings in their respective charts, but these
anomalous lines
do not conform to the pattern formed by the other glucose level readings in
their
respective charts. The at least one anomalous glucose level reading may be
adapted to
the pattern, at step 360, by the DDMS/MDMS to form an adapted glucose level
pattern,
for example, as illustrated in FIGS. 2C, 2E, 2G, 21. According to embodiments
of the
present invention, at step 370, an insulin dosage for the time period
beginning at the
common event occurrence may be calculated based on the adapted glucose level
pattern.
[00104] FIG. 4 illustrates a flowchart for analysis of diabetes
information according
to embodiments of the present invention. According to one embodiment of the
present
invention, a method of analysis using time-shifted patterns of average glucose
level
47
CA 02938541 2016-08-09
information includes, at step 410, obtaining average glucose level information
for a time
period over a plurality of days. A chart, for example, like in FIG. 2A, of
overlapping
glucose level information for a period of days (e.g., 28-days in FIG. 2A) to
obtain
average glucose level information for a 24-hour time period may be utilized.
Next, at
step 420, a current event occurrence is determined (e.g., breakfast, lunch, or
dinner,
watching the morning/evening TV news, having afternoon tea, etc.).
[00105] Assuming that the user is about to have lunch (the current event
occurrence), at step 430, an event occurrence (i.e., lunch at Noon shown at
line 210 in
FIG. 2A) in the average glucose level information within the time period
corresponding
to the selected current event occurrence (i.e., lunch now) is determined. The
current
event occurrence (lunch now) is at a different time of day than the event
occurrence.
For example, the user took lunch at Noon every day in the 28-day report of
FIG. 2A, and
the average glucose level information in FIG. 2A reflects that the user took
lunch at
Noon each day during this 28-day period. However, in the present example, the
user
was caught in a business meeting that ran long and the user is now taking
lunch an
hour later that usual, at 1 PM. Embodiments of the present invention are also
applicable if the current event occurrence occurs earlier than the event
occurrence in
the average glucose level information (e.g., the user took lunch at 11:30 AM
instead of
Noon).
[00106] At step 440, the average glucose level information starting in time
from the
event occurrence (i.e., lunch at Noon shown at line 210 in FIG. 2A) within the
time
period is analyzed. That is, the average glucose level information pattern
from the
event occurrence onwards is analyzed to determine whether there is, at step
450, a
48
CA 02938541 2016-08-09
notification event in the average glucose level information starting in time
from the event
occurrence within the time period. For example, the average glucose level
information
in FIG. 2A is analyzed to see whether there is a notification event (i.e., a
significant,
alarm, or any other event that may be of interest to the user, a medical
professional,
researcher, etc.). In the example illustrated in FIG. 2A, we note that there
is a pattern in
which the user's average glucose level tends to rise and peak shown at line
220 about
three hours after the start of lunch at Noon shown at line 210, constituting a
notification
event in the present example.
[00107] Based on the time-shifted pattern according to embodiments of the
present invention, at step 460, a current notification event in time from the
current event
occurrence (i.e., lunch now at 1 PM) is predicted based on a time span from
the event
occurrence (lunch at Noon shown at line 210 from report 200 in FIG. 2A) and
the
notification event (rise and peak shown at line 220 in FIG. 2A) from the
average glucose
level information in FIG. 2A. In the present example, the user took lunch at 1
PM
instead of the usual Noon lunch time, and given that the 28-day average
glucose level
pattern in FIG. 2A shows a rise and peak at line 220 occurring three hours
after the start
of lunch at Noon shown at line 210, according to embodiments of the present
invention,
this pattern starting at lunch at Noon shown at line 210 onwards may be time-
shifted an
hour later to predict that a similar current notification event of a rise and
peak three
hours following the start of lunch would be approximately 4 PM. From this
prediction, at
step 470, an action may be initiated in advance of the predicted current
notification
event that is forecasted to occur around 4 PM, three hours after starting
lunch at 1 PM.
49
CA 02938541 2016-08-09
[00108] Accordingly, in the present example as illustrated in FIG. 2A, the
average
glucose level pattern shows that a rise starts at 1 PM, an hour after the
start of lunch at
Noon shown at line 210. Therefore, if the user in this instance started lunch
at 1 PM, an
hour later than usual, an action may be taken to alert the user of a predicted
rise that
will start at approximately 2 PM, an hour after taking lunch. The user may be
instructed
to temporarily increase the basal rate for the next few hours or to deliver a
bolus to
minimize the rise and peak as predicted from the time-shifted average glucose
level
pattern (e.g., the "afternoon" pattern), or if so configured, to automatically
increase the
insulin delivery rate (basal or temporary) or administer a bolus, during this
predicted rise
and peak period so as to keep the user's glucose levels as stable as possible
and within
the desired glucose level range.
[00109] A pattern that may be time-shifted may constitute the entire 24-
hour period
of the average glucose levels, as illustrated in FIG. 2A, or any portion
thereof. For
example, the 24-hour period may be partitioned into three patterns for time
shifting
purposes, corresponding to three main meals per day (breakfast, lunch, and
dinner),
each pattern beginning at the start of an event occurrence (breakfast, lunch,
or dinner)
and ending right before the start of the next event occurrence. Referring to
FIG. 2A, if
we know that the user usually has breakfast at 6 AM shown at line 240, then
one
pattern may constitute the average glucose levels from 6 AM to Noon (the
breakfast/morning pattern), and then a second pattern may constitute the
average
glucose levels from Noon (lunch time shown at line 210) to 7 PM (the
lunch/afternoon
pattern), and lastly a third pattern may constitute the average glucose levels
from 7 PM
(dinner time shown at line 230) to 6 AM the next day (the dinner/evening
pattern). Each
CA 02938541 2016-08-09
of these three patterns may be used for time-shifting purposes to predict
potential
notification events; a single 24-hour pattern or any portion thereof, divided
into any
number of patterns, corresponding to any suitable event occurrence, may be
utilized
according to embodiments of the present invention. Insulin dosage/delivery
patterns
may be programmed, e.g., in an insulin pump or any other suitable device, to
match the
representative patterns generated above, such that the user may be able to
select, for
example, a "breakfast", "lunch", or "dinner" insulin delivery pattern at the
appropriate
time or event to deliver insulin to keep the user's glucose levels as stable
as possible
and within the desired range.
[00110] Patterns and time lines are often helpful in linking causes to
effects.
Rates of change (e.g., what is the highest point we can reach before we need
to make a
correction) are often helpful in determining a significant or triggering
event.
Inappropriate alarm settings, for example, may lead to behaviors that may be
detrimental to therapy. Inappropriate alarm settings may be ignored by the
user, and
then when a real critical alarm event occurs, the user may ignore this
important alarm
event as well (i.e., "crying wolf"). Therefore, making sure that the data is
accurate is
important in reducing the occurrence of inappropriate false alarms that may
train "bad"
behaviors in the user.
[00111] Factors that may influence the data quality used to develop a
treatment
plan may include: use of finger sticks to determine glucose levels, use of
glucose
sensors, use of accurate carbohydrate estimate counts, use of properly placed
markers
such as meal, activity, medication, stress, etc., and accurate insulin
delivery. Most of
these factors provide enough data in themselves that treatment plans based on
these
51
CA 02938541 2016-08-09
. .
,
factors are generally reliable. Other factors that may influence the data
quality and a
user's adherence to the treatment plan may include: how often an infusion set
is
changed, how often calibration of the various medical devices are performed,
common
deceptions (e.g., overpriming an infusion pump), quality of the bolus
calculator
recommendations and overrides applied by the user. If a user is not following
the bolus
calculator recommendations, then a doctor may infer that the settings for the
bolus
calculator are not accurate and/or helpful, and may be prompted to reset them
to be
more accurate.
[00112] Various effects or conditions may result due to different
treatment actions
or causes, including hyperglycemia and hypoglycemia (both of which may
influence
pattern strength and pattern severity), and rising and falling glucose levels,
including
sharp spikes and drops (which may result from "unmarked" meals). Actions or
causes
for these varies conditions or effects applied in treatment may include: the
basal
(pattern) vs. bolus (impulse) settings, which in turn are influenced by the
bolus impulses
administered, use of carbohydrate ratios, a person's insulin sensitivity, the
active insulin
already administered to a person, as well as the time of day (e.g., late
afternoon,
evening, etc.), and whether or not a person is active or ill, under stress,
etc. Delivery of
a bolus resulting from a bolus calculator recommendation, suspension of
delivery of
insulin, or setting a temporary basal rate may also have effects on a person's
glucose
levels. Alarms may be tied to the occurrence of varies events, too.
[00113] If a database of "Bolus Type = Effect" information is
available, some
predictions may be made such that when a person encounters a particular event
or
pattern, based on the database information and recognizing the event or
pattern
52
CA 02938541 2016-08-09
occurring, a particular bolus type that can mitigate the undesired event or
pattern may
be recommended based on past data from the user or a plurality of users.
Additionally,
if the user exhibits a particular glucose level pattern following a particular
event or
activity, e.g., a meal, an 20-minute afternoon nap, a particular type of
exercise, etc., we
may adjust the user's basal rate (especially if we know the user's current
insulin-on-
board and glucose level) based on the observed patterns in advance of the user
performing the particular activity, e.g., doing three sets of 15 pull-ups,
running a mile on
the treadmill at a 6.5 MPH pace, etc., to keep the user's glucose levels as
stable as
possible and within the desired range.
[00114] Other methods of managing therapy may include the use of a "virtual
patient". A virtual patient is a digital model of an actual human patient on a
computer to
simulate different ways diabetes, or any other medical condition, affects the
body, and
how various treatments may potentially affect the virtual patient. Virtual
patients may
help cut the time and costs of development and testing of new treatment plans.
For
example, by knowing a patient's insulin sensitivity (everyone has different
insulin
sensitivities, and for Type I diabetics, e.g., they are often more sensitive
in the late
afternoons), certain predictions may be made and patterns from the virtual
patient may
be identified and tested to see if they are close to real life. Further
description of a
virtual patient software system may be found in U.S. Pat. App. Pub. No.
2006/0272652,
published Dec. 7, 2006, to Stocker et al. and entitled "Virtual Patient
Software System
for Educating and Treating Individuals with Diabetes'!
53
CA 02938541 2016-08-09
[00115] Doctors often have access to data of multiple patients. By
comparing the
data of multiple patients in a doctor's patient pool, group patterns may be
developed
that may be helpful in treating particular patients. Similar patterns in
multiple patients
may help a doctor plan a course of treatment that may help another patient
having such
similar patterns. Data from multiple patients in a doctor's care may be
utilized for virtual
patient simulations, too, along with developing an "average patient" model as
a point of
reference.
[00116] Group patterns may be filtered by sex, age, pregnancy state,
exercise
type, body type, type of diabetes (Type I, Type II, gestational), treatment
type (pump
use, insulin type use, oral medication), etc. Another group may involve
"panic" users,
those who tend to over-deliver boluses upon a triggering or notification
event.
Accordingly, the infusion pump, controller/programmer, or any other suitable
device may
be configured such that when it recognizes a glucose level pattern occurring
that has
historically lead to a user over-delivering insulin, the infusion pump may
warn the user in
advance of this triggering event to not over-deliver a bolus. Additionally,
the infusion
pump, controller/programmer, or DDMS/MDMS, may automatically disable itself
for a
short period of time after the proper dosage has been delivered to prevent
over-delivery
by a panicked user. Group patterns also may be useful in assessing and
identifying a
"type" of patient, particularly helpful in establishing a starting point for a
new patient.
[00117] "Distracted" users may forget to treat diabetes by skipping
boluses, eating
high sugar foods, forgetting to turn on the insulin pump after suspending
insulin delivery
during exercise, or forgetting to calibrate a sensor before bedtime (which may
lead to
the user being awakened during the night for a calibration). Patterns may be
used to
54
CA 02938541 2016-08-09
quickly identify that a bolus was missed or that a high sugar drink was
consumed and
warn the user to deliver a bolus before glucose levels reach severe
hyperglycemia.
Likewise, patterns may be used to identify early that exercise has stopped and
the
pump's bolus delivery must resume. Similarly, patterns may be used to identify
habitual
lapses in compliance and remind the user to perform a task when the user is
awake and
when it is convenient.
[00118] A users exercise regime also should be considered when planning a
course of treatment. An infusion pump or controller/programmer, for example,
may
include an accelerometer, heart rate monitor, respiratory monitor, etc., to
deduce when
a user may be exercising. Sometimes a user will remove a pump just before
undergoing exercise, or set a temporary basal rate just before exercising to
prevent a
drop in glucose levels. Further descriptions of utilizing accelerometers in
diabetes
therapy may be found in U.S. Pat. App. Pub. No. 2008/0125701, published May
29,
2008, to Moberg et al. and is entitled, "Methods and Apparatuses for Detecting
Medical
Device Acceleration, Temperature, and Humidity Conditions".
[00119] As with patterns of glucose levels, patterns of insulin delivery,
e.g., basal
patterns, also may be established corresponding to the glucose level patterns
to keep
the glucose levels within the desirable range throughout the day. Based on a
glucose
level pattern, an insulin delivery pattern may be established to anticipate
and "match"
rises and falls and keep the glucose levels within the desired range. Multiple
patterns
may be established for varies times throughout the day, too. For example,
there may
be an "after breakfast" pattern, an "after lunch" pattern, an "after
dinner/ovemight
CA 02938541 2016-08-09
pattern, etc. One pattern may be more useful to a user than another, and if a
doctor
sees that a user is using one pattern but not another, the doctor may deduce
that the
other unused pattern is not configured correctly and may further adjust this
pattern to
make it more effective to the user.
[00120] According to embodiments of the present invention, an after
dinner/overnight pattern may be used to evaluate whether a user must take an
action
before bedtime. For example, if a user exercises earlier in the day, his/her
body may
demand nutrition to heal while sleeping, and the user's glucose levels may
drop during
the night to hypoglycemic levels. We may observe patterns of the glucose
levels before
bedtime and during the night, and if a hypoglycemic pattern is identified
before going to
bed, the user may take action to prevent low glucose levels, such as eating a
snack
before bedtime, eating a fatty snack so that digestion is postponed, reducing
the basal
insulin amount, changing the basal insulin profile, setting an alarm to get a
snack later,
etc.
[00121] The more accurate a user is at making an estimate of his/her
carbohydrate intake, the more accurate the delivery of the correct amount of
insulin
required to keep a user's glucose levels stable and within the desired range.
The
Medtronic Mini Med BOLUS WIZARDTM calculator, for example, is a bolus
estimator/calculator that assists a user in providing a recommended insulin
bolus
dosage for a meal based on the user's estimate of the amount of carbohydrates
in a
meal to be consumed. Further descriptions of a bolus calculator may be found
in U.S.
Pat. No. 6,554,798, issued April 29, 2003, to Mann et al. and is entitled,
"External
Infusion Device with Remote Programming, Bolus Estimator and/or Vibrational
Alarm
56
CA 02938541 2016-08-09
=
Capabilities", and U.S. Pat. No. 7,204,823, issued April 17, 2007, To Estes et
al. and is
entitled, "Medication Delivery System and Monitor"
Certain people are more accurate at estimating the amount
of carbohydrates in a particular food or food type than others. For example,
some
people are better at estimating the carbohydrate amount in foods with
generally high
carbohydrate counts (e.g., potatoes) than those with the lower ones (e.g.,
eggs).
[00122] According to embodiments of the present invention, a bolus
calculator
may be calibrated ahead of time by the user to learn of the user's biases and
tendencies to estimate high or low for certain (or all) foods (e.g., an apple,
orange juice,
pepperoni pizza, baked salmon, steamed rice, etc.) and food types (e.g.,
grains,
vegetables, fruits, dairy products, meats, etc.), and then adjust the
recommended
insulin bolus dosage based on the user's biases and tendencies (if any). For
example,
the bolus calculator may be calibrated using a computer, such as the DDMS/MDMS
discussed above with respect to FIG. 1, or the like, which may display a
variety of
different portions of foods with known true carbohydrate counts, and ask the
user to
provide his/her own estimates of the carbohydrate counts for the foods (and
portions/amounts thereof) presented. By comparing the user's estimated
carbohydrate
count with the known true carbohydrate count for a variety of different foods,
food types,
food subtypes, etc., a calibration may be made to assist in providing more
accurate
insulin bolus dosage recommendations.
[00123] For example, it can be determined that the user estimates higher
than true
carbohydrate counts for pizza in general, while the user provides accurate
estimates
with meats and wheat-based foods in general, but the user underestimates the
57
CA 02938541 2016-08-09
,
carbohydrate counts for sushi and fruits in general. Based on this
calibration, the bolus
calculator may adjust the insulin dosage recommendations to compensate for the
user's
biases in estimating high or low for particular foods and food types, and make
little or no
adjustments when the user is known to make accurate estimates for other foods
and
food types. Therefore, the bolus dosage recommendation is increased if the
user's
response to estimate the carbohydrate value for a representative food
corresponding to
a food to be consumed is lower than the true carbohydrate value for the
representative
food during calibration. Likewise, the bolus dosage recommendation is
decreased if the
user's response to estimate the carbohydrate value for a representative food
corresponding to a food to be consumed is higher than the true carbohydrate
value for
the representative food during calibration. Any particular foods, food types,
and food
subtypes (e.g., for grains -- wheat foods, rice foods, etc.) are suitable for
calibration of
the user's ability to estimate accurately carbohydrate counts for the various
foods, food
types, and food subtypes the user wishes to consume.
[00124] According to embodiments of the present invention, the bolus
calculator
may permit the user to select and calibrate with favorite foods or those foods
that are
commonly eaten by the user to obtain the most accurate and useable bolus
dosage
recommendations. For example, if the user hates or has severe allergies to
shrimp
foods, then, there is no need to calibrate with shrimp foods. The bolus
calculator may
also permit the user to designate an origin of the foods and calibrate
accordingly, e.g.,
calibrate a pizza from California Pizza Kitchen vs. a pizza from Domino's vs.
a frozen
pizza from Costco. The bolus calculator may even permit the user to calibrate
specific
foods, e.g., a pepperoni and green pepper pizza (from Domino's) vs. a sausage
and
58
CA 02938541 2016-08-09
. ,
mushroom pizza (from Costco). Any combinations of the foods, food types, food
subtypes, specific foods, and their origins, brands, etc. may be incorporated
into the
bolus calculator for calibration of the bolus calculator based on the user's
ability to
accurately estimate carbohydrate counts and adjust the bolus dosage
recommendations
based on those estimates.
[00125] FIG. 5 illustrates a flowchart for providing bolus dosage
recommendations
in diabetes therapy according to embodiments of the present invention.
According to
embodiments of the present invention, a method of calibrating and providing
bolus
dosage recommendations in diabetes therapy includes, at step 510, presenting a
plurality of representative foods to a user. A spectrum of representative
foods
(especially those foods that a user is likely to consume) is selected and
presented to the
user that is reflective of the typical diet of the user. For example, these
foods may be
presented on a display of a computer or other suitable device, including but
not limited
to the DDMS/MDMS described above with respect to FIG. 1. The user is then
prompted
to estimate a carbohydrate value for each one of the plurality of
representative foods
presented to the user. The user may account for the portion (large, small, two
vs. three
egg omelet, etc.) of the representative foods presented to the user when
estimating the
carbohydrate value. Alternatively, the user may respond with "N/A", "SKIP",
"REMOVE", or the like for those representative food(s) presented to the user
that the
user does not commonly eat or enjoy, to which the user has allergies, is not
readily
available where the user lives, etc.
[00126] At step 520, the responses from the user are received and
stored by the
computer or other suitable device. These responses are then used to calibrate
a bolus
59
CA 02938541 2016-08-09
. ,
calculator to determine whether the user has a tendency or bias to estimate
high or low
for particular foods, food types, food subtypes, etc. from their true
carbohydrate value.
Based on the estimates received from the user during calibration, the bolus
calculator
may make any adjustments or corrections in providing bolus dosage
recommendations.
[00127] When the user is about to consume a food item, the user
provides
information to the bolus calculator indicating a food to be consumed and the
user's
estimated carbohydrate value for that food to be consumed. The bolus
calculator,
receiving the information regarding the food to be consumed at step 530, may
be the
computer that was used in the calibration, a separate device (e.g., a PDA,
portable
computer, mobile phone, etc.), or even integrated into the infusion pump or
controller/programmer (that may receive calibration information from a
computer used to
conduct the calibration of the bolus calculator). The bolus calculator at step
540
calculates a bolus dosage recommendation based on the input received from the
user
regarding the food to be consumed (e.g., food, food type, food subtype,
estimated
carbohydrate count, portion, origin, brand, etc.) and the user's response to
estimate the
carbohydrate value for at least one of the plurality of representative foods
during
calibration in steps 510 and 520.
[00128] FIGS. 6A and 6B illustrate Interpretation Reports according
to
embodiments of the present invention. Referring to the Interpretation Report
610 in
FIG. 6A, information for seven days (although any number of days may be
displayed
according to embodiments of the present invention) pertaining to blood glucose
readings and averages, for example, taken from a blood glucose meter, is
displayed in
a 24-hour chart (any suitable time period is acceptable according to
embodiments of the
CA 02938541 2016-08-09
present invention), highlighting meal events (e.g., breakfast, lunch, dinner).
The
corresponding infusion device settings for basal rate, insulin sensitivity,
and the
carbohydrate ratio information (more or less settings may be provided
according to
embodiments of the present invention) along the 24-hour timeline are also
provided
under the main chart. Below that information in this Report 610 are close-up
charts for
the overnight time period, as well as the meal time periods of breakfast,
lunch, and
dinner (although close-up charts for any other suitable time period may be
analyzed,
too, according to embodiments of the present invention).
[00129] Based on the blood glucose information obtained from these charts,
systems and methods according to embodiments of the present invention analyze
the
data, much like what a doctor would do, and provide an "interpretation" of the
raw data
in an easy to read table, see, for example, on the upper right corner of the
Interpretation
Report 610. A quick glance of the interpretation table provides a medical
professional a
good snapshot of the important statistics in a patient's therapy. Basic
information
extracted from the raw data may include, for example, average glucose level
and an
estimated HbA1c value. The raw data may be interpreted, according to
embodiments of
the present invention, to report instances of hypoglycemic events (time
periods of
occurrence), instances of hyperglycemic patterns (time periods of occurrence),
and
instances of high variability in the patient. Key metrics of the patient's
infusion device
usage (e.g., insulin total daily dose (TDD), basal-bolus ratio, frequency of
site/reservoir
changes, basal duration, boluses made, and food-and-correction insulin) and
the
number of blood glucose readings taken each day may also be included in the
interpretation table. Further recommendations based on the analyzed raw data
may be
61
CA 02938541 2016-08-09
provided by the Interpretation Report 610 under the Clinical Plan section (see
lower
right section of Report 610) according to embodiments of the present
invention. The
statistics provided in the interpretation table of the Report 610 are merely
representative
examples, and greater or lesser statistics may be provided according to
embodiments of
the present invention.
[00130] The Interpretation Report 610 of FIG. 6B according to embodiments
of the
present invention includes a pie chart section 620 in lieu of the close-up
charts for the
overnight time period and meal time periods as illustrated in FIG. 6A. These
pie charts
620 illustrate the occurrences of when the percentage of time the patient is
"above", "in
range", or "below" the target blood glucose levels during various time
periods, e.g.,
Wake-up, Breakfast, Lunch, Dinner, Overnight (although any suitable time
period may
be analyzed in pie chart form other than the representative ones in FIG. 6B).
The
Interpretation Reports of FIGS. 6A and 6B automatically analyze the raw data
regarding
a patient's therapy to generate and present the information in an easy to read
format for
the medical professional, patient, and the like.
[00131] FIG. 7A illustrates a Therapy Management Dashboard according to
embodiments of the present invention, and FIG. 7B illustrates an Episode
Summary
according to embodiments of the present invention. The Therapy Management
Dashboard 710 in FIG. 7A illustrates in the top chart 24-hour continuous
glucose sensor
readings from May 2, 2009 to May 29, 2009 of a representative patient. Any
suitable
time period other than 24-hours may be utilized, as well as any number of
days. Below
these readings is a second chart providing information with respect to basal
rate and
active insulin for the corresponding time periods in the 24-hour glucose
sensor readings
62
CA 02938541 2016-08-09
chart above. Below that information are close-up charts, similar to those in
FIG. 6A, for
the Bedtime-to-Wake-up time period, as well as the meal time periods of
breakfast,
lunch, and dinner (although close-up charts for any other suitable time period
may be
analyzed, too). Information pertaining to therapy statistics (e.g., average
blood glucose
level, estimated HbA1c level, number of blood glucose readings taken per day,
number
of carbohydrates entered per day), hypoglycemic patterns (time periods of
occurrence),
hyperglycemic patterns (time periods of occurrence), infusion device usage
(e.g., insulin
total daily dose (TDD), basal/bolus ratio, units of manual boluses, Bolus
Wizard (BZW)
usage, pump suspend duration, low suspend events and duration, and
reservoir/set
changes), and sensor use (e.g., sensor blood glucose level, wear duration, low
sensed
glucose alarm occurrences, and high sensed glucose alarm occurrences), located
on
the right-hand side of the Dashboard 710, may be included as well. Any
suitable
statistics, greater or lesser than those illustrated in FIG. 7A, may be
provided according
to embodiments of the present invention.
[00132] Fig. 7B illustrates an Episode Summary 720 of the patient
information in
the Dashboard 710 in FIG. 7A according to embodiments of the present
invention. The
Episode Summary 720 provides information regarding hypoglycemic and
hyperglycemic
episodes by preceding events, the most frequent events for each episode, and
pie
charts detailing the events ending in hypoglycemic and hyperglycemic events,
respectively. The top bar graphs in the Episode Summary 720 in FIG. 7B show
the
frequency of episodes of hypoglycemia preceded by events such as, for example,
making a manual bolus, making multiple manual boluses, nocturnal,
hyperglycemia, and
large basal rate increase; and for the frequency of episodes of hyperglycemia
preceded
63
CA 02938541 2016-08-09
_
by events such as delayed site change, overcorrection of a low sensor glucose
reading,
dawn phenomenon, and large basal rate decrease. Recommendations with respect
to
these most frequent events (which may include the percentage of total events)
for both
hypoglycemia and hyperglycemia are provided immediately below the bar graphs
in the
Episode Summary 720.
[00133] Pie charts may be provided to visually break down the number of
hypoglycemic events and hyperglycemic events, respectively, that occurred
based on
the overall number of preceding events in total. Finally, the lower part of
the Episode
Summary 720 provides some Overall Observations regarding the patient's therapy
and
some recommendations to improving the therapy (e.g., not using the Bolus
Wizard,
infusion site misuse, sensor wear frequency, and meter reading frequency).
[00134] The scope of the claims should not be limited by the preferred
embodiments set forth in the examples, but should be given the broadest
interpretation
consistent with the description as a whole.
[00135] The presently disclosed embodiments are therefore to be
considered in all
respects as illustrative and not restrictive, the scope of the invention being
indicated by
the appended claims, rather than the foregoing description, and all changes
which come
within the meaning and range of equivalency of the claims are therefore
intended to be
embraced therein.
64
