In one embodiment, an analyte sensor is an implantable glucose sensor, such as described with reference to U.S. Pat. No. 6,001,067 and co-pending U.S. Patent Publication 2005/0027463 which are incorporated herein by reference in their entirety. In another embodiment, an analyte sensor is a transcutaneous glucose sensor, such as described with reference to U.S. Provisional Patent Application 60/587,787 and 60/614,683. In one alternative embodiment, the continuous glucose sensor comprises a transcutaneous sensor such as described in U.S. Pat. No. 6,565,509 to Say et al., for example. In another alternative embodiment, a continuous glucose sensor comprises a subcutaneous sensor such as described with reference to U.S. Pat. No. 6,579,690 to Bonnecaze et al. or U.S. Pat. No. 6,484,046 to Say et al., for example. In another alternative embodiment, the continuous glucose sensor comprises a refillable subcutaneous sensor such as described with reference to U.S. Pat. No. 6,512,939 to Colvin et al., for example. In another alternative embodiment, a continuous glucose sensor comprises an intravascular sensor such as described with reference to U.S. Pat. No. 6,477,395 to Schulman et al., for example. In another alternative embodiment, the continuous glucose sensor comprises an intravascular sensor such as described with reference to U.S. Pat. No. 6,424,847 to Mastrototaro et al. All of the above patents are incorporated by reference herein in their entirety. Other signal processing techniques and glucose monitoring system embodiments suitable for use with the inventions described herein are also described in U.S. Patent Publications 2005/0203360 and 2009/0192745, both of which are incorporated herein by reference in their entireties.

FIG. 1 is a block diagram that illustrates a receiver 12 in communication with a sensor 10 and an external device 34. In general, the continuous analyte sensor 10 is any sensor configuration that provides an output signal indicative of a concentration of an analyte. The output signal (e.g., sensor data, such as a raw data stream, filtered data, smoothed data, and/or otherwise transformed sensor data) is sent to the receiver 12 and received by an input module 14, which is described in more detail below. The output signal may include a raw data stream that is used to provide a useful value of the measured analyte concentration to a patient or doctor, for example. In some embodiments, the sensor data from the sensor 10 can be continuously or periodically algorithmically smoothed, calibrated, or otherwise modified to diminish outlying points that do not accurately represent the analyte concentration, for example due to signal noise or other signal artifacts, such as described in co-pending U.S. Pat. No. 6,931,327, which is incorporated herein by reference in its entirety.

Receiver

Referring again to FIG. 1, the receiver 12, which is operatively linked to the sensor 10, receives a data stream from the sensor 10 via the input module 14. In one embodiment, the input module 14 includes a quartz crystal operably connected to an RF transceiver (not shown) that together function to receive and synchronize data streams from the sensor 10. However, the input module 14 can be configured in any manner that is capable of receiving data from the sensor. Once received, the input module 14 sends the data stream to a processor 16 that processes the data stream, such as described in more detail below.

The processor 16 is the central control unit that performs the processing, such as storing data, analyzing data streams, calibrating analyte sensor data, estimating analyte values, comparing estimated analyte values with time corresponding measured analyte values, analyzing a variation of estimated analyte values, downloading data, and controlling the user interface by providing analyte values, prompts, messages, warnings, alarms, or the like. The processor includes hardware that performs the processing described herein, for example read-only memory (ROM) provides permanent or semi-permanent storage of data, storing data such as sensor ID, receiver ID, and programming to process data streams (for example, programming for performing estimation and other algorithms described elsewhere herein) and random access memory (RAM) stores the system's cache memory and is helpful in data processing.

An output module 18, which may be integral with and/or operatively connected with the processor 16, includes programming for generating output based on the sensor data received from the sensor 10 and its processing incurred in the processor 16. In some embodiments, output is generated via one or more input/output devices 20.

The input/output devices 20 of this embodiment comprise a keyboard 22, speaker 24, vibrator 26, backlight 28, display device 30, and one or more buttons 32. The components that comprise the input/output devices 20 include controls to allow interaction of the user with the receiver. The keyboard 22 can allow, for example, input of user information about himself/herself, such as mealtime, insulin and carbohydrate ratios, exercise, insulin administration, customized therapy recommendations, and reference analyte values. The speaker 24 can produce, for example, audible signals or alerts for conditions such as present and/or estimated hyper- and hypoglycemic conditions in a person with diabetes. The vibrator 26 can provide, for example, tactile signals or alerts for reasons such as described with reference to the speaker, above. In some embodiments, the display device 30 is a touch-sensitive screen. The buttons 32 can provide for toggle, menu selection, option selection, mode selection, and reset, for example. In some alternative embodiments, a microphone can be provided to allow for voice-activated control.

In some embodiments, analyte values are displayed on the display device 30. In some embodiments, prompts or messages can be displayed on the display device 30 to convey information to the user, such as reference outlier values, requests for reference analyte values, therapy recommendations, deviation of the measured analyte values from the estimated analyte values, or the like. Additionally, prompts can be displayed to guide the user through calibration or trouble-shooting of the calibration.

Additionally, data output from the output module 18 can provide wired or wireless, one- or two-way communication between the receiver 12 and an external device 34. The external device 34 can be any device that interfaces or communicates with the receiver 12. In some embodiments, the external device 34 is a computer, and the receiver 12 is able to download historical data for retrospective analysis by the physician, for example. In some embodiments, the external device 34 is a modem, and the receiver 12 is able to send alerts, warnings, emergency messages, or the like, via telecommunication lines to another party, such as a doctor or family member. In some embodiments, the external device 34 is an insulin pen, and the receiver 12 is able to communicate therapy recommendations, such as insulin amount and time to the insulin pen. In some embodiments, the external device 34 is an insulin pump, and the receiver 12 is able to communicate therapy recommendations, such as insulin amount and time to the insulin pump. The external device 34 can include other technology or medical devices, for example pacemakers, implanted analyte sensor patches, other infusion devices, telemetry devices, or the like. The receiver 12 may communicate with the external device 34, and/or any number of additional external devices, via any suitable communication protocol, including radio frequency, Bluetooth, universal serial bus, any of the wireless local area network (WLAN) communication standards, including the IEEE 802.11, 802.15, 802.20, 802.22 and other 802 communication protocols, ZigBee, wireless (e.g., cellular) telecommunication, paging network communication, magnetic induction, satellite data communication, GPRS, ANT, and/or a proprietary communication protocol.

