US20100160759A1 - Combination communication device and medical device for communicating wirelessly with a remote medical device - Google Patents

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.

Description

• 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
• 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
• 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
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• The medical device may be a liquid infusion pump and the time-based event data may be time-based infusion pump event data.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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
• 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.
• 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 ofFIG. 1.
• 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 ofFIG. 2.
• FIG. 4 shows a flowchart of one illustrative embodiment of a process for enabling a bolus advice feature of the remote electronic device.
• 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.
• 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.
• FIG. 7 shows a diagram of one illustrative embodiment of a number of databases defined in the memory device of the remote electronic device.
• FIG. 8 shows a diagram of a data buffer in the medical device that is configured to store time stamped medical device events.
• 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.
• 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.
• FIGS. 12A-12C show a flowchart of one illustrative embodiment of a bolus advice process carried out by the remote electronic device.
• 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.
• FIG. 14 shows a flowchart of one illustrative embodiment of a hypoglycemic test process.
• FIG. 15 shows a graphic representation of one illustrative embodiment of a bolus advice display screen produced by the process ofFIGS. 12A-12C.
• FIG. 16 shows a flowchart of one illustrative sub-process carried out by the remote electronic device in the bolus advice process ofFIGS. 12A-12C.
• FIGS. 17A and 17B show a flowchart of another illustrative sub-process carried out by the remote electronic device in the bolus advice process ofFIGS. 12A-12C.
• FIG. 18 shows a flowchart of yet another illustrative sub-process carried out by the remote electronic device in the bolus advice process ofFIGS. 12A-12C.
• FIG. 19 shows a flowchart of still another illustrative sub-process carried out by the remote electronic device in the bolus advice process ofFIGS. 12A-12C.
• FIG. 20 shows a flowchart of a further illustrative sub-process carried out by the remote electronic device in the bolus advice process ofFIGS. 12A-12C.
DETAILED DESCRIPTION
• 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.
• 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.
• Referring now toFIG. 1, a block diagram is shown of one illustrative embodiment of awireless communication system10 including a remoteelectronic device12 andmedical device14 that are both configured to wirelessly communicate with each other. The remoteelectronic device12 has a housing through which auser button section16 extends. In one embodiment, theuser button section16 defines a number of user buttons, keys or switches that may be manually manipulated by a user to provide input to the remoteelectronic device12. Avisual display unit18 is carried by the housing of theelectronic device12, and in one embodiment thevisual display unit18 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, thevisual display unit18 is controlled by theelectronic device12 to display information to a user of thedevice12. In alternative embodiments, theuser button section16 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 thedisplay unit18.
• Theelectronic device12 further includes acarrier port20 that extends into the housing from an opening defined therein. Thecarrier port20 is sized to receive therein a sample carrier orstrip22 upon which a liquid sample containing an analyte has been or will be deposited. Theelectronic device12 includes electrical circuitry that analyzes the liquid sample deposited on thesample carrier22, when thesample carrier22 is received within thecarrier port20, 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, thesample carrier22 may is illustratively provided in the form of a glucose test strip, and the electrical circuitry of theelectronic device12 includes conventional circuitry that measures the concentration of glucose in a blood sample deposited on thetest strip22. 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.
• In the embodiment illustrated inFIG. 1, theelectronic device12 further includes a conventional datakey port26 that extends into the housing from an opening defined therein. The datakey port26 defines an electrical interface or connector therein that is configured to electrically connect to a complementarily configured electrical interface or connector defined on aconventional data key24. The data key24 includes a conventional memory device (not shown) that is electrically connected to the electrical interface or connector defined on the data key24. The memory device, e.g., ROM key, is electrically connected to the electrical circuitry of theelectronic device12 via the electrical interface defined on the data key24 and the electrical interface defined in the datakey port26 when the data key26 is received within the datakey port24. Generally, the memory device of the data key24 has calibration data stored therein that is specific to a lot or batch oftest strips22, and the electrical circuitry of theelectronic device12 uses the calibration data stored in the memory device of the data key24 to correct glucose concentration measurements when using atest strip22 from a corresponding lot or batch of test strips as is known in the art. Typically, each lot or batch oftest strips22 purchased by a user will include a dedicated data key24 that is to be used when measuring glucose concentration with that lot or batch of strips.
• It will be understood that while thecarrier port20,sample carrier22 and electrical circuitry of theelectronic device12 have been described in one embodiment as being configured to measure the glucose concentration of blood samples deposited on thesample carrier22, this disclosure contemplates other embodiments in which thecarrier port20,sample carrier22 and/or electrical circuitry of theelectronic device12 is/are configured to measure other analytes in other liquid samples.
• Themedical device14 includes aconventional processor28 that is electrically connected to awireless communication circuit30. Theprocessor28 includes aconventional memory unit25 which has stored therein a number of processes in the form of instructions that are executable by theprocessor28 to control operation of themedical device14 and to wirelessly communicate with theelectronic device12. In the illustrated embodiment, themedical device14 further includes conventionalnon-volatile memory units27 and29. In one embodiment, thenon-volatile memory unit27 is provided in the form of a conventional ferroelectric random access memory (FRAM) and thenon-volatile memory unit29 is provided in the form of a conventional electrically erasable programmable read only memory (EEPROM), although eithermemory unit27,29 may alternatively be provided in the form of one or more other conventional non-volatile memory units. In any case, thememory units27 and29 are each external to theprocessor28 and are each electrically connected to theprocessor28. In one illustrative embodiment in which the medical device is a drug infusion pump, as will be described in greater detail hereinafter, thememory unit27 is a pump delivery (PD) memory unit in which theprocessor28 stores current pump delivery information, and thememory unit29 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 thepump14. Themedical device14 further includes awireless communication circuit30 that is configured to communicate wirelessly with a similar wireless communication module of the remoteelectronic device12 via awireless communication link40 in a conventional manner. In one embodiment, as will be illustrated by example throughout this disclosure, thewireless communication circuit30 and the wireless communication module of theelectronic device12 are both conventional BlueTooth® modules configured to wirelessly communicate according to a conventional BlueTooth® communication protocol. It will be understood, however, that the wireless communication circuit ormodule30 and the wireless communication module of theelectronic device12 may alternatively be configured to wirelessly communicate according to one or more other communication protocols.
• Themedical device14 illustratively includes a housing through which a number ofuser keys32 extend. Theuser keys32 may be provided in the form of any number of user selectable buttons, keys or switches that are electrically connected to theprocessor28. Themedical device14 further includes avisual display unit34 that is carried by the housing and that is electrically connected to theprocessor28. Thevisual display unit34 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. Thevisual display unit34 is controlled by theprocessor28 to display information to a user of themedical device14. In alternative embodiments, theuser keys32 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 thedisplay unit34.
• Theprocessor28 of themedical device14 is further electrically connected to a conventionalaudible indication device36 and to a conventionalvibratory device38. Theprocessor28 is generally operable to control theaudible indication device36 and thevibratory device38 to produce one or more audible sounds and/or vibrations respectively to notify the user of various operational aspects of themedical device14 and to also notify the user of any alarm and/or warning conditions associated with themedical device14. In alternative embodiments, themedical device14 may not include adisplay device34 and/oruser keys32. In some such embodiments, themedical device14 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.
• In one illustrative embodiment, themedical device14 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 theelectronic device14 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, themedical device14 and operations associated with themedical device14 will be described in the context of an insulin infusion pump, although it will be understood that themedical device14 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.
• Referring now toFIG. 2, a block diagram schematic is shown of one illustrative embodiment of an electronic circuit that is carried by, and that controls, the remoteelectronic device12 ofFIG. 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)processor50 that is the main controller of theelectronic device12. In addition to processing all aspects of theuser interfaces16,18, it is the origination and destination of all data communicated from and to theinsulin infusion pump14. As will be described in greater detail herein, theUI processor50 has no control over operation of the wireless communication circuit of the remoteelectronic device12. TheUI processor50 operates according to a UI clock signal that is generated internally to theUI processor50. TheUI processor50 includes amemory unit66 having instructions stored therein that are executable by theUI processor50 to control operations associated with the remoteelectronic device12. In one illustrative embodiment, theUI processor50 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 theUI processor50.
• The electronic circuit ofFIG. 2 further includes awireless communication circuit52 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 theelectronic device12. Thewireless communication circuit52 operates from a clock signal that is generated internally to thewireless communication circuit52 and that is not synchronized to the UI clock signal from which theUI processor60 operates. Operation of thewireless communication circuit52 is therefore asynchronous with respect to the operation of theUI processor60. In one illustrative embodiment, thewireless communication circuit52 is provided in the form of a conventional BlueTooth® telemetry module that includes a conventional processor and amemory unit70, and that further includes conventional wireless communication hardware such as a suitable antenna. Thememory unit70 illustratively has stored therein instructions that are executable by the processor of thewireless communication circuit52 to exclusively control of all wireless communications with external devices, such as theinsulin infusion pump14. In one illustrative embodiment, thewireless communication circuit52 is a BC419143B BlueCore™4-Flash Plug-n-Go™ single chip BlueTooth® radio and baseband integrated circuit for BlueTooth® 2.4 GHz systems that is commercially available from CSR of Richardson, Tex., although this disclosure contemplates other implementations of thewireless communication circuit52. Alternatively, as described hereinabove, this disclosure contemplates embodiments in which thewireless communication module52 is configured for wirelessly communication according to wireless communication protocols other than BlueTooth®.
• As illustrated inFIG. 2, theUI processor50 and thewireless communication module52 each includedebounce circuitry64 and68 respectively that is electrically connected to theuser buttons16. Thedebounce circuitry64,68 is conventional in that it reduces the sensitivity of theprocessors50 and52 to spurious switching events associated with theuser buttons16, thereby increasing the likelihood that only actual button presses are detected by theprocessors50 and52.
• The electronic circuit illustrated inFIG. 2 further includes amemory subsystem54 that is electrically connected to theUI processor50 and also to thewireless communication circuit52. Thememory subsystem54 is generally operable to store, at least temporarily, data moving between theUI processor50 and thewireless communication circuit52. Data communication between thememory subsystem54 and theUI processor50 is illustratively carried out via a serial peripheral interface, SPI, in which case the transfer of data between thememory subsystem54 and theUI processor50 is synchronous with a data transfer clock, SCLK, of theUI processor50. Illustratively, data communication between thememory subsystem54 and thewireless communication circuit52 is carried out via a universal asynchronous receiver/transmitter (UART) interface, in which case the transfer of data between thememory subsystem54 and thewireless communication circuit52 is asynchronous. In some alternative embodiments, the data transfer interfaces may be interchanged such that data transfer between thememory subsystem54 and theUI processor50 is asynchronous and data transfer between thememory subsystem54 and thewireless communication circuit52 is synchronous.
• Thememory subsystem54 temporarily stores data moving between theUI processor60 and thewireless communication circuit52. In some embodiments, thememory subsystem54 does not control other circuitry, and in some such embodiments thememory subsystem54 may be provided in the form of a conventional memory device. In other embodiments in which thememory subsystem54 does or does not control other circuitry, thememory subsystem54 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, theDPR processor54 operates from a clock signal that is separate from the UI clock signal from which theUI processor60 operates. In one illustrative embodiment, such aDPR processor54 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 thememory subsystem54 that is provided in the form of a conventional processor configured as aDPR processor54.
• The electronic circuit illustrated inFIG. 2 further includes a Measurement Engine (ME)processor56 that controls analyte concentration measurements of liquid samples contained ontest elements22, e.g., blood glucose measurements, and that reports the analyte concentration measurement results to theUI processor50. TheME processor56 includes amemory unit83 having instructions stored therein that are executable by theME processor56 to control analyte measurement operations. TheME processor56 operates from an internally generated clock signal that is separate from the clock signal from which theUI processor50 operates. TheME processor56 is electrically connected to theUI processor50 via an Event Interrupt line, TXD (data transmission) line and a Ready line. The Event Interrupt line is illustratively used by theME processor56 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 theME processor56 to transmit analyte measurement data to theUI processor50 for display on thedisplay unit18, for storage thereof in a history database and/or for use in conducting other operations. The Ready line is used by theME processor56 to notify theUI processor50 of the operational state, e.g., measuring or not measuring analyte concentration, of the ME processor. In one illustrative embodiment, theME processor56 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 theME processor56.
• As illustrated inFIG. 2, theME processor56, along with other electrical components, form ananalyte measuring facility88, e.g., a glucose meter. In addition to theME processor56, theanalyte measuring facility88 further includes an application specific integrated circuit (ASIC)78 that is electrically connected to theME processor56 and also to anelectrical interface76 within thecarrier port20. In one illustrative embodiment, when asample carrier22, e.g., a glucose test strip, is inserted into thecarrier port20, electrical contacts on thesample carrier22 contact theelectrical interface76 to thereby electrically connect thesample carrier22 to theASIC78. Aswitch80 contained in the ASIC is triggered by insertion of thecarrier22 into thecarrier port20, and an output of theswitch80 thus notifies theME processor56 of insertion of acarrier22 into thecarrier port20. TheASIC78 further illustratively includes aclock circuit82 that is programmable for a number of different functions. For example, theclock circuit82 may be programmed to generate a signal to automatically turn on, e.g., power up, thedevice12 at one or more programmable times. As another example, theclock circuit82 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 theclock circuit82 is provided to theME processor56, and theME processor56 is responsive to the receipt of this signal to power up from a sleep state if theME processor56 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 theUI processor50, which then powers up from a sleep state if theUI processor50 is in such a sleep state, and/or generates an audible or visible reminder corresponding to any reminder time programmed in theclock circuit82.
• As illustrated inFIG. 2, theanalyte measuring facility88 further includes anotherelectrical interface84 that is positioned within the codekey port26. Illustratively, when acode key24 is received within the codekey port26, electrical contacts on thecode key24 electrically connect with theelectrical interface84 so that theME processor56 may read the calibration information stored in the memory device of thecode key24. Theanalyte measuring facility88 further includes atemperature sensor86 that is electrically connected to theME processor56. In one illustrative embodiment, thetemperature sensor86 is provided in the form of a conventional thermistor, although this disclosure contemplates other embodiments in which thetemperature sensor88 may be or include one or more other conventional temperature sensors. In any case, theME processor56 is operable to receive a temperature signal from thetemperature sensor86 that corresponds to an operating temperature of the analyte measuring facility. In one illustrative embodiment, thememory83 has instructions stored therein that are executable by theME processor56 to disable, i.e., not conduct, analysis of an analyte containing sample if the temperature signal produced by thetemperature sensor86 indicates that the temperature of theanalyte measuring facility88 is less than a threshold temperature. In such cases, theME processor56 is further operable, pursuant to the instructions stored in thememory83, to inform theUI processor50 that the analyte measuring facility is so disabled, and theUI processor50 is operable, pursuant to instructions stored in thememory unit66, to control thedisplay device18 to display a message indicating that the temperature is too low to conduct analyte concentration measurements.
• The electronic circuit illustrated inFIG. 2 further includes ageneral power supply58 that provides a supply voltage to theASIC78, theME processor56, theUI processor50 and thememory subsystem54 on a continuous basis. The supply voltage is derived by the generalpower supply circuit58 from one or a series or parallel combination of rechargeable or non-rechargeable batteries (BATTERY)60.
• Adedicated power supply62 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 thewireless communication module52. Thepower supply62 receives one control input from theuser buttons16, and in the illustrated embodiment thepower supply62 may be powered on and off via one or a combination of theuser buttons16 via the one control input. Thepower supply62 also receives another control input from thewireless communication circuit52, and in the illustrated embodiment thepower supply62 may be turned off by thewireless communication circuit52 via the other control input.
• In addition to thedisplay18, theUI processor50 is electrically connected to a conventionalaudible indication device72 and also to a conventional vibratory device74. TheUI processor50 is generally operable to control theaudible indication device72 and the vibratory device74 to produce one or more audible sounds and/or vibrations respectively to provide for the capability of thedevice12 to produce corresponding audible and/or tactile notifications, i.e., alarms or the like. In one embodiment, theaudible indication device72 is a tone generator that produces a beep or other tone when activated, although theaudible indication device72 may alternatively or additionally be or include one or more other conventional audible indication devices.
• Generally, thememory subsystem54 acts as an independent repository of data packets moving between theUI processor50 and thewireless communication circuit52. Referring toFIG. 3, a block diagram of some of the details of thememory subsystem54 is shown along with electrical connections to theUI processor50 and to thewireless communication circuit52. In the illustrated embodiment, thememory subsystem54 is provided in the form of a DPR processor as described above, andFIG. 3 will be described in this context, although it will be understood that thememory subsystem54 may alternatively be provided in other forms as described above.
• In the embodiment illustrated inFIG. 3, one of the dual ports of theDPR processor54 is a serial peripheral interface (SPI)port92 that is electrically connected to a serialperipheral interface port90 of theUI processor50 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 theSPI port90 of theUI processor50 and theSPI port92 of theDPR processor54 is controlled by theUI processor50 using the serial clock signal, SCLK, so that data transfer between the twoprocessors50,54 is synchronized.
• The other of the dual ports of theDPR processor54 is a universal asynchronous receiver/transmitter (UART)port96 that is electrically connected to aUART port94 of thewireless communication circuit52 via a conventional asynchronous interface. Transfer of inbound and outbound data packets between theUART port94 of thewireless communication circuit52 and theUART port96 of the DPR processor54 (e.g., at 150 kbps) is controlled by thewireless communication circuit52, and takes place asynchronously with respect to the transfer of inbound and outbound data between the SPI port of theUI processor50 and theDRP processor54.
• TheDPR processor54 has aninbound data buffer98 and anoutbound data buffer100 that are each accessible by the SPI andUART ports92 and96 respectively of theDPR processor54. TheUART port96 of theDPR processor54 includes conventional clear to send (CTS) and ready to send (RTS) lines. The CTS line is monitored by theDPR processor54 and the RTS line is monitored by thewireless communication circuit52. TheDPR processor54 deactivates the UART RTS line whenever theinbound data buffer100 is full, and otherwise activates the UART RTS line. Thewireless communication circuit52 activates the UART CTS line whenever the UART port of thewireless communication circuit52 is requesting data, and otherwise deactivates the UART CTS line.
• When data is to be sent by theUI processor50 to an external device or system, e.g., theinsulin infusion pump14, theUI processor50 first requests the state of theoutbound data buffer100 of theDPR processor54. If theDPR processor54 answers that itsoutbound data buffer100 is “not full,” theUI processor50 transfers the data, or as much of the data as possible, to theoutbound data buffer100 of theDPR processor54 via the data out (DO) line of theSPI port90 at a rate determined by SCLK. If theDPR processor54 instead answers that theoutbound data buffer100 is “full,” theUI processor50 waits for a time interval and then repeats the process of requesting the state of theoutbound data buffer100, etc.
• Periodically with respect to the clock signal of thewireless communication circuit52 and asynchronously with respect to the SCLK signal, thewireless communication circuit52 requests data from theDPR processor54 by activating the UART CTS line of theDPR processor54. As long as theoutbound data buffer100 of theDPR processor54 is empty, thewireless communication circuit52 continues to periodically activate the UART CTS line. If the UART CTS line is active and theoutbound data buffer100 of theDPR processor54 is not empty, thewireless communication circuit52 retrieves the data from theoutbound data buffer100 of theDPR processor54 via the RX line of theUART port96. TheDPR processor54 illustratively transfers the data stored in itsoutbound data buffer100 to itsUART port96 in a first received to last received order until theoutbound data buffer100 has been emptied or until thewireless communication circuit52 deactivates the UART CTS line. Thewireless communication circuit52 then incorporates the data retrieved from theoutbound data buffer100 of theDPR processor52, 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 thewireless communication module52. Thewireless communication circuit52 does not process, interpret or alter the contents of the data retrieved from theoutbound data buffer100 of theDPR processor54, nor does it make any decisions or execute any steps based on the contents of the data. Rather, thewireless communication circuit52 treats all such data the same, regardless of its contents, by incorporating the data into a predefined wireless communication protocol structure, e.g., BlueTooth® protocol structure, and then wirelessly transmitting the incorporated data using the predefined wireless communication protocol. Information transferred by theUI processor50 to thememory subsystem54, and then from thememory subsystem54 to thewireless communication circuit52 for wireless transmission to another electronic device is thus referred to as outbound information or data.
• Inbound wireless signal transmissions from external devices or systems, e.g., theinsulin infusion pump14, are received by thewireless communication circuit52 via conventional wireless signal receiving circuitry of thewireless communication circuit52. Thewireless communication circuit52 first isolates the inbound data from the wireless communication protocol structure, and then checks the status of the UART RTS line of theDPR processor54. If the RTS line is activated, indicating that theinbound data buffer98 of theDPR processor54 is not full, thewireless communication circuit52 sends the isolated data, or as much if the data as possible, to theUART port96 of theDPR processor54. TheDPR processor54 then places the data received at theUART port96 into theinbound data buffer98 of theDPR processor54. If the UART RTS line is deactivated, indicating that theinbound data buffer98 of theDPR processor54 is full, thewireless communication circuit52 waits for a time interval before rechecking the state of the UART RTS line.
• Periodically, and asynchronously with respect to the operation of thewireless communication circuit52, theUI processor50 requests the state of theinbound data buffer98 of theDPR processor54 via the data in (DI) line of theSPI port90. As long as theDPR processor54 answers that theinbound data buffer98 is empty, theUI processor50 continues to periodically request the state of theinbound data buffer98. If theDPR processor54 answers that theinbound data buffer98 of theDPR processor54 contains data, theUI processor50 retrieves the data from theinbound data buffer98 of theDPR processor52 via the data in (DI) line of theSPI port90 using the SCLK signal, and then processes the data according to its contents. “Checking” the inbound and/oroutbound data buffer98,100 of theDPR processor54 by thewireless communication circuit52 and/orUI processor50, as this term may be used hereinafter, will generally refer to the process just described in the preceding several paragraphs. WhileFIGS. 2 and 3 illustrate an embodiment in which the interface between theUI processor50 and thememory subsystem54 is a synchronous interface and the interface between thewireless communication circuit52 and thememory subsystem54 is an asynchronous interface, this disclosure contemplates alternative embodiments in which the interface between theUI processor50 and thememory subsystem54 is an asynchronous interface and the interface between thewireless communication circuit52 and thememory subsystem54 is an synchronous interface or in which both interfaces are asynchronous or synchronous interfaces. In any case, it should be apparent that theUI processor50 at all times operates independently and asynchronously with respect to the operation of thewireless communication circuit52, and thewireless communication circuit52 operates independently and asynchronously with respect to the operation of theUI processor50 and also with respect to the operation of theDPR processor54.
• TheUI processor50 controls thedisplay18 of theelectronic device12 to indicate the connection status of thewireless communication module52 relative to the wireless telemetry system of theinsulin infusion pump14. Upon power up of theelectronic device12, following activation of thepower supply62 via theuser buttons16 after being deactivated and under certain other operating conditions that will be described in greater detail hereinafter, theUI processor50 attempts to establish a wireless connection with theinsulin infusion pump14. While a wireless connection is not established between theelectronic device12 and theinsulin infusion pump14, theUI processor50 controls thedisplay18 to display a flashing (or fixed) icon to indicate that no wireless connection exists between theelectronic device12 and theinsulin infusion pump14. TheUI processor50 independently controls thedisplay18 in this manner without any information provided by thewireless communication module52. TheUI processor50 then initiates establishment of a wireless connection between the remoteelectronic device12 and theinsulin infusion pump14 by placing a message into thedata buffer100 of the outbound port of thememory subsystem54, 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 theelectronic device12. Thewireless communication circuit52 then transmits this message as described above. If theinsulin infusion pump14 is within range, theinsulin infusion pump14 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 theelectronic device12, thewireless communication circuit52 is operable as described above to isolate the message from the wireless communication protocol structure and to place the message in thedata buffer98 of the inbound port of thememory subsystem54. TheUI processor50 then retrieves the message from the inbound port of thememory subsystem54, processes the message to determine whether it contains an acknowledgement response. If the message contains an acknowledgement response, theUI processor50 interprets this as indicating that a wireless connection is now established between theelectronic device12 and theinsulin infusion pump14, and controls thedisplay device18 to display a fixed (or flashing) icon to indicate that a wireless connection is established between theelectronic device12 and theinsulin infusion pump14. Theelectronic device12 periodically transmits a wireless connection status message to theinfusion pump14 in the above fashion at regular intervals. As long as theinsulin infusion pump14 responds as just described, theUI processor50 controls thedisplay18 to display the fixed (or flashing) icon to indicate that a wireless connection exists between theelectronic device12 and theinsulin infusion pump14. If theUI processor50 does not receive such a response within a predefined time period following storage of the acknowledgement response in thememory subsystem52, theUI processor50 controls thedisplay18 to display a flashing (or fixed) icon indicating that the wireless connection between theelectronic device12 and theinsulin infusion pump14 does not exist or no longer exists.
• In the illustrated embodiment thepower supply62 is generally powered on as long as thewireless communication circuit52 is communicating with either or both of theUI processor50 or theinsulin infusion pump14, unless otherwise powered off manually by a user via theuser buttons16 or automatically by thewireless communication circuit52. For example, thepower supply62 may be completely powered down, i.e., turned off, from any state via a simultaneous or sequential user press of a number of theuser buttons16. Thepower supply62 remains in the completely powered down state until the user again presses the simultaneous or sequential number of theuser buttons16 or a different simultaneous or sequential user press of a number of the user buttons, or if the user powers down theelectronic device12 and then powers back up theelectronic device12.
• While thepower supply62 is on and supplying the supply voltage to thewireless communication circuit52, thewireless communication circuit52 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 thepower supply62 after being in a lowest power sleep state for a predefined time period of inactivity. For example, when in a fully powered “awake” state, thewireless communication circuit52 is operable to periodically, e.g., every 100-200 milliseconds, check theoutbound data buffer100 of thememory subsystem54 as described above. As another example, each time thewireless communication circuit52 finds data to be sent in theoutbound data buffer100 of thememory subsystem54, thewireless communication circuit52 incorporates the data into the predetermined wireless communication protocol structure, and wirelessly transmits corresponding signals to theinsulin infusion pump14 as described above. Thewireless communication circuit52 transitions to a first low power state if it fails to find data in theoutbound data buffer100 of thememory subsystem54 when a predefined time period elapses since last finding data in theoutbound data buffer100. Thereafter, thewireless communication circuit52 transitions to successively lower power states as successively longer time periods elapse since last finding data in theoutbound data buffer100. 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, thewireless communication circuit52 periodically, e.g., every 400 milliseconds, wakes up to a “UART only” state, in which thewireless communication circuit52 has sufficient power to check the status of theoutbound data buffer100 of thememory subsystem54 via the data UART line. If theoutbound data buffer100 of thememory subsystem54 has data stored therein, thewireless communication circuit52 wakes up to a full power state to service the data. If theoutbound data buffer100 of thememory subsystem54 has no data stored therein, thewireless communication circuit52 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, thewireless communication circuit52 sends a control signal to thepower supply62 that causes thepower supply62 to turn off. As a further example, thewireless communication circuit52 directly monitors activity of theuser buttons16 via thedebounce circuitry68, and when thewireless communication circuit52 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, thewireless communication circuit52 must be capable of monitoring at least the ON button of theuser buttons16. Similarly, when thewireless communication circuit52 detects user press of the OFF button, thewireless communication circuit52 transitions itself from any of the power states to the lowest power “deep sleep” state.
• When a wireless connection is established between theelectronic device12 and theinsulin infusion pump14, and theUI processor50 determines that the wireless connection should be terminated, theUI processor50 stores a message in theoutbound data buffer100 of thememory subsystem54 that contains a connection termination request. When thewireless communication circuit52 thereafter finds the message in theoutbound data buffer100 of thememory subsystem54, thewireless communication circuit52 incorporates the message into the predetermined wireless communication protocol and then transmits the message via its wireless communication circuitry to theinsulin infusion pump14. Theinsulin infusion pump14 then wirelessly sends a signal containing a predefined connection termination response back to the remoteelectronic device12. Subsequently theprocessor28 instructs thewireless communication circuit30 to orderly terminate communications or connections with thewireless communications circuit52′ that may be specific to the predetermined wireless communications protocol. When the wireless connection is terminated in this manner, thewireless communication circuit52 is operable to periodically, but asynchronously with respect to operation of theUI processor50, check theoutbound data buffer100 of thememory subsystem54. If no data resides in theoutbound data buffer100, thewireless communication circuit52 successively enters lower power sleep states or modes as described above. If, however, thewireless communication circuit52 finds data in theoutbound data buffer100 of thememory subsystem54, thewireless communication circuit52 attempts to establish (or re-establish) a wireless connection with thewireless communication circuit30 of theinsulin infusion pump14 as described above.
• If, after a predefined or programmed number of attempts and/or elapsed time, no wireless connection can be established between thewireless communication circuit52 and thewireless communication circuit30, thewireless communication circuit52 illustratively clears theoutbound data buffer100 of thememory subsystem54. Alternatively, theUI processor50 may clear theoutbound data buffer100 if it determines that data exists in theoutbound data buffer100 after some time period has elapsed since storing the wireless communication message in theoutbound data buffer100 or after some time period has elapsed after determining, based on failure to receive acknowledgements from theinsulin infusion pump14, that a wireless connection between the remoteelectronic device12 and theinsulin infusion pump14 no longer exists. In any case, with theoutbound data buffer100 of thememory subsystem54 empty, thewireless communication circuit52 successively enters lower power sleep states or modes as described above.
• In the event of a lost wireless connection between the remoteelectronic device12 and theinsulin infusion pump14, thewireless communication circuit52 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 theoutbound data buffer100 of thememory subsystem54 since last finding data in theoutbound data buffer100. Because the wireless connection is lost, theUI processor50 will no longer receive acknowledgements from theinsulin infusion pump14 and will therefore cease to store messages in theoutbound data buffer100 of thememory subsystem54. However, a message, or at least part of a message, may reside within theoutbound data buffer100 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 theinsulin infusion pump14, thewireless communication circuit52 illustratively clears theoutbound data buffer100 of thememory subsystem54. Alternatively, theUI processor50 may clear theoutbound data buffer100 if it determines that data exists in theoutbound data buffer100 after some time period has elapsed since last storing a message in theoutbound data buffer100 or after some time period has elapsed after determining, based on failure to receive acknowledgements from theinsulin infusion pump14, that a wireless connection between thedevices12 and14 no longer exists. In any case, with theoutbound data buffer100 of thememory subsystem54 empty, thewireless communication circuit52 successively enters lower power sleep states or modes as described above.
• In one illustrative embodiment, theUI processor50 and theprocessor28 of theinsulin infusion pump14 may use scheduled messages and internal timers to control determinations by each of whether a wireless connection between the remoteelectronic device50 and theinsulin infusion pump14 exists. For example, during information exchange between theelectronic device12 and theinsulin infusion pump14, theUI processor50 is operable to periodically, e.g., every 100 milliseconds, transfer a message to theoutbound data buffer100 of thememory subsystem54 and to reset an internal timer circuit. Thewireless communication circuit52 asynchronously retrieves the message from theoutbound data buffer100 of thememory subsystem54 and transmits the message to theinsulin infusion pump14 as described above. Theinsulin infusion pump14 is responsive to receipt of the message to immediately transmit a message back to theelectronic device12 that contains an acknowledgement. The message transmitted by theinsulin infusion pump14 is received and unpacked from the wireless communication protocol by thewireless communication circuit52, and then stored by thewireless communication circuit52 in theinbound data buffer98 of thememory subsystem54. TheUI processor50 then retrieves the message from theinbound data buffer98 of thememory subsystem54 and processes the message to determine whether it contains an acknowledgement. As long as an acknowledgement is received by theUI processor50 in this manner before the next scheduled transfer of a message to theoutbound data buffer100 of thememory subsystem54, theUI processor50 resets its internal timer circuit when transferring the next message to thememory subsystem54. However, if an acknowledgement is not received by theUI processor50 before the next scheduled transfer of a message to theoutbound data buffer100 of thememory subsystem54, theUI processor50 transfers the message to theoutbound data buffer100 of thememory subsystem54 without resetting its internal timer circuit. If no acknowledgement is received by theUI processor50 within a predefined or programmed time period, e.g., 1-2 minutes, the internal timer circuit of theUI processor50 times out and theUI processor50 stops transferring messages to theoutbound data buffer100 of thememory subsystem54. Theinsulin infusion pump14, in this embodiment, ceases to send acknowledgements back to the remoteelectronic device12 after a predefined or programmed time period, e.g., 2 minutes, has passed without receiving a message transmitted by theelectronic device12.
• Illustratively, theUI processor50 is operable to cease storing messages in theoutbound data buffer100 of thememory subsystem54 upon detection of insertion of asample carrier22 into thecarrier port20 as described above. After a predefined time period in which thewireless communication circuit52 thereafter fails to find such messages in theoutbound data buffer100 of thememory subsystem54, thewireless communication circuit52 begins transitioning to lower power states as described above. When theUI processor50 then resumes storing messages in theoutbound data buffer100 of thememory subsystem54 after the analyte measurement is complete, thewireless communication circuit52 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 thewireless communication circuit52 has just entered the lowest power “deep sleep” state when the first message is stored in theoutbound data buffer100 of thememory subsystem54 after the analyte measurement is complete.
• Unless the remoteelectronic devices12 and theinsulin infusion pump14 are communicating information, thewireless communication circuit52 is generally in one of the lower power sleep states or modes. When insertion of asample carrier22 into thecarrier port20 is detected, theelectronic device12 performs an analyte determination test as described above. Theelectronic device12 generally does not wirelessly communicate with theinsulin infusion pump14 during the analyte determination test, and thewireless communication circuit52 is thus typically in one of the lower power sleep states when insertion of thesample carrier22 into thecarrier port20 is detected. Because theUI processor50 stops storing messages in theoutbound data buffer100 of thememory subsystem54 when insertion of thesample carrier22 into thecarrier port20 is detected, thewireless communication circuit52 therefore typically enters successively lower power sleep states after insertion of thesample carrier22 into thecarrier port20 is detected.
• While theelectronic device12 is illustrated and described above with respect toFIGS. 1-3 as including ananalyte measuring facility88, such an analyte measuring facility may be omitted in alternative embodiments. In any case, theelectronic device12 and theinsulin infusion pump14 may illustratively be paired according to a pairing process that establishes secure communications between theelectronic device12 and theinsulin infusion pump14. Illustratively, this process may be carried out to initially establish secure wireless communications between theelectronic device12 and a particularinsulin infusion pump14, and then again if theelectronic device12 is to be paired with a differentinsulin infusion pump14 or vice versa. In one illustrative embodiment, theelectronic device12 may only be paired with a singleinsulin infusion pump14 at a time, although this disclosure contemplates other embodiments in which theelectronic device12 may be paired with any number ofmedical devices14 generally and/or other electronic devices, and/or in which themedical device14 may be paired with any number ofelectronic devices12 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.
• Referring now toFIG. 4, a flow chart is shown of one illustrative embodiment of aprocess110 for enabling a bolus advice feature of the remoteelectronic device12. Illustratively, theprocess110 is stored in thememory unit66 of theUI processor50 in the form of instructions that are executable by theUI processor50 to enable the bolus advice feature. Theprocess110 begins atstep112 where the bolus advice feature of the remoteelectronic device12 is disabled during manufacture of the remoteelectronic device12.
• In one embodiment, theprocess110 advances fromstep112 to step114 where theUI processor50 is operable to monitor a predefined password flag. Thereafter atstep116, theUI processor50 is operable to determine whether the predefined password flag is active. If not, execution of theprocess110 loops back to step114. If; atstep116, theUI processor50 determines that the predefined password flag is active, theprocess110 advances to step118 where theUI processor50 is operable to enable the bolus advice feature of the remoteelectronic device12. Followingstep118, theprocess110 ends.
• In an alternate embodiment, as illustrated inFIG. 4, theprocess110 may advance fromstep112 to step120 where the UI processor is operable to monitor a pairing value storage location or flag. Thereafter atstep122, theUI processor50 is operable to determine whether the pairing value storage location or flag indicate that a pairing process, in which the remoteelectronic device12 is paired with themedical device14 as described above, is complete. If not, theprocess110 loops back tostep120. If, atstep122, theUI processor50 determines that the pairing value storage location or flag indicates that the pairing process is complete, theprocess110 advances to step124 where theUI processor50 is operable to enable the bolus advice feature of the remoteelectronic device12. Followingstep124, theprocess110 ends.
• In the embodiment illustrated inFIG. 4, the remoteelectronic device12 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 remoteelectronic device12, such as via theuser buttons16. 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 remoteelectronic device12 with a suitablemedical device14 according to a pairing process. Illustratively, the pairing process may be as described hereinabove with respect toFIGS. 1 through 3, although this disclosure contemplates that the pairing process between the remoteelectronic device12 and themedical device14 may alternatively be or include one or more other processes that are executed by the remoteelectronic device12 and/ormedical device14 that allows the remoteelectronic device12 and themedical device14 to communicate with each other. In another alternative embodiment, theprocess110 may include the combination of steps114-118 and120-124 such that the bolus advice feature is enabled only after successful pairing of the remoteelectronic device12 with themedical device14 and receiving of the predefined password as described above. In this embodiment, successful pairing of the remoteelectronic device12 with themedical device14 is illustratively required prior to receipt of the predefined password, although the order of these two events may alternatively be reversed.
• Referring now toFIG. 5, a flow chart of one illustrative embodiment of aprocess130 is shown that is carried out in the remoteelectronic device12 for establishing wireless communications between the remoteelectronic device12 and themedical device14 under various operating conditions of the remoteelectronic device12 in which the remoteelectronic device12 and themedical device14 may not already be connected via awireless communication link40. Illustratively, theprocess130 is stored in thememory device66 of theUI processor50 in the form of instructions that are executable by theUI processor50 to automatically establish wireless communications between the remoteelectronic device12 and themedical device14 under certain operating conditions. At the beginning of theprocess130, theUI processor50 is operable to simultaneously to execute steps at132,136,140 and142. Atstep132, theUI processor50 is operable to monitor the on/off switch of the remoteelectronic device12. Thereafter atstep134, theUI processor50 is operable to determine whether the on/off switch of the remoteelectronic device12 has been turned on. If not, theprocess130 loops back tostep132. If, atstep134, theUI processor50 determines that the on/off switch has been turned on, theUI processor50 is operable atstep144 to establish wireless communications with themedical device14 as described hereinabove with respect toFIGS. 1-3.
• TheUI processor50 is operable atstep136 of theprocess130 to monitor a number of automatic reminders programmed therein. Thereafter atstep138, theUI processor50 is operable to determine whether any of the programmed automatic reminders has triggered the power up of the remoteelectronic device12 from a powered down state. Alternatively, theUI processor50 may be operable atsteps136 and138 to monitor the on/off state of the remoteelectronic device12, and to determine whether and when the remoteelectronic device12 powers up from a powered down state in response to the occurrence of an automatic reminder. In either case, the “NO” branch ofstep138 loops back to step136, and the “YES” branch ofstep138 advances to step144 where theUI processor50 is operable to establish a wireless connection with themedical device14 as described above.
• TheUI processor50 is operable atstep140 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, theprocess130 loops back to the beginning ofstep140, and if theUI processor50 determines atstep140 that a user has selected the bolus advice feature, theprocess130 advances to step144 where theUI processor50 is operable to establish a wireless connection with themedical device14 as described above.
• TheUI processor50 is operable at142 to monitor the main menu display on thedisplay device18 of the remoteelectronic device12 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 themedical device14. In any case, the “NO” branch atstep142 loops back to the beginning ofstep142, and the “YES” branch advances to step144 where theUI processor50 is operable to establish wireless connection with themedical device14 as described above.
• Referring now toFIG. 6, a flow chart is shown of one illustrative embodiment of aprocess145 that is carried out in the remoteelectronic device12 for processing information at certain times when a wireless connection is established between the remoteelectronic device12 and themedical device14. Illustratively, theprocess145 is stored in thememory device66 of theUI processor50 in the form of instructions that are executable by theUI processor50 to carry out theprocess145. Theprocess145 begins atstep146 where theUI processor50 is operable to determine whether a wireless communication link has just been established between the remoteelectronic device12 and themedical device14, such as via one or more of the operations illustrated and described with respect toFIG. 5. If not, theprocess145 loops back to the beginning ofstep146. Illustratively, theUI processor50 is operable while executingstep146 to also executestep148 where theUI processor50 is operable to determine whether the remoteelectronic device12 has just exited a remote terminal operating mode in which the remoteelectronic device12 is configured to control operation of themedical device14 in substantially real time over a wireless connection established between the twodevices12,14. If, atstep148, theUI processor50 determines that the remoteelectronic device12 has not just exited the remote terminal operating mode with the wireless connection still established, theprocess145 loops back to the beginning ofsteps146 and148. If, atstep148, theUI processor50 determines that the remote electronic device has just exited the remote terminal operating mode with the wireless connection still established between thedevices12,14 or if, atstep146, theUI processor50 determines that a wireless communication link has just been established between the remoteelectronic device12 and themedical device14, theUI processor50 is operable to execute each ofsteps150,156 and168.
• Atstep150, theUI processor50 is operable to transfer operating data, e.g., event history information, from themedical device14 to the remoteelectronic device12 via the wireless communication link. In one embodiment, the remoteelectronic device12 includes four separate databases that hold history information for computing boluses and for reviewing and/or further analyzing. Referring toFIG. 7, a diagram is shown of one illustrative embodiment of four such databases that are included in the remoteelectronic device12, and that are illustratively located in thememory device66. The four databases include a BG/Diary database65, a pump records (PR)database67, a meal correction (MC)database69 and a correction records (CR)database71. The BG/Diary database65 acts as the main database, and thePR database67,MC database69 andCR database71 are support databases which hold data used to calculate active insulin and bolus advice. The BG/Diary database65 holds the overall resulting bolus advice data long with interim and input data used in determining the bolus advice. As illustrated inFIG. 7, the BG/Diary database65 is in data communication with each of the other threedatabases67,69 and71.
• In one illustrative embodiment, the BG/Diary database65 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 database65 contains the bolus advice calculations and input parameters used in the bolus calculations.
• In one embodiment, the correction records (CR)database71 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, theCR database71 is intended to hold 8 hours of prior bolus information. Thecorrection records database71 is monitored over time by theUI processor50 to determine which of the records are active and which are inactive. Thecorrection records database71 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 theCR database71 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.
• In the illustrated embodiment, themeal correction database69 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 database65. This update occurs whether the current meal correction record is active or not. Like thecorrection records database71, the meal correction database is monitored over time to determine whether the sole record in themeal correction database69 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 themeal correction database69 is also associated with a specific record in the BG/Diary database65, and this association is determined by the BG/Diary date and time stamp and a record counter value for the specific BG/Diary record.
• In the example embodiment, thepump records database67, like the BG/Diary database65, 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 thepump records database68 when the operating data from the pump, e.g., the pump history records, are transferred to the remoteelectronic device12 according to step154 of theprocess150 ofFIG. 6. The pump history records are synchronized with specific records in the BG/Diary database65 with the intent of matching up actual pump delivery amounts from the pump history records with bolus amounts in the BG/Diary database65. As will be described in greater detail hereinafter with respect toFIGS. 10 and 11, pump history records that match corresponding BG/Diary records are used to confirm the bolus amounts in the BG/Diary database65 as part of the synchronization process. When a pump record cannot be matched with a specific record in the BG/Diary database65, a new record containing the pump information is added to the BG/Diary database65. ThePR database67, in the illustrated embodiment, is used strictly as a scratch pad area for holding pump records that are transferred from thepump14 to the remote electronic device pursuant to step154 of theprocess150 ofFIG. 6.
• Referring now toFIGS. 8 and 9, one illustrative embodiment of the process carried out at step154 of theprocess150 illustrated inFIG. 6 is shown. Referring specifically toFIG. 8, a diagram is shown of adata buffer170 that resides in the pump history (PH)memory device29 of themedical device14. Thedata buffer170 is configured to store time stamped medical device event records, and in the embodiment illustrated inFIG. 7 thedata buffer170 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 themedical device14 to the remoteelectronic device12 during the most recent download of the medical device event records from themedical device14 to the remoteelectronic device12. However, when themedical device14 is re-paired with a new remoteelectronic device12 or re-paired with an existing remoteelectronic device12, the history position pointer, HP, is illustratively set to point to the first record in the data buffer.
• In any case, the medical device event records are illustratively stored in thedata buffer170 in the order of time of occurrence such that the oldest medical device event record is at the output of thedata buffer170 and the newest medical device event record is at the input of thedata buffer170.
• Referring now toFIG. 9, a flow chart is shown of one illustrative embodiment of a process for carrying out step154 of theprocess150 ofFIG. 6 to transfer portions of the time stamped medical device event records from themedical device14 to the remoteelectronic device12. The flow chart ofFIG. 9 is partitioned into portions that are carried out by the remoteelectronic device12 and other portions that are carried out by themedical device14. Thus, the remote electronic device will carry out some of the steps of the illustrative process while themedical device14 will carry out others. The data transfer process begins atstep172 where theUI processor50 of the remoteelectronic device12 is operable to determine whether a wireless connection between the remoteelectronic device12 and themedical device14 has just been established. If not, the process loops back to the beginning ofstep172, otherwise the process advances to step174 where theUI processor50 of the remoteelectronic device12 is operable to send a read pump history command to themedical device14 via thewireless communication circuit54. Thereafter atstep176, theprocessor28 of themedical device14 is operable to receive, via thewireless communication circuit30, the read pump history command sent by the remoteelectronic device12. Thereafter atstep178, theprocessor28 of themedical device14 is operable to scan the pump history records that have been saved in thememory device29 since storage therein of the pump history record to which the history position pointer, HP, points. If, atstep180, theprocessor28 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 remoteelectronic device12 is about to expire, the process advances fromstep180 to step182. Otherwise, step180 loops back to step178 to continue to scan and search for pump history records that have been stored in thedata buffer170 since the storage therein of the pump history record to which HP points.
• Atstep182, theprocessor28 of themedical device14 is operable to determine whether a history gap flag has been set. If so, the process advances to step184 where theprocessor28 includes a history gap indicator in the response to be sent to the remoteelectronic device12. Theprocessor28 is further operable atstep184 to determine from thedata buffer170 whether additional pump history data is available after detecting the history gap from the history gap flag. Illustratively, theprocessor28 further includes information in the response to be sent to the remoteelectronic device12 that indicates whether any such additional pump history data is available after the detected history gap. Fromstep184, and from the “NO” branch ofstep182, the process advances to step186 where theprocessor28 is operable to send, via thewireless communication circuit30, a block or partial block of pump history event records to the remoteelectronic device12. Thereafter atstep188, theUI processor50 of the remoteelectronic device12 is operable to receive, via thewireless communication circuit54, the block or partial block of pump history event records from themedical device14. Thereafter atstep190, theUI processor50 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 thePR database67, was successful. If not, the process loops back to step174 where the pump history request, search and transfer process just described is repeated. If, atstep190, theUI processor50 determines that the processing of the block or partial block of pump history event records atstep188 was successful, the process advances to step192 where theUI processor50 is operable to send thewireless communication circuit54, a successful transfer message to themedical device14. Thereafter atstep194, theprocessor28 of themedical device14 is operable to receive, via thewireless communication circuit30, 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 thedata buffer170 that corresponds the oldest pump history event record that was sent to, and successfully processed by, the remoteelectronic device12. Fromstep194, the process loops back to step176 to again scan pump history event records that were saved in the pumphistory memory device29 since storing the pump history event record to which the newly positioned history position pointer, HP, now points.
• Step192 of the illustrated process additionally advances to step196 where theUI processor50 is operable to determine whether all pump history event records since the previous execution of the illustrative process have been transferred from themedical device14 to the remoteelectronic device12. Illustratively, theprocessor28 of themedical device14 is operable to include a last record indicator in the block or partial block of pump history event records transferred from themedical device14 to the remoteelectronic device12 atstep184. If, atstep196, theUI processor50 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 themedical device14 to the remoteelectronic device12, the process advances to step198 where the process ends. Otherwise, the process loops fromstep196 back to step174 where the process continues as described until all pump history event records that were stored in thememory device29 of theprocessor28 since the previous execution of the illustrated process are transferred.
• Atstep200, theprocessor28 of themedical device14 is operable to monitor the data in the pump history event record to which the history position pointer, HP, points. Thereafter atstep202, theprocessor28 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 themedical device14 to the remoteelectronic device12. If so, this means that at least some of the pump history event records stored in thedata buffer170 have been overwritten since the last transfer of information from themedical device14 to the remoteelectronic device12, and that a gap in the time line of pump history event records therefore exists. In this case, the process advances fromstep202 to step204 where theprocessor28 is operable to activate the history gap flag described above. Otherwise, step202 loops back tostep200.
• Referring again toFIG. 6, theprocess145 advances fromstep150 to step152 where theUI processor50 is operable to process the medical device operating data that was transferred from themedical device14 to the remoteelectronic device12 atstep150. Referring now toFIGS. 10 and 11, a flowchart is shown of one illustrative process for carrying outstep152 of theprocess145 ofFIG. 6 to process the pump history records and synchronize the pump history records with the BG/Diary records in the BG/Diary database65. Illustratively, the process ofFIG. 10 is stored in thememory unit66 in the form of instructions that are executable by theUI processor50 to carry out the illustrated process.
• The pump history records transferred from thepump14 to the remoteelectronic device12 may include commanded and non-commanded pump events. Commanded events are generally those in which the remoteelectronic device12 commands theliquid infusion pump14, via thewireless communication circuits52 and30 respectively, to deliver a desired bolus amount and type, except when the remoteelectronic device12 and thepump14 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 thekeys32 of thepump14. Non-commanded events, in contrast, are those that were performed manually by the user and not commanded by the remoteelectronic device12. Non-commanded events may include manually programming the liquid infusion pump14 to deliver desired bolus amounts and types, and also manually delivering bolus amounts via a syringe or drug delivery pen. In the process illustrated inFIG. 10, both commanded and non-commanded events are read from the pump history records transferred from thepump14 to the remoteelectronic device12 and synchronized with the BG/Diary database65. 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.
• Illustratively, theUI processor50 is operable pursuant to the process illustrated inFIGS. 10 and 11 to synchronize the pump event records with the BG/Diary database65 immediately after the records are transferred from thepump14 to the remoteelectronic device12. 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 database65. Each such new addition of a BG/Diary record will require a corresponding update of thecorrection records database71.
• 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, thecorrection records database71 is updated to reflect the actual delivered bolus amount. Illustratively, thecorrection records database71 is updated in this manner to ensure accuracy of the active insulin value that can be determined from the data.
• The process illustrated inFIGS. 10 and 11 is executed once for each pump event record that is transferred from thepump14 to the remoteelectronic device12. The illustrated process begins atstep210 where theUI processor50 is operable to search the BG/Diary database for all records with non-confirmed bolus amounts. Thereafter atstep212, theUI processor50 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 theUI processor50 determines atstep212 that the current pump event is not a commanded event, the process advances to step A (FIG. 11). If theUI processor50 instead determines atstep212 that the current pump event record corresponds to a commanded pump event, the process advances to step214 where theUI processor50 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.
• If theUI processor50 determines atstep214 that the current pump event corresponds to a programmed bolus amount, the illustrated process advances to step216 where theUI processor50 searches through the non-confirmed and non-programmed Standard, Extended and Multi-wave bolus type records in the BG/Diary database65 for a record having a date/time stamp and bolus delivery type (DTD) that matches that of the current pump event record. If theUI microprocessor50 finds such a match atstep216, the illustrated process advances to step218 where theUI processor50 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 step220 where theUI processor50 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 step222 where theUI processor50 is operable to set a bolus advice flag in the current BG/Diary record to PROG. If atstep218 theUI processor50 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 step224. Likewise, if theUI processor50 determines atstep220 that the programmed bolus amount in the BG/Diary record is not equal to a user selected amount, the illustrated process advances to step224. Also, if theUI processor50 does not find a match atstep216, the illustrated process advances to step224. At step224, theUI processor50 is operable to create and add a new record to the BG/Diary database65 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.
• If, atstep214, theUI processor50 determines that the current pump event corresponds to a delivered bolus amount, the illustrated process advances to step226 were theUI processor50 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 theUI processor50 determines atstep226 that the delivered bolus type is a standard bolus (STD), the illustrated process advances to step228 where theUI processor50 searches through the non-confirmed and programmed Standard bolus type records in the BG/Diary database65 for a record having a date/time stamp and bolus delivery type (DTD) that matches that of the current pump event record. If theUI microprocessor50 finds such a match atstep228, the illustrated process advances to step230 where theUI processor50 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 step232 where theUI processor50 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 atstep230 theUI processor50 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 theUI processor50 does not find a match atstep228, the illustrated process advances to step234 where theUI processor50 is operable to create and add a new record to the BG/Diary database65 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.
• If, atstep226, theUI processor50 determines from the pump event record that the delivered bolus type is not a standard bolus (STD), the illustrated process advances to step236 where theUI processor50 searches through the non-confirmed and programmed Extended (EXT) and Multi-wave (MW) bolus type records in the BG/Diary database65 for a record having a date/time stamp and bolus delivery type (DTD) that matches that of the current pump event record. If theUI microprocessor50 finds such a match atstep236, the illustrated process advances to step238 where theUI processor50 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 step240 where theUI processor50 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 atstep238 theUI processor50 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 theUI processor50 does not find a match atstep236, the illustrated process advances to step242 where theUI processor50 is operable to create and add a new record to the BG/Diary database65 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.
• Referring now toFIG. 11, the “A” branch ofstep212 of the process illustrated inFIG. 10 advances to step250 where theUI processor50 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 theUI processor50 determines the event type to be a programmed bolus event, the process advances to step252 where theUI processor50 is operable to search through the non-confirmed and non-programmed manual and pen/syringe type bolus records in the BG/Diary database65 for a record having a date/time stamp that is closest to that of the current pump event record. Thereafter atstep254 theUI microprocessor50 is operable to determine whether the time stamp (T) of the BG/Diary record selected atstep252 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 step256 where theUI processor50 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 step260 where theUI processor50 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 ofsteps254 and256, the illustrated process advances to step258 where theUI processor50 is operable to create and add a new record to the BG/Diary database65 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.
• If, atstep250, theUI processor50 determines from the current pump history record that the pump event type corresponds to a delivered bolus event, the illustrated process advances to step262 where theUI processor50 is operable to search through the Manual and Pen/Syringe type, non-confirmed and programmed records in the BG/Diary database65 for a record having a date/time stamp that matches that of the current pump event record. If theUI microprocessor50 finds such a match atstep262, the illustrated process advances to step264 where theUI processor50 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 step266 where theUI processor50 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 atstep262 theUI processor50 does not find a match, and also from the “NO” branch ofstep264, the illustrated process advances to step268 where theUI processor50 is operable to create and add a new record to the BG/Diary database65 using the date/time stamp and data from the current pump event record. Thereafter atstep270, theUI processor50 is operable to set the bolus advice flag of this new record to DELIV and to set the delivery type to MANUAL.
• Further details relating to the processing of information in one or more of thedatabases65,67,69 and71 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.
• Referring again toFIG. 6, the “YES” branch ofstep146 also advances to step156 where theUI processor50 is operable to send a time request message to themedical device14 via the wireless communication link. Thereafter atstep158, the medical device receives the time request and sends a current medical device time (MDT) to the remoteelectronic device12 via the wireless communication link. Thereafter atstep160, the remoteelectronic device12 receives MDT and compares the medical device time to the current remote electronic device time (RDT). Followingstep160, theUI processor50 is operable atstep162 to determine whether a difference between MDT and RDT is greater than 60 seconds. If so, theUI processor50 is operable to set the current remote electronic device time, RDT, equal to the medical device time, MDT that was wirelessly sent by themedical device14 to the remoteelectronic device12 atsteps158 and160. Followingstep164, theprocess145 advances to step166 where theUI processor50 is operable to update thecorrection records database71 and themeal correction database69 with the new remote device time, RDT. More specifically, when the remote electronic device time, RDT, changes, the active records in thecorrection records database71 and themeal correction database69 are updated based on the new RDT.
• The “YES” branch ofstep146 also advances to step168 where theUI processor50 is operable to check and act on any warnings, alarms or errors that are associated with themedical device14 and the occurrence of which is communicated wirelessly to the remoteelectronic device12 when the wireless communication link is established. Followingsteps152,166 and168 and the “NO” branch ofstep162, theprocess145 ends.
• Referring now toFIGS. 12A-12C, a flow chart is shown of one illustrative embodiment of abolus advice process300 that is carried out by the remoteelectronic device12. In the context of the flowchart ofFIGS. 12A and 12B, themedical device14 is illustratively implemented in the form of an insulin infusion pump, and will be described as such throughout the description of theprocess300. It will be understood, however, that this disclosure contemplates alternate embodiments in which themedical device14 is or includes one or more other conventional medical devices.
• Illustratively, theprocess300 is stored in thememory device66 of theUI processor50 in the form of instructions that are executable by theUI processor50 to carry out thebolus advice process300. Theprocess300 presumes that the remoteelectronic device12 is powered up and that theUI processor50 is currently controlling thedisplay device18 to display amain menu302 that is generally displayed upon power up of the remoteelectronic device12. Illustratively, themain menu302 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 pumpremote control process304, a “my data”process306 and a settings or device set up process. The pumpremote control process304, or remote terminal operational mode as referred to above, illustratively provides a menu-driven process by which the remoteelectronic device12 may control operation of theinsulin infusion pump14 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.
• The “my data”process306 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, theUI processor50 stores in thememory66 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.
• 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.
• The BG test process that may be selected from themain menu302 begins atstep308 where theUI processor50 determines whether the user has selected the BG test process from themain menu302. If not, the “NO” branch ofstep308 loops back to the beginning ofstep308. If, atstep308, theUI processor50 determines that the user has selected the BG process from themain menu302, theprocess300 advances to step310 where theUI processor50 controls thedisplay device18 to prompt a user to conduct a BG test. In one embodiment, theUI processor50 controls thedisplay device18 to visually guide a user through a blood glucose measurement sequence in which a user inserts acarrier22 into theglucose measurement facility20 of the remoteelectronic device12 and deposits a sample of blood on thecarrier22, after which theblood glucose meter88 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 theblood glucose meter88 that is on-board the remoteelectronic device12 to theUI processor50 as describe hereinabove. Fromstep310, theprocess300 advances to step312 where theUI processor50 is operable to control thedisplay device18 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.
• Referring now toFIG. 13, a flow chart is shown of one illustrative embodiment of aprocess350 for controlling thedisplay device18 of the remoteelectronic device12 to indicate readily perceptible warnings and/or alerts. Theprocess350 may illustratively be used to carry outstep312 of theprocess300 illustrated inFIG. 12A, although theprocess350 is broader than briefly described with respect to step312 and may alternatively or additionally be used to control a display device of the remoteelectronic device12 and/or themedical device14 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, theprocess350 may be stored in thememory device66 of theUI processor50 and/or in thememory device25 of theprocessor28 of theinsulin infusion pump14 in the form of instructions that are executable by theprocessor50,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.
• Theprocess350 begins atstep352 where theprocessor50,28 is operable to determine whether an analyte or drug related value has just been measured or computed. If not, the “NO” branch ofstep352 loops back to the beginning ofstep352. Otherwise, theprocess350 advances to step354 where theprocessor50,28 is operable to determine a display color based on the measured or computed value relative to one or more reference values. Thereafter atstep356, theprocessor50,28 is operable to control thedisplay device18,34 to change the color of the display or a portion thereof to the display color determined atstep354 when displaying the measured or computed value and/or a warning message related to the measured or computed value. Fromstep356, theprocess350 ends.
• Theprocess350 ofFIG. 13 may illustratively be used atstep312 of theprocess300 to display the measured BG value with an on-screen color indicator. In one example embodiment, theUI processor50 may be operable atstep356 of theprocess350 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.
• Also followingstep310, theprocess300 advances to step314 where theUI processor50 is operable to execute a hypoglycemic test process in relation to the blood glucose value, BG, measured atstep310. Referring now toFIG. 14, a flowchart is shown of one illustrative embodiment of thehypoglycemic test process314. Illustratively, theprocess314 is stored in thememory66 of theUI processor50 in the form of instructions that are executable by theUI processor50 to conduct the hypoglycemic test. Theprocess314 begins atstep360 where theUI processor50 is operable to determine whether the measured BG value, BG, is less than a hypoglycemic limit value, BG_HYPO. If so, theprocess314 advances to step362 where theUI processor50 is operable to control thedisplay device18 to display a message indicating that the measured BG value is too low for a bolus to be delivered. Thereafter atstep364, theUI processor50 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_TARGET. In one embodiment, for example, theUI processor50 is operable atstep364 to compute the required carbohydrates according to the formula CARBS=(BG_TARGET−BG)*IS*CR, wherein IS corresponds to a programmable insulin sensitivity value and CR corresponds to a programmable carbohydrate ratio. In any case, theprocess314 advances fromstep364 to step366 where theUI processor50 is operable to control thedisplay device18 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. Followingstep366, theprocess314 returns the value RETURN to theprocess300 ofFIG. 12A, and following the “NO” branch ofstep360 theprocess314 returns the value ADVANCE to theprocess300 ofFIG. 12A. Thus, if the blood glucose measurement taken atstep310 is less than BG_HYPO, theprocess300 follows the RETURN path fromstep314 and loops back to display the main menu. If the blood glucose measurement taken atstep310 is not less than BG_HYPO, theprocess300 follows the ADVANCE path to step316. In alternate embodiments, the hypoglycemic limit value, BG_HYPO, may be replaced atstep360 by another suitable lower BG limit.
• If theprocess300 reaches step316, 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. TheUI processor50 is accordingly operable following the ADVANCE path fromstep314 to step316 to determine whether the user has selected the bolus option from the BG display. If not, theprocess300 advances to step318 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, theUI processor50 is operable to store the BG value in thememory unit66 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 theUI processor50 determines atstep316 that the user has selected the bolus key option from the BG value display screen, theprocess300 advances to step322.
• From themain menu302, the user may alternatively select the bolus advice process, and theUI processor50 is accordingly operable atstep320 to determine if the user has selected the bolus advice process. If not, the “NO”branch step320 loops back at the beginning ofstep320, and otherwise theprocess300 advances to step322 where theUI processor50 is operable to determine whether the pump history and/or bolus threshold and/or pump status information was updated when thebolus advice process300 was entered either viastep316 orstep322. If not, theprocess300 advances to step324 where theprocessor50 is operable to control thedisplay device18 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. Fromstep324, and from the “YES” branch ofstep322, theprocess300 advances to step326 where theprocessor50 is operable to compute the active insulin value, AI. Thereafter atstep328, theUI processor50 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 atstep328, theUI processor50 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 atstep328, theUI processor50 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.
• Theprocess300 advances fromstep328 to step330 where theUI processor50 is operable to compute a total recommended bolus, TRB, as a sum of B1-B3. Thereafter atstep332, theUI processor50 is operable to control thedisplay unit18 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 step312, 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 thepump14 from the remoteelectronic device12, and two manual types. In one embodiment, if a blood glucose measurement, BG, has been conducted within a predefined time period prior to executingstep332, theUI processor50 is operable atstep332 to display the bolus advice screen showing the measured blood glucose value, BG. Otherwise, theUI processor50 may be illustratively operable atstep332 to display “bG Test” on the screen where a BG value would be shown if a current BG value was available. Fromstep332, theprocess300 advances to a sub-process B. In general, any value that was measured by or entered into the remoteelectronic device12 ormedical device14 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.
• Referring now toFIG. 15, a graphic example is shown of one illustrative embodiment of a bolusadvice display screen386 produced by theprocess300 ofFIG. 12A at the point just prior to executing sub-process B, i.e., afterstep324 orstep330. In the illustrated example, aBolus Advice label370 appears at the top of thescreen368 to indicate that the user is executing the bolus advice feature. A blood drop symbol appears next to the displayedblood glucose value372, e.g., 120 mg/dl, and a color bar374, providing a visual indication of theblood glucose value372 relative to an acceptable blood glucose range and/or a number of blood glucose limits, is positioned next to theblood glucose value372. Theactive insulin value378, e.g., −2 U, is positioned under theblood glucose value372, and abolus value376, corresponding to the bolus value B1, is displayed adjacent to theactive insulin value378. As described above, if thebolus advice screen368 was generated viastep330 and a recently measured blood glucose value, BG, was not available, thevalue120 mg/dL would illustratively be replace by the phrase bG Test.
• An apple symbol is used to identify acarbohydrates field380, and a heart symbol is used to identify ahealth field382. Abolus type indicator386 appears below thehealth field382 and the total recommendedbolus value382, e.g., 3 U, is displayed adjacent to thebolus type indicator386. Abolus type388, e.g., Standard, is displayed below the total recommendedbolus384. At the bottom of the screen between Cancel and Confirm inputs, aBlueTooth® symbol390 is provided to indicate the connection status of the wireless communication link with theinsulin infusion pump14, e.g., solid when a wireless connection exists and otherwise flashing.
• Referring now toFIGS. 12B and 12C, the sub-process B identified afterstep332 ofFIG. 12A, is shown, wherein the sub-process B forms part of thebolus advice process300. 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 aprocess400 for measuring a blood glucose value and computing a bolus amount, B1, which corresponds to the BG measurement. In the illustrated embodiment, theprocess400 begins atstep402 where theUI processor50 is operable to determine whether a strip insert, e.g., insertion of a blood glucose strip into thecarrier port20 of the remoteelectronic device12, 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, theprocess400 loops back to the beginning ofstep402. If, atstep402, theUI processor50 determines that a strip insert or user selection of the bG Test field has been detected, theprocess400 advances to step404 where theUI processor50 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 atstep406, theUI processor50 is operable to execute thehypoglycemic test process314 illustrated inFIG. 14 and described above. If thehypoglycemic test process314 returns a value RETURN, this indicates that the blood glucose value is too low to recommend a bolus value and theprocess400 advances to step414 where theUI processor50 is operable to exit the bolus advice feature and display themain menu302. If thehypoglycemic test process314 instead returns the value ADVANCE, theprocess400 advances to step408 where theUI processor50 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 theUI processor50 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, followingstep408 theUI processor50 is operable atstep410 to compute a total recommended bolus value, TRB, as a sum of B1 and two other bolus values, B2 and B3. Thereafter atstep412, theUI processor50 is operable to update the bolus advice screen with BG; a BG color indicator as described above, B1-B3 and TRB. Fromstep412, theprocess400 loops back to the beginning of the sub-process B.
• The sub-process B ofFIG. 12B further includes aprocess420 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. Theprocess420 begins atstep422 where theUI processor50 is operable to determine whether a user has selected the CARB field of the displayed bolus advice screen, e.g.,item380 illustrated inFIG. 15. If not, theprocess420 loops back to the beginning ofstep422. If user selection of the CARBS field is detected atstep422, theprocess420 advances to step424 where theprocessor50 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, theprocess420 loops back to the beginning ofstep424. In one embodiment, the user atstep424 may manually enter a carbohydrate value into the remoteelectronic device12, e.g., via theuser buttons16, 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 theUI processor50 on thedisplay device18 atstep422 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 theUI processor50 is operable atstep424 to automatically enter the total carbohydrate value determined by the menu-driven food database process into the carbohydrate value field displayed on thedisplay device18 atstep424. In any case, if the user has entered a carbohydrate value that is detected by theUI processor50 atstep424, theprocess420 advances to step426 where theUI processor50 is operable to re-compute each of the bolus values B1-B3. Thereafter atstep428, theUI processor50 is operable to compute the total recommended bolus, TRB, as the sum of B1-B3. Thereafter atstep430, theUI processor50 is operable to control thedisplay device18 to update the bolus advice display screen to include the carbohydrate value provided by the user atstep424 to display the computed bolus values, B1-B3, determined atstep426 and to display the updated total recommended bolus value, TRB. Theprocess420 loops fromstep430 back to the beginning of the sub-process B.
• The sub-process B ofFIG. 12B further includes a process440 for entering a health information, and determining a bolus value based on the entered health information. The process440 begins atstep442 where theUI processor50 is operable to determine whether a user has selected the Health field of the displayed bolus advice screen, e.g.,item382 illustrated inFIG. 15. If not, the process440 loops back to the beginning ofstep442. If user selection of the Health field is detected atstep442, the process440 advances to step444 where theprocessor50 is operable to determine whether a Health value has been entered by the user. If not, the process440 loops back to the beginning of step444. In one embodiment, when the user manually selects atstep442 the health event field displayed on thedisplay device18 by theUI processor50, theUI processor50 is operable to control thedisplay device18 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 step444, theUI processor50 is operable thereafter atstep446 to re-compute the bolus values B1-B3. Thereafter at step448, theUI processor50 is operable to again compute the total recommended bolus, TRB, e.g., as a sum of the individual bolus values, B1-B3. The process440 advances from step448 to step450 where theUI processor50 is operable to control thedisplay device18 to update the bolus advice display to include the health event, the bolus values, B1-B3, and the total recommended bolus value, TRB. The process440 loops fromstep450 back to the beginning of the sub-process B.
• The sub-process B ofFIG. 12B further includes aprocess460 that allows the user to manually modify the total recommended bolus value, TRB. Theprocess460 begins atstep462 where theUI processor50 is operable to determine whether a user has selected the TRB field of the displayed bolus advice screen, e.g.,item384 illustrated inFIG. 15. If not, theprocess460 loops back to the beginning ofstep462. If user selection of the TRB field is detected atstep462, theprocess460 advances to step464 where theprocessor50 is operable to determine whether the user has modified the TRB value. If not, theprocess460 loops back to the beginning ofstep464. If theprocessor50 determines that the user has, atstep464, modified the TRB value, theprocess460 advances to step466 where theUI processor50 is operable to control thedisplay device18 to update the bolus advice display to include the modified total recommended bolus value, TRB. Theprocess460 loops fromstep466 back to the beginning of the sub-process B.
• Referring now toFIG. 12C, the sub-process B further includes aprocess470 for selecting a bolus type. Theprocess470 begins atstep472 where theUI processor50 is operable to determine whether a user has selected the bolus type field of the displayed bolus advice screen, e.g.,item388 illustrated inFIG. 15. If not, theprocess470 loops back to the beginning ofstep472. If user selection of the bolus type field is detected atstep472, theprocess470 advances to step474 where theprocessor50 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 remoteelectronic device12 and14 is or can be established, the available bolus types may illustratively include all bolus types that thepump14 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 atstep474, and any such alternative or additional bolus types are contemplated by this disclosure.
• Followingstep474, theprocess470 advances to step476 where theUI processor50 is operable to determine whether the user has selected a bolus type. If not, theprocess470 loops back tostep474. If theprocessor50 determines that the user has, atstep476, selected a bolus type, theprocess470 advances to step476 where theUI processor50 is operable to control thedisplay device18 to update the bolus advice display to include the selected bolus type. Theprocess470 loops fromstep478 back to the beginning of the sub-process B.
• The sub-process B ofFIG. 12C further includes aprocess480 that allows the user to cancel and exit the bolus advice process. Theprocess480 begins atstep482 where theUI processor50 is operable to determine whether a user has selected the Cancel function displayed on the bolus advice screen, e.g., seeFIG. 15, such as via one of theuser buttons16. If not, theprocess480 loops back to the beginning ofstep482. If user selection of the Cancel function is detected atstep482, theprocess480 advances to step484 where theprocessor50 is illustratively operable to exit the bolus advice process and display themain menu302.
• The sub-process B ofFIG. 12C further includes aprocess490 that allows the user to confirm the diary entry including the total recommended bolus, TRB, for delivery. Theprocess490 begins atstep492 where theUI processor50 is operable to determine whether a user has selected the Confirm function displayed on the bolus advice screen, e.g., seeFIG. 15, such as via one of theuser buttons16. If not, theprocess490 loops back to the beginning ofstep492. If user selection of the Confirm function is detected atstep492, theprocess490 advances to step494 where theUI processor50 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, theprocess490 advances to step496 where theUI processor50 is illustratively operable to store the bolus advice record, and to exit the bolus advice process and display themain menu302.
• It atstep494, theUI processor50 determines that TRB is not less than or equal to zero, theprocess490 advances to step498 where theUI processor50 is operable to determine whether the user confirmation detected atstep492 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, theprocess490 advances to step500 where theUI processor50 is operable to determine whether the remoteelectronic device12 and thepump14 are still wirelessly connected via a wireless communication link40 (seeFIG. 1). If not, theprocess490 advances to step502 where theUI processor50 sets as the currently available bolus types only the manual bolus types, i.e., manual pump and pen/syringe, and theprocess490 thereafter loops back to the beginning of the sub-process B. Thus, if theUI processor50 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 remoteelectronic device12 and theinfusion pump14, theprocess490 returns to the bolus advice process of sub-process B where theUI processor50 makes available as user selectable bolus types, e.g., atstep474 of theprocess470, only manually deliverable bolus types, e.g., via manual programming of an infusion pump or via manual delivery via a drug pen or syringe.
• If, atstep500, theUI processor50 determines that the remoteelectronic device12 and thepump14 are still wirelessly connected, theprocess490 advances to step504 theUI processor50 determines whether the user selected bolus type, i.e., the bolus type selected by the user atstep476, is a Standard bolus, STD. If so, theprocess490 advances to a process C. If not, theprocess490 advances to step506 where theUI processor50 is operable to determine whether the user selected bolus type, i.e., the bolus type selected by the user atstep476, is a multi-wave bolus, MW. If so, theprocess490 advances to a process D. If not, theprocess490 advances to a process E.
• If, atstep498, theUI Processor50 determines that the user confirmation detected atstep492 is of a manual bolus, theprocess490 advances to step508 where theUI processor50 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), theprocess490 advances to a process F, and if the confirmed bolus is a pen/syringe (PS), theprocess490 advances to a process G.
• As described hereinabove with respect toFIGS. 5-11, the remoteelectronic device12 and thepump14 illustratively cooperate to transfer pump operating history and bolus threshold/status from thepump14 to the remote electronic device when a user accesses thebolus advice process300. 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 thepump14 to deliver boluses. However, in situations in which a wireless connection cannot be established when thebolus advice process300 is accessed or thereafter, neither recent pump history nor bolus threshold/status information is transferred from thepump14 to the remoteelectronic device12, and the remoteelectronic device12 cannot remotely program thepump14 to deliver a recommended bolus from the bolus advice process if a wireless connection between thedevices12,14 cannot be established and/or is lost during the bolus advice process. Such situations may occur, for example, when thepump14 is turned off and/or when wireless communication between the remoteelectronic device12 and thepump14 are disabled or otherwise compromised. During such situations, however, thebolus advice process300 continues to be accessible, and thebolus advice process300 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 remoteelectronic device12, and recent values of Carbs and/or health information.
• In such cases, theUI processor50 is operable at step522 of theprocess300 ofFIG. 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 remoteelectronic device12 and thepump14, the remoteelectronic device12 will not display the Standard, Extended or Multi-wave boluses as available bolus types atstep476, and the user will in such cases be able to deliver the drug only by manually, e.g., locally, programming thepump14, by manually administering the drug via conventional drug pen or syringe, or via other conventional manual drug delivery techniques. The remoteelectronic device12 thus prompts the user to manually program or manually deliver the bolus amount under conditions where a wireless communications link is not established between thedevices12 and14, and theUI processor50 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 remoteelectronic device12 does not attempt to establish wireless communications during the current bolus advice session.
• Referring now toFIG. 16, a flowchart is shown of oneillustrative embodiment550 of the process C referred to in theprocess490 ofFIG. 12C. Theprocess550 is executed when the user has confirmed a Standard bolus of an amount TRB. Theprocess550 begins atstep556 where theUI processor50 is operable to display a standard bolus confirmation screen with the total recommended bolus amount. Thereafter atstep558, theUI processor50 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, theprocess550 advances to step560 where theUI processor50 returns to the bolus advice screen. If not, theprocess550 advances to step562 where theUI processor50 is operable to determine whether the user has selected a deliver function that is available on the confirmation screen. If not, theprocess550 loops back tostep560. If, atstep562, theUI processor50 determines that the user has selected deliver on the confirmation screen, theUI processor50 sends a deliver command to thepump14 to which the pump is responsive to begin delivering the standard bolus in the amount of the total programmed bolus.
• Theprocess550 advances from the “YES” branch ofstep562 to step564 where theUI processor50 is operable to send a deliver command to thepump14 and to store the entire record in memory. Thereafter atstep566, theprocessor50 is operable to receive a wireless message from thepump14 corresponding to an amount of the total programmed bolus that is currently being delivered. TheUI processor50 is, in turn, operable to control thedisplay device18 to update the total recommended bolus value, TRB, to reflect delivery by thepump14 of the bolus amount so far delivered. For example, if atstep566 theUI processor50 receives a message from thepump14 that thepump14 has delivered 1/10 U of insulin, theUI processor50 is operable to control thedisplay device18 to update the displayed TRB value by subtracting 1/10 U from the displayed value of TRB. Thereafter atstep568, theUI processor50 is operable to determine whether a user has manually stopped the insulin delivery process by manually selecting a suitable one or more of theuser buttons16 of the remoteelectronic device12. If theUI processor50 determines that the user has manually stopped the delivery of insulin by thepump14, theprocess550 advances to step570 whereUI processor50 controls thedisplay device18 to display a bolus canceled message. Otherwise, theprocess550 advances to step572 where theUI processor50 is operable to determine, based on messages wirelessly provided by thepump14, whether delivery of the standard bolus is complete. If not, theprocess550 loops back up tostep566. Thus, steps566-572 illustratively result in a count down on thedisplay device18 of bolus delivery from the total recommended bolus value, TRB. When delivery of the standard bolus is complete, step572 advances to step574 where theUI processor50 is operable to control thedisplay device18 to display a delivery complete message. Fromstep574, and also fromstep570, theprocess550 advances to step576 where theUI processor50 stores the bolus delivery record in memory.
• Referring now toFIGS. 17A and 17B, a flowchart is shown of oneillustrative embodiment580 of the process D referred to in theprocess490 ofFIG. 12C. Theprocess580 is executed when the user has confirmed a multi-wave bolus of an amount TRB. Theprocess580 begins atstep582 where theUI processor50 is operable to send a MW immediate portion (IMD) and a duration (DUR) request to thepump14 along with the total recommended bolus value, TRB. Thereafter atstep584, theUI processor50 is operable to determine whether a multi-wave bolus program command acknowledgement and accompanying multi-wave bolus data have been received from thepump14. Illustratively, thepump14 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 remoteelectronic device12 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 theUI processor50 determines atstep584 that such an acknowledgement has not been received, theprocess580 advances to step586 where theUI processor50 is operable to determine whether an acknowledgement timer has timed out since sending the command atstep582. If not, theprocess580 loops back tostep584. If the acknowledgement timer has timed out, theprocess580 advances to step588 where the UI processor returns to the previous bolus advice screen.
• If, atstep584, theUI processor50 determines that the multi-wave bolus program acknowledgement and accompanying programmed bolus data was received, theprocess580 advances to step590 where theUI processor50 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 atstep592, theUI processor50 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, theprocess580 advances to step594 where theUI processor50 is operable to return to the previous bolus advice screen. If not, theprocess580 advances to step596 where theUI processor50 is operable to determine whether the user has selected the IMD field of the multi-wave bolus screen for editing. If so, theprocess580 advances to step598 where theUI processor50 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, theprocess580 loops back to the beginning ofstep598. If so, theprocess580 loops back tostep590. If, atstep596, theUI processor50 determines that the user has not selected the IMD field for editing, theprocess580 advances to step600 where theUI processor50 is operable to determine whether the user has selected the DUR field of the multi-wave bolus screen for editing. If so, theprocess580 advances to step602 where theUI processor50 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, theprocess580 loops back to the beginning ofstep602. If so, theprocess580 loops back tostep590. If, atstep600, theUI processor50 determines that the user has not selected the IMD field for editing, theprocess580 advances to step604 where theUI processor50 is operable to determine whether the user has selected the deliver function of the multi-wave bolus screen. If, atstep606, theUI processor50 has determined that the user has selected deliver on the multi-wave bolus confirmation screen, theUI processor50 sends a deliver command to thepump14 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.
• Theprocess580 advances from the “YES” branch ofstep604 to step606 where theUI processor50 is operable to send a deliver command to thepump14 and to store the entire bolus advice record in memory. Thereafter atstep608, theUI processor50 is operable to receive a wireless message from thepump14 corresponding to an amount of the immediate portion, IMD, of the multi-wave bolus that is currently being delivered. TheUI processor50 is, in turn, operable to control thedisplay device18 to update the immediate bolus value, IMD, to reflect delivery by thepump14 of the immediate bolus amount so far delivered. For example, if atstep608 theUI processor50 receives a message from thepump14 that thepump14 has delivered 1/10 U of insulin, theUI processor50 is operable to control thedisplay device18 to update the displayed IMD value by subtracting 1/10 U from the displayed value of IMD. Thereafter atstep610, theUI processor50 is operable to determine whether a user has manually stopped the insulin delivery process by manually selecting a suitable one or more of theuser buttons16 of the remoteelectronic device12. If theUI processor50 determines that the user has manually stopped the delivery of insulin by thepump14, theprocess580 advances to step612 whereUI processor50 controls thedisplay device18 to display a bolus canceled message. Otherwise, theprocess580 advances to step614 where theUI processor50 is operable to determine, based on messages wirelessly provided by thepump14, whether delivery of the immediate portion of the multi-wave bolus is complete. If not, theprocess580 loops back up tostep608. Thus, steps608-614 illustratively result in a count down on thedisplay device18 of delivery of the immediate portion of the multi-wave bolus. When delivery of the immediate portion of the multi-wave bolus is complete, step614 advances to step616 where theUI processor50 is operable to control thedisplay device18 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.
• Referring now toFIG. 18, a flowchart is shown of oneillustrative embodiment620 of the process E referred to in theprocess490 ofFIG. 12C. Theprocess620 is executed when the user has confirmed an extended bolus of an amount TRB. Theprocess620 begins atstep622 where theUI processor50 is operable to send an extended bolus duration (DUR) request to thepump14 along with the total recommended bolus value, TRB. Thereafter atstep624, theUI processor50 is operable to determine whether an extended bolus program command acknowledgement and accompanying extended bolus data have been received from thepump14. Illustratively, thepump14 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 remoteelectronic device12 that an extended bolus in the amount of TRB has been programmed, and to await further instructions. If theUI processor50 determines atstep624 that such an acknowledgement has not been received, theprocess620 advances to step626 where theUI processor50 is operable to determine whether an acknowledgement timer has timed out since sending the command atstep622. If not, theprocess580 loops back tostep624. If the acknowledgement timer has timed out, theprocess620 advances to step628 where the UI processor returns to the previous bolus advice screen.
• If, atstep624, theUI processor50 determines that the extended bolus program acknowledgement and accompanying programmed bolus data was received, theprocess620 advances to step630 where theUI processor50 is operable to display an extended bolus confirmation screen with the bolus duration, DUR, and the total programmed bolus amount. Thereafter atstep632, theUI processor50 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, theprocess620 advances to step634 where theUI processor50 is operable to return to the previous bolus advice screen. If not, theprocess620 advances to step636 where theUI processor50 is operable to determine whether the user has selected the DUR field of the multi-wave bolus screen for editing. If so, theprocess620 advances to step638 where theUI processor50 is operable to determine whether the user has entered a new DUR value in the DUR field of the extended bolus screen. If not, theprocess620 loops back to the beginning ofstep638. If so, theprocess620 loops back tostep630. If, atstep636, theUI processor50 determines that the user has not selected the DUR field for editing, theprocess620 advances to step640 where theUI processor50 is operable to determine whether the user has selected the deliver function of the multi-wave bolus screen. If, atstep406, theUI processor50 has determined that the user has selected deliver on the extended bolus confirmation screen, theUI processor50 sends a deliver command to thepump14 to which the pump is responsive to begin delivering the extended bolus in the amount of the total programmed bolus having a duration, DUR.
• Theprocess620 advances from the “YES” branch ofstep640 to step642 where theUI processor50 is operable to send a deliver command to thepump14 and to store the entire bolus advice record in memory. Thereafter atstep644, theUI processor50 is operable to receive a wireless message from thepump14 that the pump is currently delivering the extended bolus. Thereafter atstep646, theUI processor50 is operable to control thedisplay unit18 to display a message indicating that delivery of the extended bolus is continuing.
• Referring now toFIG. 19, a flowchart is shown of oneillustrative embodiment650 of the process F referred to in theprocess490 ofFIG. 12C. Theprocess650 is executed when the user has confirmed that the bolus amount TRB will be manually programmed on thepump14. Theprocess650 begins atstep652 where theUI processor50 is operable to display a manual program screen with instructions to manually program the bolus amount TRB on thepump14. Thereafter atstep654, theUI processor50 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, theprocess650 advances to step656 where theUI processor50 is operable to return to the previous bolus advice screen. If not, theprocess650 advances to step658 where theUI processor50 is operable to determine whether the user has selected OK on the manual program bolus screen. If not, theprocess650 loops back tostep654. If, atstep658, theUI processor50 has determined that the user has selected OK on the bolus confirmation screen, theUI processor50 stores the entire record in memory atstep660.
• Referring now toFIG. 20, a flowchart is shown of oneillustrative embodiment670 of the process G referred to in theprocess490 ofFIG. 12C. Theprocess670 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. Theprocess670 begins atstep672 where theUI processor50 is operable to display a pen/syringe screen with instructions to manually deliver the bolus amount TRB via a drug pen or syringe. Thereafter atstep674, theUI processor50 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, theprocess670 advances to step676 where theUI processor50 is operable to return to the previous bolus advice screen. If not, theprocess670 advances to step678 where theUI processor50 is operable to determine whether the user has selected OK on the manual program bolus screen. If not, theprocess670 loops back tostep674. If, atstep678, theUI processor50 has determined that the user has selected OK on the bolus confirmation screen, theUI processor50 stores the entire record in memory atstep680.
• Further details relating to the bolus advice process illustrated inFIGS. 12A and 12B are provided in co-pending PCT Patent Application No. PCT/US2008/066331, the disclosure of which has been incorporated by reference.
• 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, theUI processor50 and/or theprocessor28 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 thedisplay device18 and/or34, or portion thereof, to the determined display color, as described above with respect toFIG. 13.

Claims (30)

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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 5 wherein the electronic device includes a medical device that measures an analyte concentration in a liquid sample.

7. The method ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 10 wherein the low blood glucose value is a hypoglycemic blood glucose threshold.

13. The method ofclaim 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 ofclaim 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 ofclaim 14 wherein the high blood glucose value is a hyperglycemic blood glucose threshold.

16. The method ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 21 wherein the another electronic device comprises an ambulatory medical device.

23. The method ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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.

Images