Glycemic urgency index evaluation and warning interface

Abstract

To evaluate an urgency state of a user related to a physiological state.SOLUTION: Systems and methods are disclosed that employ several or numerous factors in the determination of a glycemic urgency index (GUI), which may be based on a measured blood glucose level and other factors. The other factors may include time derivatives of the glucose level and / or other factors, e.g., user-entered data, data measured by other sensors or received from a network source, or historical data. The GUI is then presented to the user in an interesting way, e.g., via a background color or other inconspicuous notifier, e.g., on a mobile device such as a smart phone. The GUI may also be employed in the triggering of actionable alerts and alarms on an electronic device for the user. The GUI, or another index calculated from combinations of the variables and parameters described, may further be employed to drive a medicament delivery device such as a pump.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] INCORPORATION BY REFERENCE OF RELATED APPLICATIONS Any priority claim identified in this application data sheet, or any amendment thereto, is incorporated herein by reference under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Patent Application No. 61 / 978,151, filed April 10, 2014. The foregoing application is incorporated herein by reference in its entirety and hereby expressly made a part hereof.

[0002] The present embodiments relate to continuous analyte monitoring, and more particularly to signal analysis and result presentation of continuous analyte monitoring systems. [Background technology]

[0003] Diabetes mellitus is a disorder in which the pancreas fails to produce enough insulin (Type I, or insulin-dependent) and / or insulin is ineffective (Type II, or non-insulin-dependent). In the diabetic state, victims suffer from hyperglycemia, which can result in a number of physiological disorders related to the deterioration of small blood vessels, such as kidney failure, skin ulcers, or bleeding into the vitreous humor of the eye. A hypoglycemic reaction (low blood sugar) can be precipitated by inadvertent overdosing of insulin or after routine administration of insulin or glucose-lowering drugs accompanied by excessive exercise or inadequate food intake.

[0004] Traditionally, people with diabetes carry self-monitoring blood glucose (SMBG) monitors, which generally require an uncomfortable finger-prick method. Due to a lack of comfort and convenience, people with diabetes typically measure their glucose levels only two to four times a day. Unfortunately, such time intervals are far enough apart that people with diabetes are likely to detect a hyperglycemic or hypoglycemic state too late, sometimes suffering dangerous side effects. Not only are people with diabetes unlikely to recognize and address a dangerous condition in time, but they are also unlikely to understand whether their blood glucose levels are rising (higher) or falling (lower) based on traditional methods. This can therefore prevent people with diabetes from making informed insulin treatment decisions.

[0005] Another device that some diabetics have used to monitor their blood glucose is a continuous analyte sensor, e.g., a continuous glucose monitor (CGM). A CGM typically includes a sensor that is placed invasively, minimally invasively, or non-invasively. The sensor measures a given analyte, e.g., glucose, in the body and generates a raw signal that is generated by electronics associated with the sensor. The raw signal is converted into an output value that is displayed on a display device. The output value resulting from the conversion of the raw signal is typically expressed in a form that provides meaningful information to the user and that the user is familiar with for the analysis, such as blood glucose expressed in mg / dL. Summary of the Invention

[0006] The present embodiment has several features, no single one of which is solely responsible for these desirable attributes. Without limiting the scope of the present embodiment as expressed by the claims which follow, these more prominent features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled "Detailed Description," the reader will understand how the features of the present embodiment provide the advantages described herein.

[0007] Systems and methods are disclosed that use multiple variables or parameters in determining and / or calculating a glycemic urgency index (GUI), which may be based in part on a measured blood glucose level, which generally includes consideration of other factors. The other factors may include a first and / or second derivative of the blood glucose level with respect to time, and / or other factors described below, such as user-entered data, data measured by other sensors or received from network sources, or historical data. The GUI is then presented to the user in an engaging manner, for example, via background color or other unobtrusive notification means, on a mobile device such as a smartphone. In this manner, the GUI may be presented to the user continuously (whenever the display screen is on or otherwise activated). The GUI may also be used to activate actionable alerts and alarms (or other outputs) on the electronic device to the user. The GUI, or another index calculated from a combination of the described variables and parameters, may also be used to drive a drug delivery device, such as a pump. In general, a given GUI will generally result in the same notification (or actionable warning) for a given user, but users will see variations in the notification or warning depending on current sensitivity, how the user has configured their electronic device, the modes the user has allowed the device to be in, etc.

[0008] More specifically, the first type of data may be received in relation to a physiological condition. For example, a glucose concentration may be measured in a patient with diabetes, which is functionally related to the GUI. Then, the second type of data may be received, or in some cases, for example, the rate of change of the first type of data over time may be calculated. In the case of diabetes management, the second type of data may be the rate of change of the glucose concentration (i.e., whether the concentration is rising or falling, and how quickly). The second type of data may also be the acceleration of the glucose concentration, which may indicate, for example, a favorable change in the glucose concentration. In addition to the rate of change over time, the second type of data may also include pattern data, deviation from a normal glucose pattern, predicted glucose values, the duration that the glucose value (or its rate of change over time) falls within a specified range, or local maxima or minima. Like the first type of data, the second type of data is functionally related to the GUI. For example, while in some cases the second type of data is obtained or calculated from the first type of data, the second type of data is a dependent variable, i.e., an independent variable that influences the determination of the GUI.

[0009] A third type of data may also be received, which corresponds to other factors in addition to the analyte concentration and parameters derived therefrom. For example, data entered by a user may be the third type of data; e.g., data corresponding to health, exercise, dietary data, drug infusion data, or numerous other inputs. In some cases, the third type of data may be received from another device, e.g., a GPS or an exercise application running on a mobile device, which may indicate exercise performed by the user. Other applications may be used to monitor food intake, etc. An automated drug delivery device may also be interfaced with the system, for example, to indicate insulin pump operation for consideration in the GUI's determination. Similarly, the GUI may influence pump operation. Like the first and second types of data, the third type of data has a functional relationship with the GUI. Specifically, the third type of data is generally a dependent variable, i.e., an independent variable that influences the GUI's determination (although it is noted that it may feature parameters and variables that may themselves be somewhat interrelated).

[0010] A display of the GUI may be presented to a user on a user interface, for example, on a mobile device such as a smartphone. The GUI may be presented by means of naturally appearing features, such as background color or design that need not overtly identify itself as an indicator of the user's health. If the user is satisfied with the display, the interaction may end there. If the user desires additional data, the user may perform an operation, such as an unlock operation, a swipe operation, or other application operation, to retrieve additional details, for example, about how urgent the situation is, relevant measurements and parameters indicative of the situation, steps that may be taken to improve the situation, etc. If the GUI is presented by a design, features of the design may graphically (but often not numerically) show current values, such as glucose levels, which direction the value is changing, whether the value is improving, recent past values, etc. The user interface may also allow the user to input parameters and variables, which may then influence the GUI's decisions.

[0011] A monitoring device, e.g., a CGM, may be embodied as an application running on a mobile device, e.g., a smartphone, and downloadable to the mobile device. The application may specifically execute an urgency assessment module to perform a refined assessment of the urgency of the user's glycemic state, with a "higher" assessment generally associated with a "higher" urgency or "higher" risk condition. The mobile device may provide continuous notification or presentation of a GUI display and may also provide warnings or alerts if warranted.

[0012] In a first aspect, the present invention provides a method for assessing an urgency status of a user related to a physiological condition, comprising receiving a first type of data related to the physiological condition, calculating a second type of data related to the physiological condition, receiving a third type of data related to the physiological condition, determining an urgency index based at least on the first, second, and third types of received data, and providing a display of the determined urgency index on a mobile device.

[0013] The first type of data can be analyte, e.g., glucose data, from a continuous analyte sensor implanted within the body. The second data can be a first time derivative and / or a second time derivative of the first data. The third data can be data external to the analyte data from the sensor that represents factors affecting the health risk of a physiological condition reflected by the analyte within the body, e.g., factors affecting the risk of an extreme hyperglycemic or hypoglycemic state reflected by glucose data sensed by the continuous analyte data. Specifically, the third data can represent factors affecting the analyte level reflecting the physiological condition, thereby affecting the health risk.

[0014] The mobile device may be a smartphone.

[0015] The method may include outputting an audible and / or tactile alert on the mobile device, and / or ignoring other applications or processes running on the mobile device such that when the urgency index reaches or exceeds a threshold indicating a physiological condition that has reached a health risk state, for example, indicating risk of an extreme hypoglycemic or hyperglycemic state, the display of the urgency index is displayed on the mobile device regardless of other running applications or processes unless corrective action is taken by the user.

[0016] The method may include providing a display on the mobile device such that the display is visible to a user even before going past a lock screen of the mobile device, at least when the urgency index indicates a high urgency with respect to the physiological condition.

[0017] The determination of the urgency index may be performed by an urgency assessment module.

[0018] The urgency assessment module may take as input analyte data representative of a physiological condition, e.g., glucose data representative of a diabetic patient's condition, as a first type of data, and as the data approaches a health risk of the physiological condition, e.g., a risk of extreme hyperglycemia or a risk of extreme hypoglycemia, the analyte data input tends to adjust the urgency index to a value representing a higher urgency.

[0019] The urgency assessment module may take as input first and / or second time derivative data as a second type of data that tends to adjust the urgency index to a value representing less urgency when the first derivative data and / or second derivative data indicate that the health risk, e.g., risk of extreme hyperglycemia or hypoglycemia, is easing, or to a value representing more urgency when the first derivative data and / or second derivative data indicate that the health risk, e.g., risk of hyperglycemia or hypoglycemia, is worsening.

[0020] The urgency assessment module takes as input external data related to user or other actions that will affect the analyte data in the future as a third type of data, such that when the effect of the user or other action on the analyte data will mitigate the analyte level with respect to the health risk, the input external data tends to adjust the urgency index to a value representing a lower risk, and when the effect of the user or other action on the analyte data will worsen the analyte level with respect to the health risk, the input external data tends to adjust the urgency index to a value representing a higher risk. In one embodiment, the external data represents the time of insulin infusion into the body (whether via an internal pump or an external injector) and / or represents the time of food / drink ingestion and / or represents the time the user exercises, the health risk is the risk of extreme hyperglycemia or hypoglycemia, and the analyte is blood glucose.

[0021] The urgency assessment module may take as input, as second data, duration data representing the time that the analyte data is outside of a normal range defined for the physiological condition, e.g., the duration that the analyte data continuously represents a hyperglycemic or hypoglycemic state, and the duration data tends to adjust the urgency index such that a higher urgency is determined as the duration increases.

[0022] Determining the urgency index may include using a mathematical risk function having terms for the analyte data, a first time derivative of the analyte data, and a second time derivative of the analyte data, and / or a duration that the analyte data is outside a normal range for the physiological condition, wherein the data forming the terms constitute the first type of data and the second type of data.

[0023] Implementations of the first aspect may include one or more of the following: the physiological condition may be diabetes, the urgency index may be a glycemic urgency index, and the first type of data may be a glucose concentration, which may be a current measured glucose concentration, a previously measured glucose concentration, or a future predicted glucose concentration.

[0024] A second type of data, such as a first or second derivative with respect to time, may be derived from the first type of data. The second type of data derived from the first type of data may further include deviations from a normal glucose pattern, pattern data of glucose values ​​over time, predicted glucose values, duration that glucose values ​​are within a specified range, weighting of parameters or variables considered in determining the urgency index, or local maxima or minima of the first type of data.

[0025] Receiving a third type of data may include, for example, receiving data entered by a user on a user interface of a mobile device.

[0026] If the physiological condition is diabetes, the urgency index may be a glycemic urgency index, the first type of data may be a glucose concentration, and the received data input by the user may include the user's weight, a user's indication of activity level, a user's indication of food or beverage ingested or to be ingested, anthropometric data, data regarding previous insulin provided to the user, stress data, health data, data regarding placement of a sensor measuring the first type of data, age, or gender. The received data input by the user may include the user's indication of food or beverage ingested or to be ingested, or data regarding insulin provided or to be provided to the user, and may further include modifying the glycemic urgency index determined based on the received data to be less urgency.

[0027] Receiving the third type of data may include receiving data from a sensor. If the physiological condition is diabetes, the urgency index may be a glycemic urgency index, the first type of data may be a glucose concentration, and the sensor may include at least one of a scale, a glucometer, a thermometer, an accelerometer, a camera, a GPS device, or a microphone. Receiving the third type of data may also include the user's weight, a user indication of activity level, an indication of food or beverages consumed or to be consumed, anthropometric data, data regarding previous insulin provided to the user, physiological data, stress data, or health data. Receiving the third type of data may also include receiving data from a query processing engine, an electronic device configured for machine-to-machine interaction, or an electronic user record. The third type of data may be received from a mobile device and may correspond to a level of user interaction with an application, the indication being provided through the application.

[0028] The method may further include providing a warning or alert if the glycemic urgency index reaches a predetermined warning or alarm threshold, respectively, which may indicate that the user is experiencing a hypoglycemic or hyperglycemic condition.

[0029] In addition to diabetes, the physiological condition may also include one or more of obesity, malnutrition, hyperactivity, depression, or fertility.

[0030] The method may further include providing an enhanced output based on the received input.

[0031] The step of providing the indication may include displaying an indication of the urgency index on a user interface of the mobile device. The step of displaying may further include ignoring other applications or processes operating on the mobile device such that the indication of the urgency index is displayed without regard to other running applications or processes.

[0032] If the displaying step is caused by a user action, the user action may be selected from the group consisting of holding the mobile device in a hand, unlocking the mobile device, or performing a swipe action on the mobile device.

[0033] The representation of the urgency index may be a drawn element, e.g., a color, that is drawn as at least a portion of a home screen or background native to the mobile device's operating system. If the drawn element is colored, the color varies depending on the urgency index. The drawn element may also be an icon, where the position, size, or color of the icon is based on the urgency index.

[0034] The method may further include receiving an indication that a user has activated the icon and displaying additional information or an advanced output regarding the urgency index.

[0035] The third type of data may include past or future drug parameters entered by the user or received from the integrated pump, the drug parameters representing the time and / or amount of drug infused into the user to address the physiological condition. If the analyte is glucose, the urgency index may be a glycemic urgency index and the drug parameter may correspond to insulin.

[0036] The step of providing a display may further include a rendering function, as follows: For example, a series of elements may be rendered on a user interface of the mobile device, the series of elements indicating past or predicted future values ​​of the glucose concentration; the display of the urgency index may be a visual or audible alert, respectively rendered on the mobile device; the method may further include displaying a prompt to the user to input data, such that the user data may be associated with the urgency index; the prompt to the user to input data may indicate a type of data, which may be selected from the group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or emotional data, which may be utilized to form third data; the method may further include displaying at least one possible action the user may take in response to the displayed display of the urgency index; the display may be an actionable alert; the display of the display may include displaying a bandwidth occupancy, the bandwidth corresponding to a specified range of urgency index values.

[0037] The method may further include storing the determined urgency index in a storage device of the mobile device. The method may include transmitting the stored urgency index to the integrated pump. For example, the method may further include converting the stored urgency index into a pump operation and transmitting the pump operation to the integrated pump.

[0038] The method may also include displaying a current analyte data value indicative of the physiological condition, and / or displaying an indication of whether the analyte's trend for the day is increasing or decreasing, and optionally displaying an index of the rate of increase or decrease of the trend. In one implementation, the trend is indicated by a generally upward arrow indicating an increasing trend and a generally downward arrow indicating a decreasing trend, optionally with the angle of the arrow indicating the amount of change, with more vertical indicating a greater amount of change.

[0039] An indication of the urgency index may be provided by changing colors depending on the urgency, with red being selected to indicate the most urgent condition.

[0040] In a second aspect, the present invention is directed to a system for carrying out any of the above methods of the first aspect.

[0041] In a third aspect, the present invention is directed to a method for determining an urgency index associated with a physiological condition, comprising determining an urgency index based on an analyte concentration and at least two variables selected from the group consisting of a first time derivative or a second time derivative of the analyte concentration, a duration that the analyte concentration occupies a specified range, a duration that the first time derivative or the second time derivative of the analyte concentration occupies a specified range, a second time derivative of the analyte concentration, a duration that the second time derivative of the analyte concentration occupies a specified range, a past or future meal intake parameter input by a user, a past or future drug parameter input by a user or received from an integrated pump, or body temperature.

[0042] The method may include storing the determined urgency index in a storage device of the mobile device.

[0043] The urgency index may represent the urgency of requiring intervention to bring the analyte concentration from a higher health risk level to a lower health risk level with respect to the physiological condition.

[0044] Implementations of the second aspect may include one or more of the following: The method may include displaying a display of the urgency index on a user interface of the mobile device. The displaying step may further include ignoring other applications or processes operating on the mobile device, such that the display of the urgency index is displayed without regard to other running applications or processes.

[0045] If the displaying step is caused by a user action, the user action may be selected from the group consisting of holding the mobile device in a hand, unlocking the mobile device, or performing a swipe action on the mobile device.

[0046] The representation of the urgency index may be a rendered element, e.g., a color, that is rendered as at least a portion of a home screen or background native to the mobile device's operating system, or the rendered element may be an icon, where the icon's position, size, or color is based on the urgency index.

[0047] The method may further include receiving an indication that a user has activated the icon and displaying additional information or an advanced output regarding the urgency index.

[0048] If the analyte is glucose, the urgency index may be a glycemic urgency index and the drug parameter may correspond to insulin.

[0049] The method may include a drawing function, as follows: For example, a series of elements may be drawn on a user interface of a mobile device, the series of elements indicating past or predicted future values ​​of glucose concentration.

[0050] An indication of the urgency index may be provided, which may be an audible or visual alert, respectively, drawn on the mobile device or emitting a sound.

[0051] The method may further include displaying a prompt to the user to input data such that the user data can be correlated to the urgency index. The prompt to the user to input data may indicate a type of data, which may be selected from the group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or emotional data. The method may further include displaying at least one possible action the user may take in response to the displayed indication of the urgency index. The indication may be an actionable alert. The action may be adjusting the health risk when the risk of urgency is high to bring the analyte concentration toward an above-normal acceptable level for the health risk presented by the physiological condition. The display of the indication may include displaying a band occupancy, the band corresponding to a defined range of urgency index values.

[0052] The method may further include transmitting the stored urgency index to an integrated pump. For example, the method may further include converting the stored urgency index into a pump operation and transmitting the pump operation to the integrated pump. The integrated pump discussed in this paragraph and described above may be a pump for delivering a drug to treat a physiological condition.

[0053] The method may include providing a display of the determined urgency index on the mobile device.

[0054] The at least two variables may include a first time derivative and / or a second time derivative of the analyte concentration.

[0055] The mobile device may be a smartphone.

[0056] The method may include outputting an audible and / or tactile warning on the mobile device, and / or ignoring other applications or processes running on the mobile device such that when the determined urgency index reaches or exceeds a threshold indicating a physiological condition that has reached a health risk state, for example, indicating risk of an extreme hypoglycemic or hyperglycemic state, the display of the urgency index is displayed on the mobile device regardless of other running applications or processes unless corrective action is taken by the user.

[0057] The method may include providing an indication of the imminent danger on the mobile device, such that the indication is visible to a user even before going past a lock screen of the mobile device, at least when the urgency index indicates a high urgency with respect to the physiological condition.

[0058] The determination of the urgency index may be performed by an urgency assessment module.

[0059] The urgency assessment module may take analyte concentration as input, and as the data approaches a health risk of a physiological condition, e.g., a risk of extreme hyperglycemia or a risk of extreme hypoglycemia, the analyte concentration input will tend to adjust the urgency index to a value representing a higher urgency.

[0060] The urgency assessment module may take the first time derivative and / or the second time derivative as input in a manner that tends to adjust the urgency index to a value representing less urgency when the first time derivative and / or the second time derivative indicate that the health risk, e.g., the risk of the physiological condition of extreme hyperglycemia or hypoglycemia, is easing, or to a value representing more urgency when the first derivative and / or the second derivative indicate that the health risk, e.g., the risk of the physiological condition of extreme hyperglycemia or hypoglycemia, is worsening.

[0061] The urgency assessment module may take as input external data including past or future meal intake parameters entered by the user or past or future drug parameters entered by the user or received from an integrated pump, where the input external data tends to adjust the urgency index to a value representing a lower risk when the effect of the drug or meal intake on the analyte concentration alleviates the analyte level with respect to the health risk of the physiological condition, and the input external data tends to adjust the urgency index to a value representing a higher risk when the effect of the drug or meal intake on the analyte concentration worsens the analyte level with respect to the health risk. In certain embodiments, the drug parameters represent the time and / or amount of insulin infusion into the body (whether through an internal pump or an external infuser), and the meal intake parameters represent the time and / or amount of food / drink ingestion.

[0062] The at least two variables may include at least one of first and second time derivative data and a food intake parameter and a drug parameter.

[0063] The urgency assessment module may additionally or alternatively obtain as input an indication of the duration for which the analyte concentration occupies a defined range representing a normal range defined for the physiological state, e.g., the duration for which the analyte data continuously represents a euglycemic state, and the duration indication tends to adjust the urgency index such that a higher urgency is determined as the duration increases.

[0064] Determining the urgency index may include using a mathematical risk function having terms representing each of the analyte concentration, the first time derivative of the analyte concentration, and the second time derivative of the analyte concentration, and / or the duration that the analyte concentration occupies a specified range.

