U.S. patent application number 12/646113 was filed with the patent office on 2010-06-24 for combination communication device and medical device for communicating wirelessly with a remote medical device.
Invention is credited to Michael J. Celentano, Mathias Ehrsam, Paul J. Galley, Erich Imhol, Ulf Meiertoberens, Markus Oberli, Peter Sabol, Raymond Strickland.
Application Number | 20100160759 12/646113 |
Document ID | / |
Family ID | 39671858 |
Filed Date | 2010-06-24 |
United States Patent
Application |
20100160759 |
Kind Code |
A1 |
Celentano; Michael J. ; et
al. |
June 24, 2010 |
Combination communication device and medical device for
communicating wirelessly with a remote medical device
Abstract
An electronic device may selectively disable a bolus advice
process according to which the electronic device recommends
delivery of a bolus amount of a drug to a body of a user based on a
plurality of factors including glucose concentration of the user.
The electronic device may include a glucose measuring facility
configured to measure glucose concentration of a body fluid sample,
and a processor including a memory having instructions stored
therein that comprise the bolus advice process. The memory may
further have instructions stored therein that are executable by the
processor to request a glucose concentration measurement by the
glucose measurement facility prior to executing, or as part of, the
bolus advice process, and to disable execution of the bolus advice
process if a glucose concentration value resulting from the
requested glucose concentration measurement is less than a
threshold value.
Inventors: |
Celentano; Michael J.;
(Fishers, IN) ; Meiertoberens; Ulf; (Stocksund,
SE) ; Sabol; Peter; (Fishers, IN) ;
Strickland; Raymond; (Indianapolis, IN) ; Galley;
Paul J.; (Cumberland, IN) ; Oberli; Markus;
(Kirchberg, CH) ; Ehrsam; Mathias; (Bolligen,
CH) ; Imhol; Erich; (Utzenstorf, CH) |
Correspondence
Address: |
ROCHE DIAGNOSTICS OPERATIONS INC.
9115 Hague Road
Indianapolis
IN
46250-0457
US
|
Family ID: |
39671858 |
Appl. No.: |
12/646113 |
Filed: |
December 23, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
PCT/US2008/066262 |
Jun 9, 2008 |
|
|
|
12646113 |
|
|
|
|
60937779 |
Jun 29, 2007 |
|
|
|
60937933 |
Jun 29, 2007 |
|
|
|
Current U.S.
Class: |
600/365 ;
604/66 |
Current CPC
Class: |
G16H 40/67 20180101;
A61B 5/7475 20130101; A61M 2205/3569 20130101; G06F 1/1626
20130101; A61B 5/14532 20130101; A61M 5/172 20130101; G06F 1/169
20130101; G16H 20/17 20180101; G06F 1/1698 20130101; A61M 2205/3592
20130101; A61M 2209/01 20130101; A61M 5/14244 20130101; A61M
2205/502 20130101 |
Class at
Publication: |
600/365 ;
604/66 |
International
Class: |
A61B 5/145 20060101
A61B005/145; A61M 37/00 20060101 A61M037/00 |
Claims
1. An electronic device for selectively disabling a bolus advice
process according to which the electronic device recommends
delivery of a bolus amount of a drug to a body of a user based on a
plurality of factors including glucose concentration of the user,
the electronic device comprising: a glucose measuring facility
configured to measure glucose concentration of a body fluid sample,
and a processor including a memory having instructions stored
therein that comprise the bolus advice process, the memory further
having instructions stored therein that are executable by the
processor to request a glucose concentration measurement by the
glucose measurement facility prior to executing, or as part of, the
bolus advice process, and to disable execution of the bolus advice
process if a glucose concentration value resulting from the
requested glucose concentration measurement is less than a
threshold value.
2. The electronic device of claim 1 further comprising a display
device, and wherein the memory further includes instructions that
are executable by the processor to control the display device to
display a message indicating that the bolus recommendation glucose
concentration value.
3. The electronic device of claim 2 wherein the memory further
includes instructions stored therein that are executable by the
processor to compute a carbohydrate value based on the glucose
concentration value resulting from the requested glucose
concentration measurement and a target glucose concentration value,
the carbohydrate value corresponding to a quantity of carbohydrates
required to be taken by the user to increase glucose concentration
of the user to the target glucose concentration value.
4. The electronic device of claim 3 wherein the memory further
includes instructions stored therein that are executable by the
processor to control the display device to display the carbohydrate
value with instructions to consume carbohydrates in the amount of
the carbohydrate value, and wherein the threshold value corresponds
to a hypoglycemic threshold.
5. A method of controlling a color display of an electronic device,
the method comprising: determining a measured or computed value,
determining a display color based on the measured or computed value
relative to at least one limit or range, and changing a color of at
least a portion of the display to the display color when displaying
the measured or computed value or a message identifying the
value.
6. The method of claim 5 wherein the electronic device includes a
medical device that measures an analyte concentration in a liquid
sample.
7. The method of claim 6 wherein the medical device is a blood
glucose meter that measures glucose concentration in blood samples,
and wherein determining a display color based on the measured or
computed value comprises determining a display color based on a
measured glucose concentration relative to at least a target blood
glucose range.
8. The method of claim 7 wherein determining a display color
comprises selecting a first color if the measured glucose
concentration is within the target blood glucose range.
9. The method of claim 8 wherein determining a display color
comprises selecting a second color different from the first color
if the measured glucose concentration is between the target blood
glucose range and a low blood glucose value.
10. The method of claim 9 wherein determining a display color
comprises selecting a third color different from the first and
second colors if the measured glucose concentration is below the
low blood glucose value.
11. The method of claim 10 further comprising controlling the
display to display a warning message if the measured blood glucose
concentration is below the low blood glucose value.
12. The method of claim 10 wherein the low blood glucose value is a
hypoglycemic blood glucose threshold.
13. The method of claim 8 wherein determining a display color
comprises selecting a fourth color different from the first color
if the measured glucose concentration is between the target blood
glucose range and a high blood glucose value.
14. The method of claim 13 further comprising controlling the
display to display a warning message along with the fourth color if
the measured blood glucose concentration is below above the high
blood glucose value.
15. The method of claim 14 wherein the high blood glucose value is
a hyperglycemic blood glucose threshold.
16. The method of claim 5 wherein determining a measured or
computed value comprises computing a value, or receiving a computed
value, of a quantity of a drug to be delivered to a body.
17. A method of collecting in an electronic device time-based event
data stored in a medical device, the method comprising: wirelessly
sending by the electronic device a request for the time-based event
data, wirelessly sending by the medical device time-based event
data stored therein since previously wirelessly sending stored
time-based event data upon receiving the request for the time-based
event data, wirelessly sending by the electronic device an
acknowledgement signal upon receiving the time-event based data
from the another electronic device, and identifying by the medical
device a location in memory of the last item of the time-event
based data that was sent to the electronic device upon receiving
the acknowledgement signal.
18. The method of claim 17 wherein the medical device is a liquid
infusion pump and the time-based event data is time-based infusion
pump event data.
19. A method for enabling a bolus advice feature of an electronic
device according to which the electronic device recommends delivery
of a bolus amount of a drug to a body of a user based on a
plurality of factors including glucose concentration of the user,
the method comprising: disabling the bolus advice feature of the
electronic device during manufacture of the electronic device,
monitoring one of a flag and a memory location when the electronic
device is operable after manufacture thereof, and enabling the
bolus advice feature if one of the flag is activated and the memory
location includes a device pairing value.
20. The method of claim 19 wherein monitoring one of a flag and a
memory location comprises monitoring a flag, and further comprising
activating the flag if a predefined password is received by the
electronic device.
21. The method of claim 19 wherein monitoring one of a flag and a
memory location comprises monitoring a flag, and further comprising
activating the flag when the electronic device has been
successfully paired with another electronic device.
22. The method of claim 21 wherein the another electronic device
comprises an ambulatory medical device.
23. The method of claim 19 wherein monitoring one of a flag and a
memory location comprises monitoring a memory location, and further
comprising storing the device pairing value in the memory location
when the electronic device has been successfully paired with
another electronic device.
24. The method of claim 23 wherein the another electronic device
comprises an ambulatory medical device.
25. A method of maintaining a time and date in an electronic device
that communicates wirelessly with an ambulatory medical device, the
method comprising: establishing via the electronic device a
wireless communication link between the electronic device and the
ambulatory medical device, wirelessly sending by the medical device
time and date information, corresponding to a calendar date and
time of day maintained by the medical device, when the wireless
communication link is established, and modifying by the electronic
device a calendar date and time of day thereof if the time of day
received from the medical device time differs from the time of day
of the electronic device by more than a predefined time value.
26. The method of claim 25 wherein the electronic device includes a
my data feature according to which historical records stored within
the electronic device may be viewed, and wherein establishing via
the electronic device a wireless communication link between the
electronic device and the ambulatory medical device comprises
establishing the wireless communication link, if one is not already
established, when the electronic device enters the my data
feature.
27. The method of claim 25 wherein the electronic device includes a
bolus advice feature according to which the electronic device
recommends delivery of a bolus amount of a drug to a body of a user
based on a plurality of factors including glucose concentration of
the user, and wherein establishing via the electronic device a
wireless communication link between the electronic device and the
ambulatory medical device comprises establishing the wireless
communication link, if one is not already established, when the
electronic device enters the bolus advice feature.
28. The method of claim 25 wherein the electronic device includes
an on/off switch, and wherein establishing via the electronic
device a wireless communication link between the electronic device
and the ambulatory medical device comprises establishing the
wireless communication link, if one is not already established,
when the on/off switch is detected as transitioning from an off
state to an on state.
29. The method of claim 25 wherein a memory unit of the electronic
device has at least one automatic reminder stored therein, and
wherein establishing via the electronic device a wireless
communication link between the electronic device and the ambulatory
medical device comprises establishing the wireless communication
link, if one is not already established, when the at least one
automatic reminder powers on the electronic device from an off
state.
30. The method of claim 25 wherein the electronic device includes a
remote terminal operating mode according to which the electronic
device remote controls operation of the ambulatory medical device,
and wherein establishing via the electronic device a wireless
communication link between the electronic device and the ambulatory
medical device comprises establishing the wireless communication
link, if one is not already established, when the electronic device
exits the remote terminal operating mode.
Description
[0001] This application is a continuation of PCT/US2008/066262
filed Jun. 9, 2008 which is based on and claims priority to U.S.
Provisional Patent Application Ser. No. 60/937,779 and U.S.
Provisional Patent Application Ser. No. 60/937,933, both filed Jun.
29, 2007, all applications in this paragraph are hereby
incorporated by reference.
FIELD
[0002] This disclosure relates generally to electronic devices that
may include one or more on-board medical devices, and more
specifically to such electronic devices configured to wirelessly
communicate with at least on off-board medical device.
BACKGROUND
[0003] Remote electronic devices for wirelessly communicating with
at least one medical device are known. It is desirable to include
on the remote electronic device an on-board medical device, and/or
to conduct wireless communications between the remote electronic
device and an off-board medical device for the purpose of
commanding operation of the off-board medical device with the
remote electronic device.
SUMMARY
[0004] The present invention may comprise one or more of the
features recited in the attached claims, and/or one or more of the
following features and combinations thereof. An electronic device
is provided for selectively disabling a bolus advice process
according to which the electronic device recommends delivery of a
bolus amount of a drug to a body of a user based on a plurality of
factors including glucose concentration of the user. The electronic
device may comprise a glucose measuring facility configured to
measure glucose concentration of a body fluid sample, and a
processor including a memory having instructions stored therein
that comprise the bolus advice process, the memory further having
instructions stored therein that are executable by the processor to
request a glucose concentration measurement by the glucose
measurement facility prior to executing, or as part of, the bolus
advice process, and to disable execution of the bolus advice
process if a glucose concentration value resulting from the
requested glucose concentration measurement is less than a
threshold value.
[0005] The electronic device may further comprise a display device.
The memory may further include instructions stored therein that are
executable by the processor to control the display device to
display a message indicating that the bolus recommendation glucose
concentration value.
[0006] The memory may further include instructions stored therein
that are executable by the processor to compute a carbohydrate
value based on the glucose concentration value resulting from the
requested glucose concentration measurement and a target glucose
concentration value. The carbohydrate value may correspond to a
quantity of carbohydrates required to be taken by the user to
increase glucose concentration of the user to the target glucose
concentration value.
[0007] The memory may further include instructions stored therein
that are executable by the processor to control the display device
to display the carbohydrate value with instructions to consume
carbohydrates in the amount of the carbohydrate value. The
threshold value may correspond to a hypoglycemic threshold.
[0008] A method of controlling a color display of an electronic
device may comprise determining a measured or computed value,
determining a display color based on the measured or computed value
relative to at least one limit or range, and changing a color of at
least a portion of the display to the display color when displaying
the measured or computed value or a message identifying the
value.
[0009] The electronic device may include a medical device that
measures an analyte concentration in a liquid sample. The medical
device may be a blood glucose meter that measures glucose
concentration in blood samples. In this embodiment, determining a
display color based on the measured or computed value may comprise
determining a display color based on a measured glucose
concentration relative to at least a target blood glucose range.
For example, determining a display color may comprise selecting a
first color if the measured glucose concentration is within the
target blood glucose range. Determining a display color may further
comprise selecting a second color different from the first color if
the measured glucose concentration is between the target blood
glucose range and a low blood glucose value. Determining a display
color may further comprise selecting a third color different from
the first and second colors if the measured glucose concentration
is below the low blood glucose value. The method may further
comprise controlling the display to display a warning message if
the measured blood glucose concentration is below the low blood
glucose value. The low blood glucose value may be a hypoglycemic
blood glucose threshold. Determining a display color may further
comprise selecting a fourth color different from the first color if
the measured glucose concentration is between the target blood
glucose range and a high blood glucose value. The method may
further comprise controlling the display to display a warning
message along with the fourth color if the measured blood glucose
concentration is below above the high blood glucose value. The high
blood glucose value may be a hyperglycemic blood glucose
threshold.
[0010] Determining a measured or computed value may alternatively
or additionally comprise computing a value, or receiving a computed
value, of a quantity of a drug to be delivered to a body.
[0011] A method of collecting, in an electronic device, time-based
event data stored in a medical device may comprise wirelessly
sending by the electronic device a request for the time-based event
data, wirelessly sending by the medical device time-based event
data stored therein since previously wirelessly sending stored
time-based event data upon receiving the request for the time-based
event data, wirelessly sending by the electronic device an
acknowledgement signal upon receiving the time-event based data
from the another electronic device, and identifying by the medical
device a location in memory of the last item of the time-event
based data that was sent to the electronic device upon receiving
the acknowledgement signal.
[0012] The medical device may be a liquid infusion pump and the
time-based event data may be time-based infusion pump event
data.
[0013] A method is provided for enabling a bolus advice feature of
an electronic device according to which the electronic device
recommends delivery of a bolus amount of a drug to a body of a user
based on a plurality of factors including glucose concentration of
the user. The method may comprise disabling the bolus advice
feature of the electronic device during manufacture of the
electronic device, monitoring one of a flag and a memory location
when the electronic device is operable after manufacture thereof,
and enabling the bolus advice feature if one of the flag is
activated and the memory location includes a device pairing
value.
[0014] Monitoring one of a flag and a memory location may comprise
monitoring a flag. The method may further comprise activating the
flag if a predefined password is received by the electronic device.
Alternatively or additionally, the method may further comprise
activating the flag when the electronic device has been
successfully paired with another electronic device. The another
electronic device may comprises an ambulatory medical device.
[0015] Monitoring one of a flag and a memory location may comprise
monitoring a memory location. The method may further comprise
storing the device pairing value in the memory location when the
electronic device has been successfully paired with another
electronic device. The another electronic device may comprise an
ambulatory medical device.
[0016] A method of maintaining a time and date in an electronic
device that communicates wirelessly with an ambulatory medical
device may comprise establishing via the electronic device a
wireless communication link between the electronic device and the
ambulatory medical device, wirelessly sending by the medical device
time and date information, corresponding to a calendar date and
time of day maintained by the medical device, when the wireless
communication link is established, and modifying by the electronic
device a calendar date and time of day thereof if the time of day
received from the medical device time differs from the time of day
of the electronic device by more than a predefined time value.
[0017] The electronic device may include a "my data" feature
according to which historical records stored within the electronic
device may be viewed. Establishing via the electronic device a
wireless communication link between the electronic device and the
ambulatory medical device may comprise establishing the wireless
communication link, if one is not already established, when the
electronic device enters the my data feature.
[0018] Alternatively or additionally, the electronic device may
include a bolus advice feature according to which the electronic
device recommends delivery of a bolus amount of a drug to a body of
a user based on a plurality of factors including glucose
concentration of the user. Establishing via the electronic device a
wireless communication link between the electronic device and the
ambulatory medical device may comprise establishing the wireless
communication link, if one is not already established, when the
electronic device enters the bolus advice feature.
[0019] Alternatively or additionally, the electronic device may
include an on/off switch. Establishing via the electronic device a
wireless communication link between the electronic device and the
ambulatory medical device may comprise establishing the wireless
communication link, if one is not already established, when the
on/off switch is detected as transitioning from an off state to an
on state.
[0020] Alternatively or additionally, a memory unit of the
electronic device may have at least one automatic reminder stored
therein. Establishing via the electronic device a wireless
communication link between the electronic device and the ambulatory
medical device may comprise establishing the wireless communication
link, if one is not already established, when the at least one
automatic reminder powers on the electronic device from an off
state.
[0021] Alternatively or additionally, the electronic device may
include a remote terminal operating mode according to which the
electronic device remote controls operation of the ambulatory
medical device. Establishing via the electronic device a wireless
communication link between the electronic device and the ambulatory
medical device may comprise establishing the wireless communication
link, if one is not already established, when the electronic device
exits the remote terminal operating mode.
BRIEF DESCRIPTION OF THE DRAWINGS
[0022] FIG. 1 shows a block diagram of one illustrative embodiment
of a wireless communication system including a medical device and a
remote electronic device that are both configured to wirelessly
communicate with each other.
[0023] FIG. 2 shows a block diagram schematic of one illustrative
embodiment of an electronic circuit that is carried by, and that
controls, the remote electronic device of FIG. 1.
[0024] FIG. 3 shows a block diagram schematic of some of the
details of one illustrative embodiment of the memory subsystem of
the remote electronic device of FIG. 2.
[0025] FIG. 4 shows a flowchart of one illustrative embodiment of a
process for enabling a bolus advice feature of the remote
electronic device.
[0026] FIG. 5 shows a flowchart of one illustrative embodiment of a
process carried out in the remote electronic device for
establishing wireless communications between the remote electronic
device and the medical device.
[0027] FIG. 6 shows a flowchart of one illustrative embodiment of a
process carried out in the remote electronic device for processing
information after a wireless connection is established between the
remote electronic device and the medical device.
[0028] FIG. 7 shows a diagram of one illustrative embodiment of a
number of databases defined in the memory device of the remote
electronic device.
[0029] FIG. 8 shows a diagram of a data buffer in the medical
device that is configured to store time stamped medical device
events.
[0030] FIG. 9 shows a flowchart of one illustrative embodiment of a
process for transferring portions of the time stamped medical
device events from the medical device to the remote electronic
device.
[0031] FIGS. 10 and 11 show a flowchart of one illustrative
embodiment of a process carried out by the remote electronic device
for processing history data transferred from the medical device to
the remote electronic device.
[0032] FIGS. 12A-12C show a flowchart of one illustrative
embodiment of a bolus advice process carried out by the remote
electronic device.
[0033] FIG. 13 shows a flowchart of one illustrative embodiment of
a process for controlling the display of the remote electronic
device to indicate readily perceptible warnings and/or alerts.
[0034] FIG. 14 shows a flowchart of one illustrative embodiment of
a hypoglycemic test process.
[0035] FIG. 15 shows a graphic representation of one illustrative
embodiment of a bolus advice display screen produced by the process
of FIGS. 12A-12C.
[0036] FIG. 16 shows a flowchart of one illustrative sub-process
carried out by the remote electronic device in the bolus advice
process of FIGS. 12A-12C.
[0037] FIGS. 17A and 17B show a flowchart of another illustrative
sub-process carried out by the remote electronic device in the
bolus advice process of FIGS. 12A-12C.
[0038] FIG. 18 shows a flowchart of yet another illustrative
sub-process carried out by the remote electronic device in the
bolus advice process of FIGS. 12A-12C.
[0039] FIG. 19 shows a flowchart of still another illustrative
sub-process carried out by the remote electronic device in the
bolus advice process of FIGS. 12A-12C.
[0040] FIG. 20 shows a flowchart of a further illustrative
sub-process carried out by the remote electronic device in the
bolus advice process of FIGS. 12A-12C.
DETAILED DESCRIPTION
[0041] For the purposes of promoting an understanding of the
principles of the invention, reference will now be made to a number
of illustrative embodiments shown in the attached drawings and
specific language will be used to describe the same.
[0042] The following co-pending patent applications are
incorporated herein by reference: PCT Patent Application No.
PCT/US2008/066288, entitled APPARATUS AND METHOD FOR REMOTELY
CONTROLLING AN AMBULATORY MEDICAL DEVICE; PCT Patent Application
No. PCT/US2008/066331, entitled METHOD AND APPARATUS FOR
DETERMINING AND DELIVERING A DRUG BOLUS; PCT Patent Application No.
PCT/US2008/066267, entitled LIQUID INFUSION PUMP; PCT Patent
Application No. PCT/US2008/066299, entitled USER INTERFACE FEATURES
FOR AN ELECTRONIC DEVICE; PCT Patent Application No.
PCT/US2008/066247, entitled METHOD FOR PAIRING AND AUTHENTICATING
ONE OR MORE MEDICAL DEVICES AND ONE OR MORE REMOTE ELECTRONIC
DEVICES; PCT Patent Application No. PCT/US2008/066248, entitled
DEVICE AND METHODS FOR OPTIMIZING COMMUNICATIONS BETWEEN A MEDICAL
DEVICE AND A REMOTE ELECTRONIC DEVICE; and U.S. Provisional Patent
Application Ser. No. 61/130,855, entitled DEVICE AND METHODS FOR
OPTIMIZING COMMUNICATIONS BETWEEN AN ELECTRONIC DEVICE AND A
MEDICAL DEVICE.
[0043] Referring now to FIG. 1, a block diagram is shown of one
illustrative embodiment of a wireless communication system 10
including a remote electronic device 12 and medical device 14 that
are both configured to wirelessly communicate with each other. The
remote electronic device 12 has a housing through which a user
button section 16 extends. In one embodiment, the user button
section 16 defines a number of user buttons, keys or switches that
may be manually manipulated by a user to provide input to the
remote electronic device 12. A visual display unit 18 is carried by
the housing of the electronic device 12, and in one embodiment the
visual display unit 18 is provided in the form of a conventional
liquid crystal display (LCD), although this disclosure contemplates
using other conventional display units. Examples include, but are
not limited to, plasma displays, light emitting diode (LED) based
displays, vacuum fluorescent (VF) displays, and the like. In any
case, the visual display unit 18 is controlled by the electronic
device 12 to display information to a user of the device 12. In
alternative embodiments, the user button section 16 may be or
include one or more touch-sensitive buttons. In this embodiment,
one or more touch-sensitive buttons may, but not, form part of the
display unit 18.
[0044] The electronic device 12 further includes a carrier port 20
that extends into the housing from an opening defined therein. The
carrier port 20 is sized to receive therein a sample carrier or
strip 22 upon which a liquid sample containing an analyte has been
or will be deposited. The electronic device 12 includes electrical
circuitry that analyzes the liquid sample deposited on the sample
carrier 22, when the sample carrier 22 is received within the
carrier port 20, to determine a concentration of the analyte
contained in the liquid sample. In one embodiment, the liquid
sample is blood and the analyte is glucose. In this embodiment, the
sample carrier 22 may is illustratively provided in the form of a
glucose test strip, and the electrical circuitry of the electronic
device 12 includes conventional circuitry that measures the
concentration of glucose in a blood sample deposited on the test
strip 22. In alternative embodiments, the liquid sample may be or
include other bodily fluids, and the analyte may be any analyte
that is contained in a bodily fluid.
[0045] In the embodiment illustrated in FIG. 1, the electronic
device 12 further includes a conventional data key port 26 that
extends into the housing from an opening defined therein. The data
key port 26 defines an electrical interface or connector therein
that is configured to electrically connect to a complementarily
configured electrical interface or connector defined on a
conventional data key 24. The data key 24 includes a conventional
memory device (not shown) that is electrically connected to the
electrical interface or connector defined on the data key 24. The
memory device, e.g., ROM key, is electrically connected to the
electrical circuitry of the electronic device 12 via the electrical
interface defined on the data key 24 and the electrical interface
defined in the data key port 26 when the data key 26 is received
within the data key port 24. Generally, the memory device of the
data key 24 has calibration data stored therein that is specific to
a lot or batch of test strips 22, and the electrical circuitry of
the electronic device 12 uses the calibration data stored in the
memory device of the data key 24 to correct glucose concentration
measurements when using a test strip 22 from a corresponding lot or
batch of test strips as is known in the art. Typically, each lot or
batch of test strips 22 purchased by a user will include a
dedicated data key 24 that is to be used when measuring glucose
concentration with that lot or batch of strips.
[0046] It will be understood that while the carrier port 20, sample
carrier 22 and electrical circuitry of the electronic device 12
have been described in one embodiment as being configured to
measure the glucose concentration of blood samples deposited on the
sample carrier 22, this disclosure contemplates other embodiments
in which the carrier port 20, sample carrier 22 and/or electrical
circuitry of the electronic device 12 is/are configured to measure
other analytes in other liquid samples.
[0047] The medical device 14 includes a conventional processor 28
that is electrically connected to a wireless communication circuit
30. The processor 28 includes a conventional memory unit 25 which
has stored therein a number of processes in the form of
instructions that are executable by the processor 28 to control
operation of the medical device 14 and to wirelessly communicate
with the electronic device 12. In the illustrated embodiment, the
medical device 14 further includes conventional non-volatile memory
units 27 and 29. In one embodiment, the non-volatile memory unit 27
is provided in the form of a conventional ferroelectric random
access memory (FRAM) and the non-volatile memory unit 29 is
provided in the form of a conventional electrically erasable
programmable read only memory (EEPROM), although either memory unit
27, 29 may alternatively be provided in the form of one or more
other conventional non-volatile memory units. In any case, the
memory units 27 and 29 are each external to the processor 28 and
are each electrically connected to the processor 28. In one
illustrative embodiment in which the medical device is a drug
infusion pump, as will be described in greater detail hereinafter,
the memory unit 27 is a pump delivery (PD) memory unit in which the
processor 28 stores current pump delivery information, and the
memory unit 29 is a pump history (PH) memory unit that has stored
therein pump history information, e.g., in the form of event
records each corresponding to an operational event of the pump 14.
The medical device 14 further includes a wireless communication
circuit 30 that is configured to communicate wirelessly with a
similar wireless communication module of the remote electronic
device 12 via a wireless communication link 40 in a conventional
manner. In one embodiment, as will be illustrated by example
throughout this disclosure, the wireless communication circuit 30
and the wireless communication module of the electronic device 12
are both conventional BlueTooth.RTM. modules configured to
wirelessly communicate according to a conventional BlueTooth.RTM.
communication protocol. It will be understood, however, that the
wireless communication circuit or module 30 and the wireless
communication module of the electronic device 12 may alternatively
be configured to wirelessly communicate according to one or more
other communication protocols.
[0048] The medical device 14 illustratively includes a housing
through which a number of user keys 32 extend. The user keys 32 may
be provided in the form of any number of user selectable buttons,
keys or switches that are electrically connected to the processor
28. The medical device 14 further includes a visual display unit 34
that is carried by the housing and that is electrically connected
to the processor 28. The visual display unit 34 may be, for
example, a conventional liquid crystal display (LCD), plasma
displays, light emitting diode (LED) based display, vacuum
fluorescent (VF) display, or the like. The visual display unit 34
is controlled by the processor 28 to display information to a user
of the medical device 14. In alternative embodiments, the user keys
32 may be or include one or more touch-sensitive buttons. In this
embodiment, one or more touch-sensitive buttons may, but not, form
part of the display unit 34.
[0049] The processor 28 of the medical device 14 is further
electrically connected to a conventional audible indication device
36 and to a conventional vibratory device 38. The processor 28 is
generally operable to control the audible indication device 36 and
the vibratory device 38 to produce one or more audible sounds
and/or vibrations respectively to notify the user of various
operational aspects of the medical device 14 and to also notify the
user of any alarm and/or warning conditions associated with the
medical device 14. In alternative embodiments, the medical device
14 may not include a display device 34 and/or user keys 32. In some
such embodiments, the medical device 14 may include one or more
visual indicators for conveying information to a user. Examples of
such visual indicators may include, but should not be limited to,
one or more lamps, one or more light emitting diodes (LEDs), or the
like.
[0050] In one illustrative embodiment, the medical device 14 is an
ambulatory medical device. Examples of ambulatory medical devices
include, but are not limited to, an implantable liquid delivery
pump or a non-implantable liquid delivery pump, such as a drug
infusion pump, an implantable or non-implantable body condition
sensor or sensor system, or the like. In embodiments in which the
electronic device 14 is a medication delivery pump, the medication
delivered by such a pump may be or include, but should not be
limited to, insulin or other conventional blood glucose modifying
drug. In alternate embodiments, the liquid delivered by any such a
pump may be or include, but should not be limited to, one or a
combination of drugs, saline, one or a combination of perfusion
fluids, or the like. Throughout this disclosure, the medical device
14 and operations associated with the medical device 14 will be
described in the context of an insulin infusion pump, although it
will be understood that the medical device 14 may alternatively be
or include other medical devices and the following description
therefore should not be considered to be limited to an liquid
delivery pump generally or to an insulin infusion pump
specifically.
[0051] Referring now to FIG. 2, a block diagram schematic is shown
of one illustrative embodiment of an electronic circuit that is
carried by, and that controls, the remote electronic device 12 of
FIG. 1. In the illustrated embodiment, the electronic circuit
includes four modules with separate and distinct functional
responsibilities. For example, the electronic circuit includes a
User Interface (UI) processor 50 that is the main controller of the
electronic device 12. In addition to processing all aspects of the
user interfaces 16, 18, it is the origination and destination of
all data communicated from and to the insulin infusion pump 14. As
will be described in greater detail herein, the UI processor 50 has
no control over operation of the wireless communication circuit of
the remote electronic device 12. The UI processor 50 operates
according to a UI clock signal that is generated internally to the
UI processor 50. The UI processor 50 includes a memory unit 66
having instructions stored therein that are executable by the UI
processor 50 to control operations associated with the remote
electronic device 12. In one illustrative embodiment, the UI
processor 50 is a UPD70F3719GC 32-bit microcontroller that is
commercially available from NEC Electronics America of Santa Clara,
Calif., although this disclosure contemplates other implementations
of the UI processor 50.
[0052] The electronic circuit of FIG. 2 further includes a wireless
communication circuit 52 that is exclusively responsible for the
control of all wireless communications with one or more external
electronic devices but that does not control any other operations
associated with the electronic device 12. The wireless
communication circuit 52 operates from a clock signal that is
generated internally to the wireless communication circuit 52 and
that is not synchronized to the UI clock signal from which the UI
processor 60 operates. Operation of the wireless communication
circuit 52 is therefore asynchronous with respect to the operation
of the UI processor 60. In one illustrative embodiment, the
wireless communication circuit 52 is provided in the form of a
conventional BlueTooth.RTM. telemetry module that includes a
conventional processor and a memory unit 70, and that further
includes conventional wireless communication hardware such as a
suitable antenna. The memory unit 70 illustratively has stored
therein instructions that are executable by the processor of the
wireless communication circuit 52 to exclusively control of all
wireless communications with external devices, such as the insulin
infusion pump 14. In one illustrative embodiment, the wireless
communication circuit 52 is a BC419143B BlueCore.TM.4-Flash
Plug-n-Go.TM. single chip BlueTooth.RTM. radio and baseband
integrated circuit for BlueTooth.RTM. 2.4 GHz systems that is
commercially available from CSR of Richardson, Tex., although this
disclosure contemplates other implementations of the wireless
communication circuit 52. Alternatively, as described hereinabove,
this disclosure contemplates embodiments in which the wireless
communication module 52 is configured for wirelessly communication
according to wireless communication protocols other than
BlueTooth.RTM..
[0053] As illustrated in FIG. 2, the UI processor 50 and the
wireless communication module 52 each include debounce circuitry 64
and 68 respectively that is electrically connected to the user
buttons 16. The debounce circuitry 64, 68 is conventional in that
it reduces the sensitivity of the processors 50 and 52 to spurious
switching events associated with the user buttons 16, thereby
increasing the likelihood that only actual button presses are
detected by the processors 50 and 52.
[0054] The electronic circuit illustrated in FIG. 2 further
includes a memory subsystem 54 that is electrically connected to
the UI processor 50 and also to the wireless communication circuit
52. The memory subsystem 54 is generally operable to store, at
least temporarily, data moving between the UI processor 50 and the
wireless communication circuit 52. Data communication between the
memory subsystem 54 and the UI processor 50 is illustratively
carried out via a serial peripheral interface, SPI, in which case
the transfer of data between the memory subsystem 54 and the UI
processor 50 is synchronous with a data transfer clock, SCLK, of
the UI processor 50. Illustratively, data communication between the
memory subsystem 54 and the wireless communication circuit 52 is
carried out via a universal asynchronous receiver/transmitter
(UART) interface, in which case the transfer of data between the
memory subsystem 54 and the wireless communication circuit 52 is
asynchronous. In some alternative embodiments, the data transfer
interfaces may be interchanged such that data transfer between the
memory subsystem 54 and the UI processor 50 is asynchronous and
data transfer between the memory subsystem 54 and the wireless
communication circuit 52 is synchronous.
[0055] The memory subsystem 54 temporarily stores data moving
between the UI processor 60 and the wireless communication circuit
52. In some embodiments, the memory subsystem 54 does not control
other circuitry, and in some such embodiments the memory subsystem
54 may be provided in the form of a conventional memory device. In
other embodiments in which the memory subsystem 54 does or does not
control other circuitry, the memory subsystem 54 may be provided in
the form of a conventional processor that is configured to operate
as a Dual-Port RAM (DPR) processor. In such embodiments, the DPR
processor 54 operates from a clock signal that is separate from the
UI clock signal from which the UI processor 60 operates. In one
illustrative embodiment, such a DPR processor 54 is a MC9S08GT16A
8-bit microcontroller unit that is commercially available from
Freescale Semiconductor, Inc. of Austin, Tex., although this
disclosure contemplates other implementations of the memory
subsystem 54 that is provided in the form of a conventional
processor configured as a DPR processor 54.
[0056] The electronic circuit illustrated in FIG. 2 further
includes a Measurement Engine (ME) processor 56 that controls
analyte concentration measurements of liquid samples contained on
test elements 22, e.g., blood glucose measurements, and that
reports the analyte concentration measurement results to the UI
processor 50. The ME processor 56 includes a memory unit 83 having
instructions stored therein that are executable by the ME processor
56 to control analyte measurement operations. The ME processor 56
operates from an internally generated clock signal that is separate
from the clock signal from which the UI processor 50 operates. The
ME processor 56 is electrically connected to the UI processor 50
via an Event Interrupt line, TXD (data transmission) line and a
Ready line. The Event Interrupt line is illustratively used by the
ME processor 56 to notify the UI processor of analyte measurement
events, such as a strip insert event in which a user initiates an
analyte measurement. The TXD line is used by the ME processor 56 to
transmit analyte measurement data to the UI processor 50 for
display on the display unit 18, for storage thereof in a history
database and/or for use in conducting other operations. The Ready
line is used by the ME processor 56 to notify the UI processor 50
of the operational state, e.g., measuring or not measuring analyte
concentration, of the ME processor. In one illustrative embodiment,
the ME processor 56 is a MSP430T2AIPEG mixed-signal microcontroller
unit that is commercially available from Texas Instruments, Inc. of
Dallas, Tex., although this disclosure contemplates other
implementations of the ME processor 56.
[0057] As illustrated in FIG. 2, the ME processor 56, along with
other electrical components, form an analyte measuring facility 88,
e.g., a glucose meter. In addition to the ME processor 56, the
analyte measuring facility 88 further includes an application
specific integrated circuit (ASIC) 78 that is electrically
connected to the ME processor 56 and also to an electrical
interface 76 within the carrier port 20. In one illustrative
embodiment, when a sample carrier 22, e.g., a glucose test strip,
is inserted into the carrier port 20, electrical contacts on the
sample carrier 22 contact the electrical interface 76 to thereby
electrically connect the sample carrier 22 to the ASIC 78. A switch
80 contained in the ASIC is triggered by insertion of the carrier
22 into the carrier port 20, and an output of the switch 80 thus
notifies the ME processor 56 of insertion of a carrier 22 into the
carrier port 20. The ASIC 78 further illustratively includes a
clock circuit 82 that is programmable for a number of different
functions. For example, the clock circuit 82 may be programmed to
generate a signal to automatically turn on, e.g., power up, the
device 12 at one or more programmable times. As another example,
the clock circuit 82 may be programmed to generate a signal
corresponding to one or more reminders. Other examples will occur
to those skilled in the art, and such other examples are
contemplated by this disclosure. In any case, the signal generated
by the clock circuit 82 is provided to the ME processor 56, and the
ME processor 56 is responsive to the receipt of this signal to
power up from a sleep state if the ME processor 56 is in such a
sleep state, and to produce an event interrupt signal on the Event
Interrupt line. The event interrupt signal is received by the UI
processor 50, which then powers up from a sleep state if the UI
processor 50 is in such a sleep state, and/or generates an audible
or visible reminder corresponding to any reminder time programmed
in the clock circuit 82.
[0058] As illustrated in FIG. 2, the analyte measuring facility 88
further includes another electrical interface 84 that is positioned
within the code key port 26. Illustratively, when a code key 24 is
received within the code key port 26, electrical contacts on the
code key 24 electrically connect with the electrical interface 84
so that the ME processor 56 may read the calibration information
stored in the memory device of the code key 24. The analyte
measuring facility 88 further includes a temperature sensor 86 that
is electrically connected to the ME processor 56. In one
illustrative embodiment, the temperature sensor 86 is provided in
the form of a conventional thermistor, although this disclosure
contemplates other embodiments in which the temperature sensor 88
may be or include one or more other conventional temperature
sensors. In any case, the ME processor 56 is operable to receive a
temperature signal from the temperature sensor 86 that corresponds
to an operating temperature of the analyte measuring facility. In
one illustrative embodiment, the memory 83 has instructions stored
therein that are executable by the ME processor 56 to disable,
i.e., not conduct, analysis of an analyte containing sample if the
temperature signal produced by the temperature sensor 86 indicates
that the temperature of the analyte measuring facility 88 is less
than a threshold temperature. In such cases, the ME processor 56 is
further operable, pursuant to the instructions stored in the memory
83, to inform the UI processor 50 that the analyte measuring
facility is so disabled, and the UI processor 50 is operable,
pursuant to instructions stored in the memory unit 66, to control
the display device 18 to display a message indicating that the
temperature is too low to conduct analyte concentration
measurements.
[0059] The electronic circuit illustrated in FIG. 2 further
includes a general power supply 58 that provides a supply voltage
to the ASIC 78, the ME processor 56, the UI processor 50 and the
memory subsystem 54 on a continuous basis. The supply voltage is
derived by the general power supply circuit 58 from one or a series
or parallel combination of rechargeable or non-rechargeable
batteries (BATTERY) 60.
[0060] A dedicated power supply 62 provides a supply voltage, which
is also derived from the one or series or parallel combination of
rechargeable or non-rechargeable batteries (BATTERY) 60, to the
wireless communication module 52. The power supply 62 receives one
control input from the user buttons 16, and in the illustrated
embodiment the power supply 62 may be powered on and off via one or
a combination of the user buttons 16 via the one control input. The
power supply 62 also receives another control input from the
wireless communication circuit 52, and in the illustrated
embodiment the power supply 62 may be turned off by the wireless
communication circuit 52 via the other control input.
[0061] In addition to the display 18, the UI processor 50 is
electrically connected to a conventional audible indication device
72 and also to a conventional vibratory device 74. The UI processor
50 is generally operable to control the audible indication device
72 and the vibratory device 74 to produce one or more audible
sounds and/or vibrations respectively to provide for the capability
of the device 12 to produce corresponding audible and/or tactile
notifications, i.e., alarms or the like. In one embodiment, the
audible indication device 72 is a tone generator that produces a
beep or other tone when activated, although the audible indication
device 72 may alternatively or additionally be or include one or
more other conventional audible indication devices.
[0062] Generally, the memory subsystem 54 acts as an independent
repository of data packets moving between the UI processor 50 and
the wireless communication circuit 52. Referring to FIG. 3, a block
diagram of some of the details of the memory subsystem 54 is shown
along with electrical connections to the UI processor 50 and to the
wireless communication circuit 52. In the illustrated embodiment,
the memory subsystem 54 is provided in the form of a DPR processor
as described above, and FIG. 3 will be described in this context,
although it will be understood that the memory subsystem 54 may
alternatively be provided in other forms as described above.
[0063] In the embodiment illustrated in FIG. 3, one of the dual
ports of the DPR processor 54 is a serial peripheral interface
(SPI) port 92 that is electrically connected to a serial peripheral
interface port 90 of the UI processor 50 via a conventional serial
communications interface. The serial communications interface
operates from a serial clock signal, SCLK, (e.g., 125 kHz) that is
derived from the UI clock signal. Transfer of inbound and outbound
data between the SPI port 90 of the UI processor 50 and the SPI
port 92 of the DPR processor 54 is controlled by the UI processor
50 using the serial clock signal, SCLK, so that data transfer
between the two processors 50, 54 is synchronized.
[0064] The other of the dual ports of the DPR processor 54 is a
universal asynchronous receiver/transmitter (UART) port 96 that is
electrically connected to a UART port 94 of the wireless
communication circuit 52 via a conventional asynchronous interface.
Transfer of inbound and outbound data packets between the UART port
94 of the wireless communication circuit 52 and the UART port 96 of
the DPR processor 54 (e.g., at 150 kbps) is controlled by the
wireless communication circuit 52, and takes place asynchronously
with respect to the transfer of inbound and outbound data between
the SPI port of the UI processor 50 and the DRP processor 54.
[0065] The DPR processor 54 has an inbound data buffer 98 and an
outbound data buffer 100 that are each accessible by the SPI and
UART ports 92 and 96 respectively of the DPR processor 54. The UART
port 96 of the DPR processor 54 includes conventional clear to send
(CTS) and ready to send (RTS) lines. The CTS line is monitored by
the DPR processor 54 and the RTS line is monitored by the wireless
communication circuit 52. The DPR processor 54 deactivates the UART
RTS line whenever the inbound data buffer 100 is full, and
otherwise activates the UART RTS line. The wireless communication
circuit 52 activates the UART CTS line whenever the UART port of
the wireless communication circuit 52 is requesting data, and
otherwise deactivates the UART CTS line.
[0066] When data is to be sent by the UI processor 50 to an
external device or system, e.g., the insulin infusion pump 14, the
UI processor 50 first requests the state of the outbound data
buffer 100 of the DPR processor 54. If the DPR processor 54 answers
that its outbound data buffer 100 is "not full," the UI processor
50 transfers the data, or as much of the data as possible, to the
outbound data buffer 100 of the DPR processor 54 via the data out
(DO) line of the SPI port 90 at a rate determined by SCLK. If the
DPR processor 54 instead answers that the outbound data buffer 100
is "full," the UI processor 50 waits for a time interval and then
repeats the process of requesting the state of the outbound data
buffer 100, etc.
[0067] Periodically with respect to the clock signal of the
wireless communication circuit 52 and asynchronously with respect
to the SCLK signal, the wireless communication circuit 52 requests
data from the DPR processor 54 by activating the UART CTS line of
the DPR processor 54. As long as the outbound data buffer 100 of
the DPR processor 54 is empty, the wireless communication circuit
52 continues to periodically activate the UART CTS line. If the
UART CTS line is active and the outbound data buffer 100 of the DPR
processor 54 is not empty, the wireless communication circuit 52
retrieves the data from the outbound data buffer 100 of the DPR
processor 54 via the RX line of the UART port 96. The DPR processor
54 illustratively transfers the data stored in its outbound data
buffer 100 to its UART port 96 in a first received to last received
order until the outbound data buffer 100 has been emptied or until
the wireless communication circuit 52 deactivates the UART CTS
line. The wireless communication circuit 52 then incorporates the
data retrieved from the outbound data buffer 100 of the DPR
processor 52, via the data UART, into to the wireless communication
protocol structure, and wirelessly transmits the incorporated data
via conventional wireless signal transmission circuitry contained
within the wireless communication module 52. The wireless
communication circuit 52 does not process, interpret or alter the
contents of the data retrieved from the outbound data buffer 100 of
the DPR processor 54, nor does it make any decisions or execute any
steps based on the contents of the data. Rather, the wireless
communication circuit 52 treats all such data the same, regardless
of its contents, by incorporating the data into a predefined
wireless communication protocol structure, e.g., BlueTooth.RTM.
protocol structure, and then wirelessly transmitting the
incorporated data using the predefined wireless communication
protocol. Information transferred by the UI processor 50 to the
memory subsystem 54, and then from the memory subsystem 54 to the
wireless communication circuit 52 for wireless transmission to
another electronic device is thus referred to as outbound
information or data.
[0068] Inbound wireless signal transmissions from external devices
or systems, e.g., the insulin infusion pump 14, are received by the
wireless communication circuit 52 via conventional wireless signal
receiving circuitry of the wireless communication circuit 52. The
wireless communication circuit 52 first isolates the inbound data
from the wireless communication protocol structure, and then checks
the status of the UART RTS line of the DPR processor 54. If the RTS
line is activated, indicating that the inbound data buffer 98 of
the DPR processor 54 is not full, the wireless communication
circuit 52 sends the isolated data, or as much if the data as
possible, to the UART port 96 of the DPR processor 54. The DPR
processor 54 then places the data received at the UART port 96 into
the inbound data buffer 98 of the DPR processor 54. If the UART RTS
line is deactivated, indicating that the inbound data buffer 98 of
the DPR processor 54 is full, the wireless communication circuit 52
waits for a time interval before rechecking the state of the UART
RTS line.
[0069] Periodically, and asynchronously with respect to the
operation of the wireless communication circuit 52, the UI
processor 50 requests the state of the inbound data buffer 98 of
the DPR processor 54 via the data in (DI) line of the SPI port 90.
As long as the DPR processor 54 answers that the inbound data
buffer 98 is empty, the UI processor 50 continues to periodically
request the state of the inbound data buffer 98. If the DPR
processor 54 answers that the inbound data buffer 98 of the DPR
processor 54 contains data, the UI processor 50 retrieves the data
from the inbound data buffer 98 of the DPR processor 52 via the
data in (DI) line of the SPI port 90 using the SCLK signal, and
then processes the data according to its contents. "Checking" the
inbound and/or outbound data buffer 98, 100 of the DPR processor 54
by the wireless communication circuit 52 and/or UI processor 50, as
this term may be used hereinafter, will generally refer to the
process just described in the preceding several paragraphs. While
FIGS. 2 and 3 illustrate an embodiment in which the interface
between the UI processor 50 and the memory subsystem 54 is a
synchronous interface and the interface between the wireless
communication circuit 52 and the memory subsystem 54 is an
asynchronous interface, this disclosure contemplates alternative
embodiments in which the interface between the UI processor 50 and
the memory subsystem 54 is an asynchronous interface and the
interface between the wireless communication circuit 52 and the
memory subsystem 54 is an synchronous interface or in which both
interfaces are asynchronous or synchronous interfaces. In any case,
it should be apparent that the UI processor 50 at all times
operates independently and asynchronously with respect to the
operation of the wireless communication circuit 52, and the
wireless communication circuit 52 operates independently and
asynchronously with respect to the operation of the UI processor 50
and also with respect to the operation of the DPR processor 54.
[0070] The UI processor 50 controls the display 18 of the
electronic device 12 to indicate the connection status of the
wireless communication module 52 relative to the wireless telemetry
system of the insulin infusion pump 14. Upon power up of the
electronic device 12, following activation of the power supply 62
via the user buttons 16 after being deactivated and under certain
other operating conditions that will be described in greater detail
hereinafter, the UI processor 50 attempts to establish a wireless
connection with the insulin infusion pump 14. While a wireless
connection is not established between the electronic device 12 and
the insulin infusion pump 14, the UI processor 50 controls the
display 18 to display a flashing (or fixed) icon to indicate that
no wireless connection exists between the electronic device 12 and
the insulin infusion pump 14. The UI processor 50 independently
controls the display 18 in this manner without any information
provided by the wireless communication module 52. The UI processor
50 then initiates establishment of a wireless connection between
the remote electronic device 12 and the insulin infusion pump 14 by
placing a message into the data buffer 100 of the outbound port of
the memory subsystem 54, as described above. In this case, the
message includes a wireless connection request, e.g., in the form
of a command to transmit an acknowledgement response back to the
electronic device 12. The wireless communication circuit 52 then
transmits this message as described above. If the insulin infusion
pump 14 is within range, the insulin infusion pump 14 receives the
message and responds to the wireless connection request by
wirelessly transmitting a message that includes an acknowledgement
response. If the transmitted message is received by the electronic
device 12, the wireless communication circuit 52 is operable as
described above to isolate the message from the wireless
communication protocol structure and to place the message in the
data buffer 98 of the inbound port of the memory subsystem 54. The
UI processor 50 then retrieves the message from the inbound port of
the memory subsystem 54, processes the message to determine whether
it contains an acknowledgement response. If the message contains an
acknowledgement response, the UI processor 50 interprets this as
indicating that a wireless connection is now established between
the electronic device 12 and the insulin infusion pump 14, and
controls the display device 18 to display a fixed (or flashing)
icon to indicate that a wireless connection is established between
the electronic device 12 and the insulin infusion pump 14. The
electronic device 12 periodically transmits a wireless connection
status message to the infusion pump 14 in the above fashion at
regular intervals. As long as the insulin infusion pump 14 responds
as just described, the UI processor 50 controls the display 18 to
display the fixed (or flashing) icon to indicate that a wireless
connection exists between the electronic device 12 and the insulin
infusion pump 14. If the UI processor 50 does not receive such a
response within a predefined time period following storage of the
acknowledgement response in the memory subsystem 52, the UI
processor 50 controls the display 18 to display a flashing (or
fixed) icon indicating that the wireless connection between the
electronic device 12 and the insulin infusion pump 14 does not
exist or no longer exists.
[0071] In the illustrated embodiment the power supply 62 is
generally powered on as long as the wireless communication circuit
52 is communicating with either or both of the UI processor 50 or
the insulin infusion pump 14, unless otherwise powered off manually
by a user via the user buttons 16 or automatically by the wireless
communication circuit 52. For example, the power supply 62 may be
completely powered down, i.e., turned off, from any state via a
simultaneous or sequential user press of a number of the user
buttons 16. The power supply 62 remains in the completely powered
down state until the user again presses the simultaneous or
sequential number of the user buttons 16 or a different
simultaneous or sequential user press of a number of the user
buttons, or if the user powers down the electronic device 12 and
then powers back up the electronic device 12.
[0072] While the power supply 62 is on and supplying the supply
voltage to the wireless communication circuit 52, the wireless
communication circuit 52 is responsive to a number of different
events to transition itself into, and out of, any of a plurality of
different low power states, and to also turn off the power supply
62 after being in a lowest power sleep state for a predefined time
period of inactivity. For example, when in a fully powered "awake"
state, the wireless communication circuit 52 is operable to
periodically, e.g., every 100-200 milliseconds, check the outbound
data buffer 100 of the memory subsystem 54 as described above. As
another example, each time the wireless communication circuit 52
finds data to be sent in the outbound data buffer 100 of the memory
subsystem 54, the wireless communication circuit 52 incorporates
the data into the predetermined wireless communication protocol
structure, and wirelessly transmits corresponding signals to the
insulin infusion pump 14 as described above. The wireless
communication circuit 52 transitions to a first low power state if
it fails to find data in the outbound data buffer 100 of the memory
subsystem 54 when a predefined time period elapses since last
finding data in the outbound data buffer 100. Thereafter, the
wireless communication circuit 52 transitions to successively lower
power states as successively longer time periods elapse since last
finding data in the outbound data buffer 100. The number of
different power states generally range between full (100%) power
and a lowest power "deep sleep" state, and may include any number
of reduced power states between these two extremes. When in the
lowest power "deep sleep" state, the wireless communication circuit
52 periodically, e.g., every 400 milliseconds, wakes up to a "UART
only" state, in which the wireless communication circuit 52 has
sufficient power to check the status of the outbound data buffer
100 of the memory subsystem 54 via the data UART line. If the
outbound data buffer 100 of the memory subsystem 54 has data stored
therein, the wireless communication circuit 52 wakes up to a full
power state to service the data. If the outbound data buffer 100 of
the memory subsystem 54 has no data stored therein, the wireless
communication circuit 52 transitions back to the lowest power "deep
sleep" state. After being in the lowest power sleep state for a
predefined period of time of inactivity, the wireless communication
circuit 52 sends a control signal to the power supply 62 that
causes the power supply 62 to turn off. As a further example, the
wireless communication circuit 52 directly monitors activity of the
user buttons 16 via the debounce circuitry 68, and when the
wireless communication circuit 52 detects user press of the ON
button, the wireless communication processor transitions itself
from any of the lower power states to the full power state. Thus,
in the lowest power "deep sleep" state, the wireless communication
circuit 52 must be capable of monitoring at least the ON button of
the user buttons 16. Similarly, when the wireless communication
circuit 52 detects user press of the OFF button, the wireless
communication circuit 52 transitions itself from any of the power
states to the lowest power "deep sleep" state.
[0073] When a wireless connection is established between the
electronic device 12 and the insulin infusion pump 14, and the UI
processor 50 determines that the wireless connection should be
terminated, the UI processor 50 stores a message in the outbound
data buffer 100 of the memory subsystem 54 that contains a
connection termination request. When the wireless communication
circuit 52 thereafter finds the message in the outbound data buffer
100 of the memory subsystem 54, the wireless communication circuit
52 incorporates the message into the predetermined wireless
communication protocol and then transmits the message via its
wireless communication circuitry to the insulin infusion pump 14.
The insulin infusion pump 14 then wirelessly sends a signal
containing a predefined connection termination response back to the
remote electronic device 12. Subsequently the processor 28
instructs the wireless communication circuit 30 to orderly
terminate communications or connections with the wireless
communications circuit 52' that may be specific to the
predetermined wireless communications protocol. When the wireless
connection is terminated in this manner, the wireless communication
circuit 52 is operable to periodically, but asynchronously with
respect to operation of the UI processor 50, check the outbound
data buffer 100 of the memory subsystem 54. If no data resides in
the outbound data buffer 100, the wireless communication circuit 52
successively enters lower power sleep states or modes as described
above. If, however, the wireless communication circuit 52 finds
data in the outbound data buffer 100 of the memory subsystem 54,
the wireless communication circuit 52 attempts to establish (or
re-establish) a wireless connection with the wireless communication
circuit 30 of the insulin infusion pump 14 as described above.
[0074] If, after a predefined or programmed number of attempts
and/or elapsed time, no wireless connection can be established
between the wireless communication circuit 52 and the wireless
communication circuit 30, the wireless communication circuit 52
illustratively clears the outbound data buffer 100 of the memory
subsystem 54. Alternatively, the UI processor 50 may clear the
outbound data buffer 100 if it determines that data exists in the
outbound data buffer 100 after some time period has elapsed since
storing the wireless communication message in the outbound data
buffer 100 or after some time period has elapsed after determining,
based on failure to receive acknowledgements from the insulin
infusion pump 14, that a wireless connection between the remote
electronic device 12 and the insulin infusion pump 14 no longer
exists. In any case, with the outbound data buffer 100 of the
memory subsystem 54 empty, the wireless communication circuit 52
successively enters lower power sleep states or modes as described
above.
[0075] In the event of a lost wireless connection between the
remote electronic device 12 and the insulin infusion pump 14, the
wireless communication circuit 52 is operable in one embodiment to
turn off its wireless transmission circuitry and to transition to a
low power state if it fails to find data in the outbound data
buffer 100 of the memory subsystem 54 since last finding data in
the outbound data buffer 100. Because the wireless connection is
lost, the UI processor 50 will no longer receive acknowledgements
from the insulin infusion pump 14 and will therefore cease to store
messages in the outbound data buffer 100 of the memory subsystem
54. However, a message, or at least part of a message, may reside
within the outbound data buffer 100 when the wireless connection is
lost. In this case, after a predefined or programmed number of
attempts and/or after a predefined or programmed elapsed time, no
wireless connection can be established with the insulin infusion
pump 14, the wireless communication circuit 52 illustratively
clears the outbound data buffer 100 of the memory subsystem 54.
Alternatively, the UI processor 50 may clear the outbound data
buffer 100 if it determines that data exists in the outbound data
buffer 100 after some time period has elapsed since last storing a
message in the outbound data buffer 100 or after some time period
has elapsed after determining, based on failure to receive
acknowledgements from the insulin infusion pump 14, that a wireless
connection between the devices 12 and 14 no longer exists. In any
case, with the outbound data buffer 100 of the memory subsystem 54
empty, the wireless communication circuit 52 successively enters
lower power sleep states or modes as described above.
[0076] In one illustrative embodiment, the UI processor 50 and the
processor 28 of the insulin infusion pump 14 may use scheduled
messages and internal timers to control determinations by each of
whether a wireless connection between the remote electronic device
50 and the insulin infusion pump 14 exists. For example, during
information exchange between the electronic device 12 and the
insulin infusion pump 14, the UI processor 50 is operable to
periodically, e.g., every 100 milliseconds, transfer a message to
the outbound data buffer 100 of the memory subsystem 54 and to
reset an internal timer circuit. The wireless communication circuit
52 asynchronously retrieves the message from the outbound data
buffer 100 of the memory subsystem 54 and transmits the message to
the insulin infusion pump 14 as described above. The insulin
infusion pump 14 is responsive to receipt of the message to
immediately transmit a message back to the electronic device 12
that contains an acknowledgement. The message transmitted by the
insulin infusion pump 14 is received and unpacked from the wireless
communication protocol by the wireless communication circuit 52,
and then stored by the wireless communication circuit 52 in the
inbound data buffer 98 of the memory subsystem 54. The UI processor
50 then retrieves the message from the inbound data buffer 98 of
the memory subsystem 54 and processes the message to determine
whether it contains an acknowledgement. As long as an
acknowledgement is received by the UI processor 50 in this manner
before the next scheduled transfer of a message to the outbound
data buffer 100 of the memory subsystem 54, the UI processor 50
resets its internal timer circuit when transferring the next
message to the memory subsystem 54. However, if an acknowledgement
is not received by the UI processor 50 before the next scheduled
transfer of a message to the outbound data buffer 100 of the memory
subsystem 54, the UI processor 50 transfers the message to the
outbound data buffer 100 of the memory subsystem 54 without
resetting its internal timer circuit. If no acknowledgement is
received by the UI processor 50 within a predefined or programmed
time period, e.g., 1-2 minutes, the internal timer circuit of the
UI processor 50 times out and the UI processor 50 stops
transferring messages to the outbound data buffer 100 of the memory
subsystem 54. The insulin infusion pump 14, in this embodiment,
ceases to send acknowledgements back to the remote electronic
device 12 after a predefined or programmed time period, e.g., 2
minutes, has passed without receiving a message transmitted by the
electronic device 12.
[0077] Illustratively, the UI processor 50 is operable to cease
storing messages in the outbound data buffer 100 of the memory
subsystem 54 upon detection of insertion of a sample carrier 22
into the carrier port 20 as described above. After a predefined
time period in which the wireless communication circuit 52
thereafter fails to find such messages in the outbound data buffer
100 of the memory subsystem 54, the wireless communication circuit
52 begins transitioning to lower power states as described above.
When the UI processor 50 then resumes storing messages in the
outbound data buffer 100 of the memory subsystem 54 after the
analyte measurement is complete, the wireless communication circuit
52 wakes up to full power to service it. This may take at least a
wake up time period, e.g., as much as 400 milliseconds, if the
wireless communication circuit 52 has just entered the lowest power
"deep sleep" state when the first message is stored in the outbound
data buffer 100 of the memory subsystem 54 after the analyte
measurement is complete.
[0078] Unless the remote electronic devices 12 and the insulin
infusion pump 14 are communicating information, the wireless
communication circuit 52 is generally in one of the lower power
sleep states or modes. When insertion of a sample carrier 22 into
the carrier port 20 is detected, the electronic device 12 performs
an analyte determination test as described above. The electronic
device 12 generally does not wirelessly communicate with the
insulin infusion pump 14 during the analyte determination test, and
the wireless communication circuit 52 is thus typically in one of
the lower power sleep states when insertion of the sample carrier
22 into the carrier port 20 is detected. Because the UI processor
50 stops storing messages in the outbound data buffer 100 of the
memory subsystem 54 when insertion of the sample carrier 22 into
the carrier port 20 is detected, the wireless communication circuit
52 therefore typically enters successively lower power sleep states
after insertion of the sample carrier 22 into the carrier port 20
is detected.
[0079] While the electronic device 12 is illustrated and described
above with respect to FIGS. 1-3 as including an analyte measuring
facility 88, such an analyte measuring facility may be omitted in
alternative embodiments. In any case, the electronic device 12 and
the insulin infusion pump 14 may illustratively be paired according
to a pairing process that establishes secure communications between
the electronic device 12 and the insulin infusion pump 14.
Illustratively, this process may be carried out to initially
establish secure wireless communications between the electronic
device 12 and a particular insulin infusion pump 14, and then again
if the electronic device 12 is to be paired with a different
insulin infusion pump 14 or vice versa. In one illustrative
embodiment, the electronic device 12 may only be paired with a
single insulin infusion pump 14 at a time, although this disclosure
contemplates other embodiments in which the electronic device 12
may be paired with any number of medical devices 14 generally
and/or other electronic devices, and/or in which the medical device
14 may be paired with any number of electronic devices 12 or other
medical devices. In any case, further details relating to one
illustrative pairing and authentication process are provided in
co-pending PCT Patent Application No. PCT/US2008/066247, entitled
METHOD FOR PAIRING AND AUTHENTICATING ONE OR MORE MEDICAL DEVICES
AND ONE OR MORE REMOTE ELECTRONIC DEVICES, the disclosure of which
has been incorporated herein by reference.
[0080] Referring now to FIG. 4, a flow chart is shown of one
illustrative embodiment of a process 110 for enabling a bolus
advice feature of the remote electronic device 12. Illustratively,
the process 110 is stored in the memory unit 66 of the UI processor
50 in the form of instructions that are executable by the UI
processor 50 to enable the bolus advice feature. The process 110
begins at step 112 where the bolus advice feature of the remote
electronic device 12 is disabled during manufacture of the remote
electronic device 12.
[0081] In one embodiment, the process 110 advances from step 112 to
step 114 where the UI processor 50 is operable to monitor a
predefined password flag. Thereafter at step 116, the UI processor
50 is operable to determine whether the predefined password flag is
active. If not, execution of the process 110 loops back to step
114. If; at step 116, the UI processor 50 determines that the
predefined password flag is active, the process 110 advances to
step 118 where the UI processor 50 is operable to enable the bolus
advice feature of the remote electronic device 12. Following step
118, the process 110 ends.
[0082] In an alternate embodiment, as illustrated in FIG. 4, the
process 110 may advance from step 112 to step 120 where the UI
processor is operable to monitor a pairing value storage location
or flag. Thereafter at step 122, the UI processor 50 is operable to
determine whether the pairing value storage location or flag
indicate that a pairing process, in which the remote electronic
device 12 is paired with the medical device 14 as described above,
is complete. If not, the process 110 loops back to step 120. If, at
step 122, the UI processor 50 determines that the pairing value
storage location or flag indicates that the pairing process is
complete, the process 110 advances to step 124 where the UI
processor 50 is operable to enable the bolus advice feature of the
remote electronic device 12. Following step 124, the process 110
ends.
[0083] In the embodiment illustrated in FIG. 4, the remote
electronic device 12 is illustratively manufactured with the bolus
advice feature disabled. In one embodiment the feature may be
selectively enabled by entering a predefined password into the
remote electronic device 12, such as via the user buttons 16. In
one embodiment, such a password will be known or available only to
a suitable healthcare professional, although this disclosure
contemplates other embodiments in which others may have access to
the predefined password. In the alternate embodiment, the bolus
advice feature may be automatically enabled upon pairing of the
remote electronic device 12 with a suitable medical device 14
according to a pairing process. Illustratively, the pairing process
may be as described hereinabove with respect to FIGS. 1 through 3,
although this disclosure contemplates that the pairing process
between the remote electronic device 12 and the medical device 14
may alternatively be or include one or more other processes that
are executed by the remote electronic device 12 and/or medical
device 14 that allows the remote electronic device 12 and the
medical device 14 to communicate with each other. In another
alternative embodiment, the process 110 may include the combination
of steps 114-118 and 120-124 such that the bolus advice feature is
enabled only after successful pairing of the remote electronic
device 12 with the medical device 14 and receiving of the
predefined password as described above. In this embodiment,
successful pairing of the remote electronic device 12 with the
medical device 14 is illustratively required prior to receipt of
the predefined password, although the order of these two events may
alternatively be reversed.
[0084] Referring now to FIG. 5, a flow chart of one illustrative
embodiment of a process 130 is shown that is carried out in the
remote electronic device 12 for establishing wireless
communications between the remote electronic device 12 and the
medical device 14 under various operating conditions of the remote
electronic device 12 in which the remote electronic device 12 and
the medical device 14 may not already be connected via a wireless
communication link 40. Illustratively, the process 130 is stored in
the memory device 66 of the UI processor 50 in the form of
instructions that are executable by the UI processor 50 to
automatically establish wireless communications between the remote
electronic device 12 and the medical device 14 under certain
operating conditions. At the beginning of the process 130, the UI
processor 50 is operable to simultaneously to execute steps at 132,
136, 140 and 142. At step 132, the UI processor 50 is operable to
monitor the on/off switch of the remote electronic device 12.
Thereafter at step 134, the UI processor 50 is operable to
determine whether the on/off switch of the remote electronic device
12 has been turned on. If not, the process 130 loops back to step
132. If, at step 134, the UI processor 50 determines that the
on/off switch has been turned on, the UI processor 50 is operable
at step 144 to establish wireless communications with the medical
device 14 as described hereinabove with respect to FIGS. 1-3.
[0085] The UI processor 50 is operable at step 136 of the process
130 to monitor a number of automatic reminders programmed therein.
Thereafter at step 138, the UI processor 50 is operable to
determine whether any of the programmed automatic reminders has
triggered the power up of the remote electronic device 12 from a
powered down state. Alternatively, the UI processor 50 may be
operable at steps 136 and 138 to monitor the on/off state of the
remote electronic device 12, and to determine whether and when the
remote electronic device 12 powers up from a powered down state in
response to the occurrence of an automatic reminder. In either
case, the "NO" branch of step 138 loops back to step 136, and the
"YES" branch of step 138 advances to step 144 where the UI
processor 50 is operable to establish a wireless connection with
the medical device 14 as described above.
[0086] The UI processor 50 is operable at step 140 to monitor the
main menu to determine whether the user has selected the bolus
advice feature from the main menu (or alternatively from a blood
glucose determination menu). If not, the process 130 loops back to
the beginning of step 140, and if the UI processor 50 determines at
step 140 that a user has selected the bolus advice feature, the
process 130 advances to step 144 where the UI processor 50 is
operable to establish a wireless connection with the medical device
14 as described above.
[0087] The UI processor 50 is operable at 142 to monitor the main
menu display on the display device 18 of the remote electronic
device 12 to determine whether a user has selected the "my data"
feature from the main menu. Illustratively, the "my data" feature
corresponds to a data viewing, editing and reporting feature via
which a user may view current, historical and trend data relating
to operation of the on-board glucose meter and/or the medical
device 14. In any case, the "NO" branch at step 142 loops back to
the beginning of step 142, and the "YES" branch advances to step
144 where the UI processor 50 is operable to establish wireless
connection with the medical device 14 as described above.
[0088] Referring now to FIG. 6, a flow chart is shown of one
illustrative embodiment of a process 145 that is carried out in the
remote electronic device 12 for processing information at certain
times when a wireless connection is established between the remote
electronic device 12 and the medical device 14. Illustratively, the
process 145 is stored in the memory device 66 of the UI processor
50 in the form of instructions that are executable by the UI
processor 50 to carry out the process 145. The process 145 begins
at step 146 where the UI processor 50 is operable to determine
whether a wireless communication link has just been established
between the remote electronic device 12 and the medical device 14,
such as via one or more of the operations illustrated and described
with respect to FIG. 5. If not, the process 145 loops back to the
beginning of step 146. Illustratively, the UI processor 50 is
operable while executing step 146 to also execute step 148 where
the UI processor 50 is operable to determine whether the remote
electronic device 12 has just exited a remote terminal operating
mode in which the remote electronic device 12 is configured to
control operation of the medical device 14 in substantially real
time over a wireless connection established between the two devices
12, 14. If, at step 148, the UI processor 50 determines that the
remote electronic device 12 has not just exited the remote terminal
operating mode with the wireless connection still established, the
process 145 loops back to the beginning of steps 146 and 148. If,
at step 148, the UI processor 50 determines that the remote
electronic device has just exited the remote terminal operating
mode with the wireless connection still established between the
devices 12, 14 or if, at step 146, the UI processor 50 determines
that a wireless communication link has just been established
between the remote electronic device 12 and the medical device 14,
the UI processor 50 is operable to execute each of steps 150, 156
and 168.
[0089] At step 150, the UI processor 50 is operable to transfer
operating data, e.g., event history information, from the medical
device 14 to the remote electronic device 12 via the wireless
communication link. In one embodiment, the remote electronic device
12 includes four separate databases that hold history information
for computing boluses and for reviewing and/or further analyzing.
Referring to FIG. 7, a diagram is shown of one illustrative
embodiment of four such databases that are included in the remote
electronic device 12, and that are illustratively located in the
memory device 66. The four databases include a BG/Diary database
65, a pump records (PR) database 67, a meal correction (MC)
database 69 and a correction records (CR) database 71. The BG/Diary
database 65 acts as the main database, and the PR database 67, MC
database 69 and CR database 71 are support databases which hold
data used to calculate active insulin and bolus advice. The
BG/Diary database 65 holds the overall resulting bolus advice data
long with interim and input data used in determining the bolus
advice. As illustrated in FIG. 7, the BG/Diary database 65 is in
data communication with each of the other three databases 67, 69
and 71.
[0090] In one illustrative embodiment, the BG/Diary database 65 can
hold 1000 records and operates as a circular queue that will
over-write the records, oldest first, after the first 1000 records
have been accumulated. The BG/Diary database 65 contains the bolus
advice calculations and input parameters used in the bolus
calculations.
[0091] In one embodiment, the correction records (CR) database 71
can hold 150 records and also operates as a circular queue that
will over-write the records, oldest first, after the first 150
records have been accumulated. In this embodiment, the CR database
71 is intended to hold 8 hours of prior bolus information. The
correction records database 71 is monitored over time by the UI
processor 50 to determine which of the records are active and which
are inactive. The correction records database 71 is used to
determine the amount of active insulin in the body, and uses only
the active records to determine this parameter. Each record in the
CR database 71 is associated with a specific record in the BG/Diary
database, and this association is determined by the BG/Diary date
and time stamp and a record counter value of the specific BG/Diary
database record. In this example embodiment, the BG/Diary results
are stored with a resolution of one minute, and multiple BG/Diary
records can be created each minute. Accordingly, the record counter
is useful in this embodiment to distinguish between multiple
BG/Diary records that may have the same date and time stamp.
[0092] In the illustrated embodiment, the meal correction database
69 is a single record database that is updated each time a BG/Diary
record with a carbohydrate amount that exceeds a programmable snack
size or meal excursion limit is added to the BG/Diary database 65.
This update occurs whether the current meal correction record is
active or not. Like the correction records database 71, the meal
correction database is monitored over time to determine whether the
sole record in the meal correction database 69 is or is not
currently active. The meal correction record is used when
determining the upper BG level that is, in turn, used during the
calculation of a correction bolus. The sole record in the meal
correction database 69 is also associated with a specific record in
the BG/Diary database 65, and this association is determined by the
BG/Diary date and time stamp and a record counter value for the
specific BG/Diary record.
[0093] In the example embodiment, the pump records database 67,
like the BG/Diary database 65, can hold 1000 records and also
operates as a circular queue that will over-write the records,
oldest first, after the first 1000 records have been accumulated.
The pump records are received by the pump records database 68 when
the operating data from the pump, e.g., the pump history records,
are transferred to the remote electronic device 12 according to
step 154 of the process 150 of FIG. 6. The pump history records are
synchronized with specific records in the BG/Diary database 65 with
the intent of matching up actual pump delivery amounts from the
pump history records with bolus amounts in the BG/Diary database
65. As will be described in greater detail hereinafter with respect
to FIGS. 10 and 11, pump history records that match corresponding
BG/Diary records are used to confirm the bolus amounts in the
BG/Diary database 65 as part of the synchronization process. When a
pump record cannot be matched with a specific record in the
BG/Diary database 65, a new record containing the pump information
is added to the BG/Diary database 65. The PR database 67, in the
illustrated embodiment, is used strictly as a scratch pad area for
holding pump records that are transferred from the pump 14 to the
remote electronic device pursuant to step 154 of the process 150 of
FIG. 6.
[0094] Referring now to FIGS. 8 and 9, one illustrative embodiment
of the process carried out at step 154 of the process 150
illustrated in FIG. 6 is shown. Referring specifically to FIG. 8, a
diagram is shown of a data buffer 170 that resides in the pump
history (PH) memory device 29 of the medical device 14. The data
buffer 170 is configured to store time stamped medical device event
records, and in the embodiment illustrated in FIG. 7 the data
buffer 170 is a first-in-first-out (FIFO) buffer that is sized to
store a predefined number, e.g., 4500, medical device event
records. Also in the illustrated embodiment, a history position
pointer, HP, points to the last medical device event record that
was transferred from the medical device 14 to the remote electronic
device 12 during the most recent download of the medical device
event records from the medical device 14 to the remote electronic
device 12. However, when the medical device 14 is re-paired with a
new remote electronic device 12 or re-paired with an existing
remote electronic device 12, the history position pointer, HP, is
illustratively set to point to the first record in the data
buffer.
[0095] In any case, the medical device event records are
illustratively stored in the data buffer 170 in the order of time
of occurrence such that the oldest medical device event record is
at the output of the data buffer 170 and the newest medical device
event record is at the input of the data buffer 170.
[0096] Referring now to FIG. 9, a flow chart is shown of one
illustrative embodiment of a process for carrying out step 154 of
the process 150 of FIG. 6 to transfer portions of the time stamped
medical device event records from the medical device 14 to the
remote electronic device 12. The flow chart of FIG. 9 is
partitioned into portions that are carried out by the remote
electronic device 12 and other portions that are carried out by the
medical device 14. Thus, the remote electronic device will carry
out some of the steps of the illustrative process while the medical
device 14 will carry out others. The data transfer process begins
at step 172 where the UI processor 50 of the remote electronic
device 12 is operable to determine whether a wireless connection
between the remote electronic device 12 and the medical device 14
has just been established. If not, the process loops back to the
beginning of step 172, otherwise the process advances to step 174
where the UI processor 50 of the remote electronic device 12 is
operable to send a read pump history command to the medical device
14 via the wireless communication circuit 54. Thereafter at step
176, the processor 28 of the medical device 14 is operable to
receive, via the wireless communication circuit 30, the read pump
history command sent by the remote electronic device 12. Thereafter
at step 178, the processor 28 of the medical device 14 is operable
to scan the pump history records that have been saved in the memory
device 29 since storage therein of the pump history record to which
the history position pointer, HP, points. If, at step 180, the
processor 28 determines that enough records have been found in the
scan to form a block of records, or if a response time for
responding to the read pump history command sent by the remote
electronic device 12 is about to expire, the process advances from
step 180 to step 182. Otherwise, step 180 loops back to step 178 to
continue to scan and search for pump history records that have been
stored in the data buffer 170 since the storage therein of the pump
history record to which HP points.
[0097] At step 182, the processor 28 of the medical device 14 is
operable to determine whether a history gap flag has been set. If
so, the process advances to step 184 where the processor 28
includes a history gap indicator in the response to be sent to the
remote electronic device 12. The processor 28 is further operable
at step 184 to determine from the data buffer 170 whether
additional pump history data is available after detecting the
history gap from the history gap flag. Illustratively, the
processor 28 further includes information in the response to be
sent to the remote electronic device 12 that indicates whether any
such additional pump history data is available after the detected
history gap. From step 184, and from the "NO" branch of step 182,
the process advances to step 186 where the processor 28 is operable
to send, via the wireless communication circuit 30, a block or
partial block of pump history event records to the remote
electronic device 12. Thereafter at step 188, the UI processor 50
of the remote electronic device 12 is operable to receive, via the
wireless communication circuit 54, the block or partial block of
pump history event records from the medical device 14. Thereafter
at step 190, the UI processor 50 is operable to determine whether
the processing of the block or partial block of pump history event
records, e.g., transferring of the pump history event records to
the PR database 67, was successful. If not, the process loops back
to step 174 where the pump history request, search and transfer
process just described is repeated. If, at step 190, the UI
processor 50 determines that the processing of the block or partial
block of pump history event records at step 188 was successful, the
process advances to step 192 where the UI processor 50 is operable
to send the wireless communication circuit 54, a successful
transfer message to the medical device 14. Thereafter at step 194,
the processor 28 of the medical device 14 is operable to receive,
via the wireless communication circuit 30, the successful transfer
message, and to deactivate or render inactive the history gap flag
and set the history position pointer, HP, to a new location in the
data buffer 170 that corresponds the oldest pump history event
record that was sent to, and successfully processed by, the remote
electronic device 12. From step 194, the process loops back to step
176 to again scan pump history event records that were saved in the
pump history memory device 29 since storing the pump history event
record to which the newly positioned history position pointer, HP,
now points.
[0098] Step 192 of the illustrated process additionally advances to
step 196 where the UI processor 50 is operable to determine whether
all pump history event records since the previous execution of the
illustrative process have been transferred from the medical device
14 to the remote electronic device 12. Illustratively, the
processor 28 of the medical device 14 is operable to include a last
record indicator in the block or partial block of pump history
event records transferred from the medical device 14 to the remote
electronic device 12 at step 184. If, at step 196, the UI processor
50 determines that the last record information was received and
processed in the most recent block or partial block of the pump
history event records sent from the medical device 14 to the remote
electronic device 12, the process advances to step 198 where the
process ends. Otherwise, the process loops from step 196 back to
step 174 where the process continues as described until all pump
history event records that were stored in the memory device 29 of
the processor 28 since the previous execution of the illustrated
process are transferred.
[0099] At step 200, the processor 28 of the medical device 14 is
operable to monitor the data in the pump history event record to
which the history position pointer, HP, points. Thereafter at step
202, the processor 28 is operable to determine whether the data in
the pump history event record to which HP points has changed since
the previous transfer of information from the medical device 14 to
the remote electronic device 12. If so, this means that at least
some of the pump history event records stored in the data buffer
170 have been overwritten since the last transfer of information
from the medical device 14 to the remote electronic device 12, and
that a gap in the time line of pump history event records therefore
exists. In this case, the process advances from step 202 to step
204 where the processor 28 is operable to activate the history gap
flag described above. Otherwise, step 202 loops back to step
200.
[0100] Referring again to FIG. 6, the process 145 advances from
step 150 to step 152 where the UI processor 50 is operable to
process the medical device operating data that was transferred from
the medical device 14 to the remote electronic device 12 at step
150. Referring now to FIGS. 10 and 11, a flowchart is shown of one
illustrative process for carrying out step 152 of the process 145
of FIG. 6 to process the pump history records and synchronize the
pump history records with the BG/Diary records in the BG/Diary
database 65. Illustratively, the process of FIG. 10 is stored in
the memory unit 66 in the form of instructions that are executable
by the UI processor 50 to carry out the illustrated process.
[0101] The pump history records transferred from the pump 14 to the
remote electronic device 12 may include commanded and non-commanded
pump events. Commanded events are generally those in which the
remote electronic device 12 commands the liquid infusion pump 14,
via the wireless communication circuits 52 and 30 respectively, to
deliver a desired bolus amount and type, except when the remote
electronic device 12 and the pump 14 are operating in a remote
terminal operating mode as briefly described above. In such cases,
the commanded events are treated as being locally commanded, i.e.,
commanded by pressing appropriate ones of the keys 32 of the pump
14. Non-commanded events, in contrast, are those that were
performed manually by the user and not commanded by the remote
electronic device 12. Non-commanded events may include manually
programming the liquid infusion pump 14 to deliver desired bolus
amounts and types, and also manually delivering bolus amounts via a
syringe or drug delivery pen. In the process illustrated in FIG.
10, both commanded and non-commanded events are read from the pump
history records transferred from the pump 14 to the remote
electronic device 12 and synchronized with the BG/Diary database
65. Non-commanded events may or may not be synchronized or
associated with an existing BG result. If non-commanded events are
not synchronized, they are in effect orphaned but nevertheless
considered part of the overall history of the user.
[0102] Illustratively, the UI processor 50 is operable pursuant to
the process illustrated in FIGS. 10 and 11 to synchronize the pump
event records with the BG/Diary database 65 immediately after the
records are transferred from the pump 14 to the remote electronic
device 12. Generally, this process entails attempting to match the
bolus type, bolus amount, date and time stamp of each pump event
record to an existing BG/Diary record that does not yet have an
associated programmed or delivered bolus amount. If a pump event
record cannot be matched with such an existing BG/Diary record, a
new BG/Diary record is created and added to the BG/Diary database
65. Each such new addition of a BG/Diary record will require a
corresponding update of the correction records database 71.
[0103] If a pump event record is matched with an existing BG/Diary
record, the delivered bolus amount is checked for confirmation. If
the delivered amount in the pump event record matches the bolus
amount in the matched BG/Diary record, the bolus amount is
confirmed and the BG/Diary record is updated to reflect this
result. If, on the other hand, the delivered amount in the pump
event record is different from the bolus amount in the matched
BG/Diary record, the actual delivered amount is confirmed and the
BG/Diary record is updated to reflect this result. In this latter
case, however, the correction records database 71 is updated to
reflect the actual delivered bolus amount. Illustratively, the
correction records database 71 is updated in this manner to ensure
accuracy of the active insulin value that can be determined from
the data.
[0104] The process illustrated in FIGS. 10 and 11 is executed once
for each pump event record that is transferred from the pump 14 to
the remote electronic device 12. The illustrated process begins at
step 210 where the UI processor 50 is operable to search the
BG/Diary database for all records with non-confirmed bolus amounts.
Thereafter at step 212, the UI processor 50 is operable to
determine whether the present pump event record corresponds to a
commanded event. Generally, the pump event records will contain a
field that defines whether the pump event was a commanded or
non-commanded event. If the UI processor 50 determines at step 212
that the current pump event is not a commanded event, the process
advances to step A (FIG. 11). If the UI processor 50 instead
determines at step 212 that the current pump event record
corresponds to a commanded pump event, the process advances to step
214 where the UI processor 50 is operable to determine the event
type of the current pump record, i.e., whether the current pump
record corresponds to a programmed bolus amount or a delivered
bolus amount. Again, the pump event records illustratively contain
a field that defines whether the pump event was a programmed or a
delivered bolus amount.
[0105] If the UI processor 50 determines at step 214 that the
current pump event corresponds to a programmed bolus amount, the
illustrated process advances to step 216 where the UI processor 50
searches through the non-confirmed and non-programmed Standard,
Extended and Multi-wave bolus type records in the BG/Diary database
65 for a record having a date/time stamp and bolus delivery type
(DTD) that matches that of the current pump event record. If the UI
microprocessor 50 finds such a match at step 216, the illustrated
process advances to step 218 where the UI processor 50 determines
whether the time stamp (T) of the matched BG/Diary record is within
a predefined time value, e.g., 6 minutes, of that of the current
pump event record. If so, the illustrated process advances to step
220 where the UI processor 50 is operable to determine whether the
programmed bolus amount in the BG/Diary record is equal to a user
selected amount. If so, the illustrated process therefore advances
to step 222 where the UI processor 50 is operable to set a bolus
advice flag in the current BG/Diary record to PROG. If at step 218
the UI processor 50 determines that the time stamps (T) of the
matched BG/Diary record is not within the predefined time value of
that of the current pump event record, the illustrated process
advances to step 224. Likewise, if the UI processor 50 determines
at step 220 that the programmed bolus amount in the BG/Diary record
is not equal to a user selected amount, the illustrated process
advances to step 224. Also, if the UI processor 50 does not find a
match at step 216, the illustrated process advances to step 224. At
step 224, the UI processor 50 is operable to create and add a new
record to the BG/Diary database 65 using the date/time stamp and
data from the current pump event record, and to set a bolus advice
flag of this new record to PROG.
[0106] If, at step 214, the UI processor 50 determines that the
current pump event corresponds to a delivered bolus amount, the
illustrated process advances to step 226 were the UI processor 50
is operable to determine whether the bolus delivery type was a
standard bolus or either of an extended bolus and a multi-wave
bolus. If the UI processor 50 determines at step 226 that the
delivered bolus type is a standard bolus (STD), the illustrated
process advances to step 228 where the UI processor 50 searches
through the non-confirmed and programmed Standard bolus type
records in the BG/Diary database 65 for a record having a date/time
stamp and bolus delivery type (DTD) that matches that of the
current pump event record. If the UI microprocessor 50 finds such a
match at step 228, the illustrated process advances to step 230
where the UI processor 50 determines whether the time stamp (T) of
the matched BG/Diary record is within a predefined time value,
e.g., 6 minutes, of that of the current pump event record. If so,
the illustrated process advances to step 232 where the UI processor
50 is operable to update the confirmed bolus amount with the
delivered bolus amount from the pump event record and to then set
the bolus advice flag to DELIV. If at step 230 the UI processor 50
instead determines that the time stamps (T) of the matched BG/Diary
record is not within the predefined time value of that of the
current pump event record, or the UI processor 50 does not find a
match at step 228, the illustrated process advances to step 234
where the UI processor 50 is operable to create and add a new
record to the BG/Diary database 65 using the date/time stamp and
data from the current pump event record, and to set a bolus advice
flag of this new record to DELIV.
[0107] If, at step 226, the UI processor 50 determines from the
pump event record that the delivered bolus type is not a standard
bolus (STD), the illustrated process advances to step 236 where the
UI processor 50 searches through the non-confirmed and programmed
Extended (EXT) and Multi-wave (MW) bolus type records in the
BG/Diary database 65 for a record having a date/time stamp and
bolus delivery type (DTD) that matches that of the current pump
event record. If the UI microprocessor 50 finds such a match at
step 236, the illustrated process advances to step 238 where the UI
processor 50 determines whether the time stamp (T) of the matched
BG/Diary record is within a predefined time value, e.g., 6 minutes,
of that of the current pump event record. If so, the illustrated
process advances to step 240 where the UI processor 50 is operable
to update the confirmed bolus amount with the delivered bolus
amount from the pump event record and to then set the bolus advice
flag to DELIV. If at step 238 the UI processor 50 instead
determines that the time stamp (T) of the matched BG/Diary record
is not within the predefined time value of that of the current pump
event record, or the UI processor 50 does not find a match at step
236, the illustrated process advances to step 242 where the UI
processor 50 is operable to create and add a new record to the
BG/Diary database 65 using the date/time stamp and data from the
current pump event record, and to set a bolus advice flag of this
new record to DELIV.
[0108] Referring now to FIG. 11, the "A" branch of step 212 of the
process illustrated in FIG. 10 advances to step 250 where the UI
processor 50 is operable to determine the event type of the current
pump record, i.e., whether the current pump record corresponds to a
programmed bolus amount or a delivered bolus amount. If the UI
processor 50 determines the event type to be a programmed bolus
event, the process advances to step 252 where the UI processor 50
is operable to search through the non-confirmed and non-programmed
manual and pen/syringe type bolus records in the BG/Diary database
65 for a record having a date/time stamp that is closest to that of
the current pump event record. Thereafter at step 254 the UI
microprocessor 50 is operable to determine whether the time stamp
(T) of the BG/Diary record selected at step 252 is within a
predefined time value, e.g., 5 minutes, of that of the current pump
event record. If so, the illustrated process advances to step 256
where the UI processor 50 is operable to determine whether the
programmed bolus amount in the BG/Diary record is equal to a user
selected amount. If so, the illustrated process advances to step
260 where the UI processor 50 is operable to set the bolus advice
flag in the current BG/Diary record to PROG and to set the delivery
type of the BG/Diary record to MANUAL. From the "NO" branch of
either of steps 254 and 256, the illustrated process advances to
step 258 where the UI processor 50 is operable to create and add a
new record to the BG/Diary database 65 using the date/time stamp
and data from the current pump event record, to set a bolus advice
flag of this new record to PROG and to set the delivery type of the
record to MANUAL.
[0109] If, at step 250, the UI processor 50 determines from the
current pump history record that the pump event type corresponds to
a delivered bolus event, the illustrated process advances to step
262 where the UI processor 50 is operable to search through the
Manual and Pen/Syringe type, non-confirmed and programmed records
in the BG/Diary database 65 for a record having a date/time stamp
that matches that of the current pump event record. If the UI
microprocessor 50 finds such a match at step 262, the illustrated
process advances to step 264 where the UI processor 50 determines
whether the time stamp (T) of the matched BG/Diary record is within
a predefined time value, e.g., 5 minutes, of that of the current
pump event record. If so, the illustrated process advances to step
266 where the UI processor 50 is operable to update the confirmed
bolus amount with the delivered bolus amount from the pump event
record and to then set the bolus advice flag to DELIV. If at step
262 the UI processor 50 does not find a match, and also from the
"NO" branch of step 264, the illustrated process advances to step
268 where the UI processor 50 is operable to create and add a new
record to the BG/Diary database 65 using the date/time stamp and
data from the current pump event record. Thereafter at step 270,
the UI processor 50 is operable to set the bolus advice flag of
this new record to DELIV and to set the delivery type to
MANUAL.
[0110] Further details relating to the processing of information in
one or more of the databases 65, 67, 69 and 71 are provided in
co-pending PCT Patent Application No. PCT/US2008/066331 and which
is assigned to the assignee of this disclosure, and the disclosure
of which has been incorporated herein by reference.
[0111] Referring again to FIG. 6, the "YES" branch of step 146 also
advances to step 156 where the UI processor 50 is operable to send
a time request message to the medical device 14 via the wireless
communication link. Thereafter at step 158, the medical device
receives the time request and sends a current medical device time
(MDT) to the remote electronic device 12 via the wireless
communication link. Thereafter at step 160, the remote electronic
device 12 receives MDT and compares the medical device time to the
current remote electronic device time (RDT). Following step 160,
the UI processor 50 is operable at step 162 to determine whether a
difference between MDT and RDT is greater than 60 seconds. If so,
the UI processor 50 is operable to set the current remote
electronic device time, RDT, equal to the medical device time, MDT
that was wirelessly sent by the medical device 14 to the remote
electronic device 12 at steps 158 and 160. Following step 164, the
process 145 advances to step 166 where the UI processor 50 is
operable to update the correction records database 71 and the meal
correction database 69 with the new remote device time, RDT. More
specifically, when the remote electronic device time, RDT, changes,
the active records in the correction records database 71 and the
meal correction database 69 are updated based on the new RDT.
[0112] The "YES" branch of step 146 also advances to step 168 where
the UI processor 50 is operable to check and act on any warnings,
alarms or errors that are associated with the medical device 14 and
the occurrence of which is communicated wirelessly to the remote
electronic device 12 when the wireless communication link is
established. Following steps 152, 166 and 168 and the "NO" branch
of step 162, the process 145 ends.
[0113] Referring now to FIGS. 12A-12C, a flow chart is shown of one
illustrative embodiment of a bolus advice process 300 that is
carried out by the remote electronic device 12. In the context of
the flowchart of FIGS. 12A and 12B, the medical device 14 is
illustratively implemented in the form of an insulin infusion pump,
and will be described as such throughout the description of the
process 300. It will be understood, however, that this disclosure
contemplates alternate embodiments in which the medical device 14
is or includes one or more other conventional medical devices.
[0114] Illustratively, the process 300 is stored in the memory
device 66 of the UI processor 50 in the form of instructions that
are executable by the UI processor 50 to carry out the bolus advice
process 300. The process 300 presumes that the remote electronic
device 12 is powered up and that the UI processor 50 is currently
controlling the display device 18 to display a main menu 302 that
is generally displayed upon power up of the remote electronic
device 12. Illustratively, the main menu 302 provides for a number
of selectable user options that include, but that should not be
limited to, a blood glucose (BG) test, a bolus advice process, a
pump remote control process 304, a "my data" process 306 and a
settings or device set up process. The pump remote control process
304, or remote terminal operational mode as referred to above,
illustratively provides a menu-driven process by which the remote
electronic device 12 may control operation of the insulin infusion
pump 14 substantially in real time. One illustrative embodiment of
such a process is described in co-pending PCT Patent Application
No. PCT/US2008/066288, which is assigned to the assignee of this
disclosure, and the disclosure of which has been incorporated
herein by reference.
[0115] The "my data" process 306 illustratively provides for the
viewing and editing of diary records, e.g., specific BG test
records and pump history records, and also for the analysis of the
records over daily and/or weekly time periods. Illustratively, the
UI processor 50 stores in the memory 66 up to 1,000 diary records,
and up to 250 records may be reviewed using the remote electronic
device. The diary records may also be downloaded to a PC or other
computer, and using compatible software all records may be viewed
and/or analyzed. Each diary record may contain date and time, BG
test result, meal time events, carbohydrate value, health event,
bolus type, bolus amount and duration. The UI processor can filter
and/or sort data from these data records.
[0116] The "my data" process also provides for the analysis of the
data records in the form of daily and weekly averages, and standard
deviations, defined by time slot, and for trend analysis of any of
the collected data. Standard day and standard week tables or graphs
may be generated to view averages and/or trends. Various charting
and table options are also available for presenting data in desired
formats.
[0117] The BG test process that may be selected from the main menu
302 begins at step 308 where the UI processor 50 determines whether
the user has selected the BG test process from the main menu 302.
If not, the "NO" branch of step 308 loops back to the beginning of
step 308. If, at step 308, the UI processor 50 determines that the
user has selected the BG process from the main menu 302, the
process 300 advances to step 310 where the UI processor 50 controls
the display device 18 to prompt a user to conduct a BG test. In one
embodiment, the UI processor 50 controls the display device 18 to
visually guide a user through a blood glucose measurement sequence
in which a user inserts a carrier 22 into the glucose measurement
facility 20 of the remote electronic device 12 and deposits a
sample of blood on the carrier 22, after which the blood glucose
meter 88 analyzes the blood sample in a conventional manner to
produce a blood glucose (BG) value that corresponds to a
concentration of glucose in the deposited blood sample. The blood
glucose value, BG, is provided by the blood glucose meter 88 that
is on-board the remote electronic device 12 to the UI processor 50
as describe hereinabove. From step 310, the process 300 advances to
step 312 where the UI processor 50 is operable to control the
display device 18 to display the BG value along with an on-screen
color indicator that is based on the BG value relative to one or
more reference BG values.
[0118] Referring now to FIG. 13, a flow chart is shown of one
illustrative embodiment of a process 350 for controlling the
display device 18 of the remote electronic device 12 to indicate
readily perceptible warnings and/or alerts. The process 350 may
illustratively be used to carry out step 312 of the process 300
illustrated in FIG. 12A, although the process 350 is broader than
briefly described with respect to step 312 and may alternatively or
additionally be used to control a display device of the remote
electronic device 12 and/or the medical device 14 generally to
display any analyte or drug related value with an on-screen color
indicator that is based on the value of the analyte or drug related
value relative to one or more reference values. In the illustrated
embodiment, the process 350 may be stored in the memory device 66
of the UI processor 50 and/or in the memory device 25 of the
processor 28 of the insulin infusion pump 14 in the form of
instructions that are executable by the processor 50, 28 to display
the analyte or drug related value on a corresponding display device
with on-screen color indicator that is based on the value of the
analyte or drug related value relative to one or more reference
values.
[0119] The process 350 begins at step 352 where the processor 50,
28 is operable to determine whether an analyte or drug related
value has just been measured or computed. If not, the "NO" branch
of step 352 loops back to the beginning of step 352. Otherwise, the
process 350 advances to step 354 where the processor 50, 28 is
operable to determine a display color based on the measured or
computed value relative to one or more reference values. Thereafter
at step 356, the processor 50, 28 is operable to control the
display device 18, 34 to change the color of the display or a
portion thereof to the display color determined at step 354 when
displaying the measured or computed value and/or a warning message
related to the measured or computed value. From step 356, the
process 350 ends.
[0120] The process 350 of FIG. 13 may illustratively be used at
step 312 of the process 300 to display the measured BG value with
an on-screen color indicator. In one example embodiment, the UI
processor 50 may be operable at step 356 of the process 350 to
display a green bar next to measured and displayed BG values that
are within a target range, to display a yellow bar next to measured
and displayed BG values that are between the target range and a
hypoglycemic limit value, to display a red bar with the text HYPO
within the red bar next to measured and displayed BG values that
are less than the hypoglycemic limit value, to display a light blue
bar next to measured and displayed BG values when the measured BG
values are between the target range and a hyperglycemic limit
value, and to display the text HYPER within the light blue color
bar next to measured and displayed BG values that are greater than
the hyperglycemic limit value. In some alternative embodiments,
more, fewer and/or different colors may be displayed based on more,
fewer and/or different BG value comparisons with BG limits or
ranges. In other alternative embodiments, one or more portions of
the display, or the entire display, may be changed in color based
on the measured or computed value relative to one or more reference
values. Any such color change may be implemented as a solid or
transparent color, flashing or otherwise patterned in time, and/or
accompanied by one or more explanatory messages.
[0121] Also following step 310, the process 300 advances to step
314 where the UI processor 50 is operable to execute a hypoglycemic
test process in relation to the blood glucose value, BG, measured
at step 310. Referring now to FIG. 14, a flowchart is shown of one
illustrative embodiment of the hypoglycemic test process 314.
Illustratively, the process 314 is stored in the memory 66 of the
UI processor 50 in the form of instructions that are executable by
the UI processor 50 to conduct the hypoglycemic test. The process
314 begins at step 360 where the UI processor 50 is operable to
determine whether the measured BG value, BG, is less than a
hypoglycemic limit value, BG.sub.HYPO. If so, the process 314
advances to step 362 where the UI processor 50 is operable to
control the display device 18 to display a message indicating that
the measured BG value is too low for a bolus to be delivered.
Thereafter at step 364, the UI processor 50 is illustratively
operable to compute a number of carbohydrates, e.g., fast-acting
carbohydrates, which will be suggested to be taken by the user to
get the user's blood glucose value back to a target blood glucose
value, BG.sub.TARGET. In one embodiment, for example, the UI
processor 50 is operable at step 364 to compute the required
carbohydrates according to the formula
CARBS=(BG.sub.TARGET-BG)*IS*CR, wherein IS corresponds to a
programmable insulin sensitivity value and CR corresponds to a
programmable carbohydrate ratio. In any case, the process 314
advances from step 364 to step 366 where the UI processor 50 is
operable to control the display device 18 to display a message
recommending intake of the computed amount of carbohydrates. In one
embodiment, the CARBS value has a lower limit, e.g., 12 grams,
which is substituted for the computed CARBS value when the computed
GARBS value is less than the lower limit. Following step 366, the
process 314 returns the value RETURN to the process 300 of FIG.
12A, and following the "NO" branch of step 360 the process 314
returns the value ADVANCE to the process 300 of FIG. 12A. Thus, if
the blood glucose measurement taken at step 310 is less than
BG.sub.HYPO, the process 300 follows the RETURN path from step 314
and loops back to display the main menu. If the blood glucose
measurement taken at step 310 is not less than BG.sub.HYPO, the
process 300 follows the ADVANCE path to step 316. In alternate
embodiments, the hypoglycemic limit value, BG.sub.HYPO, may be
replaced at step 360 by another suitable lower BG limit.
[0122] If the process 300 reaches step 316, the BG value display
screen illustratively provides a bolus option that a user may
select to enter the bolus advice process directly from the BG
measurement process. The UI processor 50 is accordingly operable
following the ADVANCE path from step 314 to step 316 to determine
whether the user has selected the bolus option from the BG display.
If not, the process 300 advances to step 318 where the user has
pressed another key or has selected another option, or
alternatively has done nothing and caused the BG value screen to
time out. Generally, the UI processor 50 is operable to store the
BG value in the memory unit 66 along with measurement time and date
information. Illustratively, the user may also store additional
information along with the time and date stamp BG value, examples
of which may include, but should not be limited to, the timing of
the BG measurement relative to meal, bedtime and/or awake time
information, amount of carbohydrates taken at the time of the BG
measurement, health information such as exercise level, illness or
stress, and the like. In any case, if the UI processor 50
determines at step 316 that the user has selected the bolus key
option from the BG value display screen, the process 300 advances
to step 322.
[0123] From the main menu 302, the user may alternatively select
the bolus advice process, and the UI processor 50 is accordingly
operable at step 320 to determine if the user has selected the
bolus advice process. If not, the "NO" branch step 320 loops back
at the beginning of step 320, and otherwise the process 300
advances to step 322 where the UI processor 50 is operable to
determine whether the pump history and/or bolus threshold and/or
pump status information was updated when the bolus advice process
300 was entered either via step 316 or step 322. If not, the
process 300 advances to step 324 where the processor 50 is operable
to control the display device 18 to display a warning message on
the bolus advice screen that one or more bolus advice values and/or
an active insulin may not be based on current drug pump operating
history. From step 324, and from the "YES" branch of step 322, the
process 300 advances to step 326 where the processor 50 is operable
to compute the active insulin value, AI. Thereafter at step 328,
the UI processor 50 is operable to compute a first bolus value, B1,
which is illustratively based on a recent blood glucose value and
also on pump operating history data. In embodiments in which blood
glucose has not recently been measured, B1=0. Also at step 328, the
UI processor 50 is operable to compute a second bolus value, B2,
that is illustratively based on CARB values entered by the user
that correspond to carbohydrates that the user has taken or is
planning to take. Further at step 328, the UI processor 50 is
operable to compute a third bolus value, B3, which is
illustratively based on health information entered by the user that
corresponds to a current health state of the user. As one
illustrative example, the health state of the user may correspond
to exercise, stress, illness, or the like. Further details relating
to illustrative techniques for computing AI and B1-B3 are provided
in co-pending PCT patent application Ser No PCT/US2008/066331, the
disclosure of which has been incorporated herein by reference.
[0124] The process 300 advances from step 328 to step 330 where the
UI processor 50 is operable to compute a total recommended bolus,
TRB, as a sum of B1-B3. Thereafter at step 332, the UI processor 50
is operable to control the display unit 18 to display a bolus
advice screen that shows the active insulin value, AI, any recent
blood glucose value, BG, a BG color indicator as described with
respect to step 312, B1-B3, TRB and a bolus type, e.g., standard
(STD), multi-wave (MW), extended (EXT), each of which may be used
to automatically program the pump 14 from the remote electronic
device 12, and two manual types. In one embodiment, if a blood
glucose measurement, BG, has been conducted within a predefined
time period prior to executing step 332, the UI processor 50 is
operable at step 332 to display the bolus advice screen showing the
measured blood glucose value, BG. Otherwise, the UI processor 50
may be illustratively operable at step 332 to display "bG Test" on
the screen where a BG value would be shown if a current BG value
was available. From step 332, the process 300 advances to a
sub-process B. In general, any value that was measured by or
entered into the remote electronic device 12 or medical device 14
may illustratively be displayed when a screen that includes such a
value is displayed if the value was measured or entered within a
predefined time period since measuring or entering the value.
[0125] Referring now to FIG. 15, a graphic example is shown of one
illustrative embodiment of a bolus advice display screen 386
produced by the process 300 of FIG. 12A at the point just prior to
executing sub-process B, i.e., after step 324 or step 330. In the
illustrated example, a Bolus Advice label 370 appears at the top of
the screen 368 to indicate that the user is executing the bolus
advice feature. A blood drop symbol appears next to the displayed
blood glucose value 372, e.g., 120 mg/dl, and a color bar 374,
providing a visual indication of the blood glucose value 372
relative to an acceptable blood glucose range and/or a number of
blood glucose limits, is positioned next to the blood glucose value
372. The active insulin value 378, e.g., -2 U, is positioned under
the blood glucose value 372, and a bolus value 376, corresponding
to the bolus value B1, is displayed adjacent to the active insulin
value 378. As described above, if the bolus advice screen 368 was
generated via step 330 and a recently measured blood glucose value,
BG, was not available, the value 120 mg/dL would illustratively be
replace by the phrase bG Test.
[0126] An apple symbol is used to identify a carbohydrates field
380, and a heart symbol is used to identify a health field 382. A
bolus type indicator 386 appears below the health field 382 and the
total recommended bolus value 382, e.g., 3 U, is displayed adjacent
to the bolus type indicator 386. A bolus type 388, e.g., Standard,
is displayed below the total recommended bolus 384. At the bottom
of the screen between Cancel and Confirm inputs, a BlueTooth.RTM.
symbol 390 is provided to indicate the connection status of the
wireless communication link with the insulin infusion pump 14,
e.g., solid when a wireless connection exists and otherwise
flashing.
[0127] Referring now to FIGS. 12B and 12C, the sub-process B
identified after step 332 of FIG. 12A, is shown, wherein the
sub-process B forms part of the bolus advice process 300. It will
be observed that the sub-process B includes a number of processes
that may each be accessed independently any number of times. For
example, the sub-process B includes a process 400 for measuring a
blood glucose value and computing a bolus amount, B1, which
corresponds to the BG measurement. In the illustrated embodiment,
the process 400 begins at step 402 where the UI processor 50 is
operable to determine whether a strip insert, e.g., insertion of a
blood glucose strip into the carrier port 20 of the remote
electronic device 12, has been detected or if the user has selected
the bG Test field if this field is displayed in place of a blood
glucose value as described above. If not, the process 400 loops
back to the beginning of step 402. If, at step 402, the UI
processor 50 determines that a strip insert or user selection of
the bG Test field has been detected, the process 400 advances to
step 404 where the UI processor 50 is operable to conduct a blood
glucose test, e.g., by prompting and guiding a user through such a
BG test as described above, which returns a measured blood glucose
value, BG. Thereafter at step 406, the UI processor 50 is operable
to execute the hypoglycemic test process 314 illustrated in FIG. 14
and described above. If the hypoglycemic test process 314 returns a
value RETURN, this indicates that the blood glucose value is too
low to recommend a bolus value and the process 400 advances to step
414 where the UI processor 50 is operable to exit the bolus advice
feature and display the main menu 302. If the hypoglycemic test
process 314 instead returns the value ADVANCE, the process 400
advances to step 408 where the UI processor 50 is operable to
compute all of the bolus values, B1-B3. In the illustrated
embodiment, measured and/or user entered value may have an effect
on one or more of the bolus values, B1-B3, and the UI processor 50
is accordingly operable in sub-process B to re-compute each bolus
value, B1-B3, after each BG measurement, Carbohydrate entry or
health entry. In any case, following step 408 the UI processor 50
is operable at step 410 to compute a total recommended bolus value,
TRB, as a sum of B1 and two other bolus values, B2 and B3.
Thereafter at step 412, the UI processor 50 is operable to update
the bolus advice screen with BG; a BG color indicator as described
above, B1-B3 and TRB. From step 412, the process 400 loops back to
the beginning of the sub-process B.
[0128] The sub-process B of FIG. 12B further includes a process 420
for entering a carbohydrate value of a meal or snack that has just
been, or is planned to be taken, and determining a bolus value
based on the entered carbohydrate value. The process 420 begins at
step 422 where the UI processor 50 is operable to determine whether
a user has selected the CARB field of the displayed bolus advice
screen, e.g., item 380 illustrated in FIG. 15. If not, the process
420 loops back to the beginning of step 422. If user selection of
the CARBS field is detected at step 422, the process 420 advances
to step 424 where the processor 50 is operable to determine whether
a carbohydrate value relating to a meal or snack that was just, or
is planned to be, taken, has been entered by the user. If not, the
process 420 loops back to the beginning of step 424. In one
embodiment, the user at step 424 may manually enter a carbohydrate
value into the remote electronic device 12, e.g., via the user
buttons 16, that corresponds to a carbohydrate content of the meal
or snack that was just taken or is planned to be taken. In an
alternative embodiment, selection by the user of the carbohydrate
value field displayed by the UI processor 50 on the display device
18 at step 422 may take the user to a menu-driven food database via
which the user may select the various food items that comprise the
meal or snack. In this embodiment, the menu-driven food database is
operable to compute a total carbohydrate value based on the
individual carbohydrate values of the food items selected by the
user from the food database, and the UI processor 50 is operable at
step 424 to automatically enter the total carbohydrate value
determined by the menu-driven food database process into the
carbohydrate value field displayed on the display device 18 at step
424. In any case, if the user has entered a carbohydrate value that
is detected by the UI processor 50 at step 424, the process 420
advances to step 426 where the UI processor 50 is operable to
re-compute each of the bolus values B1-B3. Thereafter at step 428,
the UI processor 50 is operable to compute the total recommended
bolus, TRB, as the sum of B1-B3. Thereafter at step 430, the UI
processor 50 is operable to control the display device 18 to update
the bolus advice display screen to include the carbohydrate value
provided by the user at step 424 to display the computed bolus
values, B1-B3, determined at step 426 and to display the updated
total recommended bolus value, TRB. The process 420 loops from step
430 back to the beginning of the sub-process B.
[0129] The sub-process B of FIG. 12B further includes a process 440
for entering a health information, and determining a bolus value
based on the entered health information. The process 440 begins at
step 442 where the UI processor 50 is operable to determine whether
a user has selected the Health field of the displayed bolus advice
screen, e.g., item 382 illustrated in FIG. 15. If not, the process
440 loops back to the beginning of step 442. If user selection of
the Health field is detected at step 442, the process 440 advances
to step 444 where the processor 50 is operable to determine whether
a Health value has been entered by the user. If not, the process
440 loops back to the beginning of step 444. In one embodiment,
when the user manually selects at step 442 the health event field
displayed on the display device 18 by the UI processor 50, the UI
processor 50 is operable to control the display device 18 to
display a plurality of health event choices. The health event
choices may include, for example, but should not be limited to, no
entry, one or more exercise options, an illness option and a
sickness option, although more, fewer and/or different options may
alternatively be available. In this embodiment, the user may define
percentage values associated with each of the health event options
during the device set up process such that when the user manually
selects one of the health event options at step 444, the UI
processor 50 is operable thereafter at step 446 to re-compute the
bolus values B1-B3. Thereafter at step 448, the UI processor 50 is
operable to again compute the total recommended bolus, TRB, e.g.,
as a sum of the individual bolus values, B1-B3. The process 440
advances from step 448 to step 450 where the UI processor 50 is
operable to control the display device 18 to update the bolus
advice display to include the health event, the bolus values,
B1-B3, and the total recommended bolus value, TRB. The process 440
loops from step 450 back to the beginning of the sub-process B.
[0130] The sub-process B of FIG. 12B further includes a process 460
that allows the user to manually modify the total recommended bolus
value, TRB. The process 460 begins at step 462 where the UI
processor 50 is operable to determine whether a user has selected
the TRB field of the displayed bolus advice screen, e.g., item 384
illustrated in FIG. 15. If not, the process 460 loops back to the
beginning of step 462. If user selection of the TRB field is
detected at step 462, the process 460 advances to step 464 where
the processor 50 is operable to determine whether the user has
modified the TRB value. If not, the process 460 loops back to the
beginning of step 464. If the processor 50 determines that the user
has, at step 464, modified the TRB value, the process 460 advances
to step 466 where the UI processor 50 is operable to control the
display device 18 to update the bolus advice display to include the
modified total recommended bolus value, TRB. The process 460 loops
from step 466 back to the beginning of the sub-process B.
[0131] Referring now to FIG. 12C, the sub-process B further
includes a process 470 for selecting a bolus type. The process 470
begins at step 472 where the UI processor 50 is operable to
determine whether a user has selected the bolus type field of the
displayed bolus advice screen, e.g., item 388 illustrated in FIG.
15. If not, the process 470 loops back to the beginning of step
472. If user selection of the bolus type field is detected at step
472, the process 470 advances to step 474 where the processor 50 is
illustratively operable to display available bolus types on the
bolus advice screen. In one illustrative embodiment, the available
bolus types may include, but should not be limited to, a standard
bolus (STD), a multi-wave (MW) bolus, an extended (EXT) bolus, a
manually programmable bolus and a manually administered bolus via
an insulin pen or syringe or the like. In cases were a wireless
connection between the remote electronic device 12 and 14 is or can
be established, the available bolus types may illustratively
include all bolus types that the pump 14 is currently capable of
delivering. In other cases where a wireless connection could not be
established when first entering the bolus advice process, and
cannot currently be established, the available bolus types may
illustratively include only manually programmable and/or manual
delivery via insulin pen/syringe. Those skilled in the art will
recognize more, fewer and/or different bolus types that may be made
available to the user at step 474, and any such alternative or
additional bolus types are contemplated by this disclosure.
[0132] Following step 474, the process 470 advances to step 476
where the UI processor 50 is operable to determine whether the user
has selected a bolus type. If not, the process 470 loops back to
step 474. If the processor 50 determines that the user has, at step
476, selected a bolus type, the process 470 advances to step 476
where the UI processor 50 is operable to control the display device
18 to update the bolus advice display to include the selected bolus
type. The process 470 loops from step 478 back to the beginning of
the sub-process B.
[0133] The sub-process B of FIG. 12C further includes a process 480
that allows the user to cancel and exit the bolus advice process.
The process 480 begins at step 482 where the UI processor 50 is
operable to determine whether a user has selected the Cancel
function displayed on the bolus advice screen, e.g., see FIG. 15,
such as via one of the user buttons 16. If not, the process 480
loops back to the beginning of step 482. If user selection of the
Cancel function is detected at step 482, the process 480 advances
to step 484 where the processor 50 is illustratively operable to
exit the bolus advice process and display the main menu 302.
[0134] The sub-process B of FIG. 12C further includes a process 490
that allows the user to confirm the diary entry including the total
recommended bolus, TRB, for delivery. The process 490 begins at
step 492 where the UI processor 50 is operable to determine whether
a user has selected the Confirm function displayed on the bolus
advice screen, e.g., see FIG. 15, such as via one of the user
buttons 16. If not, the process 490 loops back to the beginning of
step 492. If user selection of the Confirm function is detected at
step 492, the process 490 advances to step 494 where the UI
processor 50 is illustratively operable to determine whether the
current value of TRB is less than or equal to zero, i.e., whether
the user has confirmed a null or negative bolus. If so, the process
490 advances to step 496 where the UI processor 50 is
illustratively operable to store the bolus advice record, and to
exit the bolus advice process and display the main menu 302.
[0135] It at step 494, the UI processor 50 determines that TRB is
not less than or equal to zero, the process 490 advances to step
498 where the UI processor 50 is operable to determine whether the
user confirmation detected at step 492 is of a manual, e.g., manual
pump or pen/syringe, or commanded, e.g., STD, MW or EXT, bolus. If
the user confirmation is of a commanded bolus, the process 490
advances to step 500 where the UI processor 50 is operable to
determine whether the remote electronic device 12 and the pump 14
are still wirelessly connected via a wireless communication link 40
(see FIG. 1). If not, the process 490 advances to step 502 where
the UI processor 50 sets as the currently available bolus types
only the manual bolus types, i.e., manual pump and pen/syringe, and
the process 490 thereafter loops back to the beginning of the
sub-process B. Thus, if the UI processor 50 determines after user
confirmation of a commanded bolus, e.g., STD, MW or EXT, that a
wireless connection does not or no longer exists between the remote
electronic device 12 and the infusion pump 14, the process 490
returns to the bolus advice process of sub-process B where the UI
processor 50 makes available as user selectable bolus types, e.g.,
at step 474 of the process 470, only manually deliverable bolus
types, e.g., via manual programming of an infusion pump or via
manual delivery via a drug pen or syringe.
[0136] If, at step 500, the UI processor 50 determines that the
remote electronic device 12 and the pump 14 are still wirelessly
connected, the process 490 advances to step 504 the UI processor 50
determines whether the user selected bolus type, i.e., the bolus
type selected by the user at step 476, is a Standard bolus, STD. If
so, the process 490 advances to a process C. If not, the process
490 advances to step 506 where the UI processor 50 is operable to
determine whether the user selected bolus type, i.e., the bolus
type selected by the user at step 476, is a multi-wave bolus, MW.
If so, the process 490 advances to a process D. If not, the process
490 advances to a process E.
[0137] If, at step 498, the UI Processor 50 determines that the
user confirmation detected at step 492 is of a manual bolus, the
process 490 advances to step 508 where the UI processor 50 is
operable to determine whether the confirmed bolus type is a manual
pump (MP), corresponding to manually programming an infusion pump
to deliver the bolus, or a pen/syringe (PS), corresponding to
manual delivery of the bolus via a conventional drug pen or
syringe. If the confirmed bolus is a manual pump (MP), the process
490 advances to a process F, and if the confirmed bolus is a
pen/syringe (PS), the process 490 advances to a process G.
[0138] As described hereinabove with respect to FIGS. 5-11, the
remote electronic device 12 and the pump 14 illustratively
cooperate to transfer pump operating history and bolus
threshold/status from the pump 14 to the remote electronic device
when a user accesses the bolus advice process 300. The remote
electronic device is further operable to compute B1 based, at least
in part, on recent bolus delivery history, and utilize the wireless
communication link to wirelessly program the pump 14 to deliver
boluses. However, in situations in which a wireless connection
cannot be established when the bolus advice process 300 is accessed
or thereafter, neither recent pump history nor bolus
threshold/status information is transferred from the pump 14 to the
remote electronic device 12, and the remote electronic device 12
cannot remotely program the pump 14 to deliver a recommended bolus
from the bolus advice process if a wireless connection between the
devices 12, 14 cannot be established and/or is lost during the
bolus advice process. Such situations may occur, for example, when
the pump 14 is turned off and/or when wireless communication
between the remote electronic device 12 and the pump 14 are
disabled or otherwise compromised. During such situations, however,
the bolus advice process 300 continues to be accessible, and the
bolus advice process 300 illustrated and described herein is
illustratively operable under such conditions to compute active
insulin, AI, and a total recommended bolus, TRB, based on current
BG measurements and pump history and that was previously collected
and processed by the remote electronic device 12, and recent values
of Carbs and/or health information.
[0139] In such cases, the UI processor 50 is operable at step 522
of the process 300 of FIG. 12A to determine if pump history and/or
bolus threshold and pump status information was not updated at the
start of the current bolus advice session. If a wireless connection
cannot be established between the remote electronic device 12 and
the pump 14, the remote electronic device 12 will not display the
Standard, Extended or Multi-wave boluses as available bolus types
at step 476, and the user will in such cases be able to deliver the
drug only by manually, e.g., locally, programming the pump 14, by
manually administering the drug via conventional drug pen or
syringe, or via other conventional manual drug delivery techniques.
The remote electronic device 12 thus prompts the user to manually
program or manually deliver the bolus amount under conditions where
a wireless communications link is not established between the
devices 12 and 14, and the UI processor 50 accordingly notifies the
user when a wireless connection cannot be established when the
bolus advice process is begun and when the wireless connection is
lost during the bolus advice process. When wireless communications
is lost during a bolus advice session, the remote electronic device
12 does not attempt to establish wireless communications during the
current bolus advice session.
[0140] Referring now to FIG. 16, a flowchart is shown of one
illustrative embodiment 550 of the process C referred to in the
process 490 of FIG. 12C. The process 550 is executed when the user
has confirmed a Standard bolus of an amount TRB. The process 550
begins at step 556 where the UI processor 50 is operable to display
a standard bolus confirmation screen with the total recommended
bolus amount. Thereafter at step 558, the UI processor 50 is
operable to determine whether the user has selected a back, i.e.,
go back, function that is available on the confirmation screen. If
so, the process 550 advances to step 560 where the UI processor 50
returns to the bolus advice screen. If not, the process 550
advances to step 562 where the UI processor 50 is operable to
determine whether the user has selected a deliver function that is
available on the confirmation screen. If not, the process 550 loops
back to step 560. If, at step 562, the UI processor 50 determines
that the user has selected deliver on the confirmation screen, the
UI processor 50 sends a deliver command to the pump 14 to which the
pump is responsive to begin delivering the standard bolus in the
amount of the total programmed bolus.
[0141] The process 550 advances from the "YES" branch of step 562
to step 564 where the UI processor 50 is operable to send a deliver
command to the pump 14 and to store the entire record in memory.
Thereafter at step 566, the processor 50 is operable to receive a
wireless message from the pump 14 corresponding to an amount of the
total programmed bolus that is currently being delivered. The UI
processor 50 is, in turn, operable to control the display device 18
to update the total recommended bolus value, TRB, to reflect
delivery by the pump 14 of the bolus amount so far delivered. For
example, if at step 566 the UI processor 50 receives a message from
the pump 14 that the pump 14 has delivered 1/10 U of insulin, the
UI processor 50 is operable to control the display device 18 to
update the displayed TRB value by subtracting 1/10 U from the
displayed value of TRB. Thereafter at step 568, the UI processor 50
is operable to determine whether a user has manually stopped the
insulin delivery process by manually selecting a suitable one or
more of the user buttons 16 of the remote electronic device 12. If
the UI processor 50 determines that the user has manually stopped
the delivery of insulin by the pump 14, the process 550 advances to
step 570 where UI processor 50 controls the display device 18 to
display a bolus canceled message. Otherwise, the process 550
advances to step 572 where the UI processor 50 is operable to
determine, based on messages wirelessly provided by the pump 14,
whether delivery of the standard bolus is complete. If not, the
process 550 loops back up to step 566. Thus, steps 566-572
illustratively result in a count down on the display device 18 of
bolus delivery from the total recommended bolus value, TRB. When
delivery of the standard bolus is complete, step 572 advances to
step 574 where the UI processor 50 is operable to control the
display device 18 to display a delivery complete message. From step
574, and also from step 570, the process 550 advances to step 576
where the UI processor 50 stores the bolus delivery record in
memory.
[0142] Referring now to FIGS. 17A and 17B, a flowchart is shown of
one illustrative embodiment 580 of the process D referred to in the
process 490 of FIG. 12C. The process 580 is executed when the user
has confirmed a multi-wave bolus of an amount TRB. The process 580
begins at step 582 where the UI processor 50 is operable to send a
MW immediate portion (IMD) and a duration (DUR) request to the pump
14 along with the total recommended bolus value, TRB. Thereafter at
step 584, the UI processor 50 is operable to determine whether a
multi-wave bolus program command acknowledgement and accompanying
multi-wave bolus data have been received from the pump 14.
Illustratively, the pump 14 is responsive to the MW bolus program
command to automatically program a multi-wave bolus in the amount
of TRB using previous or default values of the immediate portion,
IMD, and of the duration, DUR, of the extended portion of the
multi-wave bolus, and to send an acknowledgement back to the remote
electronic device 12 that a multi-wave bolus in the amount of TRB
has been programmed having an immediate amount of IMD and a
duration of DUR, and to await further instructions. If the UI
processor 50 determines at step 584 that such an acknowledgement
has not been received, the process 580 advances to step 586 where
the UI processor 50 is operable to determine whether an
acknowledgement timer has timed out since sending the command at
step 582. If not, the process 580 loops back to step 584. If the
acknowledgement timer has timed out, the process 580 advances to
step 588 where the UI processor returns to the previous bolus
advice screen.
[0143] If, at step 584, the UI processor 50 determines that the
multi-wave bolus program acknowledgement and accompanying
programmed bolus data was received, the process 580 advances to
step 590 where the UI processor 50 is operable to display a
multi-wave bolus confirmation screen with the immediate portion,
IMD, the bolus duration, DUR, and the total programmed bolus
amount. Thereafter at step 592, the UI processor 50 is operable to
determine whether the user has selected a back, i.e., go back,
function that is available on the confirmation screen. If so, the
process 580 advances to step 594 where the UI processor 50 is
operable to return to the previous bolus advice screen. If not, the
process 580 advances to step 596 where the UI processor 50 is
operable to determine whether the user has selected the IMD field
of the multi-wave bolus screen for editing. If so, the process 580
advances to step 598 where the UI processor 50 is operable to
determine whether the user has entered a new IMD value in the IMD
field of the multi-wave bolus screen. If not, the process 580 loops
back to the beginning of step 598. If so, the process 580 loops
back to step 590. If, at step 596, the UI processor 50 determines
that the user has not selected the IMD field for editing, the
process 580 advances to step 600 where the UI processor 50 is
operable to determine whether the user has selected the DUR field
of the multi-wave bolus screen for editing. If so, the process 580
advances to step 602 where the UI processor 50 is operable to
determine whether the user has entered a new DUR value in the DUR
field of the multi-wave bolus screen. If not, the process 580 loops
back to the beginning of step 602. If so, the process 580 loops
back to step 590. If, at step 600, the UI processor 50 determines
that the user has not selected the IMD field for editing, the
process 580 advances to step 604 where the UI processor 50 is
operable to determine whether the user has selected the deliver
function of the multi-wave bolus screen. If, at step 606, the UI
processor 50 has determined that the user has selected deliver on
the multi-wave bolus confirmation screen, the UI processor 50 sends
a deliver command to the pump 14 to which the pump is responsive to
begin delivering the multi-wave bolus in the amount of the total
programmed bolus having an immediate portion, IMD, and a duration,
DUR.
[0144] The process 580 advances from the "YES" branch of step 604
to step 606 where the UI processor 50 is operable to send a deliver
command to the pump 14 and to store the entire bolus advice record
in memory. Thereafter at step 608, the UI processor 50 is operable
to receive a wireless message from the pump 14 corresponding to an
amount of the immediate portion, IMD, of the multi-wave bolus that
is currently being delivered. The UI processor 50 is, in turn,
operable to control the display device 18 to update the immediate
bolus value, IMD, to reflect delivery by the pump 14 of the
immediate bolus amount so far delivered. For example, if at step
608 the UI processor 50 receives a message from the pump 14 that
the pump 14 has delivered 1/10 U of insulin, the UI processor 50 is
operable to control the display device 18 to update the displayed
IMD value by subtracting 1/10 U from the displayed value of IMD.
Thereafter at step 610, the UI processor 50 is operable to
determine whether a user has manually stopped the insulin delivery
process by manually selecting a suitable one or more of the user
buttons 16 of the remote electronic device 12. If the UI processor
50 determines that the user has manually stopped the delivery of
insulin by the pump 14, the process 580 advances to step 612 where
UI processor 50 controls the display device 18 to display a bolus
canceled message. Otherwise, the process 580 advances to step 614
where the UI processor 50 is operable to determine, based on
messages wirelessly provided by the pump 14, whether delivery of
the immediate portion of the multi-wave bolus is complete. If not,
the process 580 loops back up to step 608. Thus, steps 608-614
illustratively result in a count down on the display device 18 of
delivery of the immediate portion of the multi-wave bolus. When
delivery of the immediate portion of the multi-wave bolus is
complete, step 614 advances to step 616 where the UI processor 50
is operable to control the display device 18 to display an
immediate bolus delivery complete message that is followed by or
that includes a message that the multi-wave bolus delivery is
continuing.
[0145] Referring now to FIG. 18, a flowchart is shown of one
illustrative embodiment 620 of the process E referred to in the
process 490 of FIG. 12C. The process 620 is executed when the user
has confirmed an extended bolus of an amount TRB. The process 620
begins at step 622 where the UI processor 50 is operable to send an
extended bolus duration (DUR) request to the pump 14 along with the
total recommended bolus value, TRB. Thereafter at step 624, the UI
processor 50 is operable to determine whether an extended bolus
program command acknowledgement and accompanying extended bolus
data have been received from the pump 14. Illustratively, the pump
14 is responsive to the extended bolus program command to
automatically program an extended bolus in the amount of TRB using
a previous or default value of the duration, DUR, of the extended
bolus, and to send an acknowledgement back to the remote electronic
device 12 that an extended bolus in the amount of TRB has been
programmed, and to await further instructions. If the UI processor
50 determines at step 624 that such an acknowledgement has not been
received, the process 620 advances to step 626 where the UI
processor 50 is operable to determine whether an acknowledgement
timer has timed out since sending the command at step 622. If not,
the process 580 loops back to step 624. If the acknowledgement
timer has timed out, the process 620 advances to step 628 where the
UI processor returns to the previous bolus advice screen.
[0146] If, at step 624, the UI processor 50 determines that the
extended bolus program acknowledgement and accompanying programmed
bolus data was received, the process 620 advances to step 630 where
the UI processor 50 is operable to display an extended bolus
confirmation screen with the bolus duration, DUR, and the total
programmed bolus amount. Thereafter at step 632, the UI processor
50 is operable to determine whether the user has selected a back,
i.e., go back, function that is available on the confirmation
screen. If so, the process 620 advances to step 634 where the UI
processor 50 is operable to return to the previous bolus advice
screen. If not, the process 620 advances to step 636 where the UI
processor 50 is operable to determine whether the user has selected
the DUR field of the multi-wave bolus screen for editing. If so,
the process 620 advances to step 638 where the UI processor 50 is
operable to determine whether the user has entered a new DUR value
in the DUR field of the extended bolus screen. If not, the process
620 loops back to the beginning of step 638. If so, the process 620
loops back to step 630. If, at step 636, the UI processor 50
determines that the user has not selected the DUR field for
editing, the process 620 advances to step 640 where the UI
processor 50 is operable to determine whether the user has selected
the deliver function of the multi-wave bolus screen. If, at step
406, the UI processor 50 has determined that the user has selected
deliver on the extended bolus confirmation screen, the UI processor
50 sends a deliver command to the pump 14 to which the pump is
responsive to begin delivering the extended bolus in the amount of
the total programmed bolus having a duration, DUR.
[0147] The process 620 advances from the "YES" branch of step 640
to step 642 where the UI processor 50 is operable to send a deliver
command to the pump 14 and to store the entire bolus advice record
in memory. Thereafter at step 644, the UI processor 50 is operable
to receive a wireless message from the pump 14 that the pump is
currently delivering the extended bolus. Thereafter at step 646,
the UI processor 50 is operable to control the display unit 18 to
display a message indicating that delivery of the extended bolus is
continuing.
[0148] Referring now to FIG. 19, a flowchart is shown of one
illustrative embodiment 650 of the process F referred to in the
process 490 of FIG. 12C. The process 650 is executed when the user
has confirmed that the bolus amount TRB will be manually programmed
on the pump 14. The process 650 begins at step 652 where the UI
processor 50 is operable to display a manual program screen with
instructions to manually program the bolus amount TRB on the pump
14. Thereafter at step 654, the UI processor 50 is operable to
determine whether the user has selected a back, i.e., go back,
function that is available on the confirmation screen. If so, the
process 650 advances to step 656 where the UI processor 50 is
operable to return to the previous bolus advice screen. If not, the
process 650 advances to step 658 where the UI processor 50 is
operable to determine whether the user has selected OK on the
manual program bolus screen. If not, the process 650 loops back to
step 654. If, at step 658, the UI processor 50 has determined that
the user has selected OK on the bolus confirmation screen, the UI
processor 50 stores the entire record in memory at step 660.
[0149] Referring now to FIG. 20, a flowchart is shown of one
illustrative embodiment 670 of the process G referred to in the
process 490 of FIG. 12C. The process 670 is executed when the user
has confirmed that the bolus amount TRB will be manually delivered
via a drug pen or syringe or the like. The process 670 begins at
step 672 where the UI processor 50 is operable to display a
pen/syringe screen with instructions to manually deliver the bolus
amount TRB via a drug pen or syringe. Thereafter at step 674, the
UI processor 50 is operable to determine whether the user has
selected a back, i.e., go back, function that is available on the
confirmation screen. If so, the process 670 advances to step 676
where the UI processor 50 is operable to return to the previous
bolus advice screen. If not, the process 670 advances to step 678
where the UI processor 50 is operable to determine whether the user
has selected OK on the manual program bolus screen. If not, the
process 670 loops back to step 674. If, at step 678, the UI
processor 50 has determined that the user has selected OK on the
bolus confirmation screen, the UI processor 50 stores the entire
record in memory at step 680.
[0150] Further details relating to the bolus advice process
illustrated in FIGS. 12A and 12B are provided in co-pending PCT
Patent Application No. PCT/US2008/066331, the disclosure of which
has been incorporated by reference.
[0151] While the invention has been illustrated and described in
detail in the foregoing drawings and description, the same is to be
considered as illustrative and not restrictive in character, it
being understood that only illustrative embodiments thereof have
been shown and described and that all changes and modifications
that come within the spirit of the invention are desired to be
protected. For example, the UI processor 50 and/or the processor 28
of the medical device may be configured to determine a display
color based on a computed and/or delivered bolus value, relative to
one or more reference bolus values and to change the color of the
display device 18 and/or 34, or portion thereof, to the determined
display color, as described above with respect to FIG. 13.
* * * * *