The input/output devices 20 including keyboard 22, buttons 32, a microphone (not shown), as well as the external device 34, can be configured to allow input of data. Data input can be helpful in obtaining information about the patient (for example, meal time, exercise, or the like), receiving instructions from a physician (for example, customized therapy recommendations, targets, or the like), and downloading software updates, for example. Keyboard, buttons, touch-screen, and microphone are all examples of mechanisms by which a user can input data directly into the receiver. A server, personal computer, personal digital assistant, insulin pump, and insulin pen are examples of external devices that can provide useful information to the receiver. Other devices internal or external to the sensor that measure other aspects of a patient's body (for example, temperature sensor, accelerometer, heart rate monitor, oxygen monitor, or the like) can be used to provide input helpful in data processing. In one embodiment, the user interface can prompt the patient to select an activity most closely related to their present activity, which can be helpful in linking to an individual's physiological patterns, or other data processing. In another embodiment, a temperature sensor and/or heart rate monitor can provide information helpful in linking activity, metabolism, and glucose excursions of an individual.

In a further embodiment, input/output devices can be used to generate data for tracking physical exercise performed by the host. In this regard, a global positioning device (GPS) and/or accelerometer can be incorporated internally with or communicatively coupled externally to receiving unit 12 to provide positional and/or movement data of a host. Other sensors, such as a heart monitor, can also be used either alone or in combination with the GPS and accelerometer, to provide exercise-related data for tracking exercise performed by the host. In doing so, types of rewards and reward values can be tracked and awarded based partly or wholly on exercise performed by the host, as discussed in more detail later in this disclosure.

While a few examples of data input have been provided here, a variety of information can be input, which can be helpful in data processing as will be understood by one skilled in the art.

Customized User Interfaces Depicting Sensor Data

A data stream received from a continuous analyte sensor can provide an analyte value and/or other sensor data, and display the same to the host, which can be used to warn the host (or other interested party, such as a caretaker of the host or doctor) of existing clinical risk. A data stream received from an analyte sensor can provide historical trend analyte values, which can be used to educate a patient, caretaker, and/or doctor of individual historical trends of the patient's analyte concentration.

Sensor data may be displayed in such a way as to be more interesting to the user than a line graph, for example. In one embodiment, for example, sensor data may be depicted as a series of frames of a game, an animation, or a cartoon. The display may include rewards based on actions taken by the user or based on measurement data. The data displayed may be used as a tutorial for educational interaction between the sensor system and the user. In some embodiments, data may be displayed and/or otherwise conveyed (e.g., spoken instruction may be emitted from the speaker 24 of the receiver 12) by an avatar, an icon or a character depicted on the display device 30.

In some embodiments, receivers, such as receiver 12 of FIG. 1 have multiple games which can be selected by the user. In some embodiments, the game is selected randomly or pseudorandomly. Each game may have graphics which are used by the receiver 12 to display the frames of the game, where each frame comprises a depiction of graphical and/or textual data on a display device. The graphics associated with each game may be game-specific or may be applied to multiple games. The graphics may be used to represent one or more aspects of sensor data received from a sensor, such as sensor 10 of FIG. 1, and to represent game context information for the sensor data.

FIG. 2 is a flowchart illustrating one embodiment of a method 54 of displaying sensor data as a game or a cartoon. The process is used by, for example, a receiver, such as receiver 12 of FIG. 1 to display a user interface that incorporates and/or is based on sensor data received. The process 54 includes receiving current sensor data from the sensor, which is the data point or data set most recently received, adding the received current sensor data to previously received data, determining a next frame to display based on the current sensor data and/or the previously received sensor data, and displaying the frame. In some embodiments, the receiver 12 generates graphical data indicative of a sequence of historical sensor data, as well as current sensor data, in a currently displayed frame. Depending on the embodiment, the method of FIG. 3 may include fewer or additional blocks and the blocks may be performed in a different order than is illustrated.

At block 56, current sensor data is received from the sensor 10. At block 58, the current sensor data is added to a memory containing sensor data received previously. The current sensor data and the previously received sensor data collectively form stored sensor data, which is used at block 60 to determine a next frame of the game. The sensor data may, for example, represent a glucose level, or a range of levels. In some embodiments, the sensor data is displayed with a resolution corresponding to the uncertainty of the measurement.

Each frame may be determined based on one or more selected sets of sensor data of the stored sensor data. The selection of a data set for determining a next frame may be based on a certain time frame. For example, the most recent sensor data may be selected. For example, the sensor data taken in the most recent 1 hour, 3 hours, 6 hours, day, week, month, or year may be selected. Sensor data in other most recent times may also be used. In some embodiments, sensor data received since a reference time may be selected. The reference time may include such times as when waking up, going to sleep, eating a meal, exercising, or taking insulin. Other reference times may be used. In some embodiments, sensor data received during specified time periods may be selected. For example, sensor data received between 1 pm and 5 pm on one or more days may be selected. Other time periods may be used.

