U.S. patent application number 14/684495 was filed with the patent office on 2015-08-06 for expert system for insulin pump therapy.
The applicant listed for this patent is Tandem Diabetes Care, Inc.. Invention is credited to Michael L. Blomquist.
Application Number | 20150217044 14/684495 |
Document ID | / |
Family ID | 39758848 |
Filed Date | 2015-08-06 |
United States Patent
Application |
20150217044 |
Kind Code |
A1 |
Blomquist; Michael L. |
August 6, 2015 |
EXPERT SYSTEM FOR INSULIN PUMP THERAPY
Abstract
An apparatus comprising a controller. The controller includes an
input/output (I/O) module and a rule module. The I/O module is
configured to present a question for a patient when communicatively
coupled to a user interface and receive patient information in
response to the question via the user interface. The rule module is
configured to apply a rule to the patient information and generate
a suggested insulin pump setting from application of the rule.
Other devices, systems, and methods are disclosed.
Inventors: |
Blomquist; Michael L.;
(Blaine, MN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Tandem Diabetes Care, Inc. |
San Diego |
CA |
US |
|
|
Family ID: |
39758848 |
Appl. No.: |
14/684495 |
Filed: |
April 13, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13530404 |
Jun 22, 2012 |
9008803 |
|
|
14684495 |
|
|
|
|
12774991 |
May 6, 2010 |
8219222 |
|
|
13530404 |
|
|
|
|
11753420 |
May 24, 2007 |
7751907 |
|
|
12774991 |
|
|
|
|
Current U.S.
Class: |
700/282 |
Current CPC
Class: |
A61M 2205/507 20130101;
G05B 15/02 20130101; A61M 5/1723 20130101; G06N 5/027 20130101;
A61M 2205/52 20130101; A61P 3/10 20180101; A61M 5/14244 20130101;
G16H 40/63 20180101; G16H 20/17 20180101; A61M 2205/502 20130101;
A61M 5/142 20130101; A61M 2005/1726 20130101; G16H 10/60 20180101;
G16H 50/20 20180101 |
International
Class: |
A61M 5/142 20060101
A61M005/142; G06N 5/02 20060101 G06N005/02; G05B 15/02 20060101
G05B015/02 |
Claims
1. (canceled)
2. An apparatus, comprising: a user interface including a display;
a controller communicatively coupled to the user interface and the
display, the controller including: an input/output module
configured to: present a series of questions to a patient on the
display; and receive patient information about the patient in
response to the questions through the user interface; and a rule
module configured to: apply a rule to the patient information; and
generate a suggested infusion pump setting according to the
application of the rule to the patient information; and a
communications port communicatively coupled to the controller and
configured to communicate the suggested infusion pump setting to a
programmable infusion pump for use in determining future therapy
with the programmable infusion pump.
3. The apparatus of claim 2, wherein the communications port is a
wireless port that wirelessly communicates the suggested infusion
pump setting to the programmable infusion pump.
4. The apparatus of claim 2, wherein the input/output module is
further configured to display the suggested infusion pump setting
on the display.
5. The apparatus of claim 4, wherein the input/output module is
further configured to receive, through the user interface, a
confirmation of the suggested infusion pump setting and the
communications port communicates the suggested infusion pump
setting to the programmable infusion pump after the confirmation is
received.
6. The apparatus of claim 2, further comprising a memory storing
the rule.
7. The apparatus of claim 2, wherein the input/output module is
further configured to access a remote device to obtain the
rule.
8. The apparatus of claim 2, wherein the controller is further
configured to receive data relating to the effectiveness of the
rule from the programmable infusion pump through the communications
port.
9. The apparatus of claim 2, wherein the input/output module is
further configured to receive information relating to a glucose
level of a patient and applying a rule to the patient information
includes applying the rule to the glucose level information.
10. The apparatus of claim 2, wherein the user interface, the
controller, the display and the communications port define a
computing device.
11. The apparatus of claim 10, wherein the computing device is a
handheld mobile device.
12. An apparatus comprising: a controller including: an
input/output module configured to: present a series of questions to
a patient on a display; and receive patient information about the
patient in response to the questions through a user interface; and
a rule module configured to: apply a rule to the patient
information; and generate a suggested infusion pump setting
according to the application of the rule to the patient
information; and a communications port communicatively coupled to
the controller and configured to communicate the suggested infusion
pump setting to a programmable infusion pump for use in determining
future therapy with the programmable infusion pump.
13. The apparatus of claim 12, wherein the communications port is a
wireless port that wirelessly communicates the suggested infusion
pump setting to the programmable infusion pump.
14. The apparatus of claim 12, wherein the input/output module is
further configured to: present the suggested infusion pump setting
on a display; present a request for confirmation of the suggested
infusion pump setting; and communicate the suggested infusion pump
setting to the programmable infusion pump after receiving the
confirmation.
15. The apparatus of claim 12, wherein the controller is further
configured to receive data relating to the effectiveness of the
rule from the programmable infusion pump through the communications
port.
16. The apparatus of claim 12, wherein the input/output module is
further configured to receive information relating to a glucose
level of a patient and the rule module is further configured to
apply the rule to the glucose level information.
17. The apparatus of claim 12, wherein the controller and
communications port are part of a computing device.
18. The apparatus of claim 17, wherein the computing device is a
handheld mobile device.
19. A method comprising: presenting a series of questions to a
patient on a display of a computing device; receiving patient
information about the patient in response to the questions through
a user interface of the computing device; applying a rule to the
patient information with an electronic controller of the computing
device; generating a suggested infusion pump setting with the
electronic controller according to the application of the rule to
the patient information; and communicating, with a communications
port of the computing device, the suggested infusion pump setting
to a programmable infusion pump for use in determining future
therapy with the programmable infusion pump.
20. The method of claim 19, wherein communicating the suggested
infusion pump setting to the programmable infusion pump includes
wirelessly communicating the suggested infusion pump setting.
21. The method of claim 19, further comprising displaying the
suggested infusion pump setting on the display.
22. The method of claim 21, further comprising receiving a
confirmation of the suggested infusion pump setting and
communicating the suggested infusion pump setting to the
programmable infusion pump is done after the confirmation is
received.
23. The method of claim 19, further comprising receiving data
relating to the effectiveness of the rule from the programmable
infusion pump through the communications port.
24. The method of claim 19, further comprising receiving
information relating to a glucose level of a patient and applying a
rule to the patient information includes applying the rule to the
glucose level information.
25. The method of claim 19, wherein the computing device is a
handheld mobile device.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of application Ser. No.
13/530,404 filed Jun. 22, 2012, which in turn is a continuation of
application Ser. No. 12/774,991 filed May 6, 2010, now U.S. Pat.
No. 8,219,222 issued Jul. 10, 2012, which in turn is a continuation
application Ser. No. 11/753,420 filed May 24, 2007, now U.S. Pat.
No. 7,751,907 issued Jul. 6, 2010, each of which is hereby fully
incorporated herein by reference.
TECHNICAL FIELD
[0002] The field generally relates to patient insulin management
devices and, in particular, but not by way of limitation, to
systems, devices and methods for managing insulin therapy.
BACKGROUND
[0003] People who suffer from diabetes require insulin to keep
their blood glucose level as close as possible to normal levels. It
is essential for people with diabetes to manage their blood glucose
level to within a normal range. Complications from diabetes can
include heart disease (cardiovascular disease), blindness
(retinopathy), nerve damage (neuropathy), and kidney damage
(nephropathy). Insulin is a hormone that reduces the level of blood
glucose in the body. Normally, insulin is produced by beta cells in
the pancreas. In non-diabetic people, the beta cells release
insulin to satisfy two types of insulin needs. The first type is a
low-level of background insulin that is released throughout the
day. The second type is a quick release of a higher-level of
insulin in response to eating. Insulin therapy replaces or
supplements insulin produced by the pancreas.
[0004] Conventional insulin therapy typically involves one or two
injections a day. The low number of injections has the disadvantage
of allowing larger variations in a person's insulin levels. Some
people with diabetes manage their blood glucose level with multiple
daily injections (MDI). MDI may involve more than three injections
a day and four or more blood glucose tests a day. MDI offers better
control than conventional therapy. However, insulin injections are
inconvenient and require a diabetic person to track the insulin
doses, the amount of carbohydrates eaten, and their blood glucose
levels among other information critical to control.
[0005] It is important for a diabetic person to be treated with the
proper amount of insulin. As discussed previously, high blood sugar
can lead to serious complications. Conversely, a person with low
blood sugar can develop hypoglycemia. Ideally, insulin therapy
mimics the way the body works. An insulin pump is one way to mimic
the body's insulin production. An insulin pump can provide a
background or basal infusion of insulin throughout the day and
provide a quick release or bolus of insulin when carbohydrates are
eaten. If a person develops high blood sugar, a correction bolus
can be delivered by the pump to correct it. While insulin pumps
improve convenience and flexibility for a diabetic person, they can
be sophisticated devices. Some insulin pumps can be difficult to
program. Proper use of an insulin pump requires a user to go
through a learning curve to properly treat their diabetes using the
insulin pump.
SUMMARY
[0006] This document discusses, among other things, devices and
methods for managing insulin therapy. A device example includes a
controller. The controller includes an input/output (I/O) module
and a rule module. The I/O module is configured to present a
question for a patient when communicatively coupled to a user
interface and receive patient information in response to the
question via the user interface. The rule module is configured to
apply a rule to the patient information and generate a suggested
insulin pump setting from application of the rule.
[0007] A method example includes presenting a question for a
diabetic patient using a device, receiving patient information into
the device in response to the question, applying a rule to the
patient information, and generating a suggested insulin pump
setting from application of the rule.
[0008] This summary is intended to provide an overview of the
subject matter of the present patent application. It is not
intended to provide an exclusive or exhaustive explanation of the
invention. The detailed description is included to provide further
information about the subject matter of the present patent
application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIGS. 1A and 1B illustrate portions of a device that
includes an insulin pump.
[0010] FIG. 2 is a block diagram of an example of portions of a
device to provide assistance in maintaining and adjusting a
patient's insulin pump therapy.
[0011] FIG. 3 shows a flow diagram of a method to provide
assistance in maintaining and adjusting a patient's insulin pump
therapy.
[0012] FIG. 4 is a block diagram of another example of portions of
a device to provide assistance in maintaining and adjusting a
patient's insulin pump therapy.
[0013] FIG. 5 is a diagram of yet another example of portions of a
device to provide assistance in maintaining and adjusting a
patient's insulin pump therapy.
[0014] FIG. 6 is a block diagram of a further example of portions
of a device to provide assistance in maintaining and adjusting a
patient's insulin pump therapy.
DETAILED DESCRIPTION
[0015] The following detailed description includes references to
the accompanying drawings, which form a part of the detailed
description. The drawings show, by way of illustration, specific
embodiments in which the invention may be practiced. These
embodiments, which are also referred to herein as "examples," are
described in enough detail to enable those skilled in the art to
practice the invention. The embodiments may be combined, other
embodiments may be utilized, or structural, logical and electrical
changes may be made without departing from the scope of the present
invention. The following detailed description is, therefore, not to
be taken in a limiting sense, and the scope of the present
invention is defined by the appended claims and their
equivalents.
[0016] In this document, the terms "a" or "an" are used, as is
common in patent documents, to include one or more than one. In
this document, the term "or" is used to refer to a nonexclusive or,
such that "A or B" includes "A but not B," "B but not A," and "A
and B," unless otherwise indicated. Furthermore, all publications,
patents, and patent documents referred to in this document are
incorporated by reference herein in their entirety, as though
individually incorporated by reference. In the event of
inconsistent usages between this document and those documents so
incorporated by reference, the usage in the incorporated
reference(s) should be considered supplementary to that of this
document; for irreconcilable inconsistencies, the usage in this
document controls.
[0017] FIGS. 1A and 1B illustrate portions of a device 100 that
includes an insulin pump. The device 100 includes a cassette or
cartridge of insulin. The cartridge is connectable to infusion
tubing 140 connectable to a patient such as by a Luer lock 145 or
infusion set 142. The device 100 includes a display 102 and a user
interface that may include the display 102 and include one or more
keys 104. Because proper use of an insulin pump requires a user to
go through a learning curve to properly treat their diabetes using
the pump, it is desirable for a pump to provide assistance to the
user, whether the user is a diabetic patient, a caregiver, or a
clinician. An expert system provides assistance or coaching to the
user to effectively treat their diabetes using the insulin pump
device.
[0018] FIG. 2 is a block diagram of an example of portions of a
device 200 to provide assistance in maintaining and adjusting a
patient's insulin pump therapy. The device 200 includes a
controller 205. The controller 205 can be implemented using
hardware circuits, firmware, software or any combination of
hardware, firmware and software. Examples, include a
microcontroller, a logical state machine, and a processor such as a
microprocessor, application specific integrated circuit (ASIC), or
other type of processor. The controller 205 is configured to
perform or execute a function or functions. Such functions
correspond to modules, which are software, hardware, firmware or
any combination thereof. Multiple functions may be performed in one
or more modules. In some examples, software or firmware is provided
on a computer readable medium. The computer readable includes
instructions therein, which when processed (such as by the
controller 205 for example) results in a device performing the
functions described herein. Examples of a computer readable medium
include a compact disc (CD), memory stick, or remote storage
accessible via a communication network such as the internet or a
cell phone network.
[0019] The controller 205 includes an input-output (I/O) module
210. The I/O module 210 presents a question for a patient when the
I/O module 210 is communicatively coupled to a user interface. The
user interface may include one or more pushbuttons or a keypad. The
user interface may include a display to visually present
instructions and/or the question to the user. The user of the
device 200 may be a clinician or a diabetic patient. The display
may include a touch-screen. The user interface may include a
speaker to present instructions and questions audibly. A speaker
may be desirable when the user has difficulty in reading a
display.
[0020] The I/O module 210 receives patient information in response
to the question via the user interface. In some examples, the
question and response is included in a series of questions and
responses that are part of a patient interview by the device 200. A
patient interview may cover a broad range of information. In some
examples, the patient information may include patient health
information such as a patient health status or whether the patient
has any other health-related conditions. The health information
also may include whether information concerning any drugs or
medications the patient may be taking. Some drugs may cause a
person to need more insulin, or the patient may be taking a drug to
slow down the absorption of food.
[0021] The patient information may include patient lifestyle
information. The lifestyle information may include whether a
patient tends to eat high glycemic index foods, drinks alcohol,
smokes, eats a bedtime snack, a health status of the patient,
whether the patient is typically under stress, whether the patient
tends to be active, and the amount time the patient spends
exercising, for example. The patient information may include
patient demographic information. The demographic information may
include a patient's weight, age, and gender for example.
[0022] In some examples, the patient information may be stored in a
memory 220 communicatively coupled to the controller 205. The
information may be stored in response to the questions or may be
pre-stored in the device 200. The controller 205 includes a rule
module 215. The rule module 215 applies a rule to the patient
information and generates a suggested insulin pump setting from
application of the rule. In some embodiments, the rule includes a
decision tree. A decision tree may be implemented with a series of
IF-Then logic statements. The controller 205 traverses the decision
tree using the patient information. In some embodiments, the rule
module 215 may include a look-up table stored in the memory 220.
The look-up table may have entries that include one or more insulin
pump settings. The table may include multiple dimensions to take
into account multiple factors, responses, or other information.
[0023] An example of an insulin pump setting is a basal rate. Basal
rate refers to a type of twenty-four hour background infusion of
insulin by an insulin pump that mimics the continuous background
release of insulin from a normal pancreas. It is the rate of
insulin delivery the patient normally needs independent of the
consumption of meals. The basal rate is typically specified in
insulin units per hour (u/hr). The patient information may include
a total daily dose (TDD) of insulin, or the rule module may
determine a TDD from patient information including the type of
diabetes of the patient and the patient's weight, age, and level of
fitness. The rule included in the rule module 215 may determine
that the amount of daily basal insulin according to a percentage of
TDD, such as 40%, 50%, or 60% for example. The percentage applied
by the rule may be customized according to the preferences of a
clinician. The TDD is then divided by 24 to obtain an average
hourly basal rate. For example, if a patient's TDD is determined to
be 40 units of insulin, and 50% of the TDD is used for basal
delivery, the rule module 215 determines that the average basal
rate is 20 units/24 hours or 0.83 u/hr.
[0024] Many insulin pump users may use three or more different
basal rates during the course of a day. Basal rates can be adjusted
to change delivery every few minutes (e.g., 20-30 minutes) by
increments as small as 0.05 u/hr to better track changes in demand,
such as from an increase typically needed before dawn or a decrease
needed during long active periods. The device 200 provides
assistance in determining one or more basal rates for the patient.
For example, the rule may be a look-up table that includes one or
more basal rates indexed by an activity level of the patient. The
rule determines a lower basal rate during an increased activity
level of the patient. In another example, the rule may increase a
basal rate during times when the patient takes a drug that causes
the patient to need more insulin. In yet another example, the rule
may decrease a basal rate or a segment of a basal rate pattern if
the patient is taking a drug to delay the digestion of food.
[0025] Another example of an insulin pump setting is a correction
factor. A correction factor refers to the amount in drop in blood
sugar, or blood glucose, for one unit of insulin. It is measured in
milligrams per deciliter (mg/dl) per unit in the U.S. and in
millimoles (mmol) per unit in other countries. An insulin pump may
use the correction factor to automatically determine a bolus amount
required for a high reading or a reduction in a meal bolus for a
below-target reading. The insulin pump may also use the correction
factor to calculate the amount of carbohydrates a patient should
eat to bring low blood sugar up to a target blood sugar level. An
appropriate correction factor brings a high blood glucose reading
down using an automatically determined correction bolus without a
risk of going low.
[0026] The rule module 215 may include a rule such as the "1800
rule" in setting the correction factor. For example, if a person's
TDD is 40 units of insulin, the correction factor would be 1800/40,
or 45 mg/dl per unit. (The 1800 rule corresponds to a "100 rule" if
mmol are used.) The rule module 215 may also take into account
factors such as a person's age, weight, and activity level when
setting the correction factor. Other rules include the 1700 rule
(94 rule if mmol) and the 1500 rule (83 rule if mmol). For example,
under the 1700 rule the correction factor would be 1700/40 or 42.5
mg/dl. A clinician may prefer one rule over another based on
experience including rules that are not based on TDD. The rule to
determine the correction factor may be customized according to the
preferences of the clinician.
[0027] Another example of an insulin pump setting is a carbohydrate
ratio. A carbohydrate ratio refers to the amount of carbohydrates
covered by a unit of insulin. It is sometimes referred to as a
carbohydrate factor, or carb factor, and is typically specified as
grams of carbohydrates per unit of insulin. An insulin pump device
may use the carbohydrate ratio to automatically determine a
carbohydrate insulin bolus amount required to match a number of
carbohydrates ingested by the patient, or at least to keep
post-meal blood glucose within a range that is healthy for a
patient. For example, the patient may plan to eat seventy grams of
carbohydrates. If the carbohydrate ratio is ten grams of
carbohydrates per unit of insulin, the insulin pump may determine
that seven units of insulin are required to cover the
carbohydrates.
[0028] The rule module 215 may include a formula such as the "500
rule" in setting the carbohydrate ratio. For example, if a person's
TDD is 40 units of insulin, the carbohydrate ratio would be 500/40
or about 13 grams per unit of insulin. The rule module 215 may also
take into account factors such as a person's age, weight, and
activity level when setting the carbohydrate ratio. Other formulas
include the 550 rule and the 600 rule. For example, under the 600
rule the carbohydrate ratio would be 600/40 or 15 grams per unit of
insulin. As discussed above, the larger the carbohydrate ratio, the
smaller a carbohydrate bolus becomes. Because a clinician may
prefer one rule over another based on experience; including rules
that are not based on TDD, the rule to determine the correction
factor may be customized according to the preferences of the
clinician.
[0029] According to some examples, the memory 220 may store
parameters associated with an insulin pump initial setup. The rule
module 215 applies a rule to match the insulin pump parameters to
at least one of patient health information, patient lifestyle
information, and patient demographic information to generate a
suggested insulin pump initial setup. The rule module 215 may apply
the rule to the patient information to determine at least one of an
initial correction factor, an initial carbohydrate ratio, and one
or more initial basal rate patterns or profiles. For example, as
part of the device interview a patient may enter those periods when
the patient regularly exercises into the device 200. The rule may
generate different basal rates before, during, or after the
exercise periods. In another example, the patient enter the fact
that she is pregnant or trying to get pregnant into the device 200.
The rule may suggest more aggressive correction bolus targets. In a
further example, based on the demographic data the rule may
determine different insulin pump initial setups for children,
teens, adult females, adult males, and seniors. The demographic
information would initially setup parameters including basal rates,
carbohydrate bolus limits, insulin pump feature lockouts and
enables.
[0030] FIG. 3 shows a flow diagram of a method to provide
assistance in maintaining and adjusting a patient's insulin pump
therapy. At block 305, a question is presented for a diabetic
patient using a device. At block 310, patient information is
received into the device in response to the question. At block 315,
a rule is applied to the patient information. At block 320, a
suggested insulin pump setting is generated from application of the
rule.
[0031] FIG. 4 is a block diagram of another example of portions of
a device 400 to provide assistance in maintaining and adjusting a
patient's insulin pump therapy. The device 400 includes an insulin
pump 425 or pump mechanism to deliver insulin to a patient, such as
a positive displacement pump for example. The device 400 also
includes a controller 405 communicatively coupled to a memory 420.
The controller 405 includes an I/O module 410 and a rule module
415. The memory 420 may store parameters associated with insulin
pump therapy. The rule module 415 applies a rule to generate a
suggested insulin pump initial setup.
[0032] The device 400 includes a user interface 430 communicatively
coupled to the I/O module 410. In some examples, the user interface
430 includes a display and the I/O module 410 presents one or more
suggested insulin pump settings to the user via the user interface
430. The I/O module additionally presents a request to the user for
confirmation of the insulin pump setting. After a request is
received, the setting or settings are adopted or activated by the
device 400, such as by moving the settings from the memory 420 to
operating registers for example.
[0033] FIG. 5 is a diagram of an example of a device 500 to provide
assistance in maintaining and adjusting a patient's insulin pump
therapy. The device 500 includes a computing device 550. Examples
of a computing device 550 include among other things a personal
computer (PC), laptop computer, and personal data assistant (PDA).
The computing device 550 includes a controller 505. The controller
505 includes an I/O module 510 and a rule module 515. The computing
device 550 also includes a user interface 555 that includes a
display and may include at least one of a keyboard or keypad and a
computer mouse. The computing device 550 further includes a
communication port 545 communicatively coupled to the I/O module
510. The device 500 communicates information with an insulin pump
570 via the communication port 545. In some examples, the
communication port 545 is a wireless port and the device 500
communicates with the insulin pump 570 using wireless signals, such
as a radio frequency (RF) port or infrared (IR) port for example.
In some examples, the communication port 545 is a wired port (e.g.,
a serial port) and the device 500 communicates with the insulin
pump using a removable communication cable.
[0034] The rule module 515 applies a rule to generate at least one
insulin pump setting. The I/O module 510 presents the setting to a
user as a suggested insulin pump setting via the user interface
555. The I/O module 510 also presents a request for confirmation of
the insulin pump setting. When the I/O module 510 receives a
confirmation, such as through the user interface 555 for example,
the I/O module 510 communicates the insulin pump setting to the
insulin pump 570 via the communication port 545.
[0035] As set forth previously, a rule may be customized. In some
examples, the controller 505 includes a rule development module 560
to develop a rule via edits received via the I/O module 510. The
rule development module 560 is a rule editor that edits existing
rules in addition to generating new rules. In some examples, the
rule development module 560 displays a representation 580 of the
rule when the I/O module 510 is communicatively coupled to the user
interface 555. The rule development module 560 converts a
manipulation of the displayed representation 580 via the user
interface into the edit to the rule.
[0036] The rule development module 560 provides doctors or clinical
experts the ability to develop and generate a new rule (or rule
set) or to modify rules via the user interface 555. The computing
device 550 includes software that provides a flexible framework to
create or modify rules such as by updating a graphical decision
tree or a look-up table for example. The software may be included
in a computer readable medium, such as a compact disc (CD) for
example, or the software may be downloaded to the computing device
550 from remote storage, such as from a server for example. The
computing device 550 uses the communication port 545 to communicate
the rule or rule set to the insulin pump 570.
[0037] Once a rule is developed, the doctor or clinical expert
could publish or otherwise share a rule or set of rules. In some
embodiments, rule sets can be stored in remote storage, such as a
server for example. The computing device 550 may be connected to a
communication network, such as the internet or a cell phone network
for example. A doctor or clinical expert may download a rule or
rule set from the remote storage and either download the rule set
directly from the computing device 550 into the insulin pump device
570 or modify the rule or rule set before downloading the modified
rule or rule set to the insulin pump device 570.
[0038] Returning to FIG. 4, the controller 405 may include a rule
development module. The user interface 430 receives edits to a rule
or rule set. The edits are entered into the device 400 manually by
the user via the user interface 430. For example, the user may step
through the rule with the aid of a display included in the user
interface 430. The user may then alter the rule with a keypad
included in the user interface 430. For example, the user may enter
a new look up table entry using the key pad, or add another branch
to a decision tree or edit a branch of the decision tree. In
certain examples, an entire new rule or rule set is entered
manually into the device 400 via the user interface 430.
[0039] In some examples, the device 400 of FIG. 4 or the insulin
pump device 570 of FIG. 5 stores data to track effectiveness of a
new rule or modified rule. For example, the insulin pump device 570
may track the number of times the blood glucose level of the
patient returned to a target blood glucose level or to within a
target range of levels after application of the rule. The
effectiveness may be displayed as a percentage or as X successes
out of Y applications on either a display of the insulin pump
device 570 or uploaded and displayed on a separate device, such as
the computing device 550 in FIG. 5 for example.
[0040] Returning to the device of FIG. 2, in some examples, the
rule module 215 assigns weights to corresponding table entries in a
rule. For example, a certain type of exercise (e.g. higher
intensity) may be weighted higher when determining whether to
suggest a different basal rate for the patient during the exercise
(versus suggesting a food to eat before exercise of lower
intensity). In some examples, the rule module 215 uses one or more
fuzzy logic rules to determine the question for display and any
recommended action. The fuzzy logic rules may be used to blend any
weighted questions, responses, or actions. In some examples, the
rule module 215 uses a rule involving application of artificial
intelligence methods to determine the questions and the actions to
be presented. In some examples, the weighting used by the rule is
customizable.
[0041] In some examples, the memory 220 stores a database of food
options in association with a known amount of nutrient content. The
rule module 215 uses the patient health, lifestyle, and demographic
information set forth above and generates a suggested database of
food options. For example, if the patient lifestyle information
indicates that the patient tends to eat high glycemic index foods,
or the patient health information indicates that the patient is
pregnant, the suggested data base may include mostly low glycemic
foods. If the controller 205 is included in a computing device 550
of FIG. 5 or other type of device, that device communicates the
suggested database to the insulin pump device 570 where it is
stored. If the controller 205 is included in an insulin pump device
as in FIG. 4, the controller 405 only displays the suggested
portion of the database to a user.
[0042] Without an expert system, a pump user may go through several
iterations of trial and error in finding appropriate insulin pump
settings. In some examples, the device 200 uses blood glucose
information as feedback to better tune insulin pump settings. The
rule module 215 applies the rule to blood glucose information, such
as blood glucose data taken using a blood glucose monitor (GM), to
determine one or more insulin pump settings.
[0043] The I/O module 210 may present an action for the user to
take. In some examples, the action presented may be a prompt for
the user to enter blood glucose data into the device, download
blood glucose data into the device, or to begin a blood glucose
measurement. For example, the action presented may be a prompt to
measure blood glucose level from a finger stick and to enter the
data into the I/O module 210 through a user interface. In some
examples, the device 200 includes a communication port
communicatively coupled to the controller 205. The I/O module 210
receives the blood glucose data via the communication port from a
second separate device that includes a glucose monitor. In some
examples, the communication port includes a wireless communication
port. A separate device may obtain the blood glucose data during a
test executed using an insulin pump. In some examples, the device
200 includes an insulin pump communicatively coupled to the
controller 205.
[0044] In some examples, the device 200 includes a GM. FIG. 6 is a
diagram of another example of a device 600 to provide assistance in
maintaining and adjusting a patient's insulin pump therapy. The
device 600 includes a controller 605 communicatively coupled to a
memory 620. The controller 605 includes an I/O module 610 and a
rule module 615. The device also includes a GM 680 communicatively
coupled to the controller 605. In some examples, the device 600
also includes an insulin pump communicatively coupled to the
controller 605.
[0045] If the GM 680 is a continuous GM, no action is needed from
the user to obtain blood glucose data. A continuous GM includes a
blood glucose sensor to produce a blood glucose signal
representative of a blood glucose level of the patient. The blood
glucose sensor may sense blood glucose concentration from blood or
interstitial fluid. The blood glucose sensor circuit may include a
sensor interface circuit to sample the blood glucose signal and may
provide additional signal processing such as filtering or
amplification for example. The blood glucose sensor circuit may
provide sampled blood glucose data to the I/O module 610. A
description of a blood glucose sensor circuit can be found in Steil
et al., U.S. Pat. No. 6,558,351, filed Jun. 1, 2000.
[0046] Returning to FIG. 2, the action presented by the I/O module
210 may include prompting the user to begin a test or a series of
tests in which blood glucose data is monitored and received into
the device 200 via the I/O module 210. A test may be executed using
an insulin pump. The rule module 215 applies the rule to at least
one of the blood glucose data and the patient information to
determine an insulin pump setting. In some examples, the rule
module 215 generates an insulin pump setting that includes a target
blood glucose level for the patient. The target blood glucose level
may be a range of blood glucose levels.
[0047] Because a patient's basal insulin needs may change over
time, such as with weight change or with a change in fitness level,
basal rate testing may be performed periodically to ensure that an
appropriate basal rate is being delivered by an insulin pump. Based
on blood glucose data (e.g., the blood glucose level of the patient
is not at the target blood glucose level), the rule module 215 may
determine from the rule that a basal rate test should be run (by
either the insulin pump included with the device 200 or a separate
device). The I/O module 210 may present (such as by display) a
suggestion to the user to execute a basal rate test. As a result of
the basal rate test, the rule module 215 generates one or more
basal rate patterns or profiles. The I/O module 210 may display a
recommendation to change a programmable basal rate pattern of the
insulin pump. Descriptions of devices and methods that perform a
basal rate test are found in Blomquist et al., "Basal Rate Testing
Using Frequent Blood Glucose Input," U.S. patent application Ser.
No. 11/685,617, filed Mar. 13, 2007, which is incorporated herein
by reference.
[0048] If a carbohydrate ratio is too small, the insulin pump may
determine a carbohydrate bolus that is too large for the
carbohydrates consumed. This may cause a low blood glucose level
within a few hours of the carbohydrate bolus (e.g., the blood
glucose level drops below 70 mg/dl). If a carbohydrate bolus is too
large, the insulin pump may determine a carbohydrate bolus that is
too small for the carbohydrates consumed. This may cause a high
blood glucose level within a few hours of a carbohydrate bolus.
[0049] Based on the blood glucose data, the rule module 215 may
determine that a recommendation to run a carbohydrate ratio test
should be presented. As a result of the carbohydrate ratio test,
the rule module 215 may generate a new carbohydrate ratio. The I/O
module 210 may present a recommendation to change the carbohydrate
ratio programmed in the insulin pump. In some examples, the rule
module 215 may generate a carbohydrate insulin bolus pattern or
profile to be delivered by the insulin pump. For example, the I/O
module 210 may display a recommended carbohydrate bolus pattern
that includes an extended carbohydrate bolus or a combination
bolus. Descriptions of devices and methods that perform a
carbohydrate ratio test are found in Blomquist, "Carbohydrate Ratio
Testing Using Frequent Blood Glucose Input," U.S. patent
application Ser. No. 11/679,712, filed Feb. 27, 2007, which is
incorporated herein by reference.
[0050] It is important for an insulin pump to use an effective
correction factor. If a correction factor for a pump is set too
high, the blood glucose may not actually be dropping as much as
estimated and could lead to high blood glucose levels. If the
correction factor is set too low, a correction bolus may provide
too much insulin and result in a low blood glucose level.
[0051] Based on the blood glucose data, the rule module 215 may
apply the rule to the blood glucose data and present a
recommendation that the user initiate a correction factor test. As
a result of the correction factor test, the rule module 215 may
generate a new a correction factor. The I/O module 210 may present
a recommendation to change the correction factor programmed in the
insulin pump. In some examples, the rule module 215 may generate an
insulin correction bolus pattern or profile. For example, the I/O
module 210 may display a recommended correction bolus such as a
pattern including different correction factors for different times
of the day for example. Descriptions of devices and methods that
perform a carbohydrate ratio test are found in Blomquist et al.,
"Correction Factor Testing Using Frequent Blood Glucose Input,"
U.S. patent application Ser. No. 11/626,653, filed Jan. 24, 2007,
which is incorporated herein by reference. If the device 200
includes an insulin pump, the controller 205 may executes one of
the tests described.
[0052] The examples set forth above involved the device 200
recommending an action for the user to take based on the blood
glucose data received into the device. In some examples, the rule
module 215 may use the blood glucose data to first generate a
question to be presented by the I/O module 210 before presenting an
action. The rule module 215 generates the suggested insulin pump
setting from application of the rule to the blood glucose data and
patient information received in response to the question. For
example, if the blood glucose data indicates blood glucose is low,
the rule may include a look up table having a question as to
whether the patient had a high activity level. If the device 200
receives a response through a user interface that the activity
level was high, the look up table may include a recommended action
corresponding to a table entry for low blood glucose and high
activity. The table entry may include a recommended action that the
patient eat before the activity or lower a programmable basal rate
of insulin before, during, or after the activity.
[0053] In some examples, the controller 205 determines a rate of
change of a blood glucose level of the patient from the blood
glucose data. As an illustrative example, the controller 205 may
determine that the blood glucose concentration level is increasing
or decreasing at a rate of 2 to 4 mg/di/min (milligrams per
deciliter per minute). The rule module 215 may apply one or more
rules to the rate of change of a blood glucose level to generate a
suggested insulin pump setting. If the blood glucose level is high
and increasing at a certain rate, the rule module 215 may apply the
rule to generate an insulin correction bolus pattern.
[0054] The action presented by the I/O module 210 may be a test or
tests that include a variety of steps. The tests may be included in
the rule module 215 and are designed to obtain data or other
information that is analyzed by the rule. The tests may occur over
a series of days. For example, during the test the device 200 may
instruct the insulin pump user to skip breakfast the first day,
skip lunch the second day, and skip dinner the third day. The
device 200 may display an action for the user that includes taking
blood glucose measurements at specified times in the test, such as
pre-meal, post-meal, and while fasting for example. The device 200
may ask the user to perform or not perform certain activities
(e.g., exercise) during the testing. The device may present an
action to the user to eat specific portions of food having specific
nutritional content. As part of the test, the device 200 may ask
the user to input patient information into the device 200 (e.g.,
through the user interface, or through a second separate device
that communicates with the device 200 via a communication port).
The patient information may include health information, stress
level information, or other information pertinent to later test
analysis.
[0055] After the testing, the device 200 presents one or more
questions to the user. The questions and responses from the user
are part of a post-test patient interview by the device 200. The
information from the patient interview and the blood glucose data
are then analyzed. The rule module 215 applies the rule to the
responses during the interview, the blood glucose data obtained as
part of the test, and any other test data. The rule module 215
generates changes to insulin therapy parameters. In some examples,
the changes are presented to the user, and the user has the option
of accepting the changes.
[0056] If the device 200 includes an insulin pump, the changes are
adopted by the device 200. If the device is a computing device such
as in FIG. 5, or a device that includes a GM that is separate from
the insulin pump, the changes may be communicated to the insulin
pump. According to some examples the functions can be accomplished
using multiple devices. For example, a first device may guide the
patient through the test or tests. This device may include an
insulin pump such as the device 400 in FIG. 4. The patient
interview and analysis may be done by a second device such as the
device 500 in FIG. 5.
[0057] As set forth previously, a rule or set of rules may be
customized, such as by a rule development module included in the
controller 205 for example. In some examples, all or substantially
all aspects of the rule are customizable, including the type of
tests to run, the sequence of tests to run, the steps in the tests,
and the criteria for making changes. An expert in the treatment of
diabetes would customize the rules to suit their standard of
practice.
[0058] According to some embodiments, the device 200 may present
changes other than insulin pump therapy parameters. In some
examples, the rule module 215 may generate a recommend change to a
patient lifestyle, such as a recommendation to exercise more or to
reduce smoking. The I/O module 210 presents the recommend changes
to the lifestyle of the patient. In some examples, the rule module
215 may generate a recommend change to a patient diet, such as a
recommendation to eat foods having a lower glycemic index or to
consume less alcohol.
[0059] It is to be understood that the above description is
intended to be illustrative, and not restrictive. For example, the
above-described embodiments (and/or aspects thereof) may be used in
combination with each other. Many other embodiments will be
apparent to those of skill in the art upon reviewing the above
description. The scope of the invention should, therefore, be
determined with reference to the appended claims, along with the
full scope of equivalents to which such claims are entitled. In the
appended claims, the terms "including" and "in which" are used as
the plain-English equivalents of the respective terms "comprising"
and "wherein." Also, in the following claims, the terms "including"
and "comprising" are open-ended, that is, a system, device,
article, or process that includes elements in addition to those
listed after such a term in a claim are still deemed to fall within
the scope of that claim. Moreover, in the following claims, the
terms "first," "second," and "third," etc. are used merely as
labels, and are not intended to impose numerical requirements on
their objects.
[0060] The Abstract of the Disclosure is provided to comply with 37
C.F.R. .sctn.1.72(b), requiring an abstract that will allow the
reader to quickly ascertain the nature of the technical disclosure.
It is submitted with the understanding that it will not be used to
interpret or limit the scope or meaning of the claims. In addition,
in the foregoing Detailed Description, it can be seen that various
features are grouped together in a single embodiment for the
purpose of streamlining the disclosure. This method of disclosure
is not to be interpreted as reflecting an intention that the
claimed embodiments require more features than are expressly
recited in each claim. Rather, as the following claims reflect,
inventive subject matter lies in less than all features of a single
disclosed embodiment. Thus the following claims are hereby
incorporated into the Detailed Description, with each claim
standing on its own.
* * * * *