[0065] Implementations of the third aspect may further include one or more of the following: the physiological condition may be diabetes, the urgency index may be a glycemic urgency index, the analyte concentration may be a glucose concentration, and the glucose concentration may be a current measured glucose concentration.

[0066] The method may include receiving dietary intake parameters and / or medication parameters based on corresponding data entered by a user, such as on a user interface of the mobile device.

[0067] The method may further include providing a warning or alert if the glycemic urgency index reaches a predetermined warning or alarm threshold, respectively, which may indicate that the user is experiencing a hypoglycemic or hyperglycemic condition.

[0068] The method may also include displaying a numerical value representing the analyte concentration, such as in mg / ml, and / or displaying an indication of whether the analyte concentration trend is increasing or decreasing, and optionally displaying an indication of the rate of increase or decrease of the trend. In one implementation, the trend is indicated by a generally upward arrow indicating an increasing trend and a generally downward arrow indicating a decreasing trend, optionally with the angle of the arrow indicating the amount of change, with more vertical indicating a greater amount of change. An indication of the urgency index may be provided by changing the color of the display depending on the urgency; red may be selected to indicate the highest urgency. The display may be on a mobile device, such as a smartphone.

[0069] In a fourth aspect, the present invention is directed to a system for carrying out any of the above methods of the third aspect.

[0070] In a fifth aspect, the present invention is directed to a device, system, or method substantially as hereinbefore described and / or shown in the drawings.

[0071] In a sixth aspect, the present invention relates to an electronic device for monitoring data related to a physiological condition, comprising a drug delivery device configured to substantially continuously measure a concentration of an analyte in a host and to provide continuous sensor data related to the analyte concentration in the host, and a processor module configured to perform any one of the methods set forth above.

[0072] In a seventh aspect, the present invention relates to an electronic device for delivering a drug to a host, the drug delivery device being operably connected to a continuous analyte sensor, the continuous analyte sensor being configured to substantially continuously measure a concentration of an analyte in the host and providing continuous sensor data related to the analyte concentration in the host; and a processor module configured to perform any one of the methods set out above.

[0073] To facilitate understanding of the described functionality, continuous glucose monitoring will be used as part of the following description. It will be understood that the described systems and methods are applicable to other continuous monitoring systems. For example, the discussed functionality may be used for continuous monitoring of lactate, free fatty acids, heart rate during exercise, IgG-antigliadin, insulin, glucagon, exercise tracking, fertility, calorie intake, hydration, salt concentration, sweat / perspiration (stress), ketones, adipanectin, troponin, perspiration, and / or body temperature. While glucose monitoring is used as an example, one or more of these alternative monitoring conditions may be substituted. Thus, while a GUI is described above, in a similar system, a lactose urgency index, a ketone urgency index, etc. may be defined.

[0074] Any of the features of the embodiments of the various aspects disclosed are applicable to all aspects and embodiments identified. Furthermore, any of the features of the embodiments may be independently combined in any manner, partially or fully, with other embodiments described herein, e.g., one, two, or more embodiments may be combined in whole or in part. Furthermore, any of the features of the embodiments of various aspects may be optional in other aspects or embodiments. Any aspect or embodiment of a method may be performed by a system or device of another aspect or embodiment, and any aspect or embodiment of a system may be configured to perform a method of another aspect or embodiment.

[0075] Advantages of systems and methods according to this principle may include one or more of the following: A user can receive an indication of their urgency assessment at any time with a glance at their phone. Similarly, by using an intelligent algorithm that considers multiple inputs in determining a glycemic emergency, a user can receive more actionable alerts, reduce the occurrence of nuisance alerts, and increase CGM usage. Because the urgency assessment is based on inputs not previously considered by the alert algorithm, a glycemic urgency index may better correlate to a patient's clinical diabetes management rather than necessarily correlating to glucose concentration (or derivative) information alone. A user can be safely and discreetly alerted to a glycemic emergency in an engaging and customizable manner, and by utilizing the native user interface of a device the user likely already carries, e.g., a mobile device. Other advantages will become apparent from the following description, including the figures and claims. [Brief explanation of the drawings]

[0076] The present embodiments will now be discussed in detail with an emphasis on highlighting beneficial features. These embodiments depict novel and non-obvious urgency assessment and user interfaces shown in the accompanying drawings, which are for illustrative purposes only. These drawings include the following figures, in which like numerals indicate like parts:

[0077] [Figure 1] 10 is a graph of an output trace illustrating the effect of setting the low threshold to a lower or higher value. [Figure 2] 10 is a graph of an output trace illustrating that even relatively stable glucose values ​​can trigger an alarm. [Figure 3] FIG. 1 is a block diagram of a preferred embodiment integrated system including a continuous glucose sensor and a drug delivery device. [Figure 4] 1 is an elevational view of an electronic device configured for use with the present systems and methods. [Figure 5] FIG. 5 is a functional block diagram of the electronic device of FIG. 4. [Figure 6] 4 depicts a logical diagram of certain components of the system of FIG. 3; [Figure 7] Depicts categories of parameters or variables that may be used in GUI calculations. [Figure 8] 1 is a flow chart illustrating a method according to this principle. [Figure 9] 1 is a graph illustrating how various combinations of parameters and variables can be used in determining a GUI. [Figure 10] 10 is another graph showing how various combinations of parameters and variables can be used in determining a GUI, particularly using patterns. [Figure 11] 10 is another graph showing how various combinations of parameters and variables can be used in determining a GUI using data specifically related to critical events. [Figure 12A] 1 illustrates glucose concentration as a function of time, static risk, and dynamic risk. [Figure 12B] 1 illustrates glucose concentration as a function of time, static risk, and dynamic risk. [Figure 13] Illustrates how blood glucose urgency increases with duration in hypoglycemia. [Figure 14] Illustrates how using acceleration as a parameter or variable in GUI decisions can avoid false alarms regarding dangerous conditions. [Figure 15A] Illustrates various probability distributions corresponding to example parameters and variables. [Figure 15B] Illustrates various probability distributions corresponding to example parameters and variables. [Figure 15C] Illustrates various probability distributions corresponding to example parameters and variables. [Figure 15D] Illustrates various probability distributions corresponding to example parameters and variables. [Figure 15E] Illustrates various probability distributions corresponding to example parameters and variables. [Figure 15F] Illustrates various probability distributions corresponding to example parameters and variables. [Figure 16A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 16B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 17A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 17B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 18A]10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 18B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 19A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 19B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 20A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 20B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 21A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 21B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 22A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 22B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 23] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 24]10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 25A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 25B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 26] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 27A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 27B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 28A] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 28B] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 29] 10 illustrates various user interfaces that may be used to display GUI notifications and / or actionable alerts based on a computed GUI. [Figure 30] 1 is a flowchart of an example method for providing a GUI notification and / or actionable alert. [Figure 31A] 1 is an example user interface that prompts for user input. [Figure 31B] 1 is an example user interface that prompts for user input. [Figure 32A]10 is a flowchart of another example method for implementing a retrospective algorithm. [Figure 32B] 32B is a graph illustrating the use of the method of FIG. 32A. [Figure 32C] 32B is a graph illustrating the use of the method of FIG. 32A. DETAILED DESCRIPTION OF THE INVENTION

[0078] Consider a specific example of continuous glucose monitoring. For a diabetic, glucose monitoring can literally mean the difference between life and death. However, blood glucose values ​​presented on a CGM can be unclear. For example, three users may all have the same blood glucose level measured by their CGM, but each may require different treatment depending on whether their blood glucose level is decreasing, staying the same, or increasing. This is particularly true because current CGMs activate alerts based on low and / or high thresholds, e.g., predicted or actual glucose concentration thresholds that sometimes include consideration of rate of change. Predicted values ​​are generally highly susceptible to noise, and the use of alerts based on such thresholds does not provide users with much or enough time to react before encountering a dangerous or dangerous situation.

[0079] For example, and with reference to FIG. 1, a standard hypoglycemia threshold warning may be set at 70 mg / dL. If a user's glucose level is falling rapidly, such a low-threshold warning may not provide the user with enough time to prevent a very low glucose level, for example, below 55 mg / dL. Even if the low-threshold warning were set at 80 mg / dL, the user would only hear the warning 10 minutes before falling below 55 mg / dL. It is clear from the CGM output trace of FIG. 1 that in the 30 minutes before falling below 55 mg / dL, the user fell at an average rate of 2.5 mg / dL / minute, putting the user in a very dangerous situation well before the 70 mg / dL threshold was reached.

[0080] While it is always possible to increase the sensitivity of a sensor, such an increase often leads to false alarms and user “alert fatigue.” This is especially true when monitoring is via a smartphone, which typically already alerts the user through multiple means, e.g., application notifications, text messages, emails, etc. For example, if the low threshold were set higher, e.g., at 80 or 90 mg / dL, in an effort to ensure there is sufficient time to prevent very low glucose levels, such a setting would lead to many false alarms. As another example, and with reference to FIG. 2, a stable glucose level hovering around 80 mg / dL does not warrant an alert, but if the threshold were set to 80 mg / dL, many alerts would be triggered.

[0081] Furthermore, while current systems are capable of providing users with blood glucose level and threshold-based alerts, the user interfaces associated with such systems do not meet user expectations. Both the lack of reliable alerts and the lack of a safe and discreet user interface hinder the use and adoption of such monitoring.

[0082] Similarly, current systems that integrate insulin pump operation with CGM use simple glucose thresholds to make decisions such as withholding basal insulin. However, simple glucose thresholds do not provide sufficient information regarding the user's emergency status. For example, using a 70 mg / dL threshold to withhold insulin delivery may be appropriate when glucose is gradually declining, but if glucose is rapidly falling, it may be more appropriate to withhold insulin when glucose is 100 mg / dL, or even sooner if there is a large amount of residual insulin or recent exercise. Even discontinuing predicted glucose values ​​alone has the disadvantage of numerous false positives.

[0083] Other aspects related to measuring blood glucose and providing alerts therefor are described in commonly owned, co-pending U.S. Non-Provisional Patent Application No. 13 / 742,694, entitled "SYSTEMS AND METHODS FOR PROVIDING SENSITIVE AND SPECIFIC ALARMS," filed January 16, 2013, and incorporated herein by reference in its entirety.

[0084] One non-limiting advantage of the functionality described herein is that it provides alerts and alarms that are more useful to the user, i.e., more "actionable," in the sense that the appropriate action to be taken is noticeable or readily inferable by the user in light of the alert or alarm. Such alerts and alarms are also more accurate, in the sense that they more accurately reflect the user's current glycemic urgency assessment. In addition to providing actionable alerts and / or alarms, it can provide continuous notification to the user of the user's urgency assessment and present it to the user in a compelling manner using the native user interface of a device that the device user already commonly carries, e.g., a mobile device such as a smartphone, thus negating the need for the user to carry an additional device.

[0085] Various terms are described below.

[0086] The term "continuous glucose sensor," as used herein, is a broad term and is given its ordinary and customary meaning to those skilled in the art (and is not limited to any special or individualized meaning), and refers, without limitation, to a device that continuously or intermittently measures the glucose concentration of a bodily fluid (e.g., blood, plasma, interstitial fluid, etc.) over time intervals ranging from fractions of a second up to, e.g., 1, 2, or 5 minutes or more.

[0087] The phrases "continuous glucose sensing" or "continuous glucose monitoring," as used herein, are broad terms that are given their ordinary and customary meaning to those skilled in the art (and are not limited to any special or individualized meaning), and refer, for example, but not limited to, a period of continuous or intermittent monitoring of the glucose concentration of a host's bodily fluid (e.g., blood, serous fluid, plasma, extracellular fluid, tears, etc.) over time intervals ranging from fractions of a second up to, for example, 1, 2, or 5 minutes or more. In one exemplary embodiment, the glucose concentration of the host's extracellular fluid is measured every 1, 2, 5, 10, 20, 30, 40, 50, or 60 seconds.

[0088] The term "substantially," as used herein, is a broad term, affording its ordinary and customary meaning to those of ordinary skill in the art (and not limited to a special or particular meaning), and refers, without limitation, to a large extent, but not necessarily entirely, of something given, which may include an amount greater than 50 percent, an amount greater than 60 percent, an amount greater than 70 percent, an amount greater than 80 percent, an amount greater than 90 percent, or more.

[0089] The terms "processor" and "processor module," as used herein, are broad terms that are given their ordinary and customary meaning to those skilled in the art (and are not limited to any special or particular meaning) and refer to, but are not limited to, computer systems, state machines, processors, and the like, designed to perform arithmetic or logical operations using logic circuitry that corresponds to or processes the basic instructions that make a computer operate. In some embodiments, the terms may include ROM and / or associated RAM.

[0090] Exemplary embodiments disclosed herein relate to the use of glucose sensors to measure the concentration of a substance indicative of the concentration or presence of glucose or another analyte. In some embodiments, the glucose sensor is a continuous device, e.g., a subcutaneous, transdermal, transcutaneous, non-invasive, intraocular, and / or intravascular (e.g., intravenous) device. In some embodiments, the device is capable of analyzing multiple intermittent blood samples. The glucose sensor can use any method of glucose measurement, including enzymatic, chemical, physical, electrochemical, optical, photochemical, fluorescence-based, spectrophotometric, spectroscopic (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), polarimetric, calorimetric, iontophoretic, radiometric, etc.

[0091] The glucose sensor can provide a data stream indicative of the concentration of the analyte in the host using any known detection method, including invasive, minimally invasive, and non-invasive sensing techniques. The data stream is generally a raw data signal used to provide a useful value of the analyte to a user, such as a patient or healthcare professional (e.g., a physician), who may be using the sensor.

[0092] While much of the description and examples are directed to glucose sensors capable of measuring the concentration of glucose in a host, the systems and methods of the embodiments can be applied to any measurable analyte. Some example embodiments described below utilize implantable glucose sensors. However, it should be understood that the devices and methods described herein can be applied to any device capable of detecting the concentration of an analyte and providing an output signal representative of the analyte concentration.

[0093] As noted, in some embodiments, the analyte sensor is an implantable glucose sensor, e.g., as described in U.S. Patent No. 6,001,067 and U.S. Patent Publication No. US-2011-0027127-A1. In some embodiments, the analyte sensor is a transcutaneous glucose sensor, e.g., as described in U.S. Patent Publication No. US-2006-0020187-A1. In yet other embodiments, the analyte sensor is a dual-electrode analyte sensor, e.g., as described in U.S. Patent Publication No. US-2009-0137887-A1. In yet other embodiments, the sensor is configured to be implanted within a major blood vessel or outside the body, e.g., as described in U.S. Patent Publication No. US-2007-0027385-A1. These patents and publications are incorporated herein by reference in their entireties.

[0094] The following description and examples describe the present embodiment with reference to the drawings, in which reference numbers label elements of the present embodiment, and these reference numbers are reproduced below in connection with a discussion of corresponding drawing features.

[0095] 3 is a block diagram of a preferred embodiment integrated system including a continuous glucose sensor and a drug delivery device. Such an integrated system is an example environment in which some embodiments described herein may be implemented. Here, an analyte monitoring system 100 includes a continuous analyte sensor system 8. The continuous analyte sensor system 8 includes a sensor electronics module 12 and a continuous analyte sensor 10. The system 100 may also include other devices and / or sensors, such as a drug delivery pump 2 and a reference analyte meter 4. The continuous analyte sensor 10 may be physically connected to the sensor electronics module 12, which may be integral with the continuous analyte sensor 10 (e.g., non-releasably attached) or releasably attachable. Alternatively, the continuous analyte sensor 10 may be physically separate from the sensor electronics module 12, but electrically coupled thereto, such as via inductive coupling. Additionally, the sensor electronics module 12, the drug delivery pump 2, and / or the analyte reference meter 4 may communicate with one or more additional devices, such as any or all of the display devices 14, 16, 18, and / or 20. The display devices 14, 16, 18, and 20 generally include a processor, memory, storage, and other components sufficient to run applications, including the urgency assessment module.

[0096] In some implementations, the system 100 of FIG. 3 may also include a cloud-based processor 22 configured to analyze analyte data, drug delivery data, and / or other user-related data provided over the network 24 directly or indirectly from one or more of the sensor system 8, the drug delivery pump 2, the reference analyte meter 4, and the display devices 14, 16, 18, and 20. Based on the received data, the processor 22 may further process the data, generate reports providing statistics based on the processed data, activate notifications on electronic devices associated with the host or the host's caregiver, or provide the processed information to any of the other devices of FIG. 3. In some example implementations, the cloud-based processor 22 comprises one or more servers. When the cloud-based processor 22 comprises multiple servers, the servers may be geographically local or separate from one another. The network 24 may include any wired or wireless communication medium for transmitting data, including a Wi-Fi network, a cellular network, the Internet, and any combination thereof.

[0097] In some example implementations, sensor electronics module 12 may include electronic circuitry associated with measuring and processing data generated by continuous analyte sensor 10. The generated continuous analyte sensor data may also include algorithms that may be used to process and calibrate the continuous analyte sensor data, although these algorithms may also be provided by other means, such as by devices 14, 16, 18, and / or 20. Sensor electronics module 12 may include hardware, firmware, software, or a combination thereof, for providing measurements of analyte levels via a continuous analyte sensor, such as a continuous glucose sensor.

[0098] As mentioned, sensor electronics module 12 may be coupled (e.g., wirelessly, etc.) to one or more devices, such as any or all of display devices 14, 16, 18, and 20. Display devices 14, 16, 18, and / or 20 may be configured to process and present sensor information as transmitted by sensor electronics module 12 for display on the display device. Display devices 14, 16, 18, and 20 may also activate alarms based on the analyte sensor data.

[0099] 3 , display device 14 is a key-fob-like display device, display device 16 is a handheld, application-specific computing device 16 (e.g., a DexCom G4® Platinum receiver commercially available from DexCom, Inc.), display device 18 is a general-purpose smartphone or tablet computing device 20 (e.g., a phone running the Android® OS, an Apple® iPhone®, iPad®, or iPod touch® commercially available from Apple, Inc.), and display device 20 is a computer workstation 20. In some example implementations, relatively small key-fob-like display device 14 may be a computing device embodied in a watch, belt, necklace, pendant, piece of jewelry, adhesive patch, pager, key fob, plastic card (e.g., credit card), and / or identification card (ID), etc. This small display device 14 may include a relatively small display device (e.g., smaller than display device 18) and may be configured to display a limited set of displayable sensor information, such as numbers 26 and arrows 28. Some systems may also include a wearable device 21, for example, as described in U.S. Provisional Patent Application No. 61 / 904,341, filed November 14, 2013, entitled "Devices and Methods for Continuous Analyte Monitoring," the entire disclosure of which is expressly incorporated herein by reference. Wearable device 21 may include any device(s) attached to or integrated with a user's optics, clothing, and / or body.Examples of devices include wearable devices, anklets, eyeglasses, rings, necklaces, armbands, pendants, belt clips, hair clips / elastics, pins, cufflinks, tattoos, stickers, socks, sleeves, gloves, clothing (e.g., shirts, pants, underwear, bras, etc.), "clothing accessories" such as zipper pulls, buttons, watches, shoes, contact lenses, subdermal implants, eyeglasses, cochlear implants, shoe insoles, orthotics (oral), orthotics (torso), medical bandages, sports bands (wristbands, headbands), hats, bandages, hair extensions, nail polish, artificial joints / body parts, orthopedic pins / devices, implantable cardiac or neurological devices, etc. Small display device 14 and / or wearable device 21 may include a relatively small display device (e.g., smaller than display device 18) and may be configured to display graphical and / or numerical representations of sensor information, such as numbers 26 and / or arrows 28. Conversely, display devices 16, 18, and 20 may be larger display devices capable of displaying a larger set of displayable information, such as trend graph 30 depicted on handheld receiver 16, in addition to other information such as numbers and arrows.

[0100] It will be understood that any other user equipment (e.g., computing device) configured to at least present information (e.g., drug delivery information, separate self-monitoring analyte measurements, heart rate monitoring, calorie intake monitoring, etc.) can be used in addition to or instead of those discussed with respect to FIG. 3.

[0101] 3, the continuous analyte sensor 10 comprises a sensor for detecting and / or measuring an analyte, and the continuous analyte sensor 10 may be configured to continuously detect and / or measure an analyte as a non-invasive, subcutaneous, transcutaneous, and / or intravascular device. In some example implementations, the continuous analyte sensor 10 may analyze multiple intermittent blood samples, although other analytes may also be used.

[0102] 3 , the continuous analyte sensor 10 may comprise a glucose sensor configured to measure glucose in blood using one or more measurement techniques, such as enzymatic, chemical, physical, electrochemical, fluorescent, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, etc. In examples in which the continuous analyte sensor 10 comprises a glucose sensor, the glucose sensor may comprise any device capable of measuring the concentration of glucose and may provide data, such as a data stream indicative of the concentration of glucose in a host, using various techniques for measuring glucose, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescent monitoring). The data stream may be a raw data signal that is converted into a calibrated and / or filtered data stream used to provide a glucose value to a host, such as a user, patient, or caregiver (e.g., a parent, relative, guardian, teacher, doctor, nurse, or any other individual interested in the health of the host). Additionally, the continuous analyte sensor 10 may be implanted as at least one of the following types of sensors: an implantable glucose sensor, a transcutaneous glucose sensor, a sensor implanted in a main blood vessel or extracorporeally, a subcutaneous sensor, a refillable subcutaneous sensor, an intraocular sensor, or an intravascular sensor.