In one embodiment, a host's glucose response associated with a consistent event, such as lunch, is analyzed such that a carbohydrate (referred to also as a “carb”) estimate and insulin amount given, for example, are analyzed to determine a “typical” lunch size. For example, the insulin delivery information may be more accurate, with the time to action being the key variable such that reasonable estimates for that might estimate not only the typical, approximate meal size, but also the diversity of the meal (all carbs, high fat, etc.) based on the response, thereby allowing more customization for bolus calculation in the future based on “typical” meals. In one embodiment, hosts estimate a meal size (small, medium or large, for example) and/or meal makeup (high fat, high carb, low carb, balanced carb/fat/protein, etc.), and the sensor electronics may determine insulin delivery based on “learned” knowledge of the particular patients behavior and “typical” meal size and response.

In some embodiments, the selection of sensor data for a data set is based on the content of the sensor data, such as characteristics of transformed sensor data. For example, in some embodiments, sensor data taken over a specified time having glucose levels within a specified measurement range are selected and/or sensor data between upper and lower thresholds are selected. In some embodiments, sensor data greater than or less than a certain threshold are selected. The thresholds may, for example, correspond to blood glucose target range boundaries.

In some embodiments, the selected sensor data for a data set is selected based on processed data. For example, in some embodiments, raw sensor data is processed to determine rates of change in blood glucose levels for each time point for which sensor data is acquired, and data for the data set are selected for times when the rate of change in the sensor data meets certain criteria. For example, sensor data taken when the rate of change in the blood glucose levels is greater than a certain limit, less than a certain limit, or within a certain range may be selected. As another example, average glucose values for days of the past month during which the rate of change in data does not exceed a threshold may be selected for a data set. In some embodiments, the average values for days of the past month during which the rate of change in data does exceed a threshold may be also be selected as a second data set.

The selected one or more data sets are used in conjunction with graphics associated with the current game to determine the next frame of the game. For example, a selected data set may be represented with a series of frames, where each frame of the series depicts one or more data points, e.g. blood glucose levels, of the selected data set. In some embodiments, the most recent data point is represented with a first graphic and the historical data is represented as multiple second graphics. In addition, game context graphics may also be determined based on the current game and the previous frames of the game. In some embodiments, the game context graphics include graphics which represent target range boundaries. The range boundaries may be defined through an interface to a database storing the boundary data. The range boundaries may be defined by a caretaker of a child with diabetes via a computing device in communication with the child's receiver, for example. Thus, operation of the games may be customized according to the particular characteristics of the host.

In some embodiments, the game context graphics include graphics which represent a qualitative or quantitative assessment of performance. For example, a score can be shown, or an estimated HbA1c value. Other assessment graphics include a character having a smiling face or a frowning face, and/or a variation in a color of a graphic. In some embodiments, game context graphics include a target, which indicates a desired analyte level or analyte performance characteristic.

At block 62, graphics illustrative of at least portions of the selected one or more data sets are displayed in the next frame. In some embodiments, a sequence of frames is shown to generate an animation or a cartoon. For example, a series of frames, each depicting a subset of the selected data set may be shown sequentially, such that each successive frame shows more of the selected data. The series may be displayed in response to an input from the user.

FIG. 3A is a drawing illustrating an embodiment of a frame 64 representing sensor data. The frame 64 includes a graphic 66 representing an upper limit of a target range for the host's glucose level, a graphic 68 representing a lower limit of the target range for the host's glucose level, a series 70 of graphics representing historical glucose level measurements, a graphic 72 representing the most recent measurement, and a graphic 74 representing an assessment of performance. In this embodiment, the graphics 70 and 72 cooperatively represent a centipede, where the centipede comprises body segment graphics 70 associated with historical sensor data, and a head graphic 72 associated with the latest sensor data. In this embodiment, the head graphic 72 has a face which is frowning because the latest glucose level is outside of a desired target range. In this embodiment, graphic 74 represents an assessment of performance as a numerical score.

FIG. 3B is a drawing illustrating an embodiment of a frame 76 representing sensor data. Frame 76 includes a target graphic 78, which indicates a desired glucose level or range of glucose levels In some embodiments, the target graphic 78 can change positions from frame to frame in order to entice better analyte control from the user.

FIG. 3C is a drawing illustrating an embodiment of a frame 80 representing sensor data. The frame 80 includes a graphic 82 representing a higher than target range for the host's glucose level, a graphic 84 representing a lower than target range for the host's glucose level, a series 86 of graphics representing historical glucose levels, a graphic 88 representing the latest glucose level, and a graphic 90 representing a target glucose level. Depending on the embodiment, the frames of a game (e.g., FIGS. 2 and 3) may be updated in response to each newly received sensor data point or set, after a predetermined quantity of sensor data points or sets are received (e.g., a new frame is provided after five sensor data points or sets are received by the receiver), and/or in response to receiving sensor data matching a predefined criteria (e.g., a glucose level that is approaching a hypoglycemic level). In the embodiment of FIG. 3C, the graphic 90 is at the high end of the target range so as to entice the user to generate higher glucose levels.

FIG. 3D is a drawing representing another exemplary frame illustrating graphics representative of historical and current sensor data. In this embodiment a vehicle graphic 91 represents the latest sensor data and a plurality of a track graphics 93 represent historical sensor data. The graphics 95 and 97 represent the boundaries of the desired target range, such as the sides of a road or racetrack, and may be generally vertical. In other embodiments, the boundaries, e.g., sides of the road, may be generally horizontal. In the illustrated embodiment, graphics 95 and 97 are non-linear. The non-linear boundaries can be used to further entice the user to achieve preferred glucose levels. In other embodiments, the boundaries (e.g., similar to graphics 95 and 97), which illustrates the sides of a road or racetrack, for example, may be non-linear, but parallel, or the boundaries may be linear. Depending of the embodiment, the boundaries may be user-settable and may be representative of a target glucose levels or ranges and/or may be representative of an alarm level (e.g. alert setting for hypo- or hyper-glycemia actual, predicted, or near).

FIGS. 3E-3H are drawings representing other exemplary frames illustrating graphics representative of historical and current sensor data. In these embodiments the graphics 92 associated with historical sensor data trace paths of respective objects 94 moving toward respective targets 96. In some embodiments, once the object hits the target, such as by having the latest sensor data within a desired range, an animation is displayed. For example, in the embodiment of FIG. 3E, an animation showing a bowling ball knocking down the pins may be displayed. In the embodiment of FIG. 3F the hitter may be shown hitting a home run. In the embodiment of FIG. 3G, the dog may be shown eating the treat. In the embodiment of FIG. 3H, the frog may be shown eating the fly. Depending on the embodiment, the games may be configured so that the targets 96 are reached at predetermined times of the day, such as just before lunch, dinner, and/or bedtime.

In addition, various embodiments can be configured to give different types of awards depending upon whether the historical and current data stay within one or more predefined ranges (e.g., 1, 2, 3, 4 or more different ranges). Each award can correspond to a different award value or range of values, so that a higher award can be given if a host achieves a higher award value and a lower award can be given if the host achieves a lower award value. For example, if the historical and current data stay within a first, narrow range for a predetermined amount of time, then a higher award is given than if the historical and current data exceeds the first, narrow range during one or more time periods, but never exceeds a second, broader range during the predetermined amount of time. To illustrate, this process can be used in an environment of a virtual baseball game provided on receiver 12. In this regard, should the historical and current data stay within a first range for a predetermined amount of time, then the highest award, such as a home run, is awarded; if the historical and current data exceed the first range, but does not exceed a second range for the predetermined amount of time, then the second highest award, such as a triple base hit, is awarded; if the historical and current data exceed the first and second ranges, but does not exceed a third range for the predetermined amount of time, then the third highest award, such as a double base hit, is awarded; if the historical and current data exceed the first, second and third ranges, but does not exceed a fourth range for the predetermined amount of time, then a fourth highest reward, such as a single base hit, is awarded; and if the historical and current data exceed the first, second, third and fourth ranges at one or more points in time during the predetermined amount of time, then the lowest reward, such as a strike, out, end of game or the like, will be given. The process can then repeat with a new predetermined amount of time and a score of the baseball game can be tallied based on the results. In this manner, a virtual baseball game can be played based on a host's glucose sensor data.

Moreover, in place of or in addition to the various ranges discussed above, a type of reward given (e.g., homerun, base hit or out) can be based wholly or partly on other criteria. For example, the type of reward given can depend on a duration and/or amplitude of the historical and current data exceeding one or more ranges before the historical and current data fall back within the range during the predetermined amount of time. To illustrate, a homerun can be awarded if the historical and current data never fall outside of a range during the predetermined time period, and a triple base hit can be awarded if the historical and current data fall outside of the range for less than a threshold duration and/or the amplitude of the sensor data exceeds the range by less than a threshold amplitude. Second and single base hits can similarly be awarded based on other thresholds not being exceeded. An “out” or “end of game” can be given if one or more (including all) thresholds are exceeded. In the event both the amplitude and duration thresholds are taken into account for awarding a type of award, various weighting measures can be applied to the amplitude and duration threshold exceeded for determining the type of reward given.

FIGS. 4A-4G are a series of drawings representing other exemplary frames illustrating an animation representative of historical and current sensor data. In the series of Figures, a number of flames 98 are shown, where each of the first three frames (FIGS. 4A-4C) illustrate a successively greater number of flames 98. Each flame 98 represents a good glucose level, for example, a day in the past 30 days when the glucose level stayed within a target range, or an amount of time of the current day when the rate of change in the glucose level was less than a threshold. If a sufficient number of flames 98 are generated, an animation follows, which shows a fuse being lit, and fireworks exploding (e.g., FIGS. 4D-4G).

FIG. 5 shows another exemplary frame illustrating graphics representative of historical and current sensor data. In this embodiment, the graphics are associated with at least two types of sensor data, such as data sets associated with a percentage of time within a target glucose range and percentage of time outside of the target glucose range. In this embodiment, two cars 100 and 102 are on a race track. Each car represents one of the data sets. Some aspect of each cars performance corresponds to the data of the associated data set. For example, the speed or the distance traveled for car 100 may represent a first data set—the percentage of time in target range, and the speed or distance traveled for car 102 may represent a second data set—percentage of time out of target range. Thus, the animation of FIG. 5 illustrates a graphical comparison of the two data sets. In some embodiments, the two data sets may be corresponding data (e.g., data from the same host) taken during two different time periods (e.g., the first data set may represent sensor data from a current week and the second data set may represent sensor data from a previous weeks). Accordingly, the animation may illustrate a graphical comparison of, for example, glucose control performance this week compared to last week.

FIG. 6 is a flowchart illustrating an embodiment of a method of displaying sensor data as a game where rewards are given. The process is used by, for example, a receiver, such as receiver 12 of FIG. 1. The process includes retrieving sensor data 104, determining whether the retrieved data meets a reward criteria 106, and displaying (or otherwise providing) a reward indication 108. In some embodiments, the process illustrated in FIG. 6 is initiated by a command generated in response to a request by a user. In some embodiments, the process is initiated by any interaction with the receiver which contributes toward meeting the reward criteria. In some embodiments, any interaction with the receiver contributes toward meeting the reward criteria.

The sensor data retrieved at block 104 includes at least one of current data and historical data. For example, the retrieved data may include the sensor data for the past 24 hours, or may include the sensor data for measurements taken between 12 pm and 6 pm. In some embodiments, the retrieved data may include transformed sensor data, such as calibrated and/or filtered blood glucose levels and/or one or more trend or rate of change indicators, for example.