[0103] In some implementations of FIG. 3, the continuous analyte sensor system 8 includes a DexCom G4® Platinum glucose sensor and transmitter, commercially available from DexCom, Inc., for continuously monitoring a host's glucose level.

[0104] FIG. 4 illustrates one embodiment of an electronic device 200 configured for use with the present systems and methods. Electronic device 200 includes a display 202 and one or more input / output (I / O) devices, such as one or more buttons 204 and / or switches 206 that, when activated or clicked, perform one or more functions. In the illustrated embodiment, which also functions as an I / O device, electronic device 200 is a smartphone, and display 202 includes a touchscreen that also functions as an I / O device. In other embodiments, electronic device 200 may comprise a device or devices other than a smartphone, such as a receiver for a CGM system, a smartwatch, a tablet computer, a mini-tablet computer, a handheld personal digital assistant (PDA), a game console, a multimedia player, a wearable device such as those described above, a screen in an automobile or other vehicle, etc. While electronic device 200 is illustrated in the figure as a smartphone, electronic device 200 may be any of the other electronic devices incorporating any or all of the functionality of the devices mentioned herein and / or other electronic devices, including those in which some or all of the functionality is embodied on a remote server.

[0105] 5 is a block diagram of the electronic device 200 shown in FIG. 4 and illustrates functional components of the electronic device 200 according to some embodiments. The electronic device 200 includes a display device 202 and one or more input / output ("I / O") device(s) 204, 206, as described above with respect to FIG. 4. The display device 202 may be any device capable of displaying output, such as an LCD or LED screen, and others. The input / output (I / O) devices 202, 204, 206 may include, for example, a keyboard (not shown), one or more buttons 204, one or more switches 206, etc. In embodiments including a touchscreen, the display device 202 also functions as an I / O device.

[0106] The electronic device 200 further includes a processor 208 (also referred to as a central processing unit (CPU)), memory 210, a storage device 212, a transceiver 214, and may include other components or devices (not shown). The memory 210 is coupled to the processor 208 via a system bus or a local memory bus 216. The processor 208 may be or include one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), etc., or a combination of such hardware-based devices.

[0107] The memory 210 provides the processor 208 with access, at execution time, to data and program information stored in the memory 210. Typically, the memory 210 includes random access memory (RAM) circuitry, read-only memory (ROM), flash memory, or a combination of such devices.