The reward criteria to which the retrieved data is compared at block 106 may be dependent on the type of data retrieved. For example, if the retrieved data comprises sensor data for the past 24 hours, the reward criteria may be based on a minimum percentage of time for which the sensor data is within a target range. For example, the reward criteria may be set to 75%, and the retrieved data may indicate that the sensor data was within the target range 85% of the past 24 hours. In some embodiments, the reward criteria may be based on improvements in the sensor data. Accordingly, a comparison of the criteria with the retrieved data determines that the criteria for a reward has been met. If the reward criteria is not met, in some embodiments, the receiver displays an indication that the criteria is not met.

In one embodiment, points are awarded in response to certain actions by the host, such as receiving sensor data including a glucose level that is within an acceptable range. Thus, if sensor data is received every 5 minutes, for example, the host may receive more points every 5 minutes. The points may be incremented until they reach a reward threshold and then the receiver may initiate communication of a reward to the host and/or caretaker, for example. The reward threshold may be an incremental point level, e.g., every 5,000 points, and/or may be associated with reaching a high score (e.g., higher than previously reached by the host, possibly within a certain time period).

If the reward criteria is met, at block 108 the receiver displays an indication of a reward. The indication may include a series of frames forming an animation. In some embodiments, the indication includes a single frame. In some embodiments, the display depicts the retrieved data, the criteria, and the reward indication simultaneously. Other rewards include having the opportunity to select a new “skin” for the receiver (e.g., colors, icon designs, etc.), unlocking levels of a game, unlocking an avatar, receiving credits towards purchase of a product. In some embodiments, the reward indicator is transmitted to a caretaker indicating that the user has met the reward criteria. The reward indication may be transmitted, for example, to a mobile device of the caretaker via email or sms. In some embodiments, the reward indication is randomly or pseudorandomly selected from a plurality of stored reward indications.

In some embodiments, analysis information for the retrieved data, such as the target range, and the reward criteria, such as the 75% time within range, are entered by the user. In some embodiments, access to the entry of the analysis information and the reward criteria is limited by a security device, such as a password. For example, a parent may enter a password to gain access to a data entry mode by which the parent enters reward criteria, e.g., 75% within a target range over a 24 hour period.

FIGS. 7A and 7B illustrate embodiments including systems and methods for providing rewards to a user to encourage interactions associated with a continuous glucose monitoring system. Some studies of pediatric diabetes have shown that as the child increases interactions with their receiver, hypoglycemic and hyperglycemic events are decreased. Much of this difference in glucose control may be due to the fact that users that are interested in being diligent in controlling glucose levels will interact with the receiver more according to this interest. However, this improvement in control can also be attained with less naturally diligent users by encouraging interactions of all kinds with the glucose monitoring system, even when those interactions are independent of the creation of or value of any sensor data. Encouraging a variety of different interactions with the system (in some embodiments all or substantially all interactions) will indirectly promote familiarity with the system operation, familiarity with typical user glucose levels, and familiarity with the effects user behavior has on their glucose levels. All these things will help the user control glucose levels better. Thus, by providing rewards to a child or other user with diabetes in response to many different types of interactions with their receiver or other portions of the monitoring system (e.g. pressing various buttons, changing display outputs, setting alarms, etc.), the frequency of hypoglycemic and/or hyperglycemic events may in turn be decreased.

In one such exemplary embodiment, the continuous glucose monitoring system includes a glucose sensor configured to provide real-time continuous glucose sensor data, a portable device comprising a user interface configured to receive user input and display the real time glucose sensor data responsive to user-interaction with the portable device and a processor module configured to tabulate a score based at least in part on user interactions with the user interface. While the exemplary embodiment may include a configuration wherein the processor module may be located within the portable display device, it should be understood that some or all of the processing and electronic circuitry associated therewith can be located local to the sensor, for example, within a transmitter body wired to the sensor. Additionally, some or all of the processing and electronic circuitry associated therewith can be located within hardware or software operably connected with the monitoring system, for example, through a download cable or through a wireless connection to a personal computer, mainframe computer, server, or the like.

Referring now to FIG. 7A, at block 111, the processor module is configured to retrieve the sensor data, either directly or indirectly through a wired or wireless connection with the sensor. As described in more detail elsewhere herein, the data can be transformed using a variety of algorithms to provide useful data to a user. Examples of useful data include not only real-time analyte values, but can also include trend information in the form of graphs or directional indicators, statistical data associated with a period of time, improvement in diabetes management or other metabolic control associated with an improvement with analyzed data from one time period to another time period, amount of time within a target range, and/or the like.

At block 113, a user interaction with the continuous glucose monitoring system is sensed or detected. In the exemplary embodiment of a portable display device, wherein the device is configured to receive sensor data from the glucose sensor, the device is configured to selectively display information associated with the sensor data and/or the sensor data in response to interactions from the user, which can be sensed by the device. However, other user interactions with the continuous glucose monitoring system can be sensed; for example, interactions associated with a remotely located device, such as a software program or internet site running on a computer system associated with the continuous glucose monitoring system, and these interactions can be provided to the portable display device, or any processing circuitry associated with the continuous glucose monitoring system that tabulates a score or increments a reward, as described in more detail elsewhere herein.

In some embodiments, the sensed interaction includes at least one of pressing a button, touching a screen of the receiver, activating another input device, selecting sensor data for viewing on the receiver, downloading data, inputting events, setting parameters, confirming sensor data, and the like. In some embodiments, the score may be based at least in part on receiving sensor data during a predetermined time period. In some of these embodiments, the system may sense an interaction with the system that comprises the attachment or continuous wearing of at least a portion of the glucose monitoring system for a predetermined amount of time. The attachment or placement of the receiver on the user may, for example, be detected by continuous or periodic reception of sensor data from an implanted sensor without significant interruption or periods of failed data reception. For example, wherein the monitoring system is configured for a particular sensor session time period (e.g., 3, 5, 7, 10 days, or the like), score or reward counters may be incremented based at least in part on a completion of a sensor session (e.g., 3-, 5-, 7- or 10-day sensor session), a plurality of sensor sessions (e.g., 1, 2, 3, 4, 5, 6, 7, or more sensor sessions), predetermined number of substantially consecutive sensor sessions, a predetermined time period (e.g., 1-, 3-, 5-, 7-, 10, 14-, 21-, 30-day, or more), or the like.