[0108] Storage device 212 may comprise one or more internal and / or external mass storage devices, which may be or include any conventional medium for storing large amounts of data in a non-volatile manner. For example, storage device 212 may include conventional magnetic disks, optical disks, magneto-optical (MO) storage, flash-based storage devices, or any other type of non-volatile storage device suitable for storing structured or unstructured data. Storage device 212 may also comprise storage in the "cloud," using so-called cloud computing. Cloud computing refers to computer functionality that provides an abstraction between computing resources and their underlying technological structures (e.g., servers, storage devices, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly configured and made publicly available with minimal administrative effort or service provider interaction.

[0109] Electronic device 200 may perform various processes, such as, for example, data correlation, pattern analysis, and other processes. In some embodiments, electronic device 200 may perform such processes autonomously. Alternatively, such processes may be performed by one or more other devices, such as one or more cloud-based processors 22 described above. In further embodiments, these processes may be performed partly by electronic device 200 and partly by other devices. Various example processes are described herein with respect to electronic device 200. It should be understood that these example processes are not limited to being performed by electronic device 200 alone. Furthermore, as used herein, the term "electronic device" should be interpreted to include other devices with which electronic device 200 interacts, such as one or more cloud-based processors, servers, etc.

[0110] The electronic device 200 also includes other devices / interfaces for performing various functions, for example, the electronic device 200 includes a camera (not shown).

[0111] The transceiver 214 allows the electronic device 200 to communicate with other computer systems, storage devices, and other devices over a network. While the illustrated embodiment includes the transceiver 214, in alternative embodiments, a separate transmitter and a separate receiver may be substituted for the transceiver 214.

[0112] In some embodiments, processor 208 may execute various applications, such as a CGM application that may be downloaded to electronic device 200 over the internet and / or a cellular network. Data for the various applications may be shared between electronic device 200 and one or more other devices / systems and may be stored by storage device 212 and / or on one or more other devices / systems. This CGM application may include an urgency assessment module and / or may include processing sufficient to operate the urgency assessment functions and methods described below.

[0113] In one particular embodiment of this embodiment, the sensor 10 of the continuous analyte sensor system 8 of FIG. 3 is inserted into the host's skin. A new sensor session is then initiated with the sensor 10, the sensor electronics 12, and the electronic device 200. A number of techniques can be used to initialize the sensor 10. For example, initialization can be triggered when the sensor electronics 12 engages the sensor 10. In another example, initialization can be triggered by a mechanical switch, such as a switch (not shown) on a snap-on base that receives the sensor electronics 12. The switch is automatically activated when the sensor electronics 12 snaps into the base. In another example, initialization can be menu-driven, and the user can be prompted by a user interface on the display 202 of the electronic device 200 to initiate initialization by making a selection on the user interface, for example, by pressing a button or touching a designated area on the display 202 (which may include a touchscreen). In another example involving a non-invasive sensor applied to the wearer's skin, the sensor 10 can sense contact with the skin and automatically activate. Additionally, the analyte sensor system 8 may detect the use of a new sensor 10 using any of the techniques described above, automatically prompt the user to confirm the new sensor session by means of a prompt on the user interface of the system 8, and initiate initialization in response to the user's confirmation in response to the prompt. Additional examples of initialization of the sensor 10 can be found in U.S. patent application Ser. No. 13 / 796,185, filed Mar. 12, 2013, the entire disclosure of which is incorporated herein by reference.

[0114] FIG. 6 illustrates an example logic diagram of a continuous analyte monitoring system 100, specifically illustrating the components involved in determining and calculating sensor results and determining urgency based on those results and other factors. Specifically, measurements from the sensor 10 are processed by the sensor electronics 12 and transmitted to a mobile device 18, typically a smartphone. While a smartphone is described here, it is understood that any of the various electronic devices discussed above can be used to receive and display sensor or other data and output results, as well as alerts and alarms based thereon. Furthermore, a smartphone (or similar smartphone-capable device) can transmit displayed notifications, results, alerts, and alarms to various devices coupled to it, for example, via Bluetooth®. Such devices include head-mounted displays such as Google Glass®, watches, and the like.

[0115] The mobile device 18 executes a CGM application 209, which provides various monitoring and display functions based on signals received from the sensor electronics 12. As part of this CGM application, a GUI assessment module 211 (also a processor module) is provided for implementing the urgency assessment functions described herein. While an assessment module is described, it is understood that such assessment module may be replaced by functionality appropriate to implement the methods described herein.

[0116] The mobile device 18 includes a display device 202 for displaying notifications, results, and warnings / alarms. While the display device 202 is described as a display screen and thus generally depicts results visually, it is understood that notifications, outputs, results, and even warnings / alarms in urgent cases may be communicated using other means, such as audibly. The same may be communicated as an audible version of the displayed letters or numbers. Alternatively, a beep or other sound, even a song or ringtone, may be provided to the user as a separate indication of the user's blood glucose level.

[0117] The mobile device 18 may further include memory 210 or storage 212 for retrieval and use of historical data, including user-entered data, as described in further detail below. Because the mobile device 18 may be in network communication with various servers, historical data may also be retrieved from a network server 222. In addition to historical data, the server (or other network source) may also provide other external data that may be involved in the decisions that lead to the notifications presented on the display device 202.

[0118] The display device 202 may itself provide an interface for a user to input data, for example using a touchscreen interface, or data may also be input via buttons and switches 204 and 206, respectively. In some smartphones, and in many other computing devices, a separate keyboard may be used for the same purpose.

[0119] Signal processing can occur using sensor electronics 12, using mobile device 18, or using a combination of the two. Signal processing can also be performed in the cloud, for example, on server 222 or other network source. In many cases, however, initial processing of the raw sensor signals, such as calibration, smoothing, or filtering, is performed by sensor electronics 12, and an application on mobile device 18 converts the signals received from sensor electronics 12 into a GUI, which is then shown on display device 202.

[0120] 7 illustrates how a measured blood glucose level may be combined with other parameters or variables to result in a calculated or otherwise determined GUI value 252, which is then presented on the display screen of the mobile device and which may be the basis for an alert and / or warning. The calculation or determination is performed by the urgency assessment module 211 on the mobile device 18, but may be determined in whole or in part by the server 222, or even possibly by the sensor electronics 12. It is understood that not all parameters and variables may be involved in all implementations of the determination of the GUI value 252.

[0121] Various parameters and variables are described, followed by examples of how they can be combined to yield GUI values ​​upon which presented notifications and / or alerts or warnings can be based to achieve the benefits and advantages described above. Without intending to limit the scope of the arrangements in any way, it is believed that particularly useful combinations include combining the current glucose value or a glucose value with the first derivative of the glucose value with respect to time. However, as will be understood by those skilled in the art given the present teachings, numerous combinations are useful, and therefore the scope of the present invention is not limited by the specific examples. Furthermore, while a single calculated or determined value of GUI 252 may be used in various implementations, it will also be understood that multiple values ​​related to glycemic risk or urgency may be calculated or determined and used in combination to activate an alert or warning, e.g., GUI1 = GUI1 (parameter, variable), GUI2 = GUI2 (parameter, variable), etc., or indeed in the general presentation of results to the user. Where the combined GUIs can be said to define a glycemic emergency, this is the basis for the alert and / or warning.

[0122] In FIG. 7 , GUI 252 is illustrated based at least on data 254 corresponding to a current measured glucose value, and / or data 256 corresponding to previously measured glucose values, and / or data 258 not directly related to the measured glucose value and therefore referred to as “external data.” Data 254 is generally the current measured glucose value, measured, for example, in mg / dL. Data 256 corresponds to previously measured glucose values, which may be separated into data 262 referred to as “recent” measured glucose data and data 264 referred to as “older” measured glucose data. Recent data 262 may have been measured minutes or hours prior to the current measured glucose data 254 and may therefore be particularly useful in analyzing current trends. Older data 264 may have been measured days, weeks, months, or even years prior to the current measurement and may therefore be particularly useful in calculating or determining overall patterns or trends (data 262 may also be used in this determination).

[0123] The current measured glucose data 254 and the most recently measured glucose data 262 may be used to calculate other types of data 266 based on current trends. For example, they may be used to calculate data 268 corresponding to the rate of change of the glucose data over time, such as a first derivative with respect to time, a second derivative with respect to time, etc.

[0124] Data 258 may correspond to past or current user indications, for example, how the user is feeling, what the user has eaten, etc. Thus, data 258 may be indirectly correlated with glucose levels, but is not directly based on measured glucose values ​​in a functional sense. Data 258 may also constitute a number of other variables, as described below.

[0125] Various parameters and variables based on the above types of data are described below. Again, it is noted that the determination of a GUI in a particular implementation need not include all of the various types of data described, and will often include only two or three types of data. Furthermore, as the following description is merely exemplary, types of data other than those described below may also be used. Specifically, the calculation of the GUI may be performed by an algorithm on the mobile device, for example, as described above, and the algorithm may take into account several or multiple variables in its determination of the GUI. While these variables are evaluated algorithmically simultaneously or near simultaneously, the description below will partially consider the influence of the variables on each other and on the determined GUI over time. In the context of a user interface for an electronic device such as a smartphone, the calculated GUI may result in a notification presented on the user interface of the mobile device, which may in some cases further result in an “actionable alert” (or alarm) that is displayed to the user and suggests one or more operations to be performed. In some implementations, the notification seen by the user may simply be an indication of the user's status, for example, that the user has a normal GUI. In other cases, the indication may be of a warning or alarm condition, for example, by the screen appearing in red, which may therefore imply that some action must be taken. By unlocking the mobile device, performing a "swipe" action, or otherwise "drilling down" to the data underlying the existence of the warning or alarm condition, the user can see the unambiguous action to be taken. Additional details of such user interfaces are described below in connection with Figures 16-29.

[0126] The first type of data that may be used, and which will be relevant in most implementations, is the measured glucose value. This first type of data may be in a numerical form with units in mg / dL or other formats, or may be processed or converted to obtain another type of data that generally correlates with a glucose value. In some cases, the first type of data may be used in its raw form as received from the sensor electronics without significant processing, and / or may also be processed by the sensor electronics. If desired, processing may then occur on a mobile device (or other device) running the urgency assessment module or an associated application to determine the GUI. The first type of data may further be received from an intermediate module or variant (e.g., from another application running on a smartphone). Generally, this first type of data may be processed, for example, to calibrate, smooth, filter, or otherwise "clean up" the signal representing the data.

[0127] While generally, a current measured glucose value is used, it is understood that the first type of data may also include one or more past glucose values, or even future glucose values ​​determined by a predictive algorithm, additional details of which are discussed below.

[0128] In determining the GUI, all other factors being equal, high glucose levels tend to shift the GUI value toward more urgent values ​​indicative of a hyperglycemic state. Conversely, low glucose levels tend to shift the GUI value toward more urgent values, again indicative of a hypoglycemic state. Moderate glucose levels tend to shift the GUI value toward values ​​indicative of a euglycemic state. In a very limited example, a euglycemic state may be associated with a GUI of 0, an extremely hypoglycemic state may be associated with a GUI of -5, and an extremely hyperglycemic state may be associated with a GUI of +5. Of course, numerous other schemes can also be understood and used given the present teachings. While 0 to 5 is illustrated, with positive and negative values ​​representing hyperglycemic risk versus hypoglycemic risk, the risk index can be agnostic to hyperglycemic risk versus hypoglycemic risk, e.g., simply 0 to 5, with 0 representing no risk and 5 representing the highest risk (whether hypoglycemic or hyperglycemic). The index may be qualitatively categorized into risk buckets, e.g., "no risk," "low risk," "medium risk," "high risk," etc. Other quantitative or qualitative risk indices may be envisioned as will be understood by those skilled in the art who understand that risk indices do not necessarily correlate with glycemic status, but rather with the urgency of clinical treatment to avoid a dangerous glycemic state. Time information, such as time to the next urgency index or time to a particular glycemic state, may also be provided.

[0129] Other types of data may be based on this first type of data; for example, the first derivative of the glucose value with respect to time may be used to determine the rate of change of the glucose value over time, i.e., the "velocity" of the glucose value, i.e., whether the glucose value is rising or falling and how quickly such a change is occurring. Accordingly, data values ​​representing the first derivative may be used in initial estimates of future glucose value predictions and also in determining the GUI. For example, a user with a high glucose value may start with a GUI value of 5, but a negative first derivative may reduce the GUI to 3. Furthermore, the direction and amplitude of the first derivative may be used to determine the weight of the same information in determining the GUI.

[0130] In particular, first and higher derivatives of glucose values ​​with respect to time require a certain amount of historical data to be stored and used in the calculations. Such data is generally based on recent historical data, although, as described below, it will be understood that older historical data can also be used and may also provide useful information regarding user patterns, which may be analyzed theoretically or, for example, with respect to time of day.

[0131] Another type of data that can be based on the glucose value and its first derivative at that point is the second derivative of the glucose value with respect to time, i.e., acceleration. Such data provides information about the rate at which changes in glucose levels are occurring and can often be used advantageously to determine to what extent changes in glucose levels will stabilize or result in deviations from desired values.

[0132] In the above example, if the glucose value itself results in a GUI of 5 and the first derivative moderates this to 3, the second derivative can be used to either increase the GUI (if the second derivative indicates that this decrease will "turn around" soon) or further decrease the GUI (if the second derivative indicates that this decrease will accelerate). In some cases, the second derivative can indicate that the user is not only heading towards normoglycemia, but also that the user may be entering a hypoglycemic state, e.g., the GUI may go to 0 but return to a low, medium, or high GUI as needed.

[0133] In some implementations, the determination of a glycemic emergency state or an index indicative of such a state may be based, at least in part, on a measured glucose value and a first or second derivative with respect to time of the measured glucose value, or both. Such implementations allow a high degree of confidence that an activated alert or alarm actually results in a situation requiring user (or other) intervention, with minimal warnings or alarms in situations that are likely to be resolved without user intervention. In some implementations, the calculation of a glycemic emergency state or index may be based on the above factors in combination with other factors described below. For example, a glucose value combined with another type of data based on the glucose value, such as a time derivative, may be used in combination with duration data (discussed below) to determine when a glycemic urgency index has reached a point requiring user intervention. Similarly, a glucose value and / or a time derivative may be used in combination with food intake data to determine whether to activate an alert; for example, if a user has a low glucose value but has just eaten a snack bar, the alert may be suppressed (all other aspects being equal). Insulin data may be used similarly. Other example combinations are described below.

[0134] It is noted here that the concept of alert suppression is used to indicate that an alert condition has been reached but this is not indicated to the user due to various other factors. However, it will be apparent that in other implementations the concept of suppression can be replaced by simply recalculating the variable on which the alert or alert is based, e.g., the GUI, and then basing the alert or alert on the recalculated value.

[0135] Returning to the types of data based on glucose values, such may further include higher order derivatives with respect to time, glucose output record graphs over a period of time, the level and duration of the last significant glucose value excursion, e.g., the level of the last glucose peak, etc. For example, if a user has a GUI of 3, but the last significant glucose value excursion was large and of long duration, such a situation may tend to move the GUI upwards (e.g., to 4 or 5) in determining the GUI.

[0136] Another type of data related to the sensor and electronics that measure glucose levels, but not necessarily directly related to the glucose values ​​themselves, is accuracy, confidence level, and / or noise information in the glucose measurement. Specifically, glycemic urgency indicators are only as accurate as the underlying data processed. Therefore, GUIs and the like can be made more reliable by including accuracy information for certain available inputs, and in some cases, the urgency assessment module can determine how much weight to give to certain inputs based on the accuracy information. Alternatively, ranges (instead of single numbers) can be displayed for various outputs to indicate that those outputs are subject to some uncertainty. Accuracy information can take various forms, including, for example, noise level, confidence level, percentage, number, or category. A particularly important quantity in this regard is the quality of the sensor signal itself, including aspects related to the glucose data, signal quality, error, and confidence level.

[0137] For example, if the GUI value is only mildly high at 5, and the sensor data calls into question the accuracy and confidence in the sensor value, such a situation may tend to raise the GUI value to provide the most conservative and safe measurement for the user. If the situation persists, an appropriate warning may be provided to reset the sensor or electronics, etc.

[0138] Such data is generally available using data from the sensor and associated sensor electronics or from analysis of the signal itself. Further details regarding accuracy, confidence level, and noise information in analyte measurements and the processing of such are disclosed in U.S. patent application Ser. No. 12 / 258,345, filed Oct. 24, 2008, entitled SYSTEMS AND METHODS FOR PROCESSING SENSOR DATA, published as 2009 / 0192366 A1, which is incorporated herein by reference in its entirety.

[0139] A related type of data input to the urgency assessment module may be provided by the sensor electronics or processing circuitry or software on the mobile device (or server) and indicate the amount of processing performed on the glucose value signal and thus the value of the delay associated with the signal. Such processing may include the amount of calibration, filtering, smoothing, etc. The more processing of the signal, the more delay is created in the signal. Therefore, if a large amount of processing is performed or required on the signal, or if the processing is delayed for some reason, the signal will have more delay, and it can be assumed that this signal itself may be considered more important (or associated with a greater weight) in the urgency assessment module, since delayed signals may be significantly more difficult to resolve than non-delayed signals. Specifically, there is a higher likelihood of unidentified deviations from the last known value. Thus, for example, if the GUI value is 3 but a significant delay is determined, the GUI may cause an upward trend in the GUI determination for reasons similar to those for a low-accuracy signal situation. Similarly, such data is generally available from the sensor and associated sensor electronics. However, such data may also be determined from analysis of the raw signal data itself, for example, from the most recent value of the measured glucose concentration.

[0140] For other types of data that may be used in the calculation, glucose values ​​may be further processed to provide a predicted glucose value or range. Specifically, real-time glucose values ​​may be "time delayed" relative to the actual glucose value due to physiological and / or data processing reasons. For example, values ​​measured in blood as a result of a finger prick may not represent blood glucose in the brain contemporaneously with the measurement. Furthermore, data processing steps such as the calibration, smoothing, and filtering described above may introduce additional delays. To address both of these issues, a predicted glucose value may be determined using a predictive algorithm, which may then be provided to the urgency assessment module as an input in determining a glycemic urgency state or index. It is noted here again that the GUI is not the predicted glucose value itself, but rather an index related to the potential risk, danger, or urgency of the target user's glycemic state, which may provide an actionable warning based on the index value. In some cases, rather than a specific predicted value, a range of predicted values ​​may be determined, which may be used to determine the GUI. Finally, predictive algorithms may provide additional insight into a user's glycemic state, which may be useful in combination with other inputs described herein in determining glycemic urgency, even without the benefit of reducing the effect of delay.

[0141] Systems and methods according to this principle allow for an expansion of the prediction horizon beyond what was previously possible. For example, while some levels of prediction allow for the detection of hypoglycemic events occurring within a certain period of the future, the use of certain parameters and variables in the GUI determination can greatly expand the prediction horizon. Example prediction horizons can include 10 minutes, 20 minutes, 30 minutes, 45 minutes, 1 hour, 90 minutes, or even longer.

[0142] For example, if the GUI value is 3, but the predicted GUI value indicates that the user is heading towards a higher glycemic state, the GUI value may be raised, for example, to 4 or higher. Again, the GUI itself is not a glucose value, but glucose values ​​can affect the GUI.

[0143] The data for prediction is generally available through analysis of stored glucose values. Further details regarding prediction algorithms are disclosed in U.S. Patent Application No. 11 / 007,920, filed December 8, 2004, entitled "SIGNAL PROCESSING FOR CONTINUOUS ANALYTE SENSOR," which was granted on October 9, 2012 as U.S. Patent No. 8,282,549, and is incorporated herein by reference in its entirety.

[0144] The duration that a measured glucose level occupies a specified range is yet another type of data that can be used in the calculation, which can be determined by analysis of glucose values, particularly values ​​over time. The specified range can be arbitrarily defined but generally can indicate a particular emergency condition, e.g., high or low hyperglycemia, high or low hypoglycemia, or euglycemia.

[0145] To further address the issue of the prior lack of consideration of such duration, the time a user spends in the range corresponding to an emergency condition (or other ranges) can provide an important input to the urgency assessment module, as this time can correlate to the danger the user faced, particularly if the emergency condition is one of hypoglycemia or hyperglycemia. For example, if a user has a GUI of −3 (based on other factors) but the duration of a relatively low hypoglycemic event is significant, the GUI may be further reduced to −4 based on duration, as further downward excursions are significantly more likely and should increase the urgency. In using duration as a factor, the urgency assessment module may use the duration itself, or the time a particular emergency condition exceeded a threshold duration, or other relevant parameters as input. Such data is typically available through analysis of stored longitudinal glucose values. Additional details are discussed below in connection with Example 1.

[0146] Another type of data that may be used in the calculation or GUI determination corresponds to recent or past events, specifically large deviations from predicted or baseline glucose levels or GUIs. Specifically, a user who has recently experienced a significant excursion is generally more likely to have a significant current or future excursion. To address this issue, the urgency assessment module may take such prior past events into account in determining the GUI. For example, the level of the last glucose peak or its duration (measured as the time above or within a threshold level) may be used in the determination. The level and / or duration of the last significant excursion, or a deviation of glucose values ​​away from baseline (or otherwise predicted) values, may be used in the determination because these often indicate the user's current risk of a glycemic excursion and, specifically, are indicators of a higher likelihood of a future excursion or deviation. For example, if a determined GUI is 6 but the user has experienced many recent excursions or deviations, the GUI may be increased to 7. As a subset of this type of data, the "last hypo / hyperglycemic event" (including its level and duration) may be used in the determination. In either event, such data is generally available through analysis of stored glucose values.

[0147] Another type of data that can be used in determining the GUI uses older measured glucose values. In one instance, and as mentioned above, a pattern of glucose values ​​can be determined and used, for example, to indicate measured baseline values ​​where deviations that may constitute significant deviations from baseline values ​​exist. While pattern data is based in part on time or time of day, this is not necessarily the case. Specifically, users often follow very regular patterns based on eating, exercise, or other activities that occur at specific times that can be correlated to glucose levels. These can be advantageously used to determine whether deviations outside normal levels are predicted. As time solidifies the pattern, the determined GUI can be more predictive and confident, providing more useful feedback. The use of pattern data in the GUI algorithm addresses the issue of otherwise normal GUI values ​​triggering warnings or alarms, thus helping to avoid the problem of "alert fatigue." Of course, such pattern data is generally available through analysis of stored glucose values.

[0148] For example, a user may generally experience lower glucose values ​​in the morning than in the afternoon. The urgency assessment module can match this pattern and predict lower readings in the morning and higher readings in the afternoon. Similarly, a user may typically consume an oatmeal meal in the morning, thus causing a spike in the user's glucose levels. Rather than necessarily causing a warning or alert, the urgency assessment module may determine that such a meal at approximately the same time each morning constitutes a pattern and may suppress activation of the alert because this is simply deemed "normal" based on the GUI assessment. As noted above, "suppression" may simply be a recalculation of the GUI that results in not activating the alert. Thus, taking into account the patterned values ​​of the baseline results in the analysis of the spike not classifying it as a spike at all. Of course, other factors affect the calculation of the GUI, and these, in combination, may determine an urgent GUI and activate a warning or alert.

[0149] In the above situation, the sudden rise in glucose levels due to oatmeal may result in an increase in GUI away from euglycemic states in the absence of pattern information, but recognition of the pattern in determining the GUI may result in more accurate maintenance of that value.

[0150] While eating and sleeping are disclosed elsewhere herein, it is understood that patterns can be recognized or generated for other events, such as meetings, work, exercise, etc., and used in determining the GUI. Time information can be retrieved from any clock circuit or application, such as from a server or from a mobile device or sensor electronics. Patterns can be based on detected events occurring with any kind of periodicity, such as daily, weekly, or monthly periods. Such data is commonly available through analysis of stored glucose values, and various pattern recognition software applications can be advantageously used. In some cases, patterns can be detected, and the user can be prompted to determine whether a particular cause of the pattern exists, such as common meal times, exercise classes occurring at regular times, etc. Such prompting can be particularly useful when the urgency assessment module uses machine learning to determine a given user's daily or other periodic patterns or behaviors.

[0151] In this same manner, deviations from the recognized pattern may result in similar user input requests. For example, deviations may result in the urgency assessment module asking the user, "Did you do something different?" Such a question may allow for analysis and disambiguation of, for example, a missed bolus versus an insufficient bolus.

[0152] Such pattern data may even provide anticipated notifications or warnings. While user interface details for such notifications, warnings, and alerts are described in more detail below, it is noted here that pattern data may be used to suggest where a user's glucose level (or GUI) is headed based on past data. For example, the urgency assessment module may send a warning such as, "It's almost 2 PM, and we know you're often low at 2 PM. You should review X and take possible action Y," where X is a user-understandable variable such as glucose level, and Y is the appropriate action to take given the currently determined GUI.

[0153] It will also be understood that other types of data may be used in connection with deviations from a normal glucose pattern, but these are not necessarily time-based. Such situations may include when exercise (e.g., detected by movement or heart rate) is typically associated with a drop in glucose levels. A "normal glucose pattern" may be learned for a particular user using known pattern recognition algorithms. Deviations from such a normal pattern may then be defined and used as inputs to the GUI's determination. In some cases, an out-of-the-ordinary glycemic event may be a predictor of a higher-risk condition, due at least in part to the unexpectedness of the event, which may dictate a different type of output to the user, i.e., rendered on the display of the mobile device, or a different type of notification, warning, or alert output to the insulin delivery device, i.e., pump. In this way, the problem of processing patterns that are not time-based may be effectively addressed.

[0154] Other types of data based on glucose values, or glucose values ​​measured over time, will also be appreciated. For example, a glucose output record over a recent period, e.g., six hours, may be used to inform the current GUI calculation or decision.

[0155] Other types of data can be used in determining the GUI, and these are not based on glucose values. A first category of such data types is based on data from other sensors or sources or input by the user. For example, the data can be of a type that includes anthropometric data corresponding to body measurements, such as BMI or weight. Anthropometric data can be particularly important for type II diabetes patients, but may also have some impact for type I diabetes. In particular, for type II diabetes patients, changes in body measurements can have a significant impact on the determination of the GUI. For example, an improvement in a type II patient's BMI, all other aspects being equal, should generally lead to a better GUI. Anthropometric data measurements can be captured semi-automatically, for example, via a connected weight and height scale, or values ​​for such BMI calculations can be entered by the user at, for example, the user interface of a mobile device. Measurements can also be captured from other systems, including from the cloud. In this way, the problem of treating all users the same regardless of their anthropometric data can be effectively addressed and solved.

[0156] For example, all other factors being equal, a user may have a determined GUI of 6. If the user is obese, the GUI may be increased to 7 based on this factor because the urgency or risk to such an individual is greater than to an individual who is not obese.

[0157] Another type of data that can be used in determining the GUI is data regarding the user's activity level, specifically the amount of activity, the type of activity, and the duration of the activity (or a combination thereof). Specifically, quantifying the user's activity level can generally provide a greater understanding of glucose value trends. Activity information can be fed into determining the GUI and can be useful for presenting to users who wish to receive additional information regarding why their GUI has a particular value. Such information can also be used to determine what types of questions can be asked to assist the user in managing their diabetes.

[0158] For example, a user may have a determined GUI of 0, indicating a state of risk for euglycemia, but the first derivative of the glucose value may indicate that it is decreasing, potentially causing the GUI to decrease to -1. If the determined activity level indicates that the user has recently engaged in a significant amount of exercise, and the cause of the increase can be attributed to physical activity rather than an overdose of insulin, for example, the GUI of 0 may be maintained, particularly if the second derivative indicates that the glucose value will rise.

[0159] Activity level measurement may be via an accelerometer, GPS data, or even Wi-Fi data, which indicates location. In a specific implementation, the M7 chip in an iPhone® 5 smartphone uses a motion coprocessor, which enables the mobile device to, for example, count steps or, more generally, determine whether the user of the mobile device is stationary, walking, running, driving, etc. In another specific implementation, a third-party device such as FitBit® may be used. It is understood that such data, for example, the number of miles run, walked, or biked, can also be manually entered. Using such systems and methods according to this principle, problems related to hyperglycemic and hypoglycemic events caused by or coordinated with a user's activity level can be effectively addressed.

[0160] A related type of data is information about exercise, which is generally beneficial for diabetics and can help prevent hyperglycemia and hypoglycemia and assist in managing insulin delivery. However, exercise can sometimes have long-term effects on diabetes and can lead to severe hypoglycemia several hours later in certain users. Therefore, due to this long delay, it is sometimes difficult to identify exercise as the cause of hypoglycemia. If exercise can be accurately detected, for example, by using the measurement devices described above, predictive analytics can be used to predict when exercise may begin to affect glucose levels and therefore related risk conditions, such as the GUI. Exercise can be monitored using much the same types of devices used to monitor activity and can include parameters such as exercise duration, type of exercise, and amount of calories burned. It is understood that such data can also be entered manually.

[0161] A further related type of data corresponds to sleep information or status. Specifically, diabetic users are known to be more likely to experience unrecognized hypoglycemic events while asleep. Movement, or lack thereof, and other factors can be used to detect sleep and correspondingly assess risk. Other factors can include, for example, heart rate, user input, etc. Monitoring devices, such as mobile devices running an acuity assessment module, can be equipped with a user-installable "night mode" feature or module that can be used to assist in detecting sleep. Motion detection for such purposes can be implemented, for example, through the use of an accelerometer worn on the body, as described above. For example, a CGM sensor or transmitter can incorporate such an accelerometer or other motion detection circuitry. A phone or other motion detector placed adjacent to the user can also detect how frequently the user moves, indicating sleep. In some cases, a motion detector in an alarm device can be used to provide such information and data. Heart rate monitoring can measure changes in the user's heart rate. The user interface of the mobile device can also be used to assist in detecting sleep status. For example, if a user is not interacting with their mobile device at all, as determined by button presses, swipes, or other similar interactions, such a state may be associated with or consistent with a state of sleep, or this may be learned by an urgency assessment module associated with such a state. Conversely, if a user is interacting with their mobile device, it may be assumed that the user is not asleep.

[0162] In an embodiment according to this principle, if a user was not in a euglycemic state, for example, with a GUI of approximately 0, but is currently not moving and their heart rate is decreasing, it may be assumed that the user is asleep, and the urgency assessment module may therefore assess a higher risk that the user is experiencing an unaware hypoglycemic event. This risk may be factored into the GUI determination, for example, resulting in a more prominent warning or alarm, e.g., one corresponding to a GUI of (-)4 or (-)5. A mobile device running the urgency assessment module may be equipped with a "sleep mode" feature, and the user may activate such a feature when no assumptions regarding sleep or sleep detection are needed.

[0163] Such a "sleep mode," "night mode," or sleep detection functionality may provide several advantages in certain implementations. Specifically, by assessing a higher risk status for glycemic events during the night versus the day, the system understands that the user is likely unaware of their diabetes risk status and therefore glycemic events should be addressed differently. In this way, issues of user inattention during sleep, or excursive glucose values ​​encountered during sleep, can be effectively addressed.

[0164] Another category of data types that can be used in determining the GUI corresponds to physiological data. One such type of physiological data includes hydration information. Specifically, dehydration is often associated with high blood glucose levels. Therefore, this can be used to further inform the determination of the GUI. Hydration information can be received, for example, from a Tanita BC-1000 body composition monitor in combination with a Garmin® Connected System. It is understood that such data can also be manually input, at least at a qualitative level. As an example of determining the GUI using hydration, a user may have a determined GUI of 3, all other factors being equal. If the user becomes dehydrated, such a condition can push the GUI up to 4, indicating a higher likelihood of a hyperglycemic event. While sensor data is typically used to measure hydration, it can also be input by the user, at least qualitatively.

[0165] Another such type of physiological data includes heart rate information. Heart rate may indicate exercise or other factors, such as stress. If heart rate or changes in heart rate are due to exercise or other activity, the activity monitor described above can be used to quantify this. Alternatively, heart rate may be wirelessly communicated from a heart rate monitor or other application. In another implementation, heart rate may be manually entered by the user, using a displayed or quantified value, such as a "high heart rate," "normal heart rate," or the like, if the user is able to measure such.

[0166] Another such type of physiological data includes blood pressure information. Specifically, the vascular effects of diabetes tend to increase the risk of hypertension. Therefore, monitoring blood pressure can be useful and can be included as a factor in the GUI's decisions. Various body-worn blood pressure monitors are available that can communicate blood pressure data in a wired or wireless manner to a device running the aggression assessment module. Alternatively, a user can measure their own blood pressure and manually enter it into the device.

[0167] Further physiological data types include body temperature. Body temperature is often an indicator of illness, which in turn may affect diabetes risk status and therefore the GUI. For example, body temperature and / or underlying illness may result in a glycemic response to various inputs or treatments that differs from what would be expected in other users or from what would be expected historically from the same user.

[0168] This type of temperature data can be captured by incorporating a temperature sensor into a sensor patch or by using other such thermometers. This and other types of temperature monitors can be found in commonly owned U.S. patent application Ser. No. 13 / 747,746, filed Jan. 23, 2013, entitled "DEVICES, SYSTEMS, AND METHODS TO COMPENSATE FOR EFFECTS OF TEMPERATURE ON IMPLANTABLE SENSOR," published as U.S. Patent Application No. 2014 / 0005508A1, and incorporated herein by reference in its entirety. Temperature information can also be manually entered, either qualitatively or quantitatively.

[0169] To illustrate the above-mentioned parameters or variables, a user with a determined GUI of 3 (without heart rate, blood pressure, or temperature input) may be determined to have a GUI of 4 if the user's heart rate, blood pressure, or temperature is particularly high, thus indicating a higher urgency related to the glycemic state. Using such systems and methods according to this principle, the problem of glucose monitoring for users lacking consideration of the refinement of such parameters or variables can be effectively addressed.

[0170] The level of user interaction with the monitor was mentioned above in connection with determining or detecting sleep states. Such a level of interaction, at least with respect to the level of user interaction with the user's glucose monitor, can generally be used to determine the user's desired level of managing or being notified about their diabetes. Specifically, the level at which the user interacts with their CGM, e.g., a mobile device running an application whose GUI is determined by the urgency assessment module, can be used as a factor in determining the GUI. For example, a high level of user interaction can indicate a strong awareness of the user's glycemic state and correspondingly result in a lower risk. Conversely, a low level of user interaction can indicate a low awareness or even no awareness of the glycemic state and correspondingly result in a higher risk assessment and therefore the GUI, particularly if the glucose is on the "borderline" of normal blood glucose levels and this input (distance from the target range) can be included in the GUI determination. Such a level of user interaction can be measured by the amount of time the screen is powered on, the number of buttons pressed or swiped, orientation determined by an accelerometer, etc. However, it should be noted that such data may be modified or informed by user pattern data in various ways. For example, pattern data may indicate that a user does not use their mobile device after 8:00 p.m. In this case, the user may not be considered a "low-aware" user based on the user's lack of interaction with the device late at night, but rather simply be associated with a pattern. However, if the same user generally interacts with their device frequently during the day but suddenly stops interacting for an extended period in the afternoon, such a case may increase the urgency assessment because it may be assumed that the user is unaware of their current glycemic risk state.

[0171] For example, a user at risk for hyperglycemia may be alerted to this and a decision may be made to treat the condition appropriately, e.g., by analysis of one or more temporal rates of change of glucose values. If the user interacts with the electronic device, e.g., a mobile device, a lot, the GUI may maintain the current value with an appropriate subsequent alert (which may be absent). If the user interacts with the monitoring device less than usual, the GUI may trend upward, resulting in an additional alert (or increased visibility of the GUI on the user interface) to gain the user's awareness.

[0172] Using such monitoring device user interface data, the problem of treating patients with different usage habits of their monitoring devices can be effectively addressed. Usage-related data is typically obtained using the operating system of the monitoring device, e.g., a mobile device.

[0173] Similar types of data, context and behavioral information can be used in determining the GUI. Specifically, such information can correspond to how a patient uses their mobile device, thus providing context for specific data determined by the device. Behavioral input information can be obtained through the system and can include data regarding the amount of interaction, glucose alert / alarm status, sensor data, number of screen taps, alert analysis, events (e.g., characteristics associated with user response, time to respond, glycemic control associated with response, user feedback associated with the alert, not acknowledging alert / alarm within X minutes, time to acknowledge alert / alarm, duration of alert state, etc.), diabetes management data (e.g., CGM data, insulin pump data, insulin sensitivity, patterns, activity data, calorie data), fatty acids, heart rate during exercise, IgG-antigliadin, stress level (sweat / perspiration) from a skin patch sensor, free amino acids, troponin, ketones, adipanectin, sweat, body temperature, etc. Input can be provided by sensors in data communication with the monitoring device. In some implementations, information can be obtained through an intermediary, such as a remote data storage device.

[0174] Contextual information that may be provided as input to the GUI's decisions includes human biology, location, ambient sensations (e.g., light, sound levels), and environmental data (e.g., weather, temperature, humidity, barometric pressure). Input may be received over a mesh network via peer-to-peer or machine-to-machine communications. Contextual information may include daily routine information (which may vary, particularly between weekdays and weekends) from a calendar application. Contextual information may include how often the monitoring device is touched or grabbed, even without interaction, based on sensed movement of the device.

[0175] The photograph can provide contextual information. For example, a photograph of one or more of a glucose meter reading, an insulin pen or pump IOB, a location (e.g., a gym, a park, a home, an Italian restaurant), or a meal can be used to provide contextual information. The photograph can be processed, for example, to identify the calorie intake of the meal shown in the photograph. The type of insulin used can also be provided to the monitoring system as a useful input to the GUI's determination. Context can also be provided by basal or bolus settings provided to or determined by the monitoring device.

[0176] Other inputs to the GUI's determination that constitute contextual / behavioral data may include data types mentioned elsewhere that are not contextual / behavioral inputs, such as exercise information from a stationary bike, glucose sensor information from a blood glucose (BG) meter or CGM, insulin delivery from an insulin delivery device, results of the device's residual insulin calculations, and other device-provided or calculated information. Other contextual / behavioral data inputs to the GUI's determination may include hydration level, heart rate, target heart rate, internal temperature, external temperature, external humidity, body analytes, hydration input, power output (cycling), sweat rate, cadence, and adrenaline level, stress, medical condition / disease, metabolic rate / calorie burn rate, lipolysis rate, current weight, BMI, desired weight, daily calorie (consumed) goal, daily calorie (expanded) goal, location, favorite foods, and level of effort.

[0177] For any of the behavioral or contextual inputs mentioned above, the system can be configured to receive and / or generate analytical indices based on the inputs. For example, a composite value can be generated based on the glucose level, temperature, and time of day data generated for the user's index value. The composite value can then be taken into account in determining the GUI.

[0178] This information may be collected from various on-device or off-device sensors, such as accelerometers, GPS, camera data, etc., and tracking applications, including third-party sleep cycle applications. For example, such tracking applications may use geolocation information to determine context and behavior. Additionally, context and behavior may also be determined through the use of social networking information available about the user, where social networking feeds associated with the user are arranged to provide a source of data to the urgency assessment module and / or provide output to the urgency assessment module.

[0179] Using such systems and methods according to this principle, the problem of lack of consideration of such context / behavioral aspects can be effectively addressed. Additional details regarding context and behavioral information can be found in U.S. Patent Application No. N61 / 898,300, filed October 31, 2013, entitled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES," owned by the present applicant, specifically in Figure 4 and the accompanying text, which is incorporated herein by reference in its entirety.

[0180] Other types of data that may be used in determining the GUI include information regarding foods and beverages ingested and insulin. Variables or parameters appropriate for these types of data may include information regarding their amounts, their types, and the time and duration they were received.

[0181] If food and beverages are consumed at a meal, such data can be captured by several means, such as by the user manually entering food and beverage information into the device; on a spreadsheet, for example; using the camera on the mobile device to capture a photo of the meal; or by data input from a third-party food application that may allow, for example, meal items at a given restaurant (with data already entered into the application) to be "checked off" as they are consumed and entered into the decision. In some cases, the user may be prompted for such information if, for example, the device detects a spike in glucose levels. Meal data may even be assumed (requiring confirmation by the user) by using GPS or social networking data that indicates proximity to or "checked in" to a known favorite restaurant. The user may be prompted to confirm that they have ordered their "regular meal," which may then automatically populate the food data with the meal's parameters, or if the user deviates from their usual choices, the prompt may provide an opportunity to enter other food choices. Generally, dietary data may be provided along with details such as amount ingested, time of ingestion, and other dietary data that allow for the determination of clinically significant GUI. Using such information, problems currently encountered in diabetes treatment based on the lack of such factors (and other factors) may be effectively addressed.

[0182] In one example of using meal data in determining the GUI, a user who is in a mildly hypoglycemic state may have a GUI of -2. If the user eats a meal with significant carbohydrate and / or sugar intake, the GUI may be modified to -1 to reflect the fact that the user's urgency assessment has been modified. It is further noted that the modification may occur immediately after notification that the user has eaten the meal, well before a change in blood glucose level is seen.

[0183] Another variable or parameter that may be factored into the GUI's determination is insulin level. Data may be provided directly from an integrated insulin pump or from a cloud-based EMR. Such data may include information about the amount of residual insulin, insulin sensitivity, and past, current, and future planned basal and bolus levels. Data may be obtained through sensor data or other electronically communicated data, or may be provided by user input. One type of information that may be obtained from this data includes the time between the insulin bolus and the meal peak, which may be determined using insulin and glucose information.

[0184] For example, a user in a hyperglycemic state may have a GUI of 3. If the user injects a bolus of insulin, the GUI may be modified to 1 to reflect the fact that the user's urgency assessment has been modified. In systems and methods according to this principle, the modification may occur immediately after notification that the user has injected a bolus, well before a change in blood glucose level is detected. Using such insulin data, problems encountered previously in diabetes management, such as the lack of immediate updates of risk status based on user-entered data regarding food intake, may be effectively addressed.

[0185] Another type of data that may be used in determining the GUI corresponds to stress levels. Specifically, stress is known to affect diabetes and therefore the user's risk status. In some cases, such data may be provided via sensors, but often is captured by asking the user to select from a variety of emotional icons or other indications of emotion. Such data may also be inferred from other sources, such as by analyzing events related to the user's calendar or other regularly scheduled activities, such as work, exercise, family time, etc. Stress data may also include information regarding the amount of stress, the type of stress, and how long the stress lasted.

[0186] A related type of data that can be used in determining the GUI corresponds to current health, which may overlap with current emotional state. Such measurements may be captured manually via the device, including through the use of the same type of emotional icon for stress mentioned above, or may be captured from cloud information. Current health and emotions, as well as anthropometric data, are known to have a significant impact on glucose control, particularly type 2 glucose control and insulin resistance. Health data may include information about current illnesses, the severity of the illness, how long the user has had the illness, etc.

[0187] For example, a user with an otherwise non-threatening GUI may have their GUI elevated if they are currently experiencing significant levels of stress or poor health. Such an elevation would reflect the fact that these factors are known to adversely increase or decrease blood glucose levels. Using such data types, previously seen problems related to a user's current stress or lack of health considerations can be effectively addressed.

[0188] Demographic data such as age or gender may also be used. Specifically, demographic data may be collected from online stores, networks, or crowdsources, or may be manually entered into the device, and such data may provide useful information in determining the GUI. For example, it is known that pediatric users tend to have faster and higher blood glucose fluctuations. As another example, it is believed that a user's risk status may be higher for a particular blood glucose excursion, especially in older users and users with type II diabetes, compared to a younger user with the same blood glucose excursion.

[0189] In certain examples, pediatric users with an otherwise calculated GUI of elevated risk status, e.g., 3, may have their risk status increased to 4 to reflect the pediatric user's tendency toward faster and higher blood glucose fluctuations.

[0190] Using such data, problems seen in the past with a lack of consideration of such factors can be effectively addressed.

[0191] Another factor that may be used in determining the GUI is sensor site location. Specifically, in some cases, the location or location of the CGM sensor may result in maintained specificity in blood glucose levels relative to that location. These specificities may be included as a factor in determining the GUI. While such data is typically manually entered by the user, historical data may be used to avoid such user input if such data is regular and therefore an unambiguous decision can be made. Additional details regarding the use of sensor site location can be found in commonly owned U.S. Patent Application No. 61 / 904,396, filed November 14, 2013, of this application, entitled "INDICATOR AND ANALYTICS FOR SENSOR INSERTION IN A CONTINUOUS ANALYTE MONITORING SYSTEM AND RELATED METHODS," which is incorporated herein by reference in its entirety.

[0192] Another factor that may be cited to influence the GUI's decision is the cause of the rise or fall in blood glucose levels, if known. It is noted that some changes in glucose levels are caused by stress, and others by food ingestion. Such data may be pre-processed or pre-associated prior to data entry into the urgency assessment module, or may be associated therein. For example, food data may be processed in combination with glucose levels to determine whether the rise in glucose resulted from food or another cause, such as stress. Using such data, problems previously seen with a lack of consideration of such causes and effects may be effectively addressed.

[0193] As noted above, glucose values ​​(and derivative data) may be weighted by the evaluation module based on signal quality, confidence level, etc. Such weighting is typically performed automatically by the electronic device based on analysis of signal data from the sensor electronics. However, any of the above variables or parameters may enter the GUI calculation in a weighted manner, with the weighting being performed automatically, for example, by signal analysis from underlying sensors, e.g., accelerometers, weight scales, etc., or by using manually entered data, for example, from a physician or patient. Using such data, problems seen in the past with a lack of consideration of such factors can be effectively addressed.

[0194] A summary of the types of data described is provided below in Table I. Note that certain parameters and variables may occur in more than one data category. [Table 1-1] [Table 1-2]

[0195] FIG. 8 illustrates a flowchart 40 illustrating the general use of the parameters and variables discussed above. In a first step, multiple inputs related to a disease, such as diabetes, are received, the inputs corresponding to variables or parameters, which may be measured, entered by a user, or otherwise obtained, for example, via the cloud or other source (step 272). A GUI is then calculated based on the received inputs (step 274). The GUI may be determined or calculated in several ways, as described below. The next step is to provide a display of the GUI, such as an output (step 276). Alternatively, or in combination, the state of the GUI may change, or a warning or alert may be provided if the GUI reaches a particular value or based on a threshold (step 278). Similarly, various types of advanced output (additional processing) or additional details regarding GUI processing (e.g., information regarding the inputs) may also be provided (step 282). In some implementations, the determined GUI may serve to activate an integrated pump for medication (step 275), as described in further detail below.

[0196] Several variations will be understood. For example, notifications, indications, alerts, or alarms, and advanced outputs may be provided to the patient or another user, e.g., a caregiver, physician, family member, etc. Generally, an indication or notification of the user's status is available and provided. Furthermore, in the case of an emergency, an alert or alarm may be provided to the user so that the user can take appropriate action. Furthermore, not all of these need be provided to the user in a given situation. In some cases, the user may simply wish to review the user interface of their mobile device to ascertain their status, in which case an indication is provided even if no alert, alarm, or advanced output occurs. In related cases, only the advanced output may be desired by the user. In other cases, when important information is an alert or alarm, the alert or alarm may be provided without providing a specific general indication of the status to avoid distracting the user. Other variations will also be understood.

[0197] Example 1 In one exemplary implementation, several inputs are used to determine the GUI, including at least: a) the glucose value (concentration), b) the velocity (amplitude and / or direction) of the glucose value, i.e., its rate of change, c) the acceleration (amplitude and / or direction) of the glucose concentration, and the duration of one or more of the above. For example, a first input may be the glucose value, a second input may be the derivative of the glucose value, and a third input may be the duration or other parameters or variables described. In this implementation, an initial notification based on the glucose value may be adjusted upward or downward and / or recalculated using the GUI function based on the derivative and / or duration of any input. For example, the glucose value may be low or high, but if the glucose value trends toward a desired intermediate value determined by the first derivative, the GUI may determine that there is no risk condition or a low risk condition, and the baseline warning may be suppressed. The warning may be further suppressed if the second derivative, as determined by the GUI, indicates that the glucose value is not rising or falling (or vice versa) in a manner that leads away from the intermediate value. In an alternative implementation, the suppression may be replaced by a recalculation of the GUI leading to no or low risk conditions.