In some embodiments, the sensed interaction is any action that causes current sensor data to be displayed. For example, pressing a button, touching a screen, adjusting an alarm for increased sensitivity (e.g., more sensitive alarm thresholds). In some embodiments, the sensed interaction causes historical sensor data to be displayed, for example display of the 1, 3,6, 9, 12, 24 hour trend screen(s) or the like. In some embodiments, the sensed interaction initiates or changes a display on the receiver. For example, pressing a button or touchscreen may awaken the device from a sleep mode and cause the device to display current sensor data. A button push may change the display from current data to historical data, or may change the display to one that contains a projected future glucose concentration. It may be noted here that the score increase or reward may be given in response to many different interactions regardless of the user's diligence in measuring glucose levels or success at maintaining them. Providing rewards based at least in part on such interactions, however, may lead to better success at glucose control in the future.

At block 115, the processor module is configured to tabulate a score, also referred to as incrementing a reward counter, associated with one or more user interactions, such as the user interactions described herein. In some embodiments, the processor module is configured to detect substantially all sensed interactions, where substantially all sensed interactions are input into the score tabulation or reward counter. In some embodiments, the processor module is configured to detect one or a plurality of predefined interactions, whereby the score or reward counter can be incremented. In some embodiments, the sensed interactions used to increment the score or reward counter are independent of the creation or value of any sensor data; for example, a user can be simply rewarded for interacting with the device regardless of any performance associated with their disease management.

In some cases, it is advantageous to include time based limitations on which interactions can cause the score or reward counter to be incremented. Thus, in some embodiments, the processor module is configured for sensing time periods between interactions, and incrementing the reward counter in response to a second interaction when the second interaction is sensed within a predetermined time period from a first interaction. For example, the score may be incremented only if interactions with the device are performed with a certain pre-defined frequency or frequency range. Excessive delay between interactions may result in reduced or no score increment. At the other end of the spectrum, to avoid having a user just mindlessly press buttons to achieve high scores, a limit on the amount of reward or score may be set for a given time period, for example, a user may achieve up to a predetermined number of points for up to a predetermined number of interactions in a predetermined time period. One of ordinary skill in the art can appreciate a variety of numerical and time-based limits that may be applied to encourage a reasonable or optimal interaction frequency.

As noted above, it is believed to be advantageous to increment scores/reward counters based on interactions that are not dependent on glucose measurements themselves. However, this does not mean that providing rewards for direct success in glucose management is not also worthwhile as part of a reward system. Thus, in some embodiments, the score may also be based at least in part on one or more sensor data values falling within a predetermined range. For example, when a predetermined number or average of a predetermined number of glucose values are within a target glycemic range over a period of time.

In some embodiments, the score is based at least in part on sensor data associated with a predetermined time period meeting one or more criteria. For example, criteria can include target range of analyte values, average and/or statistical measures of analyte information over a time period. Average and/or statistical measures can include area under the curve, MARD, ARD, A1c, and the like. Some additional examples include measures of, sustained outcomes of increased normoglycemia, decreased area under curve, decreased hypoglycemic episodes, decreased variability, and the like.

In some embodiments, the score is based at least in part on a change in one or more sensor data values within a predetermined time period immediately after an alarm is triggered. For example, when a hypoglycemic alarm is triggered, a score can be tabulated based on the amount of time before the user achieves normoglycemia (e.g., glucose within a predefined target range). For example, the increment or value of the score can be based on whether the user achieves normoglycemia within 10, 20, 30, 40, 50, 60, 90, 120 or more minutes.

In some embodiments, the score is based at least in part on sensor data associated with a first time period indicative of an improvement in glycemic control or diabetes management as compared to sensor data associated with a historical time period, including averages or statistical measures evaluated over a predetermined time period. For example, if a user decreases the amount of time spent in a hyperglycemic range during a week time period as compare to a previous week time period, a particular score or reward amount can be calculated or tabulated. It should be appreciated that numerous other statistical and/or analytical measures of analyte data can be used to compare between any definable time periods and provided with any number or scoring options associated therewith, as can be understood by one of ordinary skill in the art.

In some embodiments, the score is based at least in part on user interactions involving setting of or changing of receiver operation parameters. Some receiver operation parameters include alarm settings (e.g., analyte thresholds, rate of change thresholds, predictive alarm settings, type of output, display features, and the like). It should be noted that operational parameters can be also be set, displayed and/or applied in a portable device type receiver and/or any other device that receives and/or displays the sensor data, including, downloadable software, web-hosted databases, servers, and the like.

In some embodiments, the score is based at least in part on user interactions that cause downloading of data by a user from the receiver to another processing system, for example downloadable software, web-hosted databases, servers, and the like. In some embodiments, the score is based at least in part on whether or how the user sets or confirms alarm settings on the receiver; for example, when an alarm criteria is met, the receiver triggers an alarm, and the user acknowledges the alarm by pressing a button, touching the screen, or the like.

In some embodiments, the score is based at least in part on an evaluation of the sensor data to determine whether the user is maintaining good control, for example by tracking a running average of average glucose over time. Maintaining good control can include a variety of statistical and clinical evaluations of the data, wherein the determination of good control or improvement in a particular patient's diabetes can be user settable, physician settable, adaptable by an algorithm on the system, relative to a previous sensor session or time period, or the like.

In some embodiments, the score is based at least in part on user events, for example, when a user enters an event into the receiver and/or other systems associated with the system. Some examples of events include caloric intake, level of activity, health, and the like.