[0198] Example 1 solves the problem that rate of change information alone (first derivative) cannot accurately predict when a "turnaround" event is about to occur, when glucose values ​​will resolve in the long term. By using acceleration information, "turnaround" events can be predicted more accurately to avoid overcorrection or false alarms.

[0199] In certain implementations, for example, at 0 mg / dL / min / min (no acceleration or deceleration detected), the urgency assessment module may rely only on the first and second inputs for determining the glycemic urgency index. However, at 1 or 2 mg / dL / min / min, the urgency assessment module may further rely on other inputs, including acceleration, to determine the type of "improvement" event and its predicted impact.

[0200] Example 2 In another example implementation, the first input is the same as in Example 1, the second input is the rate of rise or fall, and the third input is the acceleration. Other inputs, including other parameters and variables selected from Table I, may also be taken into account in determining the GUI.

[0201] Example 3 In yet another example implementation, the first input is the same as in Example 1, the second input is the rate or rate of change of the glucose value, and the third input is another parameter or variable selected from Table I.

[0202] Example 4 In yet another example implementation, the first input is the same as in Example 1, the second input is acceleration (which may or may not involve calculating velocity), and the third input is another parameter or variable selected from Table I.

[0203] In another specific implementation of the embodiment, and with reference to graph 50 of FIG. 9 , a trace 283 of glucose values ​​(applied to axis 289) and a trace 285 of GUI values ​​(applied to axis 291) are illustrated plotted against time axis 287. As can be seen, in region I, the user is initially hyperglycemic and has a GUI in the low to medium range. Another type of GUI is illustrated here, ranging from 0 (low urgency) to higher values ​​(indicating higher urgency). However, by considering the rate of change of glucose values ​​trending toward the target range, the GUI, and therefore the urgency assessment, may be lowered toward a "no urgency" zone or band. If the glucose value had a positive rather than negative rate of change, or an acceleration indicating a trend toward a higher value, the GUI would rise toward a more urgent assessment, even if the glucose value itself was decreasing.

[0204] In region II, glucose values ​​are seen to occupy a range 293 of hyperglycemic values ​​(e.g., 180-400 mg / dL) for a period of Δt1. If time Δt1 exceeds a defined threshold, as in the case of FIG. 9, such a situation may indicate why the GUI would rise, even if the user is only mildly hyperglycemic or has never experienced a further increase in the user's glucose values. Region II of FIG. 9 illustrates a hyperglycemic range, and it is understood that occupancy of a hypoglycemic range similarly raises the GUI value, particularly since the duration the user occupies the hypoglycemic range is related to the predicted further hypoglycemic excursion.

[0205] More specifically, the duration of the input may also be used by the urgency assessment module in determining the GUI. Specifically, the longer the duration of a hypoglycemic or hyperglycemic excursion, the greater the impact the excursion may have on the GUI. For example, a high glucose state (e.g., above 180 mg / dL) for two hours is more dangerous than a 20-minute period of the same high glucose level, at least in terms of long-term complications associated with diabetes. Furthermore, glucose levels become logarithmically more dangerous above 180 mg / dL. Similarly, a low glucose level (e.g., below 70 mg / dL) for two hours may be more dangerous than a 20-minute period of the same low glucose level, at least in terms of increasing the likelihood that small changes will easily put the user in a dangerously low state. In other words, the longer the time at a low glucose level, the greater the likelihood and likelihood of a drop to a dangerously low glucose level, e.g., below 55 mg / dL.

[0206] For example, by tracking the duration or amount of time spent below a threshold for a particular event or time, the glycemic emergency state or index can be effectively modified or refined to more accurately reflect the risk and clinical significance to the user.

[0207] Referring again to FIG. 9, region III indicates the beginning of the time when the user indicated (by entering data into the electronic device) a mitigating factor in the hyperglycemic event, e.g., the infusion of a bolus of insulin. For example, the user entered data indicating that a bolus was delivered, whether or not in response to a prompt by the urgency assessment module (an integrated pump may also provide such data). The urgency assessment module may immediately result in a decrease in the GUI, which may occur well before a decrease in glucose concentration is actually seen. In the case of FIG. 9, such a delay is indicated by time Δt2.

[0208] By considering parameters and variables beyond glucose value alone, and even beyond considering mere rises or falls in glucose values, notifications, including continuous notifications, alerts, and alarms, can be more finely tailored to a given user using systems and methods according to these principles, thus offering several advantages, including reduced nuisance alerts. For example, using the system described above, if the threshold is set at 70 but the user is 69 and rising, the previous system would continue to alert because the user is still below the threshold. Systems and methods according to the current principles recognize that the user has a rising glucose level and therefore does not need to be alerted in the first place. Even if the user was not measured when rising, but they had just eaten, systems and methods according to these principles may recognize based on the GUI that the user has a glucose level that will soon rise, thus avoiding a nuisance alert or alarm that would otherwise be triggered.

[0209] Region IV indicates an area where the glucose value is somehow noisy and therefore a low confidence level may be associated with this portion of the signal. Thus, the GUI may be viewed as elevated, recognizing that glucose values ​​with low confidence are associated with a higher or more urgent urgency assessment. A similar elevation in urgency assessment would occur if it was determined that a significant delay had occurred in the signal.

[0210] Region V illustrates another parameter or variable that may affect the determination of the GUI. Specifically, in Region V, it is assumed that the user has become more interactive with their mobile device, as determined by a significant number of key presses, touch screen activations, accelerometer-determined movements, etc. Therefore, because it is determined that the user is more interactive with their device and therefore more likely to see urgency assessment updates, alerts, and alarms, the GUI and urgency assessment may be reduced because the user is more likely to be able to take action quickly.

[0211] Area VI illustrates a situation where the predicted value 313 of the glucose level indicates an increase in the glucose level, such a prediction being calculated by a predictive analytics tool as described above. In this case, this may result in an increase in the GUI recognizing a predicted increase in blood glucose value. Such a prediction may also have the advantage of compensating for a delay in the glucose level.

[0212] Region VII illustrates another situation in which a rising glucose level does not necessarily require a significant increase in the urgency assessment based on the data entered by the user. Specifically, region VII indicates that the user is heading toward a mild hyperglycemic state. However, if the user has recently entered data indicating that they are about to engage in significant physical activity, such as exercise, the tendency toward a mild hyperglycemic state may be counteracted by the expected effects of exercise. Therefore, the GUI 285 for region VII does not need to be significantly increased.

[0213] Variations will be appreciated. For example, while GUI axis 291 is used in only one direction, the GUI axis may be used in two directions (not shown) to indicate hyperglycemic urgency and hypoglycemic urgency. While a single GUI axis 291 is used, in order to disambiguate the type of urgency and therefore provide a notification or actionable alert, the algorithm providing this is aware of the glucose value as well as other variables and parameters that make up the GUI's determination, so that the notification or actionable alert displayed takes into account whether the user is hyperglycemic or hypoglycemic.

[0214] Furthermore, while in some cases a user may view an output record 285 showing the GUI or may see a numerical index representing the GUI, it is understood that most notifications or actionable alerts provide an indication of the GUI by other means, such as through the use of color, icons, etc., as described in further detail below. In other words, many users do not need to see the GUI itself, but rather what the GUI represents.

[0215] While FIG. 9 is intended to summarize in a condensed manner several different types of variables and parameters and illustrate their influence on the determined GUI, it will be understood that in any given implementation, not all such parameters and variables need to be monitored or used in the determination.

[0216] 10 illustrates another graph 60 summarizing several different types of variables and parameters and showing their influence on the determined GUI. As with FIG. 9, not all such parameters and variables need to be monitored or used in the determination. Furthermore, the parameters and variables depicted in FIG. 9 may be combined in any manner with those depicted in FIG. 10.

[0217] In FIG. 10 , the time axis is divided into several different segments related to a typical day. Actual glucose concentration 295 is plotted overlaid with a determined or calculated pattern of glucose concentration 297 for a given user. Pattern glucose concentrations may be developed using past glucose values ​​and may be time-based or related, e.g., linked, to events such as meal intake, exercise, or an insulin bolus. Other patterns, including those that are not time-based, will also be understood. Two types of GUIs are also illustrated in FIG. 10 . A GUI 299 is shown that does not consider patterns. Specifically, GUI 299 may be based on glucose values ​​and other factors discussed above, such as the rate of change of glucose values, acceleration, etc., but is otherwise “absolute” in the sense of not being pattern-based. A GUI 301 that does take pattern 297 into account is also illustrated. Specifically, if a hyperglycemic or hypoglycemic event is recognized as part of a pattern, the GUI may not increase, i.e., the urgency assessment may remain the same or may only change slightly, recognizing the fact that the increase or decrease is part of an established pattern. For example, glucose may fall by XXX during dinner as shown in part V, which does not correlate with the host's normal glucose profile (pattern) and results in an elevation of the GUI (unless meal information is entered into the GUI).

[0218] 10 also illustrates deviations in glucose levels from established patterns, specifically, an atypical decrease 309 in glucose values ​​during sleep. As noted above, during sleep, hypoglycemic events often go undetected and are therefore particularly serious. Thus, in such situations, an increase 311 in the GUI can be used to increase the urgency assessment and warn or alert the user.

[0219] 11 shows a graph 70 illustrating the impact of a previous significant glucose excursion. Specifically, a significantly hyperglycemic event 303 is illustrated in the glucose concentration, and this appears to resolve over time in the graph 70. However, a subsequent rise 305 can be seen, and instead of simply resulting in a gradual increase in the GUI, the subsequent rise 305 may result in a sudden rise 307 in the GUI, as it can be assumed that the previous significantly hyperglycemic excursion may repeat itself (a rebound). Thus, the urgency assessment is superior to simply being based on glucose values ​​alone.

[0220] Other examples will also be appreciated. For example, a user who would otherwise have a "low risk" urgency rating based, for example, on glucose value and rate of change, may be given a higher risk urgency rating if they are overweight or have a high BMI, high blood pressure, high stress, are dehydrated, etc. Aspects such as body temperature, anthropometric data, and illness, as well as demographic data, may further modify the GUI, as may contextual and behavioral information. Sensor location may also modify the determined GUI. For example, a user may have a low GUI and therefore a low risk urgency rating, but if the sensor location is such that a significant delay in the glucose value is predicted, the GUI and urgency rating may be elevated to reflect a lack of confidence in the current measured glucose level.

[0221] Using the principles described above, a glycemic risk state in the form of a glycemic urgency index can be calculated based on input parameters and variables using mathematical techniques. The output can be one of several predefined glycemic states, or the output can be qualitative or quantitative, for example, in terms of a percentage or number. For example, the output can be GUI=1, 2, 3, etc., or where such numbers are converted into terms that can be more easily understood by the user. The output can be further categorized as hypoglycemia / hyperglycemia / euglycemia, etc., or current or predicted, regular or irregular, etc., or by other means that may be particularly useful to a given user. Names and labels can be applied, including indicators of real-time events that affect the state, such as "exercise-induced," "improvement," "long duration," etc.

[0222] Other user interfaces may provide further details about specific glycemic risk states.

[0223] For example, if a user's glucose level remains below a specified threshold for more than 15-20 minutes, even after ingesting carbohydrates, such a status may be provided on the device's user interface, thus making the user aware of the significant duration for which low glucose levels have been ineffectively treated.

[0224] As another example, a user's glucose value may be above a specified threshold but is expected to decrease in the near future, in which case predicted glucose values ​​over, say, a 20 minute prediction range would provide the user with a useful and actionable alert, allowing for an unambiguous action (or actions) to be taken.

[0225] In another example, a user's glucose level may exceed a specified threshold for an extended period of time, in which case an indication of how long the user has been above the threshold can help alert the user to the seriousness of the situation.

[0226] In yet another example, if a user's glucose level exceeds a defined threshold for an extended period of time and fails to decrease, then indicating the duration of the elevated levels and a percentage indicative of the lack of return to normoglycemia provides the user with critical and actionable information.

[0227] Analysis Framework Several mathematical frameworks and inputs can be used to determine a user's risk status for hypoglycemia and hyperglycemia. One example of how to estimate a user's risk status is described below, which uses parameters and variables including current glucose level, current glucose rate of change, and glucose change direction to provide a risk value. In one specific implementation of a system and method according to this principle, glucose acceleration and duration of time spent in a hypoglycemic or hyperglycemic state are added as inputs to arrive at a GUI.

[0228] Previously, static and dynamic risk functions have been proposed, which are mathematical models that map glucose levels and glucose variability to risk functions (e.g., 0 to 100). For example, Kovatchev ("Risk Analysis of Blood Glucose Data: A Quantitative Approach to Optimizing the Control of Insulin-Dependent Diabetes," Journal of Theoretical Medicine, Vol. 3, pp. 1-10 (2000), incorporated herein by reference) described a static risk function that maps glucose concentrations to static risk values, where extreme hypoglycemia and hyperglycemia both have a level of 100. Similarly, Guerra ("A Dynamic Risk Measure from Continuous Glucose Monitoring Data," Diabetes Technology & Therapeutics, Vol. 13(8) (2011), incorporated herein by reference) described a dynamic risk function that maps glucose concentrations and rate of change of glucose concentrations to dynamic risk values ​​by scaling the static risk number based on rate of change information. This implementation can be built on the static and dynamic risk functions of Kovatchev and Guerra with additional inputs.

[0229] Other inputs that may contribute to a user's at-risk state include the acceleration or duration of a hypoglycemic or hyperglycemic state, and the duration of a constant rate or acceleration of blood glucose levels. An example is shown in Figures 12A and 12B, where a subject's risk increases the longer they remain above 180 mg / dL.

[0230]

number

[0231] In the formula, SR(g)=r h (g)-r1(g),

[0232] where r1(g)=r(g) if f(g)<0, and 0 otherwise;

[0233] If f(g)>0, then r h (g) = r(g), otherwise 0.

[0234] g is the glucose concentration

[0235]

number

[0236] is the rate of change of glucose concentration, ΔT is the time in hours above 180 mg / dL or below 70 mg / dL, and δ is an adjustable parameter for how much weight to give to the duration of time at risk.

[0237] Figure 13 provides a graphical illustration of the increasing risk for a health condition with duration of hyperglycemia. Referring to this figure, an example is shown of a user's glucose levels that are hyperglycemic but do not continue to rise. However, the figure shows that as duration increases, the risk continues to rise over time.

[0238] Figure 14 shows an example of avoiding false risk conditions by using acceleration as a parameter or variable in determining the GUI. In this figure, the acceleration or second time derivative indicates that the glucose value is decreasing while also in the process of improving, returning toward a euglycemic state. However, a continued rise may result in an elevated risk assessment, and therefore the GUI, due to the possibility of a hyperglycemic event.

[0239] The following equation (8) describes the situation in FIG.

[0240]

number

[0241] where A represents the acceleration rate of glucose in mg / dL / min and σ represents an adjustable parameter for how much weight to give to the acceleration and critical conditions.

[0242] Other functionality can also be brought into the analytical framework to support it. For example, adaptive learning can be applied, as broadly described in U.S. Provisional Patent Application No. 61 / 898,300, filed October 31, 2013, entitled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES," and U.S. Application No. 13 / 827,119, filed March 14, 2013, entitled "ADVANCED CALIBRATION FOR ANALYTE SENSORS," both of which are owned by the present applicant and are incorporated herein by reference in their entireties. In one application of adaptive learning, a monitoring device, e.g., a mobile device, can adaptively learn user behavior over time as the user experiences hypoglycemic and hyperglycemic events. For example, each time a user falls below 55 mg / dL, the data preceding that event can be used as a positive test case by a machine learning algorithm, e.g., a support vector machine (SVM) or linear discriminant analysis (LDA). Additionally, instances in which the user's glucose level remained between 70 and 110 could be used as poor test cases by the machine learning algorithm. The machine learning algorithm could undergo regular or irregular training, for example, monthly, to optimize the classification of imminent hypoglycemia. For example, the algorithm could study the conditions of that particular user one hour or one and a half hours prior to the hypoglycemic event. Example inputs to the machine learning algorithm used for classification could include glucose output records over the past six hours, current glucose level, current rate of change in glucose level, current glucose acceleration, time of last insulin bolus, size of last insulin bolus, number of declared carbohydrates, time of carbohydrate declaration, level of last glucose peak, last time the user interacted with the monitoring device, time of last exercise, time of day, time between insulin bolus and meal peak, etc. Once the classifier is optimized, it can be applied to data in real time to determine whether hypoglycemia is likely to occur within a certain probabilistic time window.

[0243] Another type of functionality that can be used uses Bayesian theory. Such functionality provides a probabilistic means of quantifying the risk of a particular day or night event based on prior distributions. Figures 15A-15F show example distributions applied to multiple GUI inputs, such as (A) a distribution applied to glucose concentration based on prior reliability information; (B) a distribution of variance values ​​based on noise in the data and / or the amplitude of the rate of change; (C) a distribution of carbohydrate information entered by the user based on the user's prior knowledge of carbohydrate estimates; (D) a distribution of the user's current health status; (E) a distribution of residual insulin based on integrated pump data; and (F) a distribution of, for example, acceleration data. Distributions can be used for any of the inputs, and a probabilistic algorithm is then used to determine a risk index. Such probabilistic algorithms can include joint probability algorithms or more complex analyses involving, for example, Bayesian statistics.

[0244] Yet another type of functionality that can be used involves "decision fusion" methods. Specifically, decision fusion provides another framework for determining a user's risk status from multiple inputs. Decision fusion uses statistical models to optimally combine risk information from multiple inputs to generate a likelihood value that some event, such as hypoglycemia, will occur. Such methods are particularly useful for combining disparate inputs, such as the rate of glucose change over the past 20 minutes and the number of receiver button presses, into a single likelihood scale. Prior knowledge of the sensitivity and specificity of each input in predicting an undesirable event, e.g., hypoglycemia, is used to determine how much weight to give each input in the final risk output, as described in further detail below.

[0245] Decision fusion methods can be used, for example, to determine whether a given user is likely to fall below 55 mg / dL within the next hour. In such a way, different data parameters can be used to make a decision as to whether hypoglycemia will occur at a given time, e.g., within the next hour. Data analysis can be performed to determine optimal detection parameters and their optimal yes / no decision thresholds, as well as associated sensitivity.

[0246] Exemplary parameters that can be used to make a determination as to whether glucose levels are likely to fall below 55 mg / dL within the next hour are shown in Table II below, along with their thresholds for the determination and associated sensitivity and specificity. Note that while some parameters may be highly sensitive (e.g., glucose values ​​will always be below 80 mg / dL before falling below 55 mg / dL), they may not be specific; i.e., there may be many occurrences where glucose falls below 80 mg / dL but then does not fall below 55 mg / dL within the next hour. Generally, the best predictors have both high sensitivity and specificity, such as predicted glucose levels being below 55 mg / dL.

[0247] [Table 2]

[0248] Each parameter can be compared in real time to its threshold and a yes / no decision made as to whether a hypoglycemic event is about to occur.

[0249] In this analysis, the "yes" case (hypoglycemia) is denoted as H1 and the "no" case (euglycemia) is denoted as H0, i.e., the null hypothesis. Decisions are made for each parameter (d=1 or d=0), and the sensitivity and specificity of the parameters are calculated by comparing each decision with a likelihood value, λ

[0250]

number

[0251] is used to convert

[0252] The likelihood value is the probability of making a decision where the subject will indeed have hypoglycemia divided by the probability of making a decision where the subject will not have hypoglycemia. For a "yes" or 1 decision, the likelihood value can be thought of as the sensitivity divided by (1 - specificity), i.e., the probability of a false alarm.

[0253]

number

[0254] For a test with high sensitivity and specificity, λ will be very high for a decision of 1 and very small for a decision of 0. Thus, this weighting of each decision based on test performance enters into the calculation. Once each decision is converted to a likelihood value, all likelihood values ​​can be simply multiplied. The final likelihood value is then a range where a low number means a very low probability of hypoglycemia occurring and a high number means a high probability of hypoglycemia occurring. These likelihood numbers can be used to inform a GUI as an input to present risk or urgency to the user.

[0255] Heuristics are yet another type of mathematical method that can be applied to an analytical framework. In such methods, experience informs the development of potential solutions. For example, an urgency assessment module may have empirical data suggesting that when a given user is at a given set of GPS coordinates, which happen to be a coffee shop, and the user also has a staff meeting scheduled the next day, the user typically has high glucose levels. The glucose levels may be stress-related or eating-related. In developing such heuristic solutions, regression models may be used, as well as related techniques such as MPC, if-then logic, expert systems, logistic regression analysis, neural networks, fuzzy logic, and weighting functions (where weighting may be applied to more risky glycemic risk inputs). As a specific example of the use of a regression model, A1C may be assumed as a current indicator of good / poor diabetes management. Some or many of the parameters or variables disclosed herein may be obtained from a statistically significant number of users, and regression analysis may be performed to determine which of these factors significantly affect A1C. The resulting multiples can then be scaled to provide an easily interpretable risk score, for example, on a 1-100 scale.

[0256] Thus, the GUI may be calculated by several means and by using several different variables and parameters, some of which are measured and others of which are input by the patient or other user. However, once the GUI is calculated, it may then be used to dynamically provide an indication to the patient (or caregiver) of a glycemic emergency, repeatedly updating the emergency over time. While the emergency may relate to hypoglycemia, hyperglycemia, or euglycemia, this provides much more sophisticated information than simply whether a glucose value (or predicted glucose value) has crossed a threshold. The display to the user is typically a graphical indicator of the emergency and may advantageously use the native capabilities of a mobile device such as a smartphone. The smartphone user interface may also be used to provide alerts / alerts to the user.

[0257] The additional information provided, beyond that provided by a system that simply indicates that a glucose value has exceeded a threshold, may include one or more of the following: The displayed information may include a prediction as to whether the glucose value is likely to bounce back to a desired value or continue to excursion away from normoglycemic values. The displayed information may include (or take into account) a prediction as to future emergency conditions, as distinct from simply providing a predicted glucose value. The displayed information may include consideration of whether the glucose value is following or deviating from a known pattern.

[0258] An urgency assessment module running on the mobile device (or elsewhere) can provide a framework for distinguishing between levels of risk and urgency for action that simple thresholds cannot provide, thus providing the user with actionable alerts but not overly alerting when not necessary, thus preventing alert fatigue. In this regard, it is noted that when smartphones are used for glucose monitoring, users continuously receive notifications from their phones for, for example, emails, texts, phone calls, applications, etc., so it becomes increasingly important to distinguish which alerts are important for the user to notice. It is important that particularly dangerous conditions requiring immediate attention be differentiated from such general cell phone sounds, perhaps by providing a special sound or vibration or even light / color to alert the user. Furthermore, it is important that the alert escalates noticeably if the user does not respond immediately, and the parameters and variables described above can be used to determine when such an escalation should occur. Indications can be provided by several means, such as using color, vibration, icons, heat maps, predictive representations, representations of risk as numbers, voice prompts, pop-up messages, etc.

[0259] In some cases, it may be desirable for the user to be alerted, but in a separate manner. Such an alert may be particularly appropriate when the user is with people who are currently unaware of the user's condition. Thus, a vibration alert, particularly a long vibration, may be provided that may alert the user to check their mobile device and determine what action is required. Another vibration, for example, a long vibration, but applied periodically until turned off by the user, for example, for a duration of 5 seconds, 10 seconds, etc., and at a frequency of once per minute, twice per minute, etc., may be used for the alert.

[0260] Where vibration-based warnings and alerts do not result in user action by the user pressing a button to at least indicate awareness thereof, the warning or alert may be provided audibly, such as by a ring melody, including a ring melody specifically selected for such a condition.

[0261] If neither the vibration nor the audible tone results in user interaction, an automated phone call or text message can be placed to another number, for example, to alert a physician or family member.

[0262] Assuming a user does not respond to the alert or alarm, a typical first reaction may be to pick up or otherwise hold their smartphone. In some cases, the user must perform a swipe action or enter a code to gain access to the smartphone's user interface. An indication of an emergency condition, given this scenario, may be provided on the user interface in several ways. First, the indication may be provided regardless of whether the phone is being held. This may be appropriate if the user leaves their phone in a position where it can be used, such as in a docking station face-up on a desk (e.g., background screen, home screen, periodic push notifications, etc.). Second, the indication may be provided when a signal that the phone has been held is received by the user interface, for example, via an internal accelerometer or other motion detector. Third, the indication may be provided after access to the smartphone user interface is gained, for example, via a swipe action, entering a code, etc.

[0263] For the first and second means, the display provided on the user interface may include somewhat less information than with the third means, recognizing the fact that others may be able to view the display. For the third means, if the user has already picked up the phone and performed an operation on the phone, it may be assumed that the user has obtained a desired level of privacy. Thus, the display in the first and second means may be, for example, a color or other indicator of an emergency condition that the user is familiar with. For example, a bright red color on the user interface may indicate a high level of urgency, such as an upcoming hypoglycemic or hyperglycemic event. The red color may be placed by the urgency assessment module through manipulation of the mobile device's background or wallpaper, or it may be the background of an application running the urgency assessment module, e.g., a CGM application, with the background and application prominently positioned in an elevated emergency.

[0264] In another implementation, the color may be accompanied by a number or arrow that conveys additional details about whether the GUI is assessing a significant risk of a hyperglycemic event versus a hypoglycemic event. Such numbers or arrows may provide useful information to the user while preserving unobtrusive, specific details of the user's condition.

[0265] Regardless of how the display occurs, user interaction with the application allows the user to become aware of relevant details of the user's condition and potential steps to take in adjusting it. In other words, the user can decide if they want to "drill down" into the numbers in more detail, and interaction with the application allows the user to do so. Variations on the above example may also be seen. For example, instead of a red screen, a red border or a large red circle around the user's home screen could be used. A different color or location could be used to indicate hyperglycemia versus hypoglycemia, or the user may need to instantiate the application to find the user's current condition. A different location or cross-line pattern could be advantageously used as an option for users who are color-blind.

[0266] Several types of functionality available on the mobile device user interface will now be described to indicate actionable alerts based on GUI values. It is understood that such user interfaces are purely exemplary, and that other such user interfaces are also possible. The user interface may show various levels of information, specifically a glycemic urgency index and blood glucose or glucose information, possibly together on the screen. The display of GUI values ​​may be done in several ways, such as through the use of visualizations or representations, such as colors or icons. While specific icons are discussed below, it will be understood that these may vary in many ways, such as a happy face (euglycemia) or a sad face (hypoglycemia or hyperglycemia), a comic book hero (low urgency or risk assessment) or a comic book villain (high urgency or risk assessment), a depiction of a meal (hypoglycemia) or a syringe or pump (hyperglycemia), a numerical value, etc.

[0267] Concepts such as "read" may be used, where "read" is defined as a level of information conveyed to the user, also known as information hierarchy, which is the arrangement of elements or content on a screen in such a way as to reveal an order of importance. Reads can consist of anything, including topography, shapes, color, contrast, weight, position, size, and space (including negative space). Reads are presented to achieve an order of importance or usability. A primary read may be the first item the user sees or is shown (the most visible or prominent). If there is only one level of information shown, there is no need for a secondary read. However, a device may have multiple levels or reads. A device with larger numbers in bright red font followed by smaller numbers in a lighter font has two reads. The larger numbers are the primary reads (what the user sees first), and the smaller numbers are the secondary reads (what the user sees, notices, or wants to see less frequently compared to the primary reads). Generally, the first readout provides lower resolution but more actionable or glanceable information, such as a representation showing a GUI, blood sugar status, or glucose level, which can be read at a quick glance. Generally, the second readout provides higher resolution (more detailed) information, which can be read with a longer gaze or a longer thought process. Additional readouts can be provided with greater or different levels of detail, as can be understood by those skilled in the art. In some implementations, the first readout is provided on a first, viewable screen (e.g., the background or home screen of a mobile device or software app), and the second readout is provided on the same screen in a configuration and location that is less viewable or easily readable at a glance. In some implementations, the first readout and the second readout are on different screens that require the user to access them separately.Additionally, the first lead can be a simple light, such as a red, blue, or yellow color LED on the side of a phone, on a smartwatch, and / or on a wearable device, as described in the patent application incorporated by reference above. In one implementation of a wearable device, such as a wristband, the first lead can be provided as a color LED that can be displayed on the wearable device, and the second lead can be accessible only through another device, such as a software app on a smartphone. The first lead can be advantageously mild or at least unobtrusive so as not to draw attention or discussion about diabetes.

[0268] 16A and 16B, a user interface 550 is illustrated that presents two different states. In FIG. 16A, the first lead 504 is illustrated by the color of the device (indicated by crosshatching). For example, the user interface of the device in FIG. 16A may be yellow, while the user interface of the device in FIG. 16B may be red. From a distance or with a quick glance, the user can thus be informed of their GUI or glycemic status. In this case, the urgency assessment may be yellow to indicate to the user that their glucose levels are relatively normal, slightly elevated, or approaching the boundary of euglycemia. In FIG. 16B, a red urgency assessment may indicate to the user that their glycemic status, based on the GUI, requires urgent attention. Additionally or alternatively, rather than yellow or red indicating a high glucose state, a low glucose state, etc., color may be used to convey other types of information, such as a positive (e.g., purple) or negative (e.g., orange) rate of change. While some users will understand the meaning of the colors, others may not realize that diabetes information is being conveyed due to the abstract nature of the background design.

[0269] 16, an optional second lead 502 is also provided, which represents the glucose value itself. As noted above, the aggression assessment typically uses the glucose value in its determination, but also uses other values, which may be equally important in the determination. Additional leads, such as GUI inputs, patterns, insights, treatment suggestions, and the like, may be accessed via the CGM for additional information.

[0270] In this and other implementations, the home screen of a mobile device running an acuity assessment module or CGM application in the background can persistently display a colored screen indicating glucose status. The colored screen generally indicates a GUI state, e.g., "normal" or no warnings, even when there are no warnings or alerts. A user does not need to swipe or enter a password to access this information. Such a screen can be quickly viewed by pressing a wake-up button on the mobile device or, as described above, by an accelerometer that determines whether the mobile device is being held in the hand.

[0271] Referring to user interface 560 of FIG. 17 , color is still used, but in this case, the first lead is not the color of the home screen 506, but rather the color of a circle located on the home screen (circle 508 in FIG. 17A and circle 508′ in FIG. 17B ). The second lead may be the size of circle 508 or 508′, e.g., the radius of the circle, and the velocity or acceleration illustrated by directional arrow 512 or 512′. For example, the arrow may illustrate the first derivative of whether the glucose value is rising or falling, and the size of the circle may indicate how fast the glucose value is rising or falling (second derivative). Alternatively, the circle may qualitatively represent potential danger due to the rise or fall. For example, a larger circle may represent an accelerating rise away from normal, while a smaller circle may represent a slowing rise. A third lead 516 is also illustrated, which indicates the actual measured glucose value. Finally, in FIG. 17B, an advanced output 514 is illustrated, which indicates the level of analysis as part of or concurrent with the GUI's decision and provides suggestions or prompts for possible steps to be taken by the user.