Whether tabulating a score, incrementing a reward counter, or the like, it should be appreciated by one of ordinary skill in the art that different criteria can be given different weighting and/or points. For example, wherein the goal of a physician is to simply encourage regular wear of the continuous glucose monitoring system, the system can be set with a heavy weight (e.g., highest scoring) for continuous sensor wear and/or user interaction as compared to achieving targets with regard to sensor data. Numerous scoring or incrementing methods can be implemented by the manufacturer, user settable (e.g., by a user or care giver), via downloadable software, via communication with an internet site and/or the like.

At block 117, the processor module is configured to display a reward indication (or score) on the receiver and/or transmit a reward indication (or score). A score can be a numerical value associated with a calculation with a variety of user interactions, however, other methods of scoring are possible. A reward indication, which can include a score and/or be based at least in part on a score, can provide a physical and/or conceptual reward, including but not limited to a numerical value, credit from the manufacturer, an “opt-in”to a social networking group or site, changing of a display on the receiver when the score reaches a predetermined reward threshold (e.g., transformation of character or display animation as a reward such as described above with reference to FIGS. 3-5), achieving new sounds (e.g., tones, downloading of tones, animation, etc), and the like.

The reward indication can be displayed on and/or transmitted to any component associated with the continuous glucose monitoring system, including, a user interface of a portable receiver, a text or email to a care giver's device linked to the user's system, downloadable software, internet site, and the like). Additionally, the score or reward indication can be configured to be displayed or transmitted continuously, at predetermined levels of achievement, at a predetermined reward threshold or value, at predetermined time periods or events, and the like.

In some embodiments, displaying and/or transmitting the reward includes transmitting a score and/or reward to an internet site, whereby users can connect with other users and/or their physician to share or compete. It is believed that by interacting through social networking or data sharing, additional motivation can be achieved. Additionally, rewards can be used by a manufacturer to provide credits, new features, upgrades, accessories, and the like.

FIG. 7B is a flowchart that illustrates another exemplary process of generating rewards based on interactions of the host with the receiver. The method of FIG. 7B may be performed by a receiver, such as receiver 12 of FIG. 1. Depending on the embodiment, the method of FIG. 7B may include fewer or additional blocks and/or the blocks may be performed in an order than is different than illustrated.

In the embodiment of FIG. 7B, interactions with the receiver contribute towards meeting one or more reward criteria. The method of FIG. 7B includes determining that an interaction with the receiver has occurred 110, incrementing a reward counter 112, determining whether a reward threshold has been reached 114, and providing a reward indication 116.

At block 110 an interaction with the receiver is sensed. Depending on the embodiment, and as described above as well, the interaction may include pressing a button, touching the screen, or activating another input device on the receiver. Interactions may also include other actions taken by the user, such as viewing sensor data on an external device. In some embodiments, interaction includes downloading data, inputting events, setting parameters, confirming sensor data, and the like, as described in more detail elsewhere herein. In some embodiments, interaction is based on an amount of time the sensor is used, for example, over a predetermined time period.

At block 112 a reward counter is incremented in response to sensing of an interaction at block 110. In some embodiments, all interactions generate a same increment value. In some embodiments, some interactions have higher increment values than other interactions. For example, interacting with the receiver in order to view glucose level trend information may be associated with a higher increment value than interacting with the receiver in order to view a current glucose level. In one embodiment, increment values for the same or similar interaction may be limited during a predetermined time period. For example, a child may be limited to receiving reward points only for a first 5 times that a particular button on the receiver is pressed within any 5 minute period. In some embodiments, increment values for various interactions are programmable.

In addition, a higher increment value award can be given if a first interaction is followed by a particular second interaction. The first interaction can be different from or the same as the second interaction. As an example, a higher increment value can be given if a user follows interacting with the receiver 12 in order to view glucose level trend (a first interaction) with exercise (a second interaction). In various embodiments, the receiver 12 receives or generates exercise data for determining whether the host has exercised from one or more external or internal devices, such as a GPS device, accelerometer and a heart rate sensor. Furthermore, a higher increment value can be awarded based on the level of exercise performed as determined from the exercise data.

At block 114 the value of the reward counter is compared to a reward threshold. If the comparison indicates that a reward has not been achieved, the method returns to block 110. However, if the comparison indicates that a reward has been achieved, the method moves to block 116, where a reward indication is provided to the host, a caretaker, a doctor, and/or other interested party. The reward indication may be similar to the reward indication of block 108 of FIG. 6.

FIG. 8A is a flowchart illustrating one embodiment of a method of interacting with a host via a tutorial. The method of FIG. 8A displaying tutorial data to the host, such as a series of glucose levels of an exemplary host, receiving input from the host of an action that should be taken in response to the provided exemplary glucose levels, and generating next glucose levels in response to the received input from the host. In this way, the tutorial may be used to educate the host as to how certain actions affect (or don't affect) the blood glucose levels. The tutorial data may be used to educate the user about expected consequences to various actions in various circumstances. The method may be performed by, for example, a receiver, such as receiver 12 of FIG. 1. Depending on the embodiment, the method of FIG. 8 may include fewer or additional blocks and/or the blocks may be performed in an order than is different than illustrated.

For example, a tutorial may display graphics representing glucose measurements that are increasing. The user may select exercise as a response. The tutorial then calculates simulated glucose values based at least in part on the response. In this example, the tutorial helps the user become more familiar with expected results of performing the various actions.

FIG. 8B illustrates three series 810A, 810B, 810C, of frames that may be displayed on a receiver as part of an interactive tutorial. Each of the frame series 810 has three frames, including a first frame 121 that corresponds with block 120 of FIG. 8A wherein tutorial data is displayed to the host, a second frame 123 that correspond with block 122 of FIG. 8A wherein input of a simulated action is received from the host, and a third frame 127 that correspond with block 126 of FIG. 8A including graphics indicating simulated glucose measurements that are responsive to the simulated action received from the host.

Beginning in block 118, the receiver determines tutorial data. The tutorial data may be based at least in part on actual measurements from a glucose monitor and/or other sensor, such as episodic SMBG. In some embodiments, the measurements were taken while monitoring the current host and stored in a memory. In some embodiments, the memory has data from one or more other users. The memory data may additionally contain synthesized data, which is not the result of measurements, but is generated by a method or using a synthesis algorithm. The memory may contain data representing various glucose excursion scenarios, such as blood glucose levels increasing towards hyperglycemia and decreasing towards hypoglycemia.

In one embodiment, patterns in the tutorial data are identified and a list of potential causes, allowing user, doctor/HCP, algorithm or remote analysis to determine most likely causes, are generated and displayed as a list of potential solutions or responses. With the potential solutions/responses, the user, doctor/HCP, algorithm or remote analysis can then determine the most likely actions or responses to recommend. In one embodiment, the response impact may be estimated by the sensor electronics and/or documented, e.g. whether the user/caretaker followed the advice, and if not what actions were taken. In one embodiment, similar methods may be used in data management software or any remote analysis done whether by algorithm or remote HCP or clinical personnel or other trained to interpret data.

At block 120, the tutorial data is displayed. The tutorial data may be displayed as a series of frames displaying a game, an animation, or a cartoon. For example, a series of blood glucose levels may be displayed as graphics similar to those of any of FIGS. 3A-3H. In other embodiments, the tutorial data may be displayed in the form of textual data or as one or more graphs. As noted above, frames 121 of FIG. 8B illustrates exemplary displayed tutorial data.

Next, in block 122, the receiver receives an indication of an input from the host. The input indicates an action to be taken in response to the currently displayed tutorial data. For example, the action can be any of eating food, eating a glucose tablet, exercising, injecting insulin, responding to stress or injury, contacting someone for help, such as a teacher, a parent, or a medical professional, and/or taking no action. As noted above, frames 123 of FIG. 8B illustrate selected actions 125 displayed alongside the glucose data so as to indicate the relative timing of the actions 125 and the glucose data.

At block 124, the receiver simulates a response to the action indicated by the user. For example, based on the glucose levels, trends in the glucose levels, and/or the action indicated by the user, a processor in the receiver may generate a simulated response to the action based on a simulation algorithm. In one embodiment, a trend in the tutorial data may not change immediately after the host indicates that an action should be taken. For example, if the host indicates an action of eating food, the tutorial data may not indicate any changes in the current trend of the blood glucose levels for 30 minutes (or some other time period) representative of a time period that is required to digest the food and increase the blood sugar levels of the exemplary host. In one embodiment, the simulated responses may be compared to sensor data that was actually measured/seen, and the different in the simulated responses and the actual responses may be utilized in by the algorithm for additional user customization and response knowledge.

At block 126, the simulated response to the action is displayed. As noted above, frames 127 of FIG. 8B illustrate simulated responses displayed along with the tutorial data and the actions 125. In some embodiments, the simulated response is displayed along with the data representing measurements prior to the action. In some embodiments, the action take is represented with an icon in the display. In some embodiments, an animation is generated indicating the simulated response. In some embodiments, a reward indication is displayed if reward criteria are met. In some embodiments, simulated responses for one or more alternate actions may be generated and displayed, for example, in response to an input indicating a request for such a display. In some embodiments, a simulated response of an alternate action is generated and displayed if the action indicated by the user is not optimal.

In one embodiment, the method repeats blocks 120-126 as more simulated actions are received from the host and more simulated blood glucose levels responsive to the actions are generated by the receiver. In this way, the host is able to simulate an extended time period of activities (e.g., from morning until night) in a very short time frame (e.g., in 1-15 minutes, for example) while learning how certain actions affect blood glucose levels. In one embodiment, the graphics used for the tutorial are similar/same as used for the actual sensor data of the host, e.g., one or more of the games illustrated in FIGS. 3A-3H or the like.

FIGS. 9A and 9B are drawings illustrating embodiments of displayed tutorial data. FIG. 9A shows tutorial data 128 representing a selected glucose scenario. Icons 130 represent eating food, eating a glucose tablet, exercising, injecting insulin, or contacting someone for help, respectively. FIG. 9B shows tutorial data with actions and results of the actions. In some embodiments, the actions are real actions taken by a user from whom measurements were taken and are included in the tutorial data. In some embodiments, at least some of the actions are actions selected within a tutorial, and the measurements shown after the actions are simulated responses to the selected actions. In some embodiments, icons such as icons 130 are used outside of a tutorial to graphically indicate actions taken by the user.

Systems and methods can also be configured to provide a diabetes management game based on simulated or sample data. These games can be run and played on a computer system such as a PC, a PDA, a mobile phone, or the receiver 12 described above, for example. One mode can be configured to cause a user to compete against the computer system, wherein the computer system makes decisions (e.g., insulin dosing decisions) based on standard bolus wizards that take into account single point glucose sensor data (e.g., from a meter or significantly time spaced sensor data by at least about 4 hours) in one embodiment or continuous glucose sensor data (e.g., from an implantable sensor) in another embodiment. Preferably, the goal of this game is for the user to achieve a good score or beat the computer system. In one embodiment, the largest contributor to the score is based on exposure to glucose; in one embodiment, it could be an A1c score derived from the area under the curve over time. Deductions from the score can occur if a player has a severe hypoglycemia episode. Low variability of glucose concentration can amplify the score. The game can be designed to be repeatedly played by the user. In this exemplary embodiment, the game does not provide help or assistance or any advice about actions to take, but the game requires the user to read only the glucose information provided by an actual continuous glucose sensor session (e.g., glucose value, trend arrow, and/or graphical time display) and make insulin dosing decisions.