[0272] Referring to FIGS. 18A and 18B, an alternative user interface 570 presented on a mobile device's home screen 516 is illustrated. FIG. 18A illustrates the example of a rising glucose level, and FIG. 18B illustrates the example of a falling glucose level. Specifically, an arrow and series of circles 518 (518') and their colors can be used to indicate to a user whether their urgency rating is rising (FIG. 18A) or falling (FIG. 18B). Specifically, and with reference to FIG. 18A, the rise itself is illustrated by the arrow, and the color progression from off-white to red illustrates that the urgency rating is also rising, i.e., the situation is becoming more urgent for the user. The glucose value itself 522 (522') is presented as an additional readout. In the case of FIG. 18B, the color progression from red to white indicates a return to a more desirable urgency state. The arrows and the presented fading of the circles corresponding to earlier measured urgency assessments, progressing from left to right, indicate progression from earlier urgency states to later urgency states and finally to the current urgency state. Alternatively, a series of circles (or icons) 518 may represent predicted glucose values ​​or ranges as a first readout, which may include a predicted glucose value at 522 and a display of the prediction range (predicted value over time) indicated by the number of circles (or icons) per circle, e.g., 5 minutes, or in this example, 15 minutes. A second readout may be accessible with a swipe or other user action that may provide additional insight or information related to the prediction.

[0273] Variations are understood and are similar to the specific aspects described above. It will be understood that such variations are provided in other embodiments described herein. Shapes or icons or visual appeals other than circles can also be used. For example, it could be an image of the moon shown in its progression from new moon to full moon. For example, the size of the circles and their colors can indicate the urgency rating. Subsequent size sequences can indicate how rapidly the value is changing. For example, a progression from very small to very large circles can indicate a rapid increase in the urgency rating. Conversely, a progression from "medium-small" to "medium-large" circles can indicate a much more gradual increase. Additional indicators or leads 524 can be used to provide a glanceable icon to quickly indicate to the user the urgency of their assessment. Such indicators can be displayed without holding the mobile device, following holding as determined by an accelerometer or other sensor, or automatically after a swipe / unlock step. This can be accomplished with an audible alert to notify the user of the emergency condition.

[0274] 19A and 19B illustrate another user interface 580 that may be used on a monitoring device, e.g., a mobile device. In FIG. 19, the home screen is divided into several regions 526a-526g (FIG. 19A) and 526a'-526g' (FIG. 19B). The regions may or may not be equally divided, and the number of regions may vary. The number of regions may further vary based on user input, for example, if the user desires finer granularity in the data presented.

[0275] In FIG. 19, seven zones are presented, with a low-risk or no-risk zone 526d in the center of the zone range. The urgency assessment shown in FIG. 19A indicates little or no assessed urgency, i.e., little risk to the user. However, the urgency assessment shown in FIG. 19B represents a higher urgency, in this case associated with elevated glucose levels. The location and color of the highlight can be used to provide an indication. In FIG. 19A, the highlight is centered and white, indicating a low urgency. In FIG. 19B, the highlight is red within the high zone, indicating a higher urgency. If the highlight, or other leading indicator, is location- or text-based rather than color-based, this can be advantageously used for individuals with color blindness. FIG. 19 also shows an arrow 528 and a numerical depiction 532 of the glucose value. From the numerical depiction 532, the user can be notified of their glucose level. From the arrow 528, the user can be notified of the direction their glucose level is heading. Arrows with more consistent colors (as shown in FIG. 19B) may indicate a more rapid or accelerating rise. These factors, and generally more factors, go into the GUI's determination, and the resulting representation of this determination is a highlighted range indicating the determined urgency rating.

[0276] An advanced output 534 is also shown, which provides the user with additional information about possible causes of hyperglycemia, possible steps towards a less urgent assessment, and the like.

[0277] It is understood that the ranges in different zones need not represent equally spaced levels of urgency, but may provide quantitative or qualitative levels of urgency based on the determined GUI. The ranges may be set by the user or by a physician or other caregiver and thus may be personalized to the needs of a particular user. Similar customizability would apply to other embodiments of the user interface disclosed herein.

[0278] 20A and B illustrate a user interface 590 with a thermometer-like scale 536, depicting a rectangle 538 that typically indicates a desired glucose range. This user interface does not require the use of arrows. Current glucose levels may be indicated by a highlighted bar 542, past glucose levels may be indicated by faded bars 544, and bars of various shades in between indicate changes in glucose values ​​over time. In some implementations, a color-matched background may indicate a third lead or level of information, such as Wi-Fi status, glucose communication (data sharing) with other mobile devices, etc.

[0279] The color of both the current and past bars may indicate a relative or absolute urgency rating. For example, bar 542 may be white, while bar 546 (FIG. 20B) may be red. The color indicates the urgency rating for which the glucose value is a factor, but only one of several or many. Thus, bar 542 is depicted as white in the figure, but in another situation, with the same glucose value, it may be depicted as red if the value was rising and accelerating (or taking other excursions).

[0280] 21A and 21B illustrate another means of representing urgency on a mobile device user interface 610. The user interface 610 particularly depicts one means by which distinct representations may be provided. Specifically, a grid pattern 548 is provided that may be personalized by or on behalf of the user. The user may associate a defined grid space with a particular urgency indication. For example, the lower row may represent a hypoglycemic urgency assessment, the middle area may be a target urgency assessment, and the upper row may represent a hyperglycemic urgency assessment.

[0281] In some implementations, the rows may represent snapshots of current or recent past urgency assessments. For example, the leftmost row may represent recent past assessments, the middle row may represent current assessments, and the right row may represent predicted future assessments. Alternatively, the rightmost row may represent current assessments, and the left and middle rows may represent recent past assessments. Other variations will also be understood.

[0282] The user may recognize the numerical threshold, but the numerical threshold may not be placed on the screen for various reasons, including discretion, to prevent questioning by others, and / or for the general purpose of clarity. Grid spaces may be added based on an urgency assessment, including, for example, the direction and severity of the upswing, as well as other variables. To an outsider, the user interface 610 may simply appear as a design pattern, or even a game screen.

[0283] As with the other embodiments, however, in this case for grid spaces 552 and 554, the highlighting occurs with a particular color, an indication of the glucose value, and an indication of the direction the glucose value is moving. As seen in Figure 21B, highlighting may also be provided in other grid spaces, shown here as grid spaces 556 and 558, to indicate recent past values ​​of measured glucose.

[0284] FIGS. 22A and 22B illustrate another user interface 620 that can be used to indicate urgency. In these figures, a graph 562 of glucose values ​​is provided to allow the user to view recent past values. Such a graph can be particularly important for users who desire a greater degree of knowledge about their current level. As illustrated in FIG. 22A, a current glucose value 566 and a box 564 that borders that value and generally indicates where the current time is represented on the graph can also be provided. Screen color 572 can be used to indicate a GUI-based urgency assessment. For example, in FIG. 22A, a light red background 572 can indicate an elevated level but a low urgency assessment. In FIG. 22B, a blue background 572' can indicate a normal blood glucose level and a zero urgency assessment. FIG. 22B also illustrates that the box 564 can be used to indicate a portion of the glucose output tracking graph that has, for example, higher fidelity, additional processing (e.g., detected patterns), etc. In the user interface of FIG. 22, a horizontal threshold bar is not required, yet through the use of a colored background, the user is still made aware of the "zone" of their urgency assessment.

[0285] FIG. 23 shows a user interface with a higher level of detail, specifically showing average and predicted glucose levels, which leads to a GUI and therefore an urgency rating based on factors such as past behavior at that time. Specifically, user interface 630 includes a background 574, which may indicate the urgency rating, e.g., blue, green, yellow, red, etc. Alternatively, the color of box 576 may indicate the urgency rating, and this box is also where the current (or alternatively predicted) glucose value 578 is displayed. Horizontal scale 582 relates to time, so that an output log graph of glucose level 584 can be displayed as a function of time. Past values ​​(average glucose profile or normal patient pattern) for a given time are illustrated by histograms 586 and 588, which illustrate the range of hypoglycemia and hyperglycemia previously seen at a given time for a given user.

[0286] A portion of the graph, such as the portion within box 576, may represent an outlying glucose level determined using predictive analytics as described above, which may or may not be relevant to the urgency assessment. This outlying value is illustrated as output record 592, which has different line widths in example FIG. 23. Areas of particular low or high values ​​may be represented by different colors, such as yellow for moderately high / low values ​​and red for very high / low values.

[0287] FIG. 24 illustrates a user interface 640 that shows a user even more detailed, or dashboard, information about their glycemic status and other blood glucose or product status. This screen presents multiple pieces of information in one place to avoid multiple button presses or swipes to access status that might otherwise be found in many different locations in the app or website. Specifically, user interface 640 includes an output trace graph 594 in which deviations from normal blood glucose values ​​are shown by traces within ranges 596 (hyperglycemia) and 598 (hypoglycemia). The output trace 594 shown in FIG. 24 is an output trace of glucose values ​​on a scale 602 plotted against time, as indicated by a time scale 604, although it will be understood that other variables, such as deviations from normal glucose values, may also be represented.

[0288] As described, the glucose value and other factors influence the GUI's determination and therefore the urgency assessment. The urgency assessment may be indicated to the user via the user interface 640 by the color of the background 614 or by an indication such as textual indication 612, which in FIG. 24 indicates that the assessment is that the user is "OK." The user interface 640 also shows the current glucose value 606 and an indication of the direction the glucose is heading, indicated by an arrow 608. In some implementations, the slope, size, or other aspects of the arrow 608 may indicate how quickly the glucose value is rising or falling.

[0289] Variations will be understood. In particular, it is noted here that not all aspects shown in this and other implementations need be displayed. For example, in FIG. 24 , the numeric glucose value 606 may be omitted because the user can obtain similar information from consideration of the output record 594 or simply by the textual display 612.

[0290] In this and other implementations, rate of change and acceleration information can be added to the trace graph arrows. Of course, rate of change can be apparent from the trace graph itself, but colored or curved arrows can be used to indicate acceleration or deceleration of glucose levels. In one implementation, a red arrow can indicate an undesirable value of acceleration, while blue indicates a desirable value. In another implementation, curvature of the arrow away from euglycemia can indicate an undesirable acceleration, while curvature toward euglycemia can indicate a desirable trend.

[0291] Referring to FIGS. 25A and 25B, a user interface 650 including additional data is displayed on a mobile device. Specifically, the user interface 60 includes an output record graph 618 corresponding to the glucose level and a numeric value 622. While the numeric value 622 can provide the user with an instantaneous or current level, the output record graph 618 can let the user know what value they are at, even without a y-axis. The color of the screen 616 can provide another readout and indicate the current urgency assessment. A qualitative graph 624 can be used to provide the user with an at-a-glance readout regarding the areas occupied by target, hyperglycemia, or hypoglycemia. In this illustration, the pie slices can represent the percentage of time in these areas per day, per month, or any other period of time. Alternatively, although not shown, the pie graph can be "overlaid" on a clock to indicate, for example, that the user had high GLU from 12 to 2 o'clock in the green segment, then the user had low GLU from 2 to 4 o'clock, etc. An area of ​​user interface 650 may be provided as a challenge area 626 that qualitatively indicates to the user how well the user is meeting the challenges they have set for themselves, generally to maintain glucose levels within a target range. A portion of user interface 650 may be provided to show the user's friends or followers 628. By swiping right or left on user interface 650, data corresponding to friends or followers may be displayed and reviewed. For example, each may see how well the others are meeting their set goals or challenges.

[0292] 26 illustrates another user interface 660 that may be advantageously used. User interface 660 is similar to that of user interface 630 of FIG. 23, but includes additional details of the prediction. Specifically, user interface 660 includes plotted points 632 corresponding to predicted glucose levels based on the predictive analysis, as described above. Instantaneous glucose levels 634 are displayed as numbers to provide an easy-to-read display for the user.

[0293] An advanced output 636 is also illustrated and may be used by the urgency assessment module in various ways. For example, if several friends or followers are associated with the user, this may provide a notification to the friends or followers to take some action against the user. For example, the friends or followers may be prompted to intervene with the user if the user's urgency rating is trending high or low. The advanced output 636 may also be used to intervene with the user themselves, for example, to suggest treatment guidelines or otherwise provide intervene. Additional details of the advanced output are provided below.

[0294] 27A and 27B illustrate various activities or posts that may be provided to or from a feed associated with a social networking service. At the most passive level, a user may receive updates from friends or followers the user associates with in the social network. This group may correspond to all friends or a subset of friends, such as those who also live with diabetes. At a more advanced and interactive level, user posts may be used within GUI decisions; for example, a post about participating in a race combined with known glucose and other data related to the user that day may provide improved data for the social networking feed. Similarly, this may be used in combination with historical data about similar situations to provide and post historical comparisons. For example, in FIG. 27B, we see the post "Race day! Last time I did this, I had a high-carb breakfast and reported feeling invincible!" (Post 638).

[0295] Given the present teachings, other aspects suitable for social networking will be understood. For example, in various other embodiments, the ratings module 211 may be used in combination with a contacts module to provide updates to a social network. In some embodiments, the smartphone 200 may use the user's location and / or other attributes associated with the user (e.g., type of diabetes, age, gender, demographic data, etc.) and / or use similar CGM devices or smartphone applications to find other people in the area with similar attributes to suggest connections. For example, a CGM application and / or a social media site in conjunction with a CGM application may allow the user to select from options such as find other people with diabetes, find other people with diabetes near me, or find recommendations for diabetes-friendly restaurants in the area.

[0296] In some embodiments (see FIG. 6 ), the CGM application 209 (alone or in combination with an assessment module 211 that typically, but not necessarily, executes within the CGM application 209) allows users to selectively upload or share information about their assessment electronically and / or via social networking sites. Example information that may be shared includes success metrics, current EGV values, screenshots, achievements, awards, pattern trend graphs, activity information, location information, and / or any other parameters described elsewhere herein as possible inputs to or outputs from the assessment module 211. For example, the CGM application 209 (it will be understood herein and below that such a CGM application may include an assessment module 211) may have user-selectable actions, such as sharing the EGV on Facebook, sharing the EGV on Twitter, sharing the screen via Facebook, Twitter, email, MMS, sending the trend screen to a printer, etc. Additionally or alternatively, the CGM application 209 may allow users to add preset and / or custom headlines or change the status of their shared information, such as "Watch My No-Hitter," which can be shared selectively (by the user or based on parameters) and / or automatically. In one example, a user can "like" a particular GUI or its representation directly on a particular social site. In certain embodiments, when a user chooses to share information, options may be shown on the display device 202 (FIG. 6) that allow the user to select what to share and with whom. A user can predefine groups and / or individuals with which to share information. For example, a user can create a group of friends, and when the user chooses to share something with the defined friends, a notification is then sent to each person in the group. This functionality is useful, for example, for parents who want to monitor their child's blood glucose.The child can choose to share their BG value and then select either parent, or mother, or father, and the BG value is then sent to the selected person(s).

[0297] In some embodiments, the CGM application 209 can be configured to collaborate with a social network, allowing users to compare EGV, trends, number of lows, etc. with friends or groups on a social networking site (e.g., Facebook). In some embodiments, the CGM application 209 uses CGM information from multiple users to compare one or more parameters to an average (e.g., grouped by some similarity) to determine the comparison of data from a single person. In some embodiments, the CGM application 209 can calculate achievements, scores, badges, or other awards based on defined criteria (e.g., maintaining blood glucose within a target range, CGM use, etc.) and selectively or automatically post these to a social networking site (e.g., Facebook). In some embodiments, when a user wants to share what they have learned from the CGM application 209 or the evaluation module 211, such as photos of food and resulting EGV or trend graphs, the CGM application 209 allows the user to selectively upload the information to the site. In this context, what is learned is an event or first situation and its resulting impact, outcome, or trend.

[0298] Additionally or alternatively, data from CGM users may be aggregated by configuring the CGM application 209 to allow the user to query current CGM users, e.g., xx% of people using CGM who are in range, other CGM users with glucose similar to the user (within a margin of error such as 80 mg / dL ± 5), etc. These queries may also be narrowed by geography, physician, age, gender, ethnicity, type of diabetes, type of treatment (pump, syringe, exenatide, metformin, etc.), etc.

[0299] Continuing the discussion of the user interface depicted in FIGS. 28A and B, we turn to the possible outcomes of user interface 680. User interface 680 presents an unobtrusive outcome that would likely only be known to the user. As such, the user's health status is not displayed in a particularly obvious manner on the user interface. Specifically, and with reference to FIG. 28A, a balloon is shown having a color 642 and an arbitrary numerical value 644. The color indicates the outcome of the GUI's decision in an unobtrusive and gentle manner. The numerical value 644 provides an additional lead, such as one related to the current glucose level in this implementation. It will be appreciated that in addition to balloons, numerous other icons or images may be used and, in fact, selected by the user. Thus, for example, the user may select a car whose color (e.g., red, yellow, green, etc.) is related to the GUI's decision. In the balloon embodiment, additional information or leads may also be provided. For example, the height of the balloon may indicate whether the GUI is becoming more or less urgent, or whether the glucose level is rising or falling. Other variations may also be envisioned.

[0300] 29 illustrates another user interface 690 that can be used to represent a level of urgency to a user. In user interface 690, a tachometer-like display has a green portion representing a low urgency condition, a yellow portion representing a medium urgency condition, and a red portion representing a higher urgency condition. The position of the needle indicates the current state, i.e., relative to the determined GUI.

[0301] It is understood that the above user interface depictions are purely exemplary and that numerous variations will occur. For example, GUI decisions and actionable alerts may be provided within a game, either to hide data so that only the user can discern it, or in such a way that favorable GUI decisions result in favorable game outcomes. In other words, if the user controls their urgency rating, the user wins the game. Furthermore, notifications and actionable alerts may be provided in a manner that differentiates them from other alerts on the mobile device, such as alerts from text messages, application updates, phone calls, voicemails, etc. The user can configure the CGM application 209 so that alerts from the urgency assessment module 211 ignore certain or all other alerts, or must dismiss alerts from the urgency assessment module 211 before the user can use the phone, so that urgency alerts or alerts are not inadvertently overlooked. As noted, alerts or alerts may escalate, i.e., become more urgent, as the urgency rating increases. Initially, a warning may be presented on the user interface upon unlocking the device, while such warnings may escalate to an audible alarm as the urgency increases.

[0302] Further information provided by the user interface may include values ​​such as bounce highs and bounce lows so that the user may be notified of such conditions and may provide possible user actions, whereby the user can easily compare and notice the causes and effects of such conditions, and easily relate the causes to actions because both are still fresh in the user's mind.

[0303] In some implementations, the data output to the user may be adaptively operated by creating various modes in which the urgency assessment module may operate. Additionally, the urgency assessment module may adapt to real-time inputs by the user or physician / caregiver, or based on other criteria deemed useful.

[0304] Specifically, a user may not want to be alerted if their GUI has a small excursion, for example, to a mild emergency condition, if the GUI simply follows a known pattern. A user may not want to be notified that their glucose is temporarily high after eating a meal because they expect the GUI to be high, which may be determined based on pattern input, as further detailed elsewhere herein. A user may not want to be alerted to glucose fluctuations if they intentionally take a day off from trying to achieve optimal control and end up spending the day with poor glucose control as a result of “bad behavior,” e.g., choosing to eat birthday cake and celebrating their birthday with friends by drinking a little alcohol. A user wants to be protected, but not necessarily alerted all the time. Thus, in one implementation, a user can set the emergency assessment module to an “operational mode” in which the user is only notified of potentially dangerous scenarios, such as “below 55,” “below 70 for more than 30 minutes,” or “above 300 and still rising rapidly.” Providing an urgency assessment module with such functionality solves the problem of CGM users being given information at what are often inconvenient or potentially bothersome times. It also allows for appropriate information or warnings to be displayed when users are not checking their CGM, as well as when they regularly check their CGM.

[0305] Referring to flowchart 720 of FIG. 30 , a method according to this principle is shown for displaying an alert. In a first step, a GUI is determined as described above (step 646). Then, the GUI outcome is determined, which may be an alert, an alarm, or simply an output of the current state of urgency (step 648). The output may also be based on adaptive learning and, specifically, learning about user characteristics, including GUI and glucose level patterns and trends 652, mobile device usage characteristics, and other parameters and variables described above. Such may include, for example, user input 654 indicating that the user wishes to be notified only of critical conditions. Adaptive learning may also be based on the mode 653 in which the urgency assessment module is operating. For example, if the mode indicates that the user wishes to be alerted only of critical conditions, such mode may be included as a factor in determining the outcome of step 648. Similarly, the user may enter a mode 653 in which they desire a certain level of prompting or suggestion. Given the present teachings, other modes will be understood as well. Other data 655 may also be used in determining the learning-based outcome.

[0306] Once the results are determined, they may be presented to the user or physician / caregiver (step 656). In presentation, the results may be displayed on a screen, sounded audibly, or otherwise rendered. The results may be a general presentation of data, alerts, warnings, etc. Alternatively, the results may simply be the display of an initial icon (step 658). The icon may provide an indication of the urgency assessment, but may be unobtrusive. In this manner, the user makes a decision as to whether to receive additional information, i.e., "drill down" to additional information. Such additional information may be requested by several means, such as by swiping an icon or by navigating to an app. The urgency assessment module receives the request (step 652) and provides the additional information (step 664), which may in some cases be the same or similar to that provided in step 656.

[0307] The request to receive additional information may be accommodated in several other ways, possibly consistent with the specific advanced output described above. One possible type of output involves prompts and questions / answers, possibly involving avatars to more fully engage a particular user, e.g., a child.

[0308] In another implementation of a user interface, exemplified by user interface 730 shown in Figures 31A and 31B, various scenarios based on an urgency assessment are presented to the user. In this manner, rather than reinforcing a specific measure, the focus is on potential actions to be taken. For example, referring to Figure 31A, user interface 730 may show a situation 666 and present various scenarios 668 from which the user can select. Figure 31B shows another situation.

[0309] The potential treatments may be ordered from safest to most aggressive.

[0310] Alternatively, a question such as "What would you do if...?" may be posed to the user, and this response returned to the evaluation module as input to the GUI's decision.

[0311] Possible actions could be a stern notification, possibly similar to a warning, or alternatively, a gentle prompt that users only see when they look at their CGM screen. In such cases, pushed data could be updated in the moment, without delay. Criteria could also be set for notifications based on potentially dangerous scenarios, such as seriously low glucose levels.

[0312] As noted above, activities such as sleep, exercise, etc. may be recognized. An output may be linked to such detected activity. For example, if a parent is asleep, e.g., it is currently 2:00 AM, and the sensor and / or mobile device has been stationary for X minutes (where X is 10 minutes, 20 minutes, 30 minutes, 1 hour, etc.), sleep is assumed and the output may be audible and loud enough to wake the user. When the user is driving, the output may also be audible and / or fairly loud. If the user deviates from a normal pattern, the output may provide additional details or ask the user a question. Other variations will be appreciated.

[0313] In addition to providing the user or caregiver / physician with information regarding the urgency assessment, the GUI can be translated or converted into an insulin pump operational display using appropriate mappings, lookup tables, or functions. The GUI can be displayed to the user for input as a pump operational display on a separate pump, or can be provided directly to the pump to dispense insulin in a closed-loop system. More specifically, the GUI can be used to moderate insulin delivery, e.g., withhold, reduce, or increase basal or bolus insulin delivery, based on a glycemic risk state. By basing pump functionality on an urgency assessment such as the GUI, the user's urgency state is considered in a much more useful manner using factors other than just a current (or even predicted) glucose level exceeding a threshold. For example, a particular implementation may request the dispensing of a bolus of insulin when the GUI indicates a hyperglycemic state. It is understood that in addition to the pump, the urgency assessment module can also interact with other devices, including devices communicatively coupled via a network.

[0314] Indicators for GUI-based notifications and for alerts and alarms may be set at the factory or may be customizable by the user, who may also set thresholds at which alerts and alarms occur. The system may also provide for alert changes based on trends or other factors in the GUI, either automatically or triggered by the user. Thus, the system allows for dynamic and / or repeated updates of urgency indicators and status over time as additional data is received and based on user actions.

[0315] For example, a user may have an estimated glucose of 100 mg / dL but may be falling at a rate of 2 mg / dL / min, so that a hypoglycemic urgency of 70 mg / dL (e.g., yellow state) is estimated after 15 minutes (a 30 mg / dL drop), and a severe hypoglycemic urgency (e.g., red state) is estimated at 22.5 minutes. If a red urgency is defined at 20 minutes to 55 mg / dL, the urgency assessment module will display a yellow state at this point, but if the user does not take action or has not yet done so, the user will likely see a change from the yellow state to the red state within a few minutes.

[0316] The urgency assessment module may allow for different sensitivities based on, for example, time of day (day vs. night), while driving, exercising or playing sports, napping, when sick, etc. Sensitivity may also be adjusted based on the user's needs. For example, if some users desire a significant amount of feedback, including positive feedback, they may adjust the sensitivity to a high setting (or a low discrimination level) to allow a significant amount of information to be presented. Other feedback provided may be positive in nature, such that the urgency begins to resolve as soon as it is assessed, and the user interface may display a message indicating an improvement in the situation, such as "Your treatment appears to be working." In this way, the user may be advantageously encouraged even before they reach an optimal correction point, further advantageously preventing insulin and food stacking that could lead to harmful overcompensation. Further details of such feedback types are described below.

[0317] Conversely, other users may only desire warnings or information when entering into a dangerous or potentially dangerous emergency assessment, and for such users, the sensitivity may be set to a low setting (or a high discrimination level) to minimize the number of warnings or alerts they receive.

[0318] Other types of prompts may also be used in the feedback or output from the urgency assessment module. For example, when a user goes from a more urgent to a less urgent glycemic state, i.e., from a higher risk to a lower risk, the output may also indicate that the user's treatment has begun to correct the glycemic urgency risk condition, again preventing insulin and food stacking.

[0319] Other types of advanced output are also understood to be possible. For example, based on the current urgency assessment and data regarding residual insulin or food intake, suggestions for treatment, i.e., means to lower the urgency assessment, may be provided. Another type of advanced output may be provided as a link that, when clicked, directs the user to additional information regarding the current condition or urgency assessment. A GUI, i.e., future or predictive trend graphs (or other means of providing such information, e.g., numerical indicators or scores, colors, etc.) may be provided that show the direction in which the urgency assessment or condition is predicted to progress or can progress with different treatment options. Future trend graphs of glucose levels or other parameters may also be provided.

[0320] By using these types of outputs, and by continuously updating the glycemic state, outputs based solely on glucose values ​​exceeding thresholds, or even GUI or urgency assessment trend information that is clearly distinct from glucose trends, can provide users with information they would not otherwise receive.

[0321] While the above information is based on a generally expected glycemic urgency assessment, selective alerts may also be based on retrospective algorithms that look for specific types of glycemic excursions that may indicate long-term glycemic complications. While such retrospective algorithms were described above in connection with GUI determinations, it is noted here that retrospective algorithms may also be the basis for various user interface displays and / or input prompts. For example, retrospective review may indicate large excursions from low to high or from high to low. An example based retrospective alert system intended to engage users in CGM events is illustrated below. Retrospective alerts may trigger alerts on users' smartphones when meaningful information is found in their data.

[0322] An example such method is illustrated by flowchart 740 in FIG. 32A. In a first step, the retrospective algorithm examines the data for various glycemic events, e.g., significant deviations from normal values ​​or values ​​determined to be typical according to the reference value, evolving patterns, etc. (step 672). In doing so, the algorithm may examine recent minima and maxima as soon as new sensor packets of data arrive. An example is illustrated by graph 750 in FIG. 32B. Output trace 678 illustrates a CGM output trace, with horizontal bar 682 representing the start of an event and horizontal bar 684 representing the end of the event. Two events are shown, one starting at 227 mg / dL and ending at 213 mg / dL, and the other starting at 294 mg / dL and ending at 46 mg / dL.

[0323] The retrospective algorithm then checks whether the excursion of the current event is outside a threshold (step 674). The threshold may be based on the difference between values ​​in mg / dL, the percentage difference between the start and end of the event, or other factors, such as whether the excursion is more than a standard deviation outside a typical excursion. By having such a threshold in place, the system ensures that only meaningful events are displayed to the user, further minimizing nuisance alerts. Advantageously, this may allow for easy collection of user information useful for pattern recognition and generally educating the user on an individual's glycemic events, patterns, or profile.

[0324] If the event is outside the threshold and therefore significant, it triggers an alert or other resulting output (step 676). For example, a push notification may be delivered, an icon may be depicted on the trend graph, a batch number may increase, etc. Other such notifications will also be appreciated. The alert displayed will generally differ based on the type of event. For example, if the event indicates that the user is crossing from a high to a low glucose value, e.g., from 294 mg / dL to 46 mg / dL, the message might read, "We have noticed a large glucose excursion. Would you like to enter carbohydrate and / or insulin information regarding this event?" The trend graph segment might be highlighted in a different color while the alert is activated to indicate that the user has not dismissed it. Such a situation might be indicated in graph 760 of FIG. 32C by a different color (line or dot) within segment 686.

[0325] A system and method for dynamically and repeatedly assessing a glycemic urgency index associated with an urgency assessment is disclosed. Various methods for determining a glycemic urgency index and displaying the determined urgency assessment to a user are disclosed.

[0326] Variations will also be apparent to those skilled in the art given the present teachings. For example, trends, particularly determined GUI trends, can be used to present information to a user on a mobile device user interface, while trends can be identified and used as a teaching tool for a physician or caregiver to note patterns, incidences, or events that the user should pay attention to.

[0327] Connections between elements are shown in the diagram illustrating example communication paths. Additional communication paths, either direct or through intermediaries, may be included to further facilitate the exchange of information between elements. Communication paths may be two-way paths that allow elements to exchange information.

[0328] As used herein, the term "determining" encompasses a wide variety of operations. For example, "determining" can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, and the like. Also, "determining" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Also, "determining" can include resolving, selecting, choosing, establishing, and the like.

[0329] As used herein, the term "message" encompasses a variety of formats for transmitting information. A message may include a machine-readable collection of information, such as an XML document, a fixed-field message, a comma-separated message, etc. A message may, in some implementations, include a signal utilized to transmit one or more representations of information. While referred to in the singular, it is understood that a message may be, for example, composed of / sent / stored / received in multiple parts.

[0330] The various operations of the methods described above may be performed by any suitable means capable of performing the operations, such as various hardware and / or software component(s), circuits, and / or module(s), etc. In general, any operation illustrated in a figure may be performed by a corresponding functional means capable of performing the operation.

[0331] The various example logical blocks, modules, and circuits described in connection with this disclosure (e.g., the blocks in FIGS. 5 and 6 ) may be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration.

[0332] In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as instructions or code on one or more computer-readable media. Computer-readable media includes both computer storage media and communication media, including any medium that facilitates transfer of a computer program from one place to another. Storage media may be any available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection qualifies as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of medium. Disk and disc, as used herein, include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically while discs reproduce data optically using lasers. Thus, in some aspects, computer-readable medium may comprise non-transitory computer-readable medium (e.g., tangible media). Furthermore, in some aspects, computer-readable medium may include transitory computer-readable medium (e.g., a signal). Combinations of the above are also intended to be included within the scope of computer-readable medium.

[0333] The methods disclosed herein include one or more steps or operations for achieving the described method. Method steps and / or operations may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or operations is specified, the order and / or use of specific steps and / or operations may be modified without departing from the scope of the claims.

[0334] Certain aspects may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may comprise a computer-readable medium having instructions stored (and / or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. For certain aspects, the computer program product may include packaging materials.

[0335] Software or instructions may also be transmitted over a transmission medium. For example, if the software is transmitted from a website, a server, or other remote source using coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless techniques such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless techniques such as infrared, radio, and microwave are included in the definition of transmission media.

[0336] Furthermore, it should be understood that modules and / or other suitable means for implementing the methods and techniques described herein may be downloaded and / or otherwise obtained by a user terminal and / or base station, where applicable. For example, such devices may be coupled with a server to facilitate the transfer of means for implementing the methods described herein. Alternatively, the various methods described herein may be provided via storage means (e.g., RAM, ROM, physical storage media such as a compact disc (CD) or floppy disk, etc.) to which the user terminal and / or base station may couple to obtain the various methods or to provide the storage means to the device. Furthermore, any other suitable manner for providing the methods and techniques described herein to a device may be utilized.

[0337] It is understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes, and variations may be made in the arrangement, operation, and details of the methods and apparatus described above without departing from the scope of the claims.

[0338] Unless otherwise defined, all terms (including technical and scientific terms) are given their ordinary and customary meanings by those skilled in the art and are not limited to any particular or particular meaning unless expressly so defined herein. Note that the use of a particular terminology, when describing a particular feature or aspect of the present disclosure, should not be taken to mean that the terminology is redefined herein to be limited to include any particular feature of the relevant feature or aspect of the present disclosure. Terms and phrases used in this application, and variations thereof, should be construed as open ended as opposed to limiting, unless expressly specified otherwise, particularly in the appended claims. As examples of the foregoing, the term "including" should be read to mean "including, but not limited to," "including, but not limited to," etc.; the term "comprising," as used herein, is synonymous with "including," "containing," or "characterized by," is inclusive or open-ended, and does not exclude additional, unrecited elements or method steps; the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including, but not limited to," and the term "examples" is used to provide illustrative instances of the item under discussion, and Rather than being an exhaustive or exclusive list, adjectives such as "known," "conventional," "standard," and terms of similar import should not be construed to limit the described items to those available during a given period or at a given time, but instead should be read to encompass known, conventional, or standard technology that may now or later be available or known; and the use of terms such as "preferably," "suitable," "desired," or "desirable," and words of similar import, should not be understood as implying that a particular feature is critical, essential, or even important to the structure or function of the invention, but instead is intended to merely highlight alternative or additional features that may or may not be utilized in a particular embodiment of the invention.Similarly, groups of items joined by the conjunction "and" should not be read as requiring each and every one of the items to be present in the group, but rather should be read as "and / or" unless expressly stated otherwise. Similarly, groups of items joined by the conjunction "or" should not be read as requiring mutual exclusivity between the group, but rather should be read as "and / or" unless expressly stated otherwise.

[0339] Where a range of values ​​is provided, it is understood that the upper and lower limits of the range, and each intervening value between the upper and lower limits, are encompassed within an embodiment.

[0340] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can translate from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for clarity. The indefinite articles "a" or "an" do not exclude plurals. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.

[0341] Where the recitation of a specific number of introduced claims is intended, such intention will be clearly recited in that claim; it will further be understood by those skilled in the art that, in the absence of such a recitation, no such intention exists. For example, as an aid to understanding, the following appended claims may include the use of the introductory clauses "at least one" and "one or more" to introduce claim recitations. However, the use of such clauses should not be construed as meaning that introducing a claim recitation with the indefinite article "a" or "an" means that any particular claim including such an introduced claim recitation is limited to embodiments including only one such recitation (e.g., "a" and / or "an" should typically be construed to mean "at least one" or "one or more"). This also applies to the use of definite articles used to introduce claim recitations, even when the same claim includes the introductory clause "one or more" or "at least one" and an indefinite article such as "a" or "an." Furthermore, even if a particular number of enumerations in an introduced claim are expressly recited, one of ordinary skill in the art will understand that such enumeration should typically be interpreted to mean at least the number recited (e.g., the explicit recitation of "two enumerations" without other modifiers typically means at least two enumerations, or more than two enumerations). Furthermore, in those cases where a convention similar to "at least one of A, B, and C, etc." is used, such an interpretation is generally intended in the sense that one of ordinary skill in the art would understand the convention to include any combination of the recited items, including, for example, a single element (e.g., "a system having at least one of A, B, and C" would include, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.).In those instances where a convention similar to "at least one of A, B, or C, etc." is used, such interpretation is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those of ordinary skill in the art that virtually any disjunction and / or clause presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, neither of the terms, or both terms. For example, the phrase "A or B" would be understood to include the possibilities of "A" or "B" or "A and B."

[0342] All numbers expressing quantities of ingredients, reaction conditions, and the like used herein are understood to be modified in all instances by the term "about." Accordingly, unless indicated to the contrary, the numerical parameters set forth herein are approximations that may vary depending upon the desired properties sought to be obtained. In any event, and not as an attempt to limit the application of the doctrine of equivalents to the scope of any claims of any prior asserted application, each numerical parameter should be construed in light of the considerable number of digits and ordinary rounding approaches.

[0343] All references cited herein are incorporated by reference in their entirety. To the extent that publications and patents or patent applications incorporated by reference conflict with the present disclosure contained herein, the present specification is intended to supersede and / or supersede any such conflicting material.

[0344] Headings are included herein for reference and to aid in locating the various portions. These headings are not intended to limit the scope of the concepts described therein. Such concepts may have applicability throughout the entire specification.

[0345] Moreover, while the foregoing has been described in some detail by way of illustration and example for purposes of clarity and understanding, it will be apparent to those skilled in the art that certain changes and modifications may be practiced. Therefore, the descriptions and examples should not be construed as limiting the scope of the invention to the specific embodiments and examples described herein, but rather also include all modifications and alternatives that come within the true scope and spirit of the invention. [Explanation of symbols]

[0346] 2. Drug delivery pump 4 Reference meter 8 Sensor System 10 Continuous Analyte Sensors 12 Sensor Electronics 14 Display Devices 16 devices 18. Mobile Devices 20. Computer Devices 21 Wearable Devices 22 Cloud-based processors 24 Network 26 Numbers 200 Electronic Devices 202 Display device

Claims

1. 1. A method for assessing an emergency condition of a user related to a physiological condition, comprising: a. receiving a first type of data related to a physiological condition; b. calculating a second type of data related to the physiological condition; c) receiving a third type of data related to the physiological condition; d. determining an urgency index based at least on the received data of the first type, the second type, and the third type; e. providing a display of said determined urgency index on a mobile device.

2. The method of claim 1 , wherein the physiological condition is diabetes, the urgency index is a glycemic urgency index, and the first type of data is a glucose concentration.

3. The method of claim 2 , wherein the glucose concentration is a currently measured glucose concentration, a previously measured glucose concentration, or a future predicted glucose concentration.

4. 4. The method of claim 1, 2, or 3, wherein the second type of data is derived from the first type of data.

5. 5. The method of claim 4, wherein the second type of data derived from the first type of data is a first or second derivative with respect to time of the first type of data.

6. 5. The method of claim 4, wherein the second type of data derived from the first type of data includes deviations from a normal glucose pattern, pattern data of glucose values ​​over time, predicted glucose values, duration that glucose values ​​are within a specified range, weighting of parameters or variables considered in determining the urgency index, or local maxima or minima of the first type of data.

7. The method of any preceding claim, wherein said receiving said third type of data comprises receiving data entered by a user.

8. The method of claim 7 , wherein said receiving comprises receiving data entered by a user on a user interface of a mobile device.

9. 9. The method of claim 7 or 8, wherein the physiological condition is diabetes, the urgency index is a glycemic urgency index, the first type of data is a glucose concentration, and the received data entered by the user includes the user's weight, a user's indication of activity level, a user's indication of food or beverages ingested or to be ingested, anthropometric data, data regarding previous insulin provided to the user, stress data, health data, data regarding placement of sensors measuring the first type of data, age, or gender.

10. 10. The method of claim 7, 8, or 9, wherein the received data input by the user includes a user indication of food or beverages ingested or to be ingested, or data regarding insulin provided to the user or before being provided to the user, and further comprising determining that the glycemic urgency index is of less urgency based on the received data.

11. The method of any preceding claim, wherein said receiving said third type of data comprises receiving data from a sensor.

12. 12. The method of claim 11, wherein the physiological condition is diabetes, the urgency index is a glycemic urgency index, the first type of data is a glucose concentration, and the sensor includes at least one of a scale, a glucometer, a thermometer, an accelerometer, a camera, a GPS device, or a microphone.

13. 13. The method of claim 12, wherein the received third type of data includes a user's weight, a user's indication of activity level, an indication of food or beverages consumed or to be consumed, anthropometric data, data regarding previous insulin provided to the user, physiological data, stress data, or health data.

14. 14. The method of any of claims 1 to 13, wherein the receiving of the third type of data includes receiving data from a query processing engine, an electronic device configured for machine-to-machine interaction, or an electronic user record.

15. The method of any preceding claim, wherein the third type of data is received from the mobile device and corresponds to a level of user interaction with an application, and the indication is provided through the application.

16. The method of any preceding claim, further comprising providing a warning or alert if the urgency index reaches a defined warning or alarm threshold, respectively.

17. 17. The method of claim 16, wherein the urgency index is a glycemic index and the predetermined warning or alert threshold indicates that the user is in a hypoglycemic or hyperglycemic state.

18. The method of claim 1 , wherein the physiological condition comprises one or more of obesity, malnutrition, hyperactivity, depression, or fecundity.

19. The method of any preceding claim, further comprising providing an intelligent output based on the received input.

20. A system for carrying out the method of any preceding claim, optionally including computer-implemented control means arranged to carry out said method.

21. 1. A method for determining a user emergency condition related to a physiological condition, comprising: determining an urgency index based on an analyte concentration and at least two variables selected from the group consisting of a first time derivative or a second time derivative of the analyte concentration, a duration that the analyte concentration occupies a specified range, a duration that the first time derivative or the second time derivative of the analyte concentration occupies a specified range, a past or future meal intake parameter input by a user, and a past or future drug parameter input by a user or received from an integrated pump; b) storing the determined urgency index in a storage device of the mobile device.

22. 22. The method of claim 21, further comprising displaying or otherwise outputting the urgency index on a user interface of the mobile device.

23. 23. The method of claim 22, wherein the displaying step further comprises ignoring other applications or processes operating on the mobile device such that the display of the urgency index is displayed without regard to other running applications or processes.

24. 23. The method of claim 22, wherein the displaying is effected by a user action, the user action being selected from the group consisting of holding the mobile device, unlocking the mobile device, or performing a swipe action on the mobile device.

25. 25. The method of claim 21, 22, 23, or 24, wherein the representation of the urgency index is a drawn element.

26. The method of claim 25 , wherein the drawn element includes a color.

27. The method of claim 25 , wherein the drawn element comprises an icon.

28. 28. The method of claim 27, wherein the icon position, size, or color is based on the urgency index.

29. a. receiving an indication that a user has activated the icon; 29. The method of claim 27 or 28, further comprising: b. displaying additional information or advanced output regarding the urgency index.

30. 30. The method of claim 26, 27, 28, or 29, wherein the rendered element is rendered as at least a portion of a home screen or background native to the operating system of the mobile device.

31. 31. The method of any one of claims 21 to 30, wherein the analyte is glucose, the urgency index is a glycemic urgency index, and the drug parameter corresponds to insulin.

32. 32. The method of claim 31, further comprising rendering a series of elements on the user interface of the mobile device, the series of elements indicating past or predicted future values ​​of glucose concentration.

33. The method of claim 22 or any one of claims 23 to 32 as dependent on claim 22, wherein the indication of the urgency index includes an audible or visual alert, respectively drawn or sounding, on the mobile device.

34. The method of any one of claims 21 to 33, further comprising displaying a prompt to a user to input data so that user data can be related to the urgency index.

35. 35. The method of claim 34, wherein the prompt for a user to enter data indicates a type of data, the type of data being selected from the group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or emotional data.

36. The method of any one of claims 21 to 35, further comprising displaying at least one possible action a user may take in response to said display of said urgency index.

37. The method of claim 22 or any one of claims 23 to 36 as dependent on claim 22, wherein the indication includes an actionable warning.

38. The method of claim 22 or any one of claims 23 to 37 as a dependent claim of claim 22, wherein the display includes displaying a bandwidth occupancy rate, the bandwidth corresponding to a specified range of urgency index values.

39. The method of any one of claims 21 to 38, further comprising transmitting the stored urgency index to an integrated pump.

40. The method of any one of claims 21 to 39, further comprising: converting the stored urgency index into a pump operation; and transmitting the pump operation to an integrated pump.

41. A system for carrying out the method of any of claims 21 to 40, optionally including computer-implemented control means arranged to carry out said method.

42. 20. A device substantially as shown and / or described herein and / or in the drawings.

43. 10. A system substantially as herein shown and / or described in the specification and / or drawings.

44. 20. A method substantially as hereinbefore shown and / or described in the specification and / or drawings.

45. 1. An electronic device for monitoring data related to a physiological condition, comprising: a. a continuous analyte sensor configured to substantially continuously measure a concentration of an analyte in a host, the continuous analyte sensor providing continuous sensor data related to the analyte concentration in the host; b. a processor module configured to perform any one of the methods of claims 1-19, 21-40, or 44.

46. 46. ​​The device of claim 45, wherein the analyte is glucose.

47. 1. An electronic device for delivering a drug to a host, comprising: a drug delivery device configured to deliver a drug to the host, the drug delivery device operably connected to a continuous analyte sensor, the continuous analyte sensor configured to substantially continuously measure a concentration of the analyte in the host and provide continuous sensor data related to the analyte concentration in the host; b. a processor module configured to perform any one of the methods of claims 1-19, 21-40, or 44.

48. 48. The device of claim 47, wherein the analyte is glucose and the drug is insulin.

Images