Blood Glucose Urgency Assessment 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 claim of priority, or any correction thereto, identified in the data sheet of this application is hereby incorporated by reference herein under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Patent Application No. 61 / 978,151, filed Apr. 10, 2014. The foregoing application is hereby incorporated by reference in its entirety and made a part hereof.

[0002] This embodiment relates to continuous analyte monitoring, specifically, signal analysis and result presentation of a continuous analyte monitoring system.

Background Art

[0003] Diabetes mellitus is a disorder in which the pancreas is unable to produce sufficient insulin (type I or insulin-dependent) and / or insulin is ineffective (type II or non-insulin-dependent). In a diabetic state, the victim suffers from hyperglycemia, which can lead to numerous physiological disorders associated with deterioration of small blood vessels, such as kidney failure, skin ulcers, or bleeding into the vitreous humor of the eye. Hypoglycemic reactions (low blood sugar) can be induced by inadvertent overdose of insulin or following the normal administration of insulin or glucose-lowering agents accompanied by extraordinary exercise or inadequate food intake.

[0004] Conventionally, people with diabetes carry a self - monitoring blood glucose (SMBG) monitor, which generally requires an uncomfortable finger - prick method. Due to the lack of comfort and convenience, people with diabetes usually measure their glucose levels only 2 to 4 times a day. Unfortunately, such time intervals are widely spaced such that people with diabetes are highly likely to miss the discovery of hyperglycemic or hypoglycemic conditions, sometimes suffering dangerous side effects. Not only is it less likely for people with diabetes to notice a dangerous condition in time and deal with it, but people with diabetes are also highly likely not to understand whether their blood glucose level is rising (higher) or falling (lower) based on the conventional method. Thus, it can prevent people with diabetes from making knowledge - based insulin - treatment decisions.

[0005] Another device that some people with diabetes have used to monitor their blood glucose is a continuous analyte sensor, such as a continuous glucose monitor (CGM). CGM typically includes sensors that are placed invasively, minimally invasively, or non - invasively. The sensor measures a given analyte in the body, such as glucose, and generates a raw signal that is generated by an electronic device 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 generally presented in a form that provides meaningful information to the user and in a form that the user is familiar with for analysis, such as blood glucose expressed in mg / dL. SUMMARY OF THE INVENTION

[0006] This embodiment has several features, none of which alone causes these desirable attributes. Without limiting the scope of this embodiment as expressed by the following claims, these further excellent features will be discussed more briefly herein. After considering this discussion, especially after reading the section specifically entitled "Detailed Description", the reader will understand how the features of this embodiment provide the advantages described herein.

[0007] Systems and methods are disclosed for determining and / or calculating a Glucose Urgency Index (GUI) using a number of variables or parameters, which may be based in part on measured glucose values, which generally includes consideration of other factors. Other factors may include the first and / or second derivatives of the glucose value with respect to time, and / or other factors described hereinafter, such as data entered by the user, data measured by other sensors, or received from network sources, or past data. The GUI is then presented to the user on a mobile device, such as a smartphone, by means of, for example, a background color or other unobtrusive notification means, in a means that is attention-grabbing. In this way, the GUI can be continuously presented to the user (whenever the display screen is on or otherwise activated). The GUI can also be used to activate actionable warnings and alerts (or other outputs) on an electronic device for the user. The GUI, or another index calculated from the combination of variables and parameters described, can also be used to drive a drug delivery device, such as a pump. Generally, a given GUI will generally result in the same notification (or actionable warning) for a given user, but depending on factors such as electrical sensitivity, how the user has configured their electronic device, the mode the user has permitted on the device, etc., the user will see variations in the notification means or warnings.

[0008] More specifically, the first type of data can be received in relation to a physiological state. For example, the glucose concentration in a functional relationship with the GUI of a patient having diabetes can be measured. Then, a second type of data can be received, or in some cases, for example, the rate of change over time of the first type of data can be calculated. In the case of diabetes management, the second type of data can be the rate of change of the glucose concentration (i.e., whether the concentration is rising or falling and how fast). The second type of data can also be the acceleration of the glucose concentration, for example, which can indicate an improvement in the glucose concentration. In addition to the rate of change over time, the second type of data can include pattern data, deviations from a normal glucose pattern, predicted glucose values, the duration for which the glucose value (or its rate of change over time) is within a specified range, or maximum or minimum values, etc. Similar to the first type of data, the second type of data is in a functional relationship with the GUI. For example, in some cases, while the second type of data is obtained from or calculated from the first type of data, the second type of data is a dependent variable, i.e., an independent variable that affects the determination of the GUI.

[0009] A third type of data can also be received, and these correspond to other elements in addition to the analyte concentration and parameters obtained therefrom. For example, data entered by a user can be of the third type, and for example, the data can correspond to health, exercise, dietary data, drug infusion data, or a number of other inputs. In some cases, the third type of data can be received from a motion application that can indicate exercise performed by a user running on another device, such as a GPS or mobile device. Other applications can be used to monitor things such as dietary intake. An automated drug delivery device can also be interfaced with the system, for example, to indicate insulin pump operation for consideration in GUI decisions. Similarly, the GUI can affect pump operation. Similar to the first and second types of data, the third type of data is in a functional relationship with the GUI. Specifically, the third type of data is generally a dependent variable, that is, an independent variable that affects the decisions of the GUI (although it should be noted that it can characterize parameters and variables that can have some interrelationship between the parameters and variables themselves).

[0010] The display of the GUI can be presented to the user on a user interface, for example, on a mobile device such as a smartphone. The GUI can be presented by means such as natural appearing features, for example, a background color or design that does not need to overtly indicate 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 can perform an operation such as an unlock operation, a swipe operation, or other application operations to read out additional details about, for example, how urgent the situation is, related measurements and parameters indicating the situation, steps that may be taken to improve the situation, etc. When the GUI is presented by design, the features of the design can graphically (but often not numerically) show current values, for example, glucose concentration, which direction the value is changing, whether the value is improving, past values in the recent past, etc. The user interface can allow the user to also input parameters and variables, which can then affect the determination of the GUI.

[0011] A monitoring device, for example, a CGM, can be embodied as an application running on a mobile device, for example, a smartphone, and as something downloadable to the mobile device. The application can specifically execute an urgency assessment module, perform a refined assessment of the urgency of the user's blood glucose situation, and generally a "higher" assessment is related to a state of "higher" urgency or "higher" risk. The mobile device can present continuous notifications or presentations of the GUI display and, if a valid reason is given, also provide warnings or alerts.

[0012] In a first aspect, the present invention relates to a method for assessing a user's emergency state related to a physiological state, including receiving first type of data related to the physiological state, calculating second type of data related to the physiological state, receiving third type of data related to the physiological state, determining an emergency degree index based at least on the received first type, second type, and third type of data, and providing a display of the emergency degree index determined on a mobile device.

[0013] The first type of data can be an analyte from a continuous analyte sensor implanted in the body, such as glucose data. The second data can be the first-order time derivative and / or second-order time derivative of the first data. The third data can be data external to the analyte data from the sensor, which represents a factor affecting the health risk of the physiological state reflected by the analyte in the body, for example, a factor affecting the risk of extreme hyperglycemia or hypoglycemia states reflected by the glucose data sensed by the continuous analyte data. Specifically, the third data can represent a factor that affects the analyte level reflecting the physiological state and thereby affects the health risk.

[0014] The mobile device may be a smartphone.

[0015] The method may include outputting an audible and / or tactile warning on the mobile device, and / or when the emergency degree index reaches or exceeds a threshold indicating a physiological state that has reached a health-risk state, for example, indicating the risk of extreme hypoglycemia or hyperglycemia states, the display of the emergency degree index is displayed on the mobile device regardless of other running applications or processes, ignoring other applications or processes running on the mobile device unless an adjustment operation is taken by the user.

[0016] The method may include providing a display on a mobile device such that the display is visible to a user even before passing through a lock screen of the mobile device, at least when an urgency index indicates a high urgency regarding a physiological state.

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

[0018] The urgency assessment module may obtain analyte data representing a physiological state as input, such as glucose data representing the state of a diabetic patient, as a first type of data, and as the analyte data input approaches a health risk of the physiological state, such as 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 obtain first derivative data and / or second derivative data as input as a second type of data, and adjust the urgency index to a value representing a lower urgency when the first derivative data and / or second derivative data indicate that a health risk, such as a risk of extreme hyperglycemia or hypoglycemia, is abating, or to a value representing a higher urgency when the first derivative data and / or second derivative data indicate that a health risk, such as a risk of hyperglycemia or hypoglycemia, is worsening.

[0020] The urgency assessment module obtains, as a third type of data, external data related to the user or other operations that will potentially affect the analyte data in the future. When the effect of the user or other operations on the analyte data will mitigate the analyte level with respect to health risk, the input external data tends to adjust the urgency index to a value representing a lower risk. When the effect of the user or other operations on the analyte data will worsen the analyte level with respect to 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 (regardless of whether it is through an in-body pump or an external injector), and / or the time of food / drink intake, and / or the time when the user performs exercise. The health risk is the risk of extreme hyperglycemia or hypoglycemia, and the analyte is blood glucose.

[0021] The urgency assessment module may obtain, as a second type of data, duration data as input. The duration data represents the time during which the analyte data is outside the normal range defined with respect to the physiological state, for example, the duration during which the analyte data continuously represents a hyperglycemic state or a hypoglycemic state. The duration data tends to adjust the urgency index such that a higher urgency is determined as the duration increases.

[0022] The step of determining the urgency index may include using a mathematical risk function having each term of the analyte data, the first-order time derivative of the analyte data, and the second-order time derivative of the analyte data, and / or the duration during which the analyte data is outside the normal range with respect to the physiological state. The data forming the terms constitutes 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 state may be diabetes, the urgency index may be a blood glucose urgency index, and the first type of data may be a glucose concentration. The glucose concentration may be the currently measured glucose concentration, the previously measured glucose concentration, or the predicted future glucose concentration.

[0024] The second type of data, such as the first derivative or the second derivative with respect to time, can be obtained from the first type of data. The second type of data obtained from the first type of data may further include a deviation from a normal glucose pattern, pattern data of glucose values over time, predicted glucose values, the duration for which the glucose value is within a specified range, the weighting of parameters or variables considered in the determination of the urgency index, or the maximum or minimum value of the first type of data.

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

[0026] When the physiological state is diabetes, the urgency index may be a blood glucose 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, user indication of activity level, user indication of food or beverage consumed or to be consumed, body measurement data, data regarding the previous insulin provided to the user, stress data, health data, data regarding the placement of the sensor for measuring the first type of data, age, or gender. The received data input by the user may include the user indication of food or beverage consumed or to be consumed, or data regarding the previous insulin provided or to be provided to the user, and may further include modifying the determined blood glucose urgency index to be of lower urgency based on the received data.

[0027] Receiving the third type of data may include receiving data from a sensor. When the physiological state is diabetes, the urgency index may be a blood glucose urgency index, the first type of data may be a glucose concentration, and the sensor may include at least one of a scale, a blood glucose meter, 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 display of the activity level, a display of food or beverage consumed or to be consumed, body measurement data, data regarding previous insulin administered to the user, physiological data, stress data, or health data. Receiving the third type of data may also include receiving data from an interrogation processing engine, an electronic device configured for machine-to-machine communication, or an electronic user record. The third type of data may be received from a mobile device, may correspond to the level of user interaction with an application, and the display is provided through the application.

[0028] The method may further include providing a warning or an alarm when the blood glucose urgency index reaches a respective predefined warning threshold or alarm threshold. Such predefined warning thresholds or alarm thresholds may indicate that the user is in a hypoglycemic or hyperglycemic state.

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

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

[0031] The step of providing the display may include displaying a display of the urgency index on the user interface of the mobile device. The step of displaying may further include ignoring other applications or processes operating on the mobile device so that the display of the urgency index is displayed regardless of other running applications or processes.

[0032] When the step of displaying is brought about by a user's operation, the user's operation may be selected from the group consisting of holding the mobile device, unlocking the mobile device, or performing a swipe operation on the mobile device.

[0033] The display of the urgency index may be a drawn element, e.g., a color, and the drawn element is drawn as at least a part of the home screen or background that comes pre - equipped in the operating system of the mobile device. When the drawn element is colored, the color varies according to the urgency index. The drawn element may also be an icon, and in that case, the position, size, or color of the icon is based on the urgency index.

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

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

[0036] The step of providing the display may further include a rendering function as follows. For example, a series of elements may be rendered on the user interface of the mobile device, and the series of elements indicate past or predicted future values of glucose concentration. The display of the urgency index may be a visual warning that is rendered on the mobile device respectively or an audible warning that emits sound. The method may further include displaying an input request for the user to input data so that the user data may be related to the urgency index. The input request for the user to input data may indicate the type of data, and the type of data may be selected from the group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or mood data, which may be utilized to form a third data. The method may further include displaying at least one possible operation that the user may perform in response to the displayed display of the urgency index. The display may be a treatable warning. The display of the display may include displaying the occupancy of the band, and the band corresponds to a specified range of the urgency index value.

[0037] The method may further include storing the determined urgency index in the storage device of the mobile device. The method may 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.

[0038] The method may also include displaying the current analyte data value indicating the physiological state and / or displaying whether the trend of the analyte date 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 generally upward arrows indicating an increasing trend and generally downward arrows indicating a decreasing trend, and optionally the angle of the arrow indicates the amount of change, and the more vertical indicates a greater amount of change.

[0039] The display of the urgency index can be provided by changing the color according to the urgency. Red can be selected to indicate the highest emergency state.

[0040] In a second aspect, the present invention relates to a system for implementing any of the above methods of the first aspect.

[0041] In a third aspect, the present invention relates to a method for determining an urgency index related to a physiological state, comprising determining the urgency index based on at least two variables selected from the group consisting of an analyte concentration, a first time derivative or a second time derivative of the analyte concentration, a duration for which the analyte concentration occupies a specified range, a duration for which 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 for which the second time derivative of the analyte concentration occupies a specified range, past or future dietary intake parameters input by a user, past or future drug parameters 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 requiring an intervening operation to bring the analyte concentration from a higher health risk level to a lower health risk level with respect to the physiological state.

[0044] Implementation examples 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 so that the display of the urgency index is displayed regardless of other running applications or processes.

[0045] If the step of displaying is brought about by a user's operation, the user's operation can be selected from the group consisting of holding the mobile device, unlocking the mobile device, or performing a swipe operation on the mobile device.

[0046] The display of the urgency index can be a drawn element, such as a color, and the color is drawn as at least a part of the home screen or background that is originally provided in the operating system of the mobile device. The drawn element can also be an icon, and in that case, the position, size, or color of the icon is based on the urgency index.

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

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

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

[0050] The display of the urgency index can be provided and can be drawn on the mobile device respectively, or can be an audible or visual warning that emits a sound.

[0051] The method may further include displaying an input request to the user to input data such that the user data may be related to an urgency index. The input request for the user to input data may indicate the type of data, and the type of data may be selected from the group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or mood data. The method may further include displaying at least one possible action that the user may perform in response to the displayed display of the urgency index. The display may be an actionable warning. The action may be to adjust the health risk such that, when the risk of urgency is high, the analyte concentration is brought towards an acceptable level above normal with respect to the health risk presented by the physiological state. The display of the display may include displaying the occupancy of a band, where the band corresponds 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 may be a pump for delivering a drug for treating a physiological state.

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

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

[0055] The mobile device may be a smartphone.

[0056] This method may include outputting audible and / or tactile warnings on a mobile device, and / or ignoring other applications or processes operating on the mobile device so that, unless an adjustment operation is taken by the user, the display of the urgency index is displayed on the mobile device regardless of other running applications or processes when the determined urgency index reaches or exceeds a threshold indicating a physiological state that has reached a health-risk state, for example, a risk of extreme hypoglycemia or hyperglycemia.

[0057] This method may include providing a display of an emergency risk on the mobile device such that the display is visible to the user even before passing through the lock screen of the mobile device, at least when the urgency index indicates a high urgency regarding the physiological state.

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

[0059] The urgency assessment module may obtain an analyte concentration as input, and as the data approaches a health risk of a physiological state, for example, a risk of extreme hyperglycemia or extreme hypoglycemia, the analyte concentration input tends to adjust the urgency index to a value representing a higher urgency.

[0060] The urgency assessment module may obtain a first time derivative and / or a second time derivative as input, and by means that tend to adjust the urgency index to a value representing a lower urgency when the first time derivative and / or the second time derivative indicate that the health risk, for example, the risk of extreme hyperglycemia or hypoglycemia of the physiological state, is abating, or a higher urgency when the first derivative and / or the second derivative indicate that the health risk, for example, the risk of hyperglycemia or hypoglycemia of the physiological state, is worsening.

[0061] The urgency assessment module may obtain, as input, external data including past or future dietary intake parameters entered by a user, or past or future drug parameters entered by or received from an integrated pump by the user. The input external data has a tendency to adjust the urgency index to a value representing a lower risk when the effect of drug or dietary intake on analyte concentration mitigates the analyte level with respect to the health risk of the physiological state, and the input external data has a tendency to adjust the urgency index to a value representing a higher risk when the effect of drug or dietary intake on analyte concentration worsens the analyte level with respect to the health risk. In one embodiment, the drug parameter represents the time and / or amount of insulin infusion into the body (regardless of whether through a pump in the body or an external injector), and the dietary intake parameter represents the time and / or amount of food / beverage intake.

[0062] At least two variables may include at least one of first time derivative data and second time derivative data and dietary intake parameters and drug parameters.

[0063] The urgency assessment module may additionally or alternatively obtain, as input, an indicator of the duration that the analyte concentration occupies a defined range representing the normal range with respect to the physiological state, e.g., the duration that the analyte data continuously represents a normal blood glucose state. The duration indicator has a tendency to adjust the urgency index such that a higher urgency is determined as the duration increases.

[0064] The step of 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 occupied the defined range.

[0065] Implementations of the third aspect may further include one or more of the following. The physiological state may be diabetes, the urgency index may be a blood glucose urgency index, and the analyte concentration may be a glucose concentration. The glucose concentration may be the currently measured glucose concentration.

[0066] The method may include receiving dietary intake parameters and / or drug parameters based on corresponding data input by the user on a user interface of a mobile device or the like.

[0067] The method may further include providing a warning or an alarm when the blood glucose urgency index reaches a respective predefined warning threshold or alarm threshold. Such predefined warning thresholds or alarm thresholds may indicate that the user is in a hypoglycemic or hyperglycemic state.

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

[0069] In a fourth aspect, the present invention pertains to a system for implementing any of the above methods of the third aspect.

[0070] In a fifth aspect, the present invention pertains to a device, system, or method substantially shown in this specification and / or the drawings.

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

[0072] In a seventh aspect, the present invention pertains to an electronic device for delivering a drug to a host, the drug delivery device being a drug delivery device configured to deliver a drug to the host, the drug delivery device being operably connected to a continuous analyte sensor, the continuous analyte sensor being configured to substantially continuously measure the concentration of an analyte in the host and provide continuous sensor data related to the analyte concentration in the host, and a processor module configured to implement any one of the methods described above.

[0073] For ease of understanding the functions described, continuous glucose monitoring is used as part of the following explanation. It will be understood that the systems and methods described are also applicable to other continuous monitoring systems. For example, the functions discussed can be used for continuous monitoring of lactate, free fatty acids, heart rate during exercise, IgG - antigliadin, insulin, glucagon, exercise tracking, reproductive ability, calorie intake, hydration, salt concentration, sweat / sweating (stress), ketones, adiponectin, troponin, sweating, and / or body temperature. When glucose monitoring is used as an example, one or more of these alternatives for monitoring the state can be substituted. Thus, while a GUI is described above, in a similar system, a lactose urgency index, a ketone urgency index, etc. can be defined.

[0074] Any of the functions of the embodiments of the various aspects disclosed is applicable to all the aspects and embodiments specified. Further, any of the functions of the embodiments can be partially or completely combined with other embodiments described herein by any means, for example, one, two, or three or more embodiments may be combinable in whole or in part. Furthermore, any of the functions of the embodiments of the various aspects may be optional in other aspects or embodiments. Any aspect or embodiment of a method may be implemented by a system or apparatus of another aspect or embodiment, and any aspect or embodiment of a system may be configured to implement a method of another aspect or embodiment.

[0075] The advantages of the system and method according to this principle may include one or more of the following. A user can receive a display of the user's urgency assessment at any time upon a glance at the user's phone. Similarly, by using an intelligent algorithm that takes into account a number of inputs in the determination of a blood glucose emergency state, a user can receive more actionable warnings, reduce the occurrence of nuisance warnings, and increase the use of CGM. Since the urgency assessment is based on inputs not previously considered by the warning algorithm, the blood glucose urgency index may correlate better with the patient's clinical diabetes management rather than being necessarily correlated with only glucose concentration (or derivative) information. A user can be safely and prudently warned of a blood glucose emergency state by means of engaging and customizable means, as well as by means of a user interface that is inherently provided in a device that the user likely already carries, such as a mobile device. Other advantages will become apparent from the following description, including the figures and the claims.

Brief Description of the Drawings

[0076] This embodiment will be discussed in detail while focusing on highlighting more beneficial functions. These embodiments depict new and non-obvious urgency evaluations and user interfaces shown in the accompanying drawings for illustrative purposes only. These drawings include the following figures, and like numerals in the figures indicate like parts.

[0077]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 13

Figure 14

Figure 15A

Figure 15B

Figure 15C

Figure 15D

Figure 15E

Figure 15F

Figure 16A

Figure 16B

Figure 17A

Figure 17B

Figure 18A

Figure 18B

Figure 19A

Figure 19B

Figure 20A

Figure 20B

Figure 21A

Figure 21B

Figure 22A

Figure 22B

Figure 23

Figure 24

Figure 25A

Figure 25B

Figure 26

Figure 27A

Figure 27B

Figure 28A

Figure 28B

Figure 29

Figure 30

Figure 31A

Figure 31B

Figure 32A

Figure 32B

Figure 32C

[0078] Consider a particular example of continuous glucose monitoring. For a diabetic patient, glucose monitoring can literally be a matter of life and death. However, the blood glucose values presented on a CGM can be unclear. For example, three users can all have the same blood glucose value measured by a CGM, but each may require different treatments depending on whether the blood glucose value is decreasing, remaining the same, or increasing. This is particularly true since current CGMs activate warnings based on low and / or high thresholds, e.g., thresholds of predicted or actual glucose concentrations that sometimes include consideration of the rate of change. Predicted values are generally strongly influenced by noise, and the use of warnings based on such thresholds does not provide the user with much sufficient time to react before encountering a dangerous or risky situation.

[0079] For example, and referring to FIG. 1, a warning for a standard hypoglycemia threshold can be set at 70 mg / dL. If a user's glucose level is dropping rapidly, such a low threshold warning may not be able to provide the user with sufficient time to prevent a very low glucose level, e.g., less than 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 dropping below 55 mg / dL. It is clear from the CGM output record of FIG. 1 that for 30 minutes before dropping below 55 mg / dL, the user was dropping at an average rate of change of 2.5 mg / dL / min and was in a very dangerous situation well before the user reached the 70 mg / dL threshold.

[0080] While it is always possible to increase the sensitivity of a sensor, such an increase often leads to false alarms and is accompanied by "warning fatigue" among users. This is especially true in the case of a smartphone where monitoring is already warning the user via multiple means, such as application notifications, text messages, emails, etc. For example, in an effort to ensure that there is sufficient time to prevent a very low glucose level, if the low threshold is set higher, for example, at 80 or 90 mg / dL, such a setting will likely lead to many false alarms. As another example, and referring to FIG. 2, there is no need to warn about a stable glucose level that is fluctuating around 80 mg / dL, but if the threshold is set at 80 mg / dL, many warnings will be triggered.

[0081] Furthermore, while current systems can present warnings to the user based on blood glucose values and thresholds, the user interfaces associated with such systems do not meet the user's expectations. The lack of reliable warnings and the lack of a safe and careful user interface both impede the use and adoption of such monitoring.

[0082] Similarly, current systems that integrate insulin pump operation with CGM make decisions such as withholding basal insulin using a simple glucose threshold. However, a simple glucose threshold cannot provide sufficient information about the user's emergency situation. For example, using a threshold of 70 mg / dL to withhold insulin delivery may be appropriate when glucose is decreasing gradually, but when glucose is dropping rapidly, it may be more appropriate to withhold insulin when glucose is 100 mg / dL, or even earlier if there is a large amount of residual insulin or recent exercise. Even interruptions based solely on predicted glucose values have the disadvantage of many false positives.

[0083] Other aspects related to measuring blood glucose and providing warnings related thereto are described in co-pending U.S. Patent Application No. 13 / 742,694, filed January 16, 2013, entitled "SYSTEMS AND METHODS FOR PROVIDING SENSITIVE AND SPECIFIC ALARMS," owned by the applicant of the present application, and are hereby incorporated by reference in their entirety.

[0084] One non-limiting advantage of the features described herein is to provide warnings and alerts that are more useful, i.e., more "actionable," to the user in terms of the appropriate actions to be taken that the user can notice or easily infer in view of the warning or alert. Such warnings and alerts are also more accurate in that they more correctly reflect the urgency assessment of the user's current blood glucose. In addition to providing actionable warnings and / or alerts, it can provide continuous notifications to the user of their urgency assessment, in a means that strongly arouses interest, using the user interface that is already inherently provided in devices that the device user already generally carries, such as mobile devices such as smartphones, and thus eliminates the need for the user to carry an additional device.

[0085] Various terms are described below.

[0086] The expression "continuous glucose sensor," as used herein, is a broad expression that provides its ordinary and customary meaning to those skilled in the art (and is not limited to a special or individualized meaning), and refers to, for example, a device that continuously or intermittently measures the glucose concentration in a body fluid (e.g., blood, plasma, interstitial fluid, etc.) at time intervals ranging from fractions of a second up to a maximum of, for example, 1, 2, or 5 minutes, or more, but is not limited thereto.

[0087] As used herein, the expressions "continuous glucose sensing" or "continuous glucose monitoring" are broad terms that provide those skilled in the art with their ordinary and customary meanings (and are not limited to special or individualized meanings), and for example, refer to a period during which the glucose concentration in a host's body fluid (e.g., blood, serous fluid, plasma, extracellular fluid, tears, etc.) is monitored continuously or intermittently at time intervals ranging from the fractional seconds up to a maximum of, for example, 1, 2, or 5 minutes, or more, but are not limited thereto. In one exemplary embodiment, the glucose concentration in the host's extracellular fluid is measured every 1, 2, 5, 10, 20, 30, 40, 50, or 60 seconds.

[0088] As used herein, the term "substantially" is a broad term that provides those skilled in the art with its ordinary and customary meanings (and is not limited to special or individualized meanings), and without limitation, refers to most but not necessarily all of a given thing, which may include an amount greater than 50 percent, greater than 60 percent, greater than 70 percent, greater than 80 percent, or 90 percent or more.

[0089] As used herein, the terms "processor" and "processor module" are broad terms that provide those skilled in the art with their ordinary and customary meanings (and are not limited to special or individualized meanings), and refer to a computer system, state machine, processor, etc. designed to perform arithmetic or logical operations using logic circuitry corresponding to or processing the basic instructions for operating a computer, but are not limited thereto. In some embodiments, the term may include ROM and / or associated RAM.

[0090] The exemplary embodiments disclosed herein relate to the use of a glucose sensor that measures the concentration of glucose or another analyte or the concentration of a substance indicative of the presence of an 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 can analyze 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., light absorption spectroscopy, Raman spectroscopy, etc.), polarimetric, calorimetric, electrophoretic, radiometric methods, 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 the raw data signal used to provide a useful value of the analyte to a user, such as a patient or a healthcare professional (e.g., a physician) who can use the sensor.

[0092] While many of the explanations and examples are directed to glucose sensors that can measure the concentration of glucose in a host, the systems and methods of the embodiments can be applied to any measurable analyte. Some of the exemplary embodiments described below utilize an implantable glucose sensor. However, it should be understood that the devices and methods described herein can be provided to any device that can detect the concentration of an analyte and provide an output signal representative of the concentration of the analyte.

[0093] As described, in some embodiments, the analyte sensor is, for example, an implantable glucose sensor as described with respect to U.S. Patent No. 6,001,067 and U.S. Patent Publication No. US-2011-0027127-A1. In some embodiments, the analyte sensor is, for example, a transcutaneous glucose sensor as described with respect to U.S. Patent Publication No. US-2006-0020187-A1. In yet another embodiment, the analyte sensor is, for example, a dual electrode analyte sensor as described with respect to U.S. Patent Publication No. US-2009-0137887-A1. In yet another embodiment, the sensor is configured to be implanted within a major blood vessel or extracorporeally and is described, for example, in U.S. Patent Publication No. US-2007-0027385-A1. These patents and publications are hereby incorporated by reference in their entirety.

[0094] The following description and examples explain this embodiment in relation to the drawings. In the drawings, reference numerals label the elements of this embodiment. These reference numerals are replicated below in connection with the discussion of the corresponding drawing functions.

[0095] FIG. 3 is a block diagram of an integrated system in a preferred embodiment, including a continuous glucose sensor and a drug delivery device. Such an integrated system is an example of an environment in which some of the embodiments described herein may be implemented. Here, the 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 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, may be integral with the continuous analyte sensor 10 (e.g., non-detachably attachable), or may be detachably attachable. Alternatively, the continuous analyte sensor 10 may be physically separated from the sensor electronics module 12, but is electrically coupled via inductive coupling or the like. Further, 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 execute an application including an 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 directly or indirectly on the network 24 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, 20. Based on the received data, the processor 22 can further process the data, generate a report providing statistics based on the processed data, activate notifications to an electronic device 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 exemplary implementations, the cloud-based processor 22 comprises one or more servers. If the cloud-based processor 22 comprises multiple servers, the servers may be geographically local or separated from each other. The network 24 may include any wired and wireless communication media for transmitting data including Wi-Fi networks, cellular networks, the Internet, and any combination thereof.

[0097] In some example implementations, the sensor electronics module 12 may include electronic circuitry related to the measurement and processing of data generated by the continuous analyte sensor 10. The continuous analyte sensor data generated thereby may also include algorithms, which 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. The sensor electronics module 12 may include hardware, firmware, software, or combinations thereof for providing measurements of analyte levels via a continuous analyte sensor, such as a continuous glucose sensor.

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

[0099] In FIG. 3, display device 14 is a key fob-like display device, display device 16 is a handheld special-purpose computer device 16 (e.g., the DexCom G4 (registered trademark) Platinum Receiver commercially available from DexCom, Inc.), display device 18 is a general-purpose smartphone or tablet computer device 20 (e.g., a phone running the Android (registered trademark) OS, the Apple (registered trademark) iPhone (registered trademark), iPad (registered trademark), or iPod touch (registered trademark) commercially available from Apple, Inc.), and display device 20 is a computer workstation 20. In some example implementations, the relatively small key fob-like display device 14 can be a computer device embodied in a wristwatch, belt, necklace, pendant, piece of jewelry, adhesive patch, pager, key fob, plastic card (e.g., a credit card), and / or identification document (ID), etc. This small display device 14 can include a relatively small display device (e.g., smaller than display device 18) and can be configured to display a limited set of displayable sensor information such as numerical value 26 and arrow 28. Some systems can also include, for example, a wearable device 21 described in U.S. Provisional Patent Application No. 61 / 904,341, titled "Devices and Methods for Continuous Analyte Monitoring," filed on Nov. 14, 2013, the entire disclosure of which is expressly incorporated herein by reference. The wearable device 21 can include any device(s) worn or integrated with the user's vision, clothing, and / or body.Examples of devices include wearable devices, anklets, glasses, rings, necklaces, armbands, pendants, belt clips, hair clips / rubber bands, pins, cuff buttons, tattoos, stickers, socks, sleeves, gloves, clothing (e.g., shirts, pants, underwear, bras, etc.), "clothing accessories" such as fastener knobs, buttons, watches, shoes, contact lenses, subcutaneous implants, glasses, cochlear implants, shoe insoles, orthotics (oral), orthotics (trunk), medical bandages, sports bands (wrist bands, head bands), hats, first aid tapes, false eyelashes, manicures, artificial joints / body parts, orthopedic pins / devices, implantable heart devices or nerve devices, etc. The small display device 14 and / or the wearable device 21 may include a relatively small display device (e.g., smaller than the display device 18), and may be configured to display graphical and / or numerical representations such as the numerical values 26 of sensor information and / or the arrows 28, etc. Conversely, the display devices 16, 18, and 20 may be larger display devices that can display a larger set of displayable information such as the trend graph 30 depicted on the handheld receiver 16 in addition to other information such as numerical values and arrows.

[0100] It is understood that any other user device (e.g., a computer 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] In some example implementations of FIG. 3, the continuous analyte sensor 10 includes a sensor for detecting and / or measuring an analyte, and the continuous analyte sensor 10 may be configured to continuously detect and / or measure the analyte as a non-invasive device, a subcutaneous device, a transdermal device, and / or an 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] In some example implementations of FIG. 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, electrophoretic, radiometric, immunochemical techniques, etc. In embodiments where the continuous analyte sensor 10 includes 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 the host, using various techniques for measuring glucose, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring). The data stream may be a raw data signal, which is converted into a calibrated and / or filtered data stream used to provide glucose values to a host, such as a user, patient, or caregiver (e.g., parent, relative, guardian, teacher, physician, nurse, or any other individual interested in the health of the host). Further, 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 major blood vessel or extracorporeally, a subcutaneous sensor, a refillable subcutaneous sensor, an intraocular, 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 the glucose level of a host.

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

[0105] FIG. 5 is a block diagram of the electronic device 200 shown in FIG. 4, illustrating the functional components of the electronic device 200 according to some embodiments. The electronic device 200 includes the display device 202 and one or more input / output (I / O) devices 204, 206 described above with respect to FIG. 4. The display device 202 can be any device that can display outputs such as an LCD or LED screen and others. The input / output (I / O) devices 202, 204, 206 can include, for example, a keyboard (not shown), one or more buttons 204, one or more switches 206, etc. In an embodiment including a touch screen, 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)), a memory 210, a storage device 212, and 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 can be 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, or may include these.

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

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

[0109] The electronic device 200 can perform various processes, such as pattern analysis, and other processes that associate data with each other. In some embodiments, the electronic device 200 can perform such processes on its own. Alternatively, such processes can be performed by one or more other devices, such as one or more of the above-described cloud-based processors 22. In further embodiments, these processes can be performed partly by the electronic device 200 and partly by other devices. Various process examples are described herein with respect to the electronic device 200. It should be understood that these process examples are not limited to being performed by the electronic device 200 alone. Further, as used herein, the term "electronic device" should be construed to include other devices with which the 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 enables the electronic device 200 to communicate with other computer systems, storage device devices, and other devices via a network. While the illustrated embodiment includes the transceiver 214, in alternative embodiments, an independent transmitter and an independent receiver can be substituted for the transceiver 214.

[0112] In some embodiments, the processor 208 may execute various applications, such as a CGM application that can be downloaded onto the electronic device 200 over the Internet and / or cellular network, etc. Data for the various applications may be shared between the electronic device 200 and one or more other devices / systems and may be stored by the 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 sufficient processing to operate the urgency assessment functions and methods described below.

[0113] In a particular 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 may be used to initialize the sensor 10. For example, initialization may be triggered when the sensor electronics 12 engages the sensor 10. In another example, initialization may be triggered by a mechanical switch, such as a switch (not shown) on a snap-on base that receives the sensor electronics 12. When the sensor electronics 12 is snap-fitted into the base, the switch automatically activates. In another example, initialization may be menu-driven, and the user may be prompted by the user interface on the electronic device 200 to start the initialization by making a selection on the user interface, such as by pressing a button on the display device 202 (which may include a touch screen) or by touching a designated area. In another example related to a non-invasive sensor applied to the wearer's skin, the sensor 10 may sense when it comes into contact with the skin and automatically activate. Further, the analyte sensor system 8 may detect the use of a new sensor 10 using any of the above techniques and automatically prompt the user to confirm a new sensor session by means of an input request on the user interface of the system 8, and initiate the initialization in response to the user's confirmation of the input request. An example of additional initialization of sensor 10 is found in U.S. Patent Application No. 13 / 796,185, filed on March 12, 2013, the entire disclosure of which is incorporated herein by reference.

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

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

[0116] Mobile device 18 includes a display device 202 for displaying notifications, results, and warnings / alerts. While the display device 202 is described as a display screen and thus generally visually depicts results, it is understood that notifications, outputs, results, and in more urgent cases, warnings / alerts, can also be communicated using other means such as audibly. The same can be communicated as an audible version of the displayed text or numerical values. Alternatively, a ringing tone or other sound, or even a song or incoming melody, can be provided to the user as a distinct indication of the user's blood glucose level.

[0117] Mobile device 18 may further include a memory 210 or storage device 212 for the search and use of past data, including data input by the user, as described in more detail below. Since mobile device 18 can communicate with various servers over a network, past data can also be read from network server 222. In addition to past data, the server (or other network source) can further provide other external data that may be involved in decisions leading to notifications presented on display device 202.

[0118] Display device 202 itself may provide an interface for the user to input data, for example, using a touchscreen interface, and data can also be input via buttons and switches 204 and 206 respectively. In some smartphones and many other computer devices, a separate keyboard can 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 sources. However, in many cases, initial processing of raw sensor signals, such as calibration, smoothing, or filtering, is performed by sensor electronics 12, and an application on mobile device 18 converts the signal received from sensor electronics 12 into a GUI, which is then shown on display device 202.

[0120] Figure 7 illustrates how the measured blood glucose value can be combined with other parameters or variables to yield the calculated or otherwise determined GUI value 252, which is then presented on the display screen of the mobile device and can serve as the basis for warnings and / or alerts. The calculation or determination is performed by the urgency assessment module 211 on the mobile device 18, but can be determined in whole or in part by the server 222 or, in some cases, even by the sensor electronics 12. It is understood that not all parameters and variables are involved in all implementations of the determination of the GUI value 252.

[0121] Examples are described of how various parameters and variables can be combined, and subsequently, to achieve the above-described benefits and advantages, to yield a GUI value upon which the presented notification can be based and / or upon which a warning or alert can be based. Without in any way intending to limit the scope of the arrangements, particularly useful combinations are considered to include the combination of the current glucose value or the first derivative of the glucose value with respect to time. However, as will be understood by those skilled in the art upon receiving this teaching, a number of combinations are useful and thus the scope of the present invention is not limited by specific examples. Further, while a single calculated or determined value of the GUI 252 can be used in various implementations, multiple values related to the risk or urgency of blood glucose can be calculated or determined, which can be combined to operate a warning or alert, for example, GUI1 = GUI1(parameters, variables), GUI2 = GUI2(parameters, variables), etc., or can also be used for the general presentation of results to the user. When the combined GUI can be said to define a blood glucose emergency, this serves as the basis for warnings and / or alerts.

[0122] In FIG. 7, the GUI 252 is exemplified based at least on data 254 corresponding to the currently measured glucose value, and / or data 256 corresponding to previously measured glucose values, and / or data 258 that is not directly related to the measured glucose value and is thus called “external data”. The data 254 is generally the currently measured glucose value measured, for example, in mg / dL. The data 256 corresponds to previously measured glucose values, and these can be divided into data 262 called “most recent” measured glucose data and data 264 called “more past” measured glucose data. The most recent data 262 can be what was measured over several minutes or hours before the currently measured glucose data 254, and can thus be particularly useful for analyzing the current trend. The more past data 264 can be what was measured over several days, weeks, months, or even years before the current measurement, and can thus be particularly useful in calculating or determining the overall pattern or trend (the data 262 can also be used for this determination).

[0123] The currently measured glucose data 254 and the most recent measured glucose data 262 can be used to calculate other types of data 266 based on the current trend. For example, they can be used in the calculation of data 268 corresponding to the rate of change of the glucose data over time, such as the first derivative with respect to time, the second derivative with respect to time, and the like.

[0124] The data 258 can correspond to past or current user representations, such as how the user is feeling, what the user has eaten, etc. Thus, the data 258 can have an indirect correlation with the glucose level, but this is not directly based on the measured glucose value in a functional sense. The data 258 can also consist of 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 the GUI in a particular implementation example need not include all the various types of data described, and in many cases will include only two or three types of data. Further, as the following description is merely illustrative, types of data other than those described below may be used. Specifically, the calculation of the GUI may be performed, for example, by an algorithm on a mobile device as described above, and the algorithm may take into account several or a number of variables in that determination of the GUI. While these variables are evaluated algorithmically simultaneously or almost simultaneously, the following description considers, in part, the influence of the variables on each other and on the determined GUI over time. In relation to the user interface of an electronic device such as a smartphone, the calculated GUI results in a notification being presented on the user interface of the mobile device, which may in some cases further result in a "treatable warning" (or alert) that presents to the user and proposes one or more actions to be performed and implemented. In some implementation examples, the notification viewed by the user may simply be an indication of the user's state, for example, that the user has a normal GUI. In other cases, the presentation may be a warning or alert state presentation that implies, for example, by a screen that appears in red, that some action must be taken. By unlocking the mobile device, performing a "swipe" operation, or otherwise "drilling down" to the data in which the presence of the warning or alert state is inherent, the user can view the non-obscured actions to be taken. Additional details of such user interfaces are described below in relation to FIGS. 16 - 29.

[0126] The first type of data that can be used and that is relevant to most implementation examples is the measured glucose value. This first type of data can be in numerical form with units such as mg / dL or in other formats, or it can be processed or transformed to obtain another type of data that generally correlates with the glucose value. In some cases, the first type of data can be used in its raw form as received from the sensor electronics without significant processing and / or can also be processed by the sensor electronics. Then, if desired, processing can be performed on a mobile device (or other device) running a criticality assessment module or related application to determine the GUI. The first type of data can be further received from an intermediate module or transformation (e.g., received from another application running on a smartphone). Generally, this first type of data can be processed, for example, to calibrate, smooth, filter, or otherwise "clean up" the signal representing the data.

[0127] Generally, while the currently measured glucose value is used, it is understood that the first type of data can also include one or more past glucose values or even future glucose values determined by a prediction algorithm. Additional details of the prediction algorithm are discussed below.

[0128] In the determination of the GUI, all other factors being equal, a high glucose level tends to move the GUI value towards a higher value indicative of the urgency of hyperglycemic conditions. Conversely, a low glucose level tends to move the GUI value towards a higher value indicative of the urgency of hypoglycemic conditions again. A medium glucose level tends to move the GUI value towards a value indicative of normoglycemic conditions. In very limited examples, normoglycemic conditions may be associated with a GUI of 0, extreme hypoglycemic conditions may be associated with a GUI of -5, and extreme hyperglycemic conditions may be associated with a GUI of +5. Of course, many other schemes can also be understood and used, assuming the present teachings. Although 0 to 5 with positive and negative values representing the risk of hyperglycemia versus the risk of hypoglycemia are exemplified, the risk indicator need not be limited to the risk of hyperglycemia versus the risk of hypoglycemia. For example, it can simply be 0 to 5, where 0 represents no risk and 5 represents the highest risk (regardless of whether it is hypoglycemia or hyperglycemia). The indicator can be qualitatively classified into risk buckets such as, for example, "no risk", "low risk", "medium risk", "high risk", etc. Other quantitative or qualitative risk indices can be envisioned as would be understood by one of ordinary skill in the art, where the risk index does not necessarily correlate with the blood glucose state, but rather correlates with the urgency of clinical treatment to avoid a dangerous blood glucose state. Time information such as the time to the next urgency index or the time to a particular blood glucose state can also be provided.

[0129] Other types of data can be based on this first type of data. For example, the first derivative of the glucose value with respect to time can be used to determine the rate of change of the glucose value over time, i.e., the "speed" of the glucose value, i.e., whether the glucose value is increasing or decreasing and how fast such a change is occurring. Thus, the data value representing the first derivative can be used in the first estimate of future glucose value prediction and also in the determination of 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 decrease the GUI to 3. Further, the direction and amplitude of the first derivative can be used to determine the weight of the same information in the determination of the GUI.

[0130] In particular, the first derivative and higher-order derivatives of the glucose value with respect to time require a certain amount of past data to be stored and used in calculations. Such data is generally based on recent past data, but as described below, older past data can also be used and can provide useful information about user patterns, and it is understood that such user patterns can be analyzed theoretically or, for example, with respect to time.

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

[0132] In the above example, if the glucose value itself results in a GUI of 5 and the first derivative relaxes this to 3, the second derivative can be used to increase the GUI (if the second derivative indicates that this decrease will "improve" soon) or to further decrease the GUI (if the second derivative indicates that this decrease will accelerate). In some cases, the second derivative can indicate that not only is the user moving towards a normal blood glucose level, but also that the user may enter a hypoglycemic state, e.g., the GUI can reach 0 but can return to a low, medium, or high GUI as needed.

[0133] In some implementation examples, the determination of a blood glucose emergency state or an index indicating such a state can be based, at least in part, on the measured glucose value and the first or second derivative, or both, of the measured glucose value with respect to time. Such implementation examples enable a fairly high degree of confidence that the activated warning or alarm will actually require user (or other) intervention, using minimal warnings or alarms in situations that are likely to be resolved without user intervention. In some implementation examples, the calculation of the blood glucose emergency state or index can be based on the above factors in combination with other factors described below. For example, the glucose value in combination with another type of data based on the glucose value, e.g., the time derivative, can be used in combination with duration data (discussed below) to determine that the blood glucose emergency index has reached the point where user intervention is required. Similarly, the glucose value and / or the time derivative can be used in combination with food intake data to determine whether a warning should be activated. For example, if the user has a low glucose value but has just eaten a snack bar, the warning can be suppressed (all other aspects being equal). Insulin data can be used similarly. Other example combinations are described below.

[0134] Here, it is noted that the concept of warning suppression is used to indicate that a warning condition has been reached but that this is not shown to the user due to various other factors. However, it is clear that in other implementation examples, the concept of suppression can be replaced by simply recalculating the variable on which the warning or alarm is based, e.g., the GUI, and then basing the warning or alarm 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 recording graphs over a period of time, the level and duration of the last significant glucose value deviation, e.g., the level of the last glucose peak, etc. For example, if the user has a GUI of 3, but the last significant glucose value deviation is large and has a long duration, such a situation may tend to move the GUI upward (e.g., to 4 or 5) in the determination of the GUI.

[0136] Another type of data related to the sensor for measuring glucose values and the electronic device, but not necessarily directly related to the glucose value itself, is the accuracy, confidence level, and / or noise information in glucose measurement. Specifically, the acute index of blood glucose is as accurate as the processed internal data. Therefore, the GUI, etc. can be made more reliable by including accuracy information for certain available inputs, and in some cases, the acute assessment module can determine how much weight to give to certain inputs based on the accuracy information. Alternatively, for various outputs, a range (instead of a single numerical value) can be displayed to indicate that those outputs are subject to some uncertainty. The accuracy information can take various forms, including, for example, the level of noise, the level of confidence, a ratio, a number, or a category. A particularly important quantity in this regard is the quality of the sensor signal itself, including aspects related to glucose data, signal quality, error, and confidence level.

[0137] For example, when the GUI value is a slightly high 5 and the sensor data is a concern regarding the accuracy and confidence in the sensor value, such a situation may tend to increase the GUI value in order to provide the most conservative and safe measurement value for the user. If the situation persists, an appropriate warning may be provided to reset the sensor or the electronic device, etc.

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

[0139] In related types of data, the input to the urgency assessment module can be provided by sensor electronics or processing circuitry or software on a mobile device (or server), and indicates the amount of processing applied to the glucose value signal, and thus the value of the delay associated with the signal. Such processing can include amounts such as calibration, filtering, smoothing, etc. More processing of the signal incurs more delay in the signal. Thus, if a large amount of processing is being done, or is required on the signal, or if the processing is delayed for some reason, the signal has more delay, and a delayed signal can be significantly more difficult to resolve than a non-delayed signal, so it can be assumed that this signal itself is considered more important (or associated with a greater weight) in the urgency assessment module. Specifically, there is a higher likelihood of an unconfirmed deviation from the last known value. Thus, for example, if the GUI value is 3, but significant delay is determined, the GUI can cause an upward bias in the determination of the GUI for reasons similar to the situation of a low accuracy signal. Similarly, such data is generally available from sensors and associated sensor electronics. However, such data can also be determined from analysis of the raw signal data itself, e.g., from the most recent value of the measured glucose concentration.

[0140] For another type of data that can be used in calculations, the glucose value can be further processed to provide a predicted glucose value or range thereof. Specifically, the real-time glucose value can be a "delayed time" relative to the actual glucose value due to physiological and / or data processing reasons. For example, the value measured in the blood as a result of a finger prick may not indicate the blood glucose in the brain at the same time as the measurement. Further, data processing steps such as the calibration, smoothing, and filtering described above can introduce additional delays. To address both of these issues, a predicted glucose value can be determined using a prediction algorithm, which can then be provided to the urgency assessment module as an input in the determination of a blood glucose emergency or index. Here again, it is noted 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 blood glucose state, which can provide actionable warnings based on the value of the index. In some cases, rather than a specific predicted value, a range of predicted values can be determined, which can be used in the determination of the GUI. Finally, the prediction algorithm can provide additional insight into the user's blood glucose state, which can be useful in combination with other inputs described herein in the determination of blood glucose urgency, even without the benefit of reducing the impact of delays.

[0141] Systems and methods according to this principle enable an expansion of the prediction range beyond what was previously possible. For example, while some levels of prediction enable the detection of hypoglycemic events occurring in a certain period in the future, the prediction range can be significantly expanded by using several parameters and variables in the determination of the GUI. Example prediction ranges can include 10 minutes, 20 minutes, 30 minutes, 45 minutes, 1 hour, 90 minutes, or even more.

[0142] For example, if the GUI value is 3, but the predicted GUI value indicates that the user is headed towards a higher blood glucose state, the GUI value can be increased, for example, to 4 or higher. Again, the GUI itself is not a glucose value, but the glucose value can affect the GUI.

[0143] Data for prediction is generally available through analysis of stored glucose values. Further details regarding the prediction algorithm are disclosed in U.S. Patent Application No. 11 / 007,920, filed Dec. 8, 2004, entitled " SIGNAL PROCESSING FOR CONTINUOUS ANALYTE SENSOR", and issued as U.S. Patent No. 8,282,549 on Oct. 9, 2012, which is hereby incorporated by reference in its entirety.

[0144] The duration for which the measured glucose level occupies a specified range is another type of data that can be used in calculations and can be determined by analysis of glucose values, specifically values over time. The specified range can be arbitrarily defined but generally can indicate a particular emergency state, e.g., high or low hyperglycemia, high or low hypoglycemia, or normoglycemia.

[0145] More specifically, to address the problem of the previous lack of consideration of such duration, the time the user spent in a range (or other range) corresponding to an emergency state can provide an important input to the emergency assessment module, especially when the emergency state is hypoglycemia or hyperglycemia, as this time can be correlated with the risk the user faced. For example, if the user has a GUI of -3 (based on other factors) and the duration of a relatively low hypoglycemic event is significant, the GUI can be further decreased to -4 based on the duration, as the likelihood of further downward deviation is much higher and the urgency should be increased. In using duration as a factor, the emergency assessment module can use the duration itself, or the time a particular emergency state exceeded a threshold duration, or other related parameters as inputs. Such data is generally available through analysis of stored glucose values over time. Additional details are discussed below in connection with Example 1.

[0146] Another type of data that can be used in calculations or GUI decisions corresponds to recent or past events, specifically predicted or reference glucose levels or significant deviations from the GUI. Specifically, a user who has recently had a significant deviation is generally likely to have a significant current or future deviation. To address this issue, the urgency assessment module may take such previous past events into account in GUI decisions. For example, the level of the last glucose peak, or its duration (measured as the time above or within a threshold level) can be used in the decision. The level and / or duration of the last significant deviation, or the deviation of the glucose value from the reference value (or otherwise predicted value) can be used in the decision as these often indicate the risk of the user's current blood glucose deviation and specifically are an indicator of a higher likelihood of future deviation or variance. For example, if the determined GUI is 6, but the user has experienced many recent deviations or variances, the GUI can be increased to 7. As a subset of this type of data, "the last low / high blood glucose event" (including its level and duration) can be used in the decision. In any event, such data is generally available through analysis of the stored glucose values.

[0147] Additional types of data that can be used in the determination of the GUI utilize more past measured glucose values. In one example, and as mentioned above, a pattern of glucose values can be determined and used, for example, to notify a measured reference value of a deviation that may constitute a significant deviation from a reference value. Pattern data is based in part on time or times, but not necessarily. Specifically, users often follow very regular patterns based on eating, exercise, or other activities that occur at specific times that may be associated with glucose levels. These can be advantageously used to determine whether a deviation is predicted to be outside of normal levels. When time solidifies a pattern, the determined GUI can be more predictable and confident and can provide more useful feedback. The use of pattern data in the GUI algorithm helps to address the problem where normal GUI values would otherwise generate warnings or alerts and thus avoid the problem of "alert fatigue". Such pattern data is of course generally available through the 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 adapt to this pattern and predict lower measured values in the morning and higher measured values in the afternoon. Similarly, a user may typically consume an oatmeal meal in the morning, which can thus result in a rapid increase in the user's glucose value. Rather than necessarily resulting in a warning or alert, the urgency assessment module can determine that such a meal at approximately the same time each morning constitutes a pattern, which can be simply regarded as "normal" based on the GUI assessment and thus suppress the activation of a warning. As described above, "suppression" can simply be a recalculation of the GUI that results in not activating a warning. Thus, taking into account the patterned reference values results in the analysis of the rapid increase not classifying it as a rapid increase at all. Of course, other factors influence the calculation of the GUI and, as a combination, these will determine the emergency GUI and result in the activation of a warning or alert.

[0149] In the above situation, a sudden increase in glucose levels due to oatmeal can lead to an increase in the GUI away from the normal blood glucose state without pattern information, but the recognition of patterns in the determination of the GUI can lead to more accurately maintaining its value.

[0150] While eating and sleeping are disclosed elsewhere in this specification, it is understood that patterns can be recognized or generated with respect to other events such as meetings, work, exercise, etc. and used in the determination of the GUI. Time information can be captured 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 that occur with any kind of periodicity such as daily, weekly, or monthly cycles. Such data is generally available through the 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 input requested to determine if there are specific causes for the pattern, such as common meal times, exercise classes that occur at usual times, etc. Such input requests can be particularly useful when the urgency assessment module uses machine learning to determine the daily or other regular patterns or behaviors of a given user.

[0151] By the same means, deviations outside the recognized patterns can lead to similar user input requests. For example, the deviation can lead to the urgency assessment module asking the user "Did you do something different?" Asking in such a way can enable, for example, the analysis of skipped boluses versus insufficient boluses and the resolution of ambiguities.

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

[0153] It will also be understood that other types of data can be used in relation to deviations from the normal glucose pattern, and these are not necessarily time-based. Such situations can include cases where exercise (detected, for example, by movement or heart rate) is normally associated with a drop in glucose level. A "normal glucose pattern" can be learned for a particular user using known pattern recognition algorithms. Deviations from such a normal pattern are then defined as inputs into the GUI decision and can be used, and in some cases, out-of-range blood glucose events can be predictors of a higher risk state, at least in part due to the unexpectedness of the event, which can determine different types of outputs to the user, i.e., different types of notifications, warnings, or alerts that are drawn on the display device of a mobile device or output to an insulin delivery device, i.e., a pump. Thus, the problem of processing non-time-based patterns can be effectively addressed.

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

[0155] Other types of data can be used in the determination of 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 body measurement data corresponding to body measurements such as, for example, BMI or weight. Body measurement data can be particularly important for type II diabetic patients but can also have some impact for type I. In particular, for type II diabetic patients, changes in body measurements can have a significant impact on the determination of the GUI. For example, an improvement in the BMI of a type II patient should generally lead to a better GUI when all other aspects are equal. Body measurement data can be captured semi - automatically, for example, via a connected weight and height meter, or values for such BMI calculations can be input by the user at the user interface of a mobile device. Measurements can also be incorporated from other systems including from the cloud. Thus, the problem of treating all users equally regardless of their body measurement data can be effectively addressed and solved.

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

[0157] Another type of data that can be used in the determination of the GUI is data regarding the user's activity level, specifically, data regarding the amount of activity, the type of activity, and the duration of the activity (or combinations thereof). Specifically, quantification of the user's activity level can generally provide a deeper understanding of the trend of glucose values. Activity information can be supplied to the determination of the GUI and can be useful in presenting to the user who desires 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 the management of their diabetes.

[0158] For example, a user may have a determined GUI of 0 indicating a critical state of normal blood glucose, but the first derivative of the glucose value may indicate that this is decreasing and could lead to the GUI decreasing 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 may be due to physical activity rather than an overdosage of insulin, for example, particularly if the second derivative indicates that the glucose value will increase, the GUI of 0 may be maintained.

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

[0160] The relevant type of data is information regarding exercise, which is generally beneficial to diabetic patients and can help prevent hyperglycemia and hypoglycemia and assist in managing insulin delivery. However, exercise can sometimes have a long-term impact on diabetes and can cause severe hypoglycemia in certain users hours later. Thus, due to this long delay, it is sometimes difficult to identify exercise as the cause of hypoglycemia. For example, if exercise can be accurately detected by using the measurement device described above, predictive analytics can be used to predict when exercise may begin to affect glucose levels and thus the associated risk states, e.g., the GUI. Exercise can be monitored using substantially the same type of device used to monitor activity and may include parameters such as the duration of the exercise, the type of exercise, the amount of calories burned, etc. It is understood that such data can also be manually entered.

[0161] Further related types of data correspond to sleep information or status. Specifically, diabetic users are known to be at a higher risk of experiencing hypoglycemic events during sleep that go unnoticed. Movement or lack thereof and other factors can be used to detect sleep and assess the associated risks accordingly. Other factors can include, for example, heart rate, user input, etc. Monitoring devices, such as mobile devices running an urgency assessment module, can be equipped with a user-installable "night mode" function or module that can assist in detecting sleep. Movement detection for such purposes can be carried out, as described above, for example, by using an accelerometer worn on the body. For example, a CGM sensor or transmitter can incorporate such an accelerometer or other movement detection circuitry. A phone or other movement detector placed adjacent to the user can additionally detect how often the user moves, which can indicate sleep. In some cases, the movement detector of 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 a mobile device can also be used to assist in detecting the sleep state. For example, if the user is not interacting with the mobile device at all, as determined by button presses, swipes, or other similar interactions, such a state can be associated or consistent with the sleep state, or this can be learned by an urgency assessment module associated with such a state. Conversely, if the user is interacting with the user's mobile device, the user can be assumed to be awake.

[0162] In an embodiment according to this principle, if the user, for example, was not in a euglycemic state with a GUI of approximately 0, but is currently not moving and the user's heart rate is decreasing, the user can be assumed to be asleep, and thus the urgency assessment module can assess a higher risk that the user is experiencing a hypoglycemic event that the user is not aware of. This risk can be included as a factor in the determination of the GUI, resulting in, for example, a more prominent warning or alert, such as one corresponding to a GUI of (-)4 or (-)5. The mobile device executing the urgency assessment module is equipped with a "sleep mode" function, and the user can activate such a function if a hypothesis regarding sleep or sleep detection is not required.

[0163] Such "sleep mode", "night mode" or sleep detection functionality can provide several advantages in certain implementations. Specifically, by assessing a higher risk state for nocturnal versus daytime glycemic events, the system understands that the user is likely not aware of the user's diabetic risk state and thus glycemic events should be treated differently. In this way, the problem of inattentiveness of the user during sleep, or skewed values of glucose encountered during sleep, can be effectively addressed.

[0164] Another category of data types that can be used in GUI decisions corresponds to physiological data. One such type of physiological data includes hydration information. Specifically, dehydration is often associated with high blood sugar levels. Therefore, this can be used to further inform GUI decisions. Hydration information can be received, for example, from a Tanita BC-1000 body composition monitor in combination with a Garmin (registered trademark) connection system. It is understood that such data can also be manually entered, at least at a qualitative level. As an example of implementing a GUI decision using hydration, a user may have three determined GUIs when all other factors are equal. If the user is dehydrated, such a state can push the GUI up to 4 to indicate a higher likelihood of hyperglycemic events. Generally, while sensor data is used to measure hydration, this can also be input by the user, at least qualitatively.

[0165] Another such type of physiological data includes heart rate information. Heart rate can indicate exercise or other factors such as stress. If the heart rate or a change in heart rate is due to exercise or other activities, the activity monitor described above can be used to quantify this. Alternatively, heart rate can be communicated wirelessly from a heart rate monitor or other application. In another implementation example, heart rate can be manually entered by the user using such display frequencies or quantitative values, etc., if the user is able to measure "high heart rate", "normal heart rate", etc.

[0166] Another such type of physiological data includes blood pressure information. Specifically, the impact of diabetes on blood vessels tends to increase the risk of high blood pressure. Therefore, monitoring blood pressure can be useful and can be included as a factor in GUI decisions. Various body-worn blood pressure monitors are available, and these can communicate blood pressure data, in a wired or wireless manner, to a device running an urgency assessment module. Alternatively, the user can measure their own blood pressure and manually enter it into the device.

[0167] Additional types of physiological data include body temperature. Body temperature is often an indicator of illness, which can in turn affect the risk profile for diabetes and thus be provided to the GUI. For example, body temperature and / or underlying illness can result in different blood glucose responses to various inputs or treatments than those predicted in other users or historically predicted in the same user.

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

[0169] To illustrate the above parameters or variables, a user with a determined GUI of 3 (without heart rate, blood pressure, or temperature input) can 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 blood glucose state. Using such systems and methods according to this principle, the problem of glucose monitoring in users lacking consideration for refinement of such parameters or variables can be effectively addressed.

[0170] The level of interaction between the monitor and the user has been mentioned above in relation to the determination or detection of the sleep state. Such a level of interaction can generally be used to determine, at least with respect to the level of interaction between the user's glucose monitor and the user, the level that the user desires to manage or be notified about their diabetes. Specifically, the level at which the user interacts with the user's CGM, for example, a mobile device running an application where the GUI is determined by the urgency assessment module, can be used as a factor in the determination of the GUI. For example, a high level of user interaction may indicate a strong awareness of the user's blood glucose state and may correspondingly result in a lower risk. Conversely, a low level of user interaction may indicate a low or even no awareness of the blood glucose state, especially when the glucose is on the "borderline" of normal blood glucose values and this input (distance from the target range) can be included in the determination of the GUI, which may correspondingly result in a higher risk assessment and thus the GUI. Such a level of user interaction can be measured by the amount of time the screen is on, the number of buttons pressed or swiped, the orientation determined by the accelerometer, etc. However, it should be noted that such data can be modified or notified in various ways by user pattern data. For example, the pattern data may indicate that the user does not use the user's mobile device after 8 pm. In this case, the user may not be considered a "low awareness" user based on the lack of interaction between the user and the device at night, which is simply associated with the pattern itself. However, if the same user generally interacts a lot with the user's device during the day but suddenly stops interacting for a long time in the afternoon, in such a case, since it can be assumed that the user is not aware of the current risky state of their blood glucose, the urgency assessment can be increased.

[0171] For example, a user in a critical hyperglycemic state can be warned of this and, for example, be determined to appropriately treat the state by analyzing one or more temporal rates of change of glucose values. When the user interacts a lot with an electronic device, such as a mobile device, the GUI can maintain the current value using an appropriate subsequent warning (which may not be present). When the user interacts less with the monitoring device than normal, the GUI can tend upward and provide additional warnings (or an increased display frequency 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. Data regarding usage is generally obtained using the operating system of a monitoring device, such as a mobile device.

[0173] Similar types of data can be used in the determination of the GUI, along with context and behavioral information. Specifically, such information can correspond to how the patient uses their mobile device and thus gives context to the specific data determined by the device. Behavioral input information can be obtained via the system and can include the amount of interaction, glucose warning / alarm status, sensor data, number of screens tapped, alarm analysis, events (e.g., features related to the user's reaction, time to reaction, glucose management related to the reaction, user feedback related to the alarm, not approving a warning / alarm within X minutes, time to approval of a warning / alarm, time of warning status, 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 / sweating) from a skin patch sensor, free amino acids, troponin, ketones, adiponectin, sweating, body temperature, etc. The input can be provided by sensors in data communication with the monitoring device. In some implementations, the information can be obtained through an intermediary such as a remote data storage device.

[0174] Contextual information that can be provided as input to GUI decisions includes human ecology, location, ambient sensations (e.g., light, sound level), environmental data (e.g., weather, temperature, humidity, air pressure). The input can be received via peer-to-peer or mesh networks via machine-to-machine communication. Contextual information can include information on daily routines (which can vary especially between weekdays and weekends) from a calendar application. Contextual information can include, for example, the frequency of touching or grasping a monitoring device based on the sensed movement of the device, even without interaction.

[0175] Photographs can provide contextual information. For example, photographs of one or more of glucose meter measurements, insulin pen or pump IOB, location (e.g., gym, park, home, Italian restaurant), or a meal can be used to provide contextual information. Photographs 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 GUI decisions. Context can also be provided by or determined by the basis or bolus settings provided to the monitoring device.

[0176] Other inputs to GUI decisions that constitute context / behavior data can include types of data mentioned elsewhere that are not context / behavior inputs, such as exercise information from a fitness bike etc., glucose sensor information from a blood glucose (BG) meter or CGM, insulin delivery amount from an insulin delivery device, the result of the calculation of the remaining insulin in the device, and information provided or calculated by other devices. Other context / behavior data inputs to GUI decisions can include hydration level, heart rate, target heart rate, internal temperature, external temperature, external humidity, analytes in the body, hydration input, power output (cycling), sweating rate, pace, and adrenaline level, stress, pathological condition / illness, metabolic rate / calorie burn rate, lipolysis rate, current weight, BMI, desired weight, daily (consumed) target calories, daily (expanded) target calories, location, favorite foods, and level of exertion.

[0177] For any of the behaviors or contextual inputs mentioned above, the system may be configured to receive and / or generate analysis metrics based on the input. For example, a composite value may be generated based on glucose levels, temperature, and the time at which the data generated a user index value. The composite value may then be taken into account in GUI decisions.

[0178] This information may be collected from various sensors, such as accelerometers, GPS, camera data, etc., inside or outside the device, and tracking applications, including third-party sleep cycle applications. For example, such tracking applications may use geographical location information to determine context and behavior. Additionally, context and behavior may also be determined by the use of social networking information available about the user, and social networking feeds related to the user are prepared to provide the data source to and / or provide an 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 / behavior aspects can be effectively addressed. Additional details regarding context and behavior information can be found in U.S. Patent Application No. 61 / 898,300, filed on October 31, 2013, owned by the applicant of this application, entitled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES", specifically in FIG. 4 and the accompanying text, which is hereby incorporated by reference in its entirety.

[0180] Other types of data that may be used in GUI decisions include information about food and beverages consumed and insulin. Variables or parameters suitable for these types of data may include information about these amounts, these types, and the times and durations at which they were received.

[0181] When food and beverages are consumed as part of a meal, such data can be captured by several means, such as manual entry of food and beverage information into the device by the user, e.g., on a spreadsheet, by using the camera on a mobile device to capture a photo of the meal, or by data entry from a third-party food application that can enable, for example, checking off items on a menu (already having data entered in the application) at a given restaurant as they are consumed. In some cases, the user may be prompted to enter such information, e.g., if the device detects a rapid increase in glucose levels. Meal data can even be hypothesized (requiring confirmation by the user) by using GPS or social networking data indicating that the user is near or has "checked in" at a known favorite restaurant. The user may be prompted to confirm that they ordered their "usual meal," which can then automatically add food data with meal parameters, or, if the user deviates from their normal choices, the prompt can provide an opportunity to enter other food selections. Generally, meal data can be provided with details such as the amount consumed, the time of ingestion, and other meal data enabling clinically significant GUI decisions. Using such information, the problems currently encountered in diabetes treatment based on the lack of such factors (and other factors) can be effectively addressed.

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

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

[0184] For example, a user in a hyperglycemic state may have a GUI of 3. If the user injects bolus insulin, the GUI can be modified to 1 in order to reflect the fact that the user's urgency assessment has changed. In a system and method according to this principle, the modification can occur immediately after notification that the user has injected a bolus, well before a change is detected in the blood glucose level. Using such insulin data, problems encountered prior to diabetes management, such as the lack of an immediate update of a risk profile based on data entered by the user regarding dietary intake, can be effectively addressed.

[0185] Another type of data that can be used in the determination of the GUI corresponds to the stress level. Specifically, stress is known to affect diabetes and thus the user's risk profile. In some cases, such data can be provided via a sensor, but often it is captured by asking the user to select from various emotion icons or other representations of emotion. Such data can also be inferred from other sources by analysis of events related to the user's calendar or other regularly scheduled activities, such as work, exercise, family time, etc. The stress data can also include information regarding the amount of stress, the type of stress, and how long the stress has lasted.

[0186] The relevant types of data that can be used in the determination of the GUI are related to current health, which can overlap with the current emotional state. Such measurements can be captured manually via the device, including by using the same type of emotional icons for stress as described above, or can be captured from cloud information. Current health and emotions are known to have a significant impact on type II glucose management and insulin resistance, just like body measurement data. Health data can include information about current illnesses, the severity of the illnesses, and how long the user has been suffering from the illnesses, etc.

[0187] For example, a user with a GUI that is not dangerous in other aspects may have their GUI increased if they are currently experiencing a significant level of stress or poor health. Such an increase reflects the fact that these factors are known to cause harmful increases or decreases in blood glucose levels. Using such types of data, past problems related to the user's current stress or lack of consideration for health can be effectively addressed.

[0188] Demographic data such as age or gender can also be used. Specifically, demographic data can be collected from online stores, networks, or cloud sources, or can be manually entered into the device, and such data can provide useful information in the determination of the GUI. For example, pediatric users are known to have a tendency towards faster and higher blood glucose fluctuations. As another example, the risk profile of a user, especially in older users and especially those with type II diabetes, may be considered to have a higher risk profile in a specific blood glucose deviation state compared to younger users with the same blood glucose deviation.

[0189] In a specific example, users with an elevated risk profile, such as a pediatric user with a calculated GUI of 3, can have their risk profile increased to 4 to reflect the tendency of pediatric users towards faster and higher blood glucose fluctuations.

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

[0191] Another factor that can be used in GUI decisions is the sensor site location. Specifically, in some cases, the site or location of the CGM sensor can result in maintained specificity in blood glucose values for such locations. These specificities can be included as factors in GUI decisions. Such data is generally manually entered by the user, but past data can be used to avoid such user input if such data is regular and thus decisions can be made that are not ambiguous. Additional details regarding the use of sensor site location can be found in U.S. Patent Application No. 61 / 904,396, filed Nov. 14, 2013, owned by the applicant of this application, entitled "INDICATOR AND ANALYTICS FOR SENSOR INSERTION IN A CONTINUOUS ANALYTE MONITORING SYSTEM AND RELATED METHODS", which is hereby incorporated by reference in its entirety.

[0192] Another factor that can be cited to influence GUI decisions, when known, is the cause of an increase or decrease in blood glucose value. In that regard, it is noted that some changes in glucose levels are caused by stress and others by food intake. Such data can be pre-processed or pre-associated before data entry into the urgency assessment module or can be associated there. For example, food data can be processed in combination with glucose levels to determine whether the increase in glucose was caused by food or another cause such as stress. Using such data, problems seen in the past with lack of consideration of such cause and effect can be effectively addressed.

[0193] As described above, the glucose value (and derivative data) can be weighted by an evaluation module based on signal quality, confidence level, etc. Such weighting is generally automatically performed by an electronic device based on analysis of signal data from a sensor electronic device. However, any of the above variables or parameters can enter into the GUI calculation in a weighted manner, and the weighting can be performed automatically, for example, by signal analysis from built-in sensors such as accelerometers, weighing scales, etc., or by using data manually input by, for example, a physician or a patient. Using such data, problems seen in the past having a lack of consideration of such factors can be effectively addressed.

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

Table 1-1

Table 1-2

[0195] FIG. 8 illustrates a flowchart 40 that exemplifies the general use of the parameters and variables discussed above. In a first step, a plurality of inputs related to a disease such as diabetes are received, the inputs corresponding to variables or parameters, which can be measured, input by a user, or otherwise obtained, for example, via the cloud or other sources (step 272). Next, a GUI is calculated based on the received inputs (step 274). The GUI can be determined or calculated by several means 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 can change, or a warning or alert can be provided when the GUI reaches a specific value or based on a threshold (step 278). Similarly, various types of advanced outputs (additional processing or additional details regarding GUI processing, such as information regarding the inputs) can also be provided (step 282). In some implementations, the determined GUI can serve to operate an integrated pump for a drug, as will be further detailed below (step 275).

[0196] Several variations will be understood. For example, notifications, displays, warnings, or alerts, and advanced outputs can be provided to the patient or another user, such as a caregiver, physician, family member, etc. Generally, means for displaying or notifying the user state are available and provided. Further, in an emergency, a warning or alert can be provided to the user so that the user can take appropriate measures. Further, not all of these need to be provided to the user in a given situation. In some cases, the user may simply desire to check their interface on their mobile device to confirm their status, in which case a display is provided even without, for example, the occurrence of a warning, alert, or advanced output. In related cases, only advanced outputs may be desired by the user. In other cases, when important information is a warning or alert, the warning or alert can be provided without providing a specific general display of the state, in order to avoid distracting the user. Other variations will also be understood.

[0197] Example 1 In one exemplary implementation, several inputs are used for the determination of the GUI, including at least: a) glucose value (concentration), b) rate of the glucose value (amplitude and / or direction), i.e., its rate of change, c) acceleration of the glucose concentration (amplitude and / or direction), and the duration of one or more of the above. For example, the first input can be the glucose value, the second input can be the derivative of the glucose value, and the third input can be the duration or other parameters or variables described. In this implementation, the first notification based on the glucose value can be adjusted upward or downward and / or recalculated using GUI functions based on the derivative and / or duration of any input. For example, the glucose value can be low or high, but if the glucose value tends to move towards a desired intermediate value determined by the first derivative, the GUI determines that it is not in a dangerous state or is in a low-danger state, so the baseline warning can be suppressed. The warning can be further suppressed if the GUI determines that the second derivative indicates that the glucose value is not increasing or decreasing (or vice versa) in a manner that the second derivative moves away from the intermediate value. In an alternative implementation, the suppression can be replaced by a recalculation of the GUI that leads to no dangerous state or a low-danger state.

[0198] Example 1 solves the problem that the rate-of-change information alone (the first derivative) may not be accurately predictable when a "recovery" event is about to occur, but the glucose value will resolve in the long term. By using acceleration information, the "recovery" event can be predicted more accurately to avoid overcorrection or false warnings.

[0199] In a particular implementation, for example, at 0 mg / dL / min / min (no detection of acceleration or deceleration), the urgency assessment module may rely only on the first and second inputs for the determination of the blood glucose urgency index. However, at 1 or 2 mg / dL / min / min, the urgency assessment module may rely further on other inputs including acceleration to determine the type of "recovery" event and its predicted impact.

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

[0201] Example 3 In yet another exemplary implementation, the first input is the same as in Example 1, the second input is the rate or speed 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 exemplary implementation, the first input is the same as in Example 1, the second input is acceleration (which may or may not involve the calculation of speed), and the third input is another parameter or variable selected from Table I.

[0203] In another particular implementation of the example, and with reference to graph 50 of FIG. 9, the output record 283 of the glucose value (applied to axis 289) and the output record 285 of the GUI value (applied to axis 291) are plotted and illustrated against the time axis 287. As can be seen, in region I, the user is initially hyperglycemic and has a low to medium range GUI. Here another type of GUI is illustrated, ranging from 0 (low urgency) to higher values (indicating higher urgency). However, by taking into account the rate of change of the glucose value that tends towards the target range, the GUI, and thus the urgency assessment, can be lowered towards the "no urgency" zone or band. If the glucose value has a positive rate of change rather than a negative rate of change, or has an acceleration indicating a tendency towards higher values, the GUI will rise towards a more urgent assessment even if the glucose value itself is decreasing.

[0204] In Region II, the glucose value is seen to occupy a range 293 of hyperglycemic values (e.g., 180 - 400 mg / dL) over a period of Δt1. If the time Δt1 exceeds a defined threshold, as is the case in Figure 9, such a situation can indicate a reason for the GUI to increase, even if the user is only mildly hyperglycemic or has not experienced a further increase in the user's glucose value. Region II in Figure 9 exemplifies the hyperglycemic range, and it is understood that occupancy of the hypoglycemic range similarly raises the GUI value, especially since the duration for which the user occupies the hypoglycemic range is related to the predicted further hypoglycemic deviation.

[0205] In more detail, the duration of the input can also be used by the urgency assessment module in the determination of the GUI. Specifically, as the duration of a hypoglycemic or hyperglycemic deviation increases, the deviation can have a greater impact on the GUI. For example, a 2 - hour hyperglycemic state (e.g., above 180 mg / dL) persisting is more dangerous in terms of at least long - term complications related to diabetes than a 20 - minute state of the same hyperglycemic level persisting. Further, the glucose level becomes logarithmically more dangerous above 180 mg / dL. Similarly, a 2 - hour state of low glucose level (e.g., below 70 mg / dL) persisting can be more dangerous than just a 20 - minute state of the same low glucose level persisting, at least in terms of the likelihood that even a small change can easily place the user in a dangerously low state. In other words, as time passes at a low glucose level, there is a high likelihood of dropping to a dangerously low glucose level, e.g., below 55 mg / dL, and it becomes easier to drop.

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

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

[0208] By considering parameters and variables that exceed only the glucose value and even beyond just considering an increase or decrease in the glucose value, notifications including continuous notifications, warnings, and alarms can be more finely tuned for a given user using a system and method according to this principle, and thus provide several advantages including a reduction in nuisance alarms. For example, using the above system, the threshold is set at 70, but if the user is 69 and rising, the previous system would continue to warn because the user is still below the threshold. The current system and method according to the principle recognize that the user has a rising glucose level and thus does not need to be warned in the first place. Even if the user was not measured while rising, but if they had just eaten a meal, the system and method according to this principle can recognize that the user will soon have a rising glucose level based on the GUI and thus avoid nuisance warnings or alarms that would otherwise be triggered.

[0209] Region IV indicates a region where noise somehow enters the glucose value, and thus a low confidence level may be associated with this part of the signal. Thus, the GUI may be seen as rising under the recognition that a glucose value with low confidence is related to a higher or more urgent urgency assessment. A similar rise in the urgency assessment will occur when it is determined that a significant delay has occurred in the signal.

[0210] Region V exemplifies another parameter or variable that can affect the determination of the GUI. Specifically, in Region V, it is assumed that the user has interacted more with their mobile device as determined by a significant number of key presses, activation of the touch screen, movement determined by the accelerometer, etc. Thus, since the user is interacting more with their device and is therefore likely to view up-to-date information, warnings, and alerts regarding the urgency assessment, the GUI and the urgency assessment can be decreased since it is highly likely that the user can take prompt action.

[0211] Region VI indicates a situation where the predicted value 313 of the glucose level indicates an increase in the glucose level, and such a prediction is calculated by the prediction analysis tool as described above. In this case, this can result in an increase in the GUI upon recognizing the prediction of an increase in the blood glucose level. Such a prediction can also have the advantage of compensating for a delay in the glucose level.

[0212] Region VII indicates another situation where an increasing glucose level does not necessarily need to significantly increase the urgency assessment based on the data input by the user. Specifically, Region VII indicates that the user is heading towards a mild hyperglycemic state. However, if the user has recently input data indicating that they are about to engage in significant physical activity such as exercise, the tendency towards a mild hyperglycemic state can be mitigated by the assumed effect of the exercise. Thus, the GUI285 in Region VII does not need to increase significantly.

[0213] The variations will be understood. For example, while the GUI axis 291 is used in only one direction, the GUI axis can be used in two directions (not shown) indicating the urgency of hyperglycemia and the urgency of hypoglycemia. While a single GUI axis 291 is used, in order to remove the ambiguity of the type of urgency and thus provide a notification or actionable warning, the algorithm that provides this takes into account the glucose value as well as other variables and parameters that make up the determination of the GUI, and thus the notification or actionable warning displayed takes into account whether the user is considering hyperglycemia or hypoglycemia.

[0214] Furthermore, in some cases, while the user can view the output record 285 showing the GUI or view the numerical indices representing the GUI, most notifications or actionable warnings provide the display of the GUI by other means such as the use of color, icons, etc., as will be described in more detail below. In other words, many users do not need to look at the GUI itself; rather, it is what the GUI represents.

[0215] Figure 9 is intended to summarize several different types of variables and parameters in a condensed format and show their impact on the determined GUI. However, it is understood that in any given implementation, not all such parameters and variables need to be monitored or used in the determination.

[0216] Figure 10 illustrates another graph 60 that summarizes several different types of variables and parameters and shows their impact on the determined GUI. Similar to Figure 9, not all such parameters and variables need to be monitored or used in the determination. Furthermore, the parameters and variables depicted in Figure 9 can be combined with those depicted in Figure 10 in any way.

[0217] In FIG. 10, the time axis is divided into several different parts related to a typical day. The actual glucose concentration 295 is plotted by overlaying the determined or calculated pattern of the glucose concentration 297 of a given user. The pattern glucose concentration can be developed using past glucose values, can be time-based, or can be related to events such as meal intake, exercise, insulin bolus, etc., for example, can be linked. Other patterns including those not time-based will also be understood. Two types of GUIs are also illustrated in FIG. 10. A GUI 299 that does not include consideration of the pattern is shown. Specifically, the GUI 299 can be based on the glucose value and other factors described above, such as the rate of change of the glucose value, acceleration, etc., or is "absolute" in the sense that it is not pattern-based. A GUI 301 that takes into account the pattern 297 is also illustrated. Specifically, if hyperglycemic or hypoglycemic events are recognized as part of the pattern, the GUI can either not increase, i.e., the urgency assessment can remain the same, or can recognize the fact that it is part of a pattern with an established increase or decrease and change only slightly. For example, glucose drops during dinner as shown in part V, which does not correlate with the host's normal glucose profile (pattern) and (unless meal information is entered into the GUI) causes an increase in the GUI.

[0218] FIG. 10 also illustrates a deviation of the glucose level from the established pattern, specifically, an atypical decrease 309 in the glucose value during sleep. As described above, during sleep, hypoglycemic events are often not detected and are therefore particularly serious. Therefore, in such a situation, an increase 311 in the GUI can be used to increase the urgency assessment and warn or alert the user.

[0219] FIG. 11 shows a graph 70 that illustrates the impact of the previous significant glucose deviation. Specifically, a significantly hyperglycemic event 303 is illustrated in the glucose concentration. Also, this appears to resolve over time in graph 70. However, a subsequent rise 305 can be seen, and instead of simply resulting in a gentle rise of the GUI, the subsequent rise 305 can result in a sharp rise 307 of the GUI because it can be assumed that the previous significant hyperglycemic deviation may repeat itself (bounce back). Therefore, the urgency assessment is superior to simply being based on the glucose value alone.

[0220] Other embodiments will also be understood. For example, otherwise, a user having a "low-risk" urgency assessment based on, for example, glucose value and rate of change may be given a higher-risk urgency assessment if they are overweight, or have a high BMI, high blood pressure, high stress, or are dehydrated, etc. Aspects such as body temperature, body measurement data, and illness, as well as demographic data, may further modify the GUI such that the contextual and behavioral information can be modified. The sensor location can also modify the determined GUI. For example, a user may have a low GUI and thus a low-risk urgency assessment, but if the sensor location is such that a significant delay is predicted in the glucose value, the GUI and urgency assessment may be increased to reflect the lack of confidence in the currently measured glucose level.

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

[0222] Other user interfaces can provide further details about a particular critical state of blood glucose.

[0223] For example, if the user's glucose level is below a defined threshold for more than 15 - 20 minutes even after carbohydrate intake, such a situation can be provided on the device's user interface. In this way, the user is alerted to a significant duration in which the low glucose value is being ineffectively treated.

[0224] As another example, the user glucose value may exceed a defined threshold but is expected to decrease in the near future. In this case, for example, the predicted glucose value over a 20 - minute prediction range gives the user a useful and actionable warning, enabling clear treatment (or treatment group) to be taken.

[0225] In another example, the user's glucose level can exceed a defined threshold for a long duration. In this case, indicating how long the user has exceeded the time threshold is useful in warning the user about the severity of the situation.

[0226] In yet another example, the user's glucose level may exceed a defined threshold for an extended period of time and may not decrease. In this case, indicating the duration of the high value and the percentage showing the lack of recovery to a normal blood glucose level provides important and actionable information to the user.

[0227] Analysis framework Several mathematical frameworks and inputs can be used to determine the critical states of hypo- and hyperglycemic users. One example of how to estimate the critical state of a user is described below, which uses parameters and variables including the current glucose level, the current rate of change of glucose, and the direction of change of glucose to provide a risk value. In certain implementations of systems and methods according to this principle, glucose acceleration and the duration of time spent in a hypoglycemic or hyperglycemic state are added as inputs for reaching the GUI.

[0228] Previously, static and dynamic functions have been proposed, which are mathematical models that map glucose levels and the amount of change in glucose to a risk function (e.g., 0 - 100). For example, Kovatchev (in "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 mapped glucose concentration to a static risk value when both extreme hypoglycemia and hyperglycemia have a level of 100. Similarly, Guerra (in "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 mapped glucose concentration and the rate of change of glucose concentration to dynamic risk values by scaling the static risk measure based on rate - of - change information. This implementation example can be built on top of the static and dynamic risk functions of Kovatchev and Guerra with additional inputs.

[0229] Other inputs that can contribute to the user's risk profile include the acceleration or duration of a hypoglycemic or hyperglycemic state, and the duration of a constant rate or acceleration of blood glucose values. One example is shown in FIGS. 12A and 12B where the subject's risk increases as they remain above 180 mg / dL for an extended period of time.

[0230]

Number

[0231] Where SR(g)=r h (g)-r1(g), and

[0232] Where, when f(g) < 0, r1(g) = r(g), otherwise 0,

[0233] when f(g) > 0, r h (g) = r(g), otherwise 0,

[0234] g is the glucose concentration,

[0235]

Number

[0236] is the rate of change of the glucose concentration, ΔΤ is the time above 180 mg / dL or below 70 mg / dL over time, and δ is an adjustable parameter for how much weight to give to the duration in a dangerous state.

[0237] Figure 13 provides a diagram by chart showing that the risk to the health state increases with the duration of hyperglycemia. Referring to this figure, the glucose levels of users with hyperglycemia but not continuing to rise are illustrated. However, this figure shows that the risk continues to increase over time as the duration increases.

[0238] Figure 14 shows an example of avoiding false dangerous states by using acceleration as a parameter or variable in the determination of the GUI. In this figure, the acceleration or the second time derivative shows that the glucose value is decreasing while also being in a recovery process and returning in the direction of the normoglycemic state. However, a continuing increase can result in an increased risk assessment, and thus a GUI, due to the possibility of hyperglycemic events.

[0239] The following equation (8) explains the situation of Figure 14.

[0240]

Number

[0241] In the formula, A represents the acceleration of glucose in mg / dL / min, and σ represents an adjustable parameter for determining how much weight to assign to the acceleration and the dangerous state.

[0242] Other functionality can also be brought to the analysis framework to support it. For example, adaptive learning can be applied, which is described in detail in U.S. Provisional Patent Application No. 61 / 898,300, filed on October 31, 2013, with the title "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES", and U.S. Application No. 13 / 827,119, filed on March 14, 2013, with the title "ADVANCED CALIBRATION FOR ANALYTE SENSORS", owned by the applicant of this application, and the entire contents of which are incorporated herein by reference. In one use of adaptive learning, a monitoring device, such as a mobile device, can adaptively learn the user's patterns over time as the user experiences hypoglycemic and hyperglycemic events. For example, each time the user's blood glucose level drops below 55 mg / dL, the data preceding that event can be used as a positive test case by a machine learning algorithm, such as a support vector machine (SVM) or linear discriminant analysis (LDA). Further, cases where the user's glucose level remained between 70 and 110 can be used as negative test cases by a machine learning algorithm. The machine learning algorithm can perform regular or irregular training, for example, monthly, to optimize the classification of hypoglycemia in the very near future. For example, the algorithm can learn the state of the user one hour or one and a half hours before a hypoglycemic event. Example inputs to the machine learning algorithm used for classification can include glucose output records over the past six hours, the current glucose level, the current rate of change of the glucose level, the current glucose acceleration, the time of the last insulin bolus, the size of the last insulin bolus, the reported number of carbohydrates, the time of carbohydrate reporting, the level of the last glucose peak, the last time the user interacted with the monitoring device, the last time the user exercised, the time of day, the time between the insulin bolus and the meal peak, etc. Once the classifier is optimized, it can be applied to data in real time to determine whether there is a likelihood of hypoglycemia occurring within a certain time window.

[0243] Another type of functionality that can be used is to employ Bayesian theory. Such functionality provides a probabilistic means of quantifying the risk of an event for a particular day or night based on a previous distribution. Figures 15A - 15F show example distributions applied to a plurality of GUI inputs, such as (A) a distribution applied to glucose concentration based on previous reliability information, (B) a distribution of the amount of change in a change value based on noise in the amplitude of data and / or rate of change, (C) a distribution of carbohydrate information entered by a user based on the user's prior knowledge of carbohydrate estimation, (D) a distribution of the user's current health state, (E) a distribution of residual insulin based on integrated pump data, and (F) a distribution of, for example, acceleration data. The distribution can be used for any of the inputs, and a probability algorithm is then used to determine a risk index. Such probability 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 a "decision fusion" method. Specifically, decision fusion provides another framework for determining a user's risk state from multiple inputs. Decision fusion uses a statistical model to optimally combine risk information from multiple inputs and generate a likelihood value that some event, such as hypoglycemia, will occur. Such a method is particularly useful for combining disparate inputs, such as the rate of glucose change over the past 20 minutes and the number of times a receiver button has been pressed, into a single likelihood scale. Prior information on the sensitivity and specificity of each input in predicting an undesirable event, such as hypoglycemia, is used to determine how much weight to give to each input in the final risk output, as will be described in more detail below.

[0245] The decision fusion method can be used, for example, to determine whether a given user is likely to drop below 55 mg / dL within the next hour. In such a method, different data parameters can be used to make a determination as to whether hypoglycemia will occur within a given time, such as within the next hour. Data analysis can be performed to determine optimal detection parameters and these optimal presence / absence decision thresholds, as well as the associated sensitivity.

[0246] Examples of parameters that can be used to make a determination as to whether the glucose level is likely to be less than 55 mg / dL within the next hour are shown in Table II below, along with these thresholds for determination and the associated sensitivities and specificities. It should be noted here that while the sensitivities of some parameters can be high (e.g., the glucose value will always be less than 80 mg / dL before it becomes less than 55 mg / dL), these can be less than definitive, i.e., there can be many occurrences where the glucose is less than 80 mg / dL but then does not become less than 55 mg / dL within the next hour. In general, the best predictors have both high sensitivity and specificity, such as a predicted glucose level of less than 55 mg / dL.

[0247] [Table 2]

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

[0249] In this analysis, cases where "yes" applies (hypoglycemia) are denoted as H1 and cases where "no" applies (euglycemia) are denoted as H0, i.e., as the null hypothesis. A determination is made for each parameter (d = 1 or d = 0), and the sensitivity and specificity of the parameter are converted to likelihood values, λ

[0250] [Equation]

[0251] and are used to convert to.

[0252] The likelihood value is the probability of making a decision when the subject will actually become hypoglycemic divided by the probability of making a decision when the subject will not become hypoglycemic. For a decision of "yes" or 1, the likelihood value can be considered as the sensitivity divided by (1 - specificity), that is, the probability of a false alarm.

[0253]

Number

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

[0255] Discovery methods are another type of mathematical method that can be applied to an analysis framework. In such methods, experience informs the development of possible solutions. For example, an urgency assessment module may have data based on the experience that a given user at a given set of GPS coordinates, which happens to be a coffee shop, and the user has a staff meeting scheduled for the next day, implies that the user may have a high glucose value. The glucose value may be related to stress or eating. In the development of such discovery solutions, related techniques such as regression models, MPC, if-then logic, expert systems, logistic regression analysis, neural networks, fuzzy logic, weight functions (which could be applied to more risky blood glucose risk inputs), etc. may also be used. As a specific example of the use of a regression model, A1C can be assumed as the current indicator of good / bad diabetes management. Some or many of the parameters or variables disclosed herein can be obtained from a statistically significant number of users, and regression analysis can be performed to determine which of these factors significantly affect A1C. The resulting multiples can then be adjusted, for example, to present risk points that are easily interpretable on a scale of 1 to 100.

[0256] Accordingly, the GUI can be calculated in several ways and using several different variables and parameters, some of which are measured and others of which are input by the patient or other user. However, the GUI is calculated and then the GUI can be used to dynamically provide a display to a patient (or caregiver) in a hyperglycemic emergency state and can update the emergency state iteratively over time. While the emergency state can be related to hypoglycemia, hyperglycemia, or normal blood glucose values, this provides much more refined information than simply whether the glucose value (or predicted glucose value) has exceeded a threshold. The display to the user is generally an indicator by means of an urgency chart and can advantageously utilize functions that are native to a mobile device such as a smartphone. The smartphone user interface can also be used to provide warnings / alerts to the user.

[0257] The additional information provided is not simply provided to indicate that the glucose value has exceeded a threshold, and may include one or more of the following. The information presented may include a prediction as to whether the glucose value is likely to bounce back to a desired value or whether the deviation from normoglycemia will continue. The information presented may include a prediction (or take into account) regarding a future emergency, which is distinguished from simply providing a predicted glucose value. The information presented may include a consideration of whether the glucose value follows a known pattern or deviates from a known pattern.

[0258] The urgency assessment module running on a mobile device (or elsewhere) can provide a framework for distinguishing the level of risk and urgency of treatments that cannot be provided by a simple threshold, thus providing the user with actionable warnings without overwarning when not necessary, thus preventing warning fatigue. In this regard, when a smartphone is used for glucose monitoring, it is noted that it becomes increasingly important for the user to distinguish which warnings are important for them to notice, as they will receive continuous notifications from their phone for, e.g., emails, texts, phone calls, applications, etc. It is important that particularly dangerous states requiring immediate attention be differentiated from such general phone sounds, perhaps by providing a special sound or vibration or even light / color to warn the user. Further, it is important that the warning increases conspicuously in stages if the user does not respond immediately, and the above parameters and variables can be used to determine when such an increase should occur. The display can be provided by several means such as using color, vibration, icons, heat maps, predictive expressions, numerical expressions of risk, voice input requests, pop-up messages, etc.

[0259] In some cases, the user is warned, but it is desirable to be in a separate mode. Such a warning can be particularly appropriate when the user is with people who are not aware of the current user's condition. Thus, a warning can be provided that is a vibration, but a particularly long vibration, that warns the user to check their mobile device and determine what action is required. Another vibration, for example, a long vibration, but at a time such as 5 seconds, 10 seconds, etc., and at a frequency such as once per minute, twice per minute, etc., that is applied periodically until stopped by the user can be used for the warning.

[0260] If vibration-based warnings and alerts do not result in user operation by the user pressing a button to at least indicate recognition of this, the warning or alert can be provided audibly by a ringtone, such as a ringtone specifically selected for such a situation.

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

[0262] Assuming that the user does not respond to a warning or alert, a first typical reaction could be to pick up or otherwise hold their smartphone. In some cases, the user may have to perform a swipe operation or enter a code to gain access to the smartphone's user interface. Considering this scenario, the emergency display can be provided on the user interface in several ways. First, the display can be provided regardless of whether the phone is held. This can be appropriate when the user leaves their phone in a position where it can be used, such as on a table, face up in a docking station, etc. (e.g., background screen, home screen, regular push notifications, etc.). Second, the display can be provided when a signal that the phone is being held is received by the user interface, for example, via a built-in accelerometer or other motion detector. Third, the display can be provided after access to the smartphone user interface is obtained, for example, via a swipe gesture, code entry, etc.

[0263] Regarding the first and second means, recognizing the fact that the display provided on the user interface may be visible to others, it may contain somewhat less information than when using the third means. Regarding the third means, when the user has already picked up the phone and is operating it, the user can be presumed to have obtained the desired level of privacy. Thus, the displays in the first and second means can be, for example, colors or other indicators that represent an emergency situation familiar to the user. For example, a bright red color on the user interface can indicate a high level of urgency, such as an impending hypoglycemic or hyperglycemic event. The red color can be arranged by the emergency assessment module by operating the background or wallpaper of the mobile device, or this can be the background of an application that is running an emergency assessment module, such as a CGM application, and this background and application are arranged to be prominent in the event of an increased emergency.

[0264] In another implementation example, the color may be accompanied by a number or an arrow, and such a number or arrow informs additional details regarding whether the GUI is evaluating a significant risk of hyperglycemic events versus hypoglycemic events. While such a number or arrow may provide useful information to the user, it previously holds certain unobtrusive details of the user's condition.

[0265] Regardless of how the display occurs, through the user operation of the application, the user can become aware of the relevant details of the user's condition and the possible steps to take in its adjustment. In other words, the user can decide whether they wish to "drill down and examine" the numbers in more detail, in which case the operation of the application permits the user to do so. Variations of the above embodiments will also be seen. For example, instead of a red screen, a red border line or a large red circle around the user's home screen may be used. Different colors or positions may be used to indicate hyperglycemia versus hypoglycemia, or the user may need to instantiate the application to find out their current condition. Different positions or parallel line patterns may be advantageously used as options for users who are color blind.

[0266] Several types of functions available on a mobile device user interface are described herein to indicate actionable warnings 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 display various levels of information, specifically, the glycemic urgency index and glycemic or glucose information, which may in some cases be shown together on the screen. The display of the GUI value may be done by several means, such as visualization or representation, for example, the use of elements such as colors or icons. While specific icons are discussed below, these may vary in many respects, for example, a happy face (normal blood glucose) 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 "lead" can be used, and "lead" is defined as the level of information conveyed to the user and is also known as the information hierarchy, which is the arrangement of elements or content on the screen in a means to clarify the order of importance. A lead can be composed of anything including topography, graphics, color, contrast, weight, position, size, and space (including negative space). A lead is presented to achieve an order of importance or operability. The first lead can be the first item the user sees or is shown (the most visible or prominent). If there is only information at one level shown, there is no need for a second lead. However, a device can have multiple levels or leads. A device with a larger number in a brighter red font and then a smaller number in a lighter colored font has two leads. The larger number is the first lead (what the user sees first), and then the smaller number is the second lead (what the user sees, notices, or wants to see less frequently compared to the first lead). Generally, the first lead is lower resolution information but more actionable information or information that can be seen at a glance, such as a representation showing a GUI, a blood glucose state or glucose level, etc., which can be quickly read at a glance. Generally, the second lead provides high resolution (more detailed) information, which can be read with a longer gaze or requires a longer thought process. Additional leads can be provided with more or different levels of detail as would be understood by those skilled in the art. In some implementation examples, the first lead is provided on the first viewable screen (e.g., the background or home screen of a mobile device or software application), and the second lead is provided in a configuration and position that is less likely to be seen at a glance or read easily on the same screen. In some implementation examples, the first lead and the second lead are on different screens that the user needs to access separately.Additionally, the first lead may be a simple light, such as, for example, 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 present patent application incorporated by reference above. In one implementation of a wearable device, such as a wristband, the first lead may be provided as a color LED that may be displayed on the wearable device, and the second lead may be accessible only via another device, such as a software app on a smartphone. The first lead may be advantageously mild or at least unobtrusive so as not to draw attention or discussion of diabetes.

[0268] With reference to Figures 16A and 16B, a user interface 550 is illustrated that presents two different states. In Figure 16A, the first lead 504 is illustrated by the color of the device (indicated by cross-hatching). For example, the user interface of the device in Figure 16A may be yellow, while the user interface of the device in Figure 16B may be red. From a distance or with a quick glance, the user can thus be informed of their GUI or glycemic state. In this case, the urgency assessment may be yellow to indicate to the user that their glucose value is relatively normal, or slightly elevated, or approaching the boundary of euglycemic values. In Figure 16B, a red urgency assessment may indicate to the user that their glycemic state, 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 users will understand the meaning of the colors, others may not realize that diabetic information is being conveyed due to the abstract nature of the background design.

[0269] In the implementation example of FIG. 16, any second lead 502 is also provided, which represents the glucose value itself. As described above, the urgency assessment generally uses the glucose value in its determination, but other values may also be used, which may be equally important in the determination. Additional leads, for example, additional information regarding GUI input, patterns, insights, treatment proposals, etc., can be accessed via the CGM.

[0270] In this implementation example and other implementation examples, the home screen of the mobile device on which the urgency assessment module or the CGM application is running in the background can be a color-coded screen indicating the glucose state. The color-coded screen generally indicates a GUI state showing, for example, a "normal" or non-warning-worthy GUI even in the absence of warnings or alerts. The user does not need to perform a swipe operation or enter a password to access this information. Such a screen can be quickly viewed by pressing the startup button on the mobile device or, as described above, by the accelerometer that determines whether the mobile device is being held.

[0271] Referring to the user interface 560 of FIG. 17, color is still being used, but in this case, the first lead is not the color of the home screen 506, but rather the color of the circle located on the home screen (circle 508 in FIG. 17A and circle 508' in FIG. 17B). The second lead can be the size of circle 508 or 508', e.g., the radius of the circle, and the speed or acceleration exemplified by an arrow 512 or 512' indicating direction. For example, the arrow can exemplify the first derivative of whether the glucose value is rising or falling, and the size of the circle can indicate how fast the glucose value is rising or falling (the second derivative). Alternatively, the circle can qualitatively represent the potential danger resulting from the rise or fall. For example, a large circle can represent that the rise is accelerating away from normal, while a small circle can represent that the rise is decelerating. A third lead 516 is also exemplified, which indicates the actual measured glucose value. Finally, in FIG. 17B, an advanced output 514 is exemplified, which indicates the level of analysis that occurs as part of or simultaneously with the GUI's decision, and provides a suggestion for a possible step for the user to take or a request for input.

[0272] Referring to FIGS. 18A and B, an alternative user interface 570 presented on the home screen 516 of a mobile device is illustrated. FIG. 18A illustrates a case of rising glucose levels, and FIG. 18B illustrates a case of decreasing glucose levels. Specifically, arrows and a series of circles 518 (518’), as well as their colors, can be used to indicate to the user whether their urgency assessment is rising (FIG. 18A) or decreasing (FIG. 18B). Specifically, referring to FIG. 18A, the rise itself is illustrated by the arrow, and the color progression from off-white to red illustrates that the urgency assessment 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 lead. In the case of FIG. 18B, the color progression from red to white indicates a return to a more desirable emergency state. The arrow, the presented fading of the circles corresponding to more past measured urgency assessments, and the progression from left to right indicate the progression from a previous emergency state to a later emergency state and ultimately to the current emergency state. Alternatively, the series of circles (or icons) 518 may represent a predicted glucose value or a range as a first lead, which may include the predicted glucose value at 522 and a display of the predicted range (predicted value over time) indicated by, for example, 5 minutes per circle or the number of circles (or icons) of 15 minutes in this embodiment. The second lead may be access via a swipe or other user operation that provides additional insight or information related to the prediction.

[0273] The variations are understood and are similar to the specific embodiments described above. It will also be understood that such variations are provided in other embodiments described herein. Shapes other than circles or icons or things that appeal to the visual can also be used. For example, it can be an image of the moon shown in its progression from new moon to full moon. For example, the size of the circle and their colors can indicate the urgency assessment. The subsequent arrangement of sizes can indicate how rapidly the values are changing. For example, the progression from a very small circle to a very large circle can indicate a rapid increase in the urgency assessment. Conversely, the progression from a "medium-small" circle to a "medium-large" circle can indicate a much more gradual increase. Additional indicators or leads 524 can be used to provide icons that can be read at a glance to quickly indicate to the user the importance of the user's assessment. Such indicators can be displayed automatically after a step of swiping / unlocking, or following the act of holding the mobile device in hand or determined by an accelerometer or other sensor without holding the mobile device in hand. This can be achieved by an audible warning to notify the user of an emergency situation.

[0274] Figures 19A and B illustrate another user interface 580 that can be used on a monitoring device, such as 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 can be divided equally or not equally, and the number of regions can vary. The number of regions can vary further based on user input, for example, if the user desires a finer granularity in the data presented to the user.

[0275] In FIG. 19, seven regions are presented with a low-risk or no-risk region 526d at the center of the region's range. For the urgency assessment shown in FIG. 19A, the assessed urgency is little or none, i.e., there is little risk to the user. However, the urgency assessment shown in FIG. 19B represents a higher emergency state, in this case related to elevated glucose levels. The position and color of the highlighting can be used to provide the display. In FIG. 19A, the highlighting is at the center and the color is white, indicating low urgency. In FIG. 19B, the highlighting is within the higher region and is colored red, indicating a higher emergency state. If the highlighting, or other leading indicators, are 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 for the glucose value and a numerical depiction 532. From the numerical depiction 532, the user can be informed of their glucose value. From the arrow 528, the user can be informed of the direction in which their glucose value is heading. Arrows of the same color (shown in FIG. 19B) can indicate a more rapid rise or an accelerating rise. These factors, and generally more factors, go into the determination of the GUI, and the representation of the determination result is the highlighted range, indicating the determined urgency assessment.

[0276] An advanced output 534 is also shown, and such an advanced output 534 provides the user with additional information about possible causes of hyperglycemia, possible steps towards a lower urgency assessment, etc.

[0277] The ranges within the different regions do not need to represent equally spaced levels of urgency, and it is understood that this can provide a quantitative or qualitative level of urgency based on the determined GUI. The ranges can be set by the user or by a physician or other caregiver, and thus can be individualized to the specific needs of the user. Similar individualization possibilities will apply to other embodiments of the user interfaces disclosed herein.

[0278] In FIGS. 20A and B, a user interface 590 having a scale 536 similar to a thermometer is illustrated, where a rectangle 538 indicating a generally desired glucose range is depicted. This user interface does not require the use of arrows. The current glucose level can be indicated by an emphasized horizontal bar 542, the past glucose levels can be indicated by a more faded horizontal bar 544, and the various gradation horizontal bars in between indicate the change over time in the glucose value. In some implementations, a background color of the same color can indicate third lead or third level information such as, for example, Wi-Fi status, glucose communication (data sharing) with other mobile devices, etc.

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

[0280] FIGS. 21A and B illustrate another means of representing urgency on a user interface 610 of a mobile device. The user interface 610 depicts a means by which a distinct representation can be provided in particular. Specifically, a grid pattern 548 that can be individualized by the user or on behalf of the user is provided. The user can associate a defined grid space with a specific urgency indication. For example, the lower horizontal row can represent a hypoglycemia urgency assessment, the middle area can be a target urgency assessment, and the upper horizontal row can represent a hyperglycemia urgency assessment.

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

[0282] The user may recognize the numerical threshold, but the numerical threshold is not placed on the screen for various reasons including the general purposes of caution, preventing questions from others, and / or clarity. Grid spaces may be added based on, for example, the urgency assessment including the direction and magnitude of increase, 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] Similar to other embodiments, however, in this case regarding grid spaces 552 and 554, the emphasis occurs together with a particular color, the display of the glucose value, and the display of the direction in which the glucose value is moving. As seen in FIG. 21B, the highlighted display may also be provided within other grid spaces shown here as grid spaces 556 and 558 for showing the most recent past values of the measured glucose.

[0284] Figures 22A and B illustrate another user interface 620 that can be used to represent urgency. In these figures, a graph 562 of glucose values is provided to enable the user to view values from the recent past. Such a graph can be particularly important to users who desire a higher level of knowledge about the user's current level. As illustrated in Figure 22A, a current glucose value 566, and a box 564 that bounds that value and generally indicates where on the graph the current time is represented can also be provided. To represent a GUI-based urgency assessment, the color 572 of the screen can be used. For example, in Figure 22A, a light red background 572 can indicate an increasing level but a low urgency assessment. In Figure 22B, a blue background 572' can indicate a normal blood glucose value and a zero urgency assessment. Figure 22B also shows that the box 564 can be used to show, for example, a portion of a glucose output recording graph with a higher level of fidelity, additional processing (e.g., detected patterns), etc. In the user interface of Figure 22, a horizontal threshold bar is not necessary, and yet through the use of a colored background, the user is still made aware of their "zone" of urgency assessment.

[0285] Figure 23 shows a user interface with a higher level of detail, specifically showing average and predicted glucose levels, which leads to an urgency assessment based on factors such as the GUI and thus the past behavior at that time. Specifically, the user interface 630 includes a background 574, which can indicate an urgency assessment, for example, blue, green, yellow, red, etc. Alternatively, the color of box 576 can indicate the urgency assessment, and this box is also where the current (or alternatively predicted) glucose value 578 is displayed. A horizontal scale 582 is provided with respect to time, and thus an output recording graph of glucose level 584 can be displayed as a function of time. Past values (average glucose profile or normal patient pattern) at a given time are illustrated by bar graphs 586 and 588, which illustrate the range of hypoglycemia and hyperglycemia seen in the past at a given time for a given user.

[0286] A portion of the graph, for example, a portion within box 576, may represent an elevated glucose level determined using predictive analytics as described above, which may or may not be involved in the urgency assessment. This elevated value is illustrated as output record 592, which has a different line width in exemplary FIG. 23. Specific low or high value areas may be represented in different colors, for example, yellow for moderately high / low values and red for very high / low values.

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

[0288] As described, glucose values and other factors affect the determination of the GUI and thus the urgency assessment. The urgency assessment may be shown to the user via the color of the background 614 or by a display such as the text display 612 etc. via user interface 640, which in FIG. 24 indicates that the assessment is that the user is "OK". User interface 640 also shows the current glucose value 606 and the direction in which the glucose is headed as indicated by arrow 608. In some implementations, the gradient, size, or other aspect of arrow 608 may indicate how fast the glucose value is rising or falling.

[0289] The variations will be understood. Specifically, it is noted here that not all aspects shown in this implementation example and other implementation examples need to be displayed. For example, in FIG. 24, the numerical glucose value 606 can be omitted because the user can obtain similar information from the consideration of the output record 594 or simply from the character display 612.

[0290] In this implementation example and other implementation examples, the rate of change and acceleration information can be added to the output record graph arrows. Of course, the rate of change can be obvious from the output record graph itself, but colored or curved arrows can be used to indicate the acceleration or deceleration of the glucose level. In one implementation example, red arrows can indicate undesirable values of acceleration, while blue indicates desirable values. In another implementation example, the curvature of the arrow away from normal blood glucose can indicate undesirable acceleration, while the curvature towards normal blood glucose can indicate a desirable trend.

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

[0292] FIG. 26 illustrates another user interface 660 that may be advantageously used. The user interface 660 is similar to that of the user interface 630 of FIG. 23 but includes additional details of the prediction. Specifically, the user interface 660 includes points 632 plotted to correspond to the predicted glucose levels based on predictive analysis as described above. The instantaneous glucose level 634 is displayed as a numerical value to provide the user with an easy-to-read display.

[0293] High output 636 is also exemplified and can be used in various ways by the urgency assessment module. For example, if several friends or followers are associated with the user, this can provide a notification to the friends or followers to take some action with respect to the user. For example, friends or followers can be called upon to reach out to the user if the user's urgency assessment tends to be high or low. High output 636 can also be used to reach out to the user himself, for example, to propose treatment guidelines or otherwise provide an outreach. Additional details of the high output are provided below.

[0294] Figures 27A and B illustrate various activities or posts that can be provided to or from a feed related to a social networking service. At the most passive level, the user can receive up-to-date information from friends or followers the user is associated with in the social network. This group can correspond to all friends or a subset of friends, for example, people who are also living with diabetes. At a more advanced and two-way level, user posts can be used within the determination of the GUI. For example, a post about participating in a race combined with known glucose and other data related to the user for that day can provide improved data for the social networking feed. Similarly, this can be used in combination with past data regarding similar situations to provide and post past comparisons. For example, in Figure 27B, a post (post 638) of "Race day! The last time I did this, I reported feeling invincible with a high-carb breakfast!" can be seen.

[0295] Based on this teaching, other aspects suitable for social networking will be understood. For example, in various other embodiments, the evaluation module 211 can be used in combination with the contact module to provide up-to-date information to the social network. In some embodiments, the smartphone 200 uses the user's location and / or other attributes related to the user (e.g., type of diabetes, age, gender, demographic data, etc.) and / or a similar CGM device or smartphone application to find other people in the area with similar attributes in order to propose connections between people. For example, the CGM application and / or a social media site in conjunction with the CGM application can enable the user to select from options such as finding other people with diabetes, finding other people with diabetes near me, or finding recommendations for diabetes-friendly restaurants in the area.

[0296] In some embodiments (see Figure 6), the CGM application 209 (either alone or not necessarily running within the CGM application 209, but generally in combination with an evaluation module 211 that runs within it) enables the user to selectively upload or share information regarding their evaluation electronically and / or via a social networking site. Example information that can be shared includes evaluation criteria for success, current EGV values, screenshots, achievements, awards, pattern trend graphs, activity information, location information, and / or any other parameter described elsewhere in this specification as a possible input to or output from the evaluation module 211. For example, the CGM application 209 (it will be understood here and below that such a CGM application may include an evaluation module 211) may have selectable operations for the user, such as sharing of EGV on Facebook, sharing of EGV on Twitter, sharing of screens via Facebook, Twitter, email, MMS, sending of trend screens to a printer, etc. Additionally or alternatively, the CGM application 209 may enable the user to add pre-settings and / or custom headings, or change the status of their shared information such as looking at my no-hitter, which can be shared selectively and / or automatically (either by the user or based on parameters). In one example, the user can directly "like" a particular GUI or its display on a particular social site. In certain embodiments, when the user selects to share information, options may be presented on the display device 202 (Figure 6) that enable the user to select what and with whom they are sharing. The user can pre-define the groups and / or individuals with whom to share information. For example, the user can create a group of friends, and when the user selects to share something that they have selected to share with the defined friends, then a notification is sent to each person within the group. This functionality is useful, for example, for parents who want to monitor the blood glucose of their children.The child can choose to share the BG value and then can select the parent, or the mother, or the father, and then the BG value is sent to the selected person(s).

[0297] In some embodiments, the CGM application 209 can be configured to work with a social network to enable a user to compare EGVs, 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 for determining a comparison of data from one person to an average (grouped, for example, by some similarity). In some embodiments, the CGM application 209 calculates an achievement, score, badge, or other award based on defined criteria (maintaining blood glucose within a target range, CGM use, etc.) and can selectively or automatically post this to a social networking site (e.g., Facebook). In some embodiments, when a user wants to share something learned from the CGM application 209 or the evaluation module 211, e.g., a photo of food and the resulting EGV or trend graph, the CGM application 209 enables the user to selectively upload the information to the site. In this context, something learned is an event or first situation and the resulting impact, output, or trend that occurred as a result thereof.

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

[0299] The discussion of the user interfaces shown in FIGS. 28A and B continues to the possible results of the user interface 680. The user interface 680 shows rather unremarkable results that will probably only be known to the user. Thus, the user's health status is not displayed in a particularly obvious manner on the user interface. Specifically, referring to FIG. 28A, a balloon having a color 642 and any numerical value 644 is shown. The color displays the result of the GUI decision in an unobtrusive and gentle manner. The numerical value 644 provides additional leads as being related to the current glucose value in this implementation example. In addition to the balloon, a number of other icons or images can be used and, in fact, it is understood that they can be selected by the user. Thus, for example, the user can select a car whose color is related to the GUI decision (e.g., red, yellow, green, etc.). In the balloon example, additional information or leads can also be provided. For example, the height of the balloon can indicate whether the GUI is more urgent or less urgent, or whether the glucose value is rising or falling. Other variations will also be seen.

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

[0301] The foregoing description of the user interface is purely exemplary, and it will be understood that numerous variations will be apparent. For example, the GUI determination and actionable warnings may be provided within the game either to hide data so that only the user can distinguish it, or by means such that a preferred GUI determination results in a preferred game outcome. In other words, if the user controls their urgency assessment, the user wins the game. Further, the notifications and actionable warnings may be provided in a manner that differentiates them from other warnings on the mobile device, such as warnings from text messages, application updates, phone calls, voicemails, etc. The user may configure the CGM application 209 such that warnings from the urgency assessment module 211 must be cleared before the user can use the phone, so that warnings from the urgency assessment module 211 either override all other warnings or ensure that urgency warnings or alerts are not inadvertently missed. As described, warnings or alerts may scale up incrementally as the urgency assessment increases, i.e., becomes more urgent. Initially, the warning may be presented on the user interface when the device is unlocked, while such warnings may scale up incrementally to audible alerts as the urgency increases.

[0302] Additional information provided by the user interface may include such values so that the user can be notified of states such as bounce high values and bounce low values, and may provide possible user actions. In so doing, the user can easily compare and become aware of the causes and effects of such states, and since both are still fresh in the user's mind, easily associate the cause with the action.

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

[0304] Specifically, users may not desire a warning if the GUI simply follows a known pattern, for example, if their GUI has a small deviation into a minor emergency state. Since users expect the GUI to increase based on pattern input, as further detailed elsewhere in this specification, they may not desire to be notified that their glucose has temporarily increased after eating a meal. When users take a day off from deliberately trying to achieve optimal management and choose to engage in "bad behavior," such as eating a birthday cake and having a little alcohol with friends to celebrate their birthday, resulting in a day of poor glucose management, they may not desire to be alerted to glucose fluctuations. Users are protected but may not always desire to be constantly monitored. Thus, in one implementation, users can set the urgency assessment module to an "operating mode" where they are notified only of potentially dangerous scenarios, such as "< 55", "< 70 for over 30 minutes", or "> 300 and still rising rapidly". Providing an urgency assessment module with such functionality solves the problem of CGM users often being given information at inconvenient or potentially bothersome times. This also allows appropriate information or warnings to be displayed when users are not checking their CGM and when they are regularly checking their CGM.

[0305] Referring to flowchart 720 of FIG. 30, a method according to this principle is shown for the display of a warning. In a first step, the GUI is determined as described above (step 646). Then, the result of the GUI is determined, which can be a warning, an alert, or simply an output of the current state of urgency (step 648). The output can also be based on adaptive learning, and specifically, learning about the characteristics of the user, including patterns and trends 652 of the GUI and glucose levels, characteristics of mobile device usage, and other parameters and variables described above. Such things can include, for example, user input 654 indicating that the user desires to be notified only of dangerous states. Adaptive learning can also be based on the mode 653 in which the urgency assessment module is operating. For example, if the mode indicates that the user desires to be warned only of dangerous states, such a mode can be included as a factor in the determination of the result in step 648. Similarly, the user can input a mode 653 in which they desire a significant level of intervention or recommendation. Assuming the present teachings, other modes will be understood similarly. Other data 655 can also be used in the determination of the result based on learning.

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

[0307] Requests to receive additional information can be addressed by several other means and may in some cases match the specific advanced outputs described above. One possible type of output involves input requests and questions / answers and may in some cases involve an avatar to more fully engage a particular user, such as a child.

[0308] In another implementation example of the user interface, illustrated by the user interface 730 shown in FIGS. 31A and B, various scenarios based on the urgency assessment are presented to the user. Thus, rather than enhancing a particular measurement, the focus is tailored to the possible treatments to be taken. For example, referring to FIG. 31A, the user interface 730 may display situation 666 and present various scenarios 668 that the user can select. FIG. 31B shows another situation.

[0309] Possible treatments can be ordered based on the safest to the most aggressive.

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

[0311] Possible treatments can be severe notifications similar to warnings in some cases, or alternatively gentle input requests that are only seen when the user views their CGM screen. In such cases, the pushed data can be updated immediately without delay. The criteria can also be set for notifications based on potentially dangerous scenarios, such as severe low glucose levels, etc.

[0312] As described above, activities such as sleep and exercise can be recognized. The output can be linked to such detected activities. For example, if the parent is sleeping, for example, it is currently 2 am, and the sensor and / or mobile device has been stationary for X minutes (X can be 10 minutes, 20 minutes, 30 minutes, 1 hour, etc.), sleep is assumed, and the output can be audible and loud enough to wake the user. When the user is driving, the output can also be audible and / or quite loud. If the user is deviating from the normal pattern, the output can provide additional details or ask the user questions. Other variations will be understood.

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

[0314] Indicators for GUI-based notifications as well as for warnings and alerts can be factory-set or individualized by the user who can also set the thresholds at which warnings and alerts occur. The system can also be provided for changing warnings based on trends or other factors in the GUI, either automatically or triggered by the user. For this purpose, the system enables dynamic and / or iterative updating of the urgency indicators and status over time when additional data is received and based on user operations.

[0315] For example, a user may have an estimated glucose of 100 mg / dL but may be dropping at a rate of 2 mg / dL / min, so the urgency of hypoglycemia at 70 mg / dL (e.g., yellow status) is estimated after 15 minutes (a 30 mg / dL drop), and the critical hypoglycemia urgency (e.g., red status) is estimated at 22.5 minutes. If the red emergency state is defined as up to 55 mg / dL in 20 minutes, 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 can enable different sensitivities based on, for example, time (day vs. night), during driving, during exercise or sports, during a nap, when sick, etc. The sensitivity can also be adjusted based on user requests. For example, a user who desires a significant amount of feedback including positive feedback can adjust the sensitivity to a high setting (or low discrimination level) to enable a significant amount of information to be presented. Other feedback provided can be essentially positive such that the urgency begins to resolve as soon as it is evaluated, and the user interface can display a message indicating an improvement in the situation such as "Your treatment seems to be working." In this way, the user can be beneficially intervened even before the user reaches the optimal correction point, and further advantageously prevent the stacking of insulin and food that can lead to harmful overcompensation. Further details of such types of feedback are described below.

[0317] Conversely, other users may desire warnings or information only when entering a critical urgency assessment or a potentially critical urgency assessment. For such users, the sensitivity can be set to a low setting (or a high discrimination level) in order to minimize the number of warnings or alerts received.

[0318] Other types of interventions can also be used within the output from the feedback or urgency assessment module. For example, when the user goes from a more urgent blood glucose state to a less urgent blood glucose state, i.e., from a higher risk to a lower risk, the output can similarly indicate that the user's treatment has begun to correct the critical blood glucose risk state, and again, prevent the stacking of insulin and food.

[0319] Other types of advanced outputs that are conceivable will also be understood. For example, based on the current urgency assessment and data regarding residual insulin or food intake, a proposal for treatment, i.e., a means to lower the urgency assessment, can be provided. As another type of advanced output, a link can be provided that, when clicked, leads the user to additional information regarding the current state or urgency assessment. A GUI, i.e., a future or predictive trend graph (or other means of providing such information, such as a numerical indicator or score, color, etc.) indicating whether the urgency assessment or state is predicted to progress or in which direction different treatment options can be advanced, can be provided. A future trend graph in glucose level or other parameters can also be provided.

[0320] By using these types of outputs and by continuously updating the blood glucose state, GUI or urgency assessment trend information that is clearly distinguishable from only output based on glucose value threshold crossings or even from glucose trends can provide them with information that they would otherwise not receive.

[0321] While the above information is based on a generally expected glycemic urgency assessment, selective warnings can also be based on a retrospective algorithm that looks for certain types of glycemic deviations that may indicate long-term glycemic complications. Such a retrospective algorithm was described above in connection with GUI decisions, but it is noted here that the retrospective algorithm can also be the basis for various user interface displays and / or input requests. For example, a retrospective investigation can show large deviations from low to high or from high to low. One example based on a retrospective warning system intended to draw the user into CGM events is illustrated below. The retrospective warning can issue a warning on the user's smartphone when significant information is found in their data.

[0322] One such exemplary method is illustrated by flowchart 740 of FIG. 32A. In a first step, the retrospective algorithm examines data for various glycemic events, such as significant deviations from normal values or values determined to be typical according to a reference value, evolving patterns, etc. (step 672). In so doing, the algorithm can examine the most recent minimum and maximum values as soon as a new sensor packet of data arrives. An example is illustrated by graph 750 of FIG. 32B. Output recording point 678 illustrates the CGM output recording, horizontal bar 682 represents the start of an event, and horizontal bar 684 represents the end of an 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] Next, the retrospective algorithm checks whether the deviation of the current event is outside the threshold (step 674). The threshold can be based on the difference between values in mg / dL, the percent difference between the start and end of the event, or other factors such as whether the deviation exceeds a standard deviation outside of typical deviations. By placing such thresholds appropriately, the system ensures that only meaningful events are displayed to the user and that nuisance warnings are minimized. Advantageously, easy collection of user information useful for pattern recognition and generally teaching the user about their personal blood glucose events, patterns, or profiles can be made possible.

[0324] If the event is outside the threshold and thus meaningful, this triggers a warning or other resulting output (step 676). For example, a push notification can be sent, an icon can be represented on a trend graph, a batch number can be incremented, etc. Other such notifications will also be understood. The warning displayed generally varies based on the type of event. For example, if the event indicates that the user is crossing from a high glucose value to a low glucose value, e.g., from 294 mg / dL to 46 mg / dL, the message could be "We noticed a large glucose deviation. Do you want to enter carbohydrate and / or insulin information regarding this event?" While the trend graph segment can be highlighted in a different color, the warning is active, indicating that the user has not dismissed it. Such a situation can be shown in graph 760 of FIG. 32C by different colors (lines or dots) within segment 686.

[0325] A system and method for dynamically and repeatedly evaluating a blood glucose urgency index related to an urgency assessment are disclosed. Various methods for determining the blood glucose urgency index and for displaying the determined urgency assessment to a user are disclosed.

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

[0327] The connections between elements are shown in the figures that illustrate example communication channels. Additional communication channels, either direct or via intermediaries, can be included to further facilitate the exchange of information between elements. The communication channels can be two-way communication channels that enable elements to exchange information.

[0328] As used herein, the term "determine" encompasses a wide variety of operations. For example, "determine" can include calculate, compute, process, derive, inquire, refer (e.g., to a table, database, or another data structure), ascertain, etc. Further, "determine" can include receive (e.g., receive information), access (e.g., access data in a memory), etc. Further, "determine" can include resolve, select, choose, establish, etc.

[0329] As used herein, the term "message" encompasses a wide variety of formats for transmitting information. Messages can include machine-readable aggregates of information, such as XML documents, fixed-field messages, comma-separated messages, etc. Messages can, in some implementations, include signals utilized to transmit one or more representations of information. While cited in the singular, messages are understood to be composed / sent / stored / received in multiple parts, for example.

[0330] The various operations of the above method can be performed by any suitable means capable of performing operations such as various hardware and / or software components, circuits, and / or modules. Generally, any operation illustrated in the figures can be performed by corresponding functional means capable of performing the operation.

[0331] The various exemplary logical blocks, modules, and circuits described in connection with the present disclosure (e.g., the blocks of FIGS. 5 and 6) can 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 signal (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination of these designed to perform the functions described herein. The general-purpose processor can be a microprocessor, but in the alternative, the processor can be any commercially available processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration.

[0332] In one or more aspects, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functionality may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. 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 media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can 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 is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disk generally magnetically reproduces data, while disc uses lasers to optically reproduce data. Thus, in some aspects, computer-readable media may comprise non-transitory computer-readable media (e.g., tangible media). Further, in some aspects, computer-readable media may include transitory computer-readable media (e.g., a signal). The above combinations are also intended to be within the scope of computer-readable media.

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

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

[0335] Software or instructions can even be transmitted via a transmission 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 technology such as infrared, wireless, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology such as infrared, wireless, and microwave are included in the definition of transmission medium.

[0336] Furthermore, it should be understood that modules and / or other suitable means for implementing the methods and techniques described herein can be downloaded and / or otherwise obtained by the user terminal and / or the base station if applicable. For example, such a device can be coupled to a server to facilitate the transfer of means for implementing the methods described herein. Alternatively, the various methods described herein can be obtained by the user terminal and / or the base station in combination, or provided via storage means such as storage means (e.g., RAM, ROM, physical storage media such as compact discs (CDs) or floppy discs, etc.) that provide the storage means to the device. Furthermore, any other suitable means for providing the methods and techniques described herein to the device can be utilized.

[0337] It is understood that the claims are not limited to the detailed configurations and components exemplified above. Various modifications, changes, and variations can be added to the arrangements, operations, and details of the methods and apparatuses described above without departing from the scope of the claims.

[0338] Unless otherwise defined, all terms (including technical and scientific terms) shall have their ordinary and customary meanings as would be apparent to one of ordinary skill in the art and shall not be limited to special or individualized meanings, unless expressly so defined herein. The use of certain specialized terms, when describing certain functions or aspects of the present disclosure, should be noted as not being meant to be redefined herein so as to be limited to any particular features of the functions or aspects of the present disclosure to which such specialized terms pertain. It should be understood that the terms and expressions used in this application and their variations are to be construed as being non-limiting, in contrast to being limiting, unless otherwise expressly specified, particularly in the appended claims. By way of the foregoing example, the term "including" should be read to mean "including, but not limited to", "not limited to, but including", etc., the term "comprising" when used herein represents the same as "including", "containing", or "characterized by", includes without limitation or exclusion of additional unrecited elements or method steps, the term "has" should be construed to mean "has at least", the term "includes" should be construed to mean "including, but not limited to", the term "example" is used to provide an instance that is an example of the item under discussion and not a complete or limiting listing thereof, and adjectives such as "known", "ordinary", "standard", etc., and terms of similar meaning should not be construed to limit the item described to items available at a given period or point in time, but rather should be read to include known, ordinary, or standard techniques that are currently or later available or could be known, and the use of terms such as "preferably", "suitable", "desired", or "desirable", and words of similar meaning are not meant to imply that a particular function is critical, essential, or even important to the structure or function of the present invention, but rather should be understood as merely emphasizing alternative or additional features that may or may not be utilized in a particular embodiment of the present invention.Similarly, a group of items connected by the conjunction "and" should not be read as requiring each and every one of these items to be present within the group, but rather should be read as "and / or" unless specifically specified otherwise. Similarly, a group of items connected by the conjunction "or" should not be read as requiring mutual exclusivity between the groups, but rather should be read as "and / or" unless specifically specified otherwise.

[0339] When a range of values is provided, it is understood that the upper and lower limits of the range, as well as each intervening value therebetween, are included within the embodiments.

[0340] Regarding the use of substantially any plural and / or singular terms herein, one of ordinary skill 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 substitutions may be explicitly recited herein for clarity. The indefinite articles "a" or "an" do not exclude the plural. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measured values are recited in different dependent claims does not indicate that combinations of these measured values cannot be used to advantage. No reference signs in the claims shall be construed as limiting the scope.

[0341] Where a specific number of introduced claim recitations is intended, such intention will be further understood by one of ordinary skill in the art to be expressly recited in the claim, and where there is no such recitation, there is no such intention. For example, by way of aid to understanding, the appended claims below may include the use of introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases does not mean that the introduction of a claim recitation by the indefinite article “a” or “an” should be construed to limit any particular claim that includes such introduced claim recitation to embodiments that include only one such recitation (e.g., “a” and / or “an” should typically be construed to mean “at least one” or “one or more”), and this also applies to the use of definite articles used to introduce claim recitations. Further, even if a specific number of introduced claim recitations is expressly recited, one of ordinary skill in the art will understand that such recitation should typically be construed to mean at least the recited number (e.g., an explicit recitation of “two recitations” without other modifying language typically means at least two recitations, or two or more recitations). Further, in these instances where conventions similar to “at least one of A, B, and C, etc.” are used, such interpretations are generally intended in the sense that one of ordinary skill in the art will understand the convention to include any combination of the recited items that includes, for example, a single element (e.g., “a system having at least one of A, B, and C” will include, but not be limited to, a system 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 these instances where conventions similar to "at least one of A, B, or C, etc." are used, generally such an interpretation is 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 not be limited to, a system 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 should be further understood by one of ordinary skill in the art that, regardless of whether in the description, in the claims, or in the drawings, substantially any disjunctive and / or clause presenting two or more different terms contemplates the possibility of including one of the terms, including neither of the terms, or including both of the terms. For example, the expression "A or B" would be understood to include the possibilities of "A" or "B" or "A and B".

[0342] All numbers representing quantities of ingredients, reaction conditions, etc. used in this specification are understood to be modified in all instances by the term "about". Accordingly, unless indicated to the contrary, the numerical parameters set forth in this specification 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 scope of any claims of any application that may have been filed prior to this application and that may claim the benefit of the same principle, each numerical parameter should be construed in light of the significant digits and ordinary rounding methods.

[0343] All references cited in this specification are hereby incorporated by reference in their entirety. To the extent that any incorporated publications and patents or patent applications included in this specification conflict with the present disclosure, this specification is intended to supersede and / or take precedence over any such conflicting materials.

[0344] Headings are included in this specification for reference purposes and to assist in finding various sections. These headings are not intended to limit the scope of the concepts described therein. Such concepts may have applicability throughout this specification.

[0345] Furthermore, although the foregoing has been described in some detail by means of figures and examples for purposes of clarity and understanding, it will be apparent to those skilled in the art that certain changes and modifications can be made. Accordingly, the description and examples should not be construed as limiting the scope of the invention to the particular embodiments and examples described herein, but rather should also include all modifications and alternative means coming within the true scope and spirit of the invention.

Description of Reference Numerals

[0346] 2 Drug delivery pump 4 Reference meter 8 Sensor system 10 Continuous analyte sensor 12 Sensor electronics 14 Display device 16 Device 18 Mobile device 20 Computer device 21 Wearable device 22 Cloud-based processor 24 Network 26 Numerical value 200 Electronic device 202 Display device

Claims

1. An operating method of a medical device including an electronic device, which determines an emergency degree index of a user related to a physiological state, a. Receiving first type of data related to a physiological state, wherein the first type of data is data indicating a glucose concentration measured by a glucose sensor; b. Calculating second type of data related to the physiological state, wherein the calculated second type of data is derived from the received first type of data; c. Receiving third type of data, wherein the third type of data is provided by a sensor electronic device, a processing circuit, or software of the glucose sensor, and indicates a delay value related to an amount of processing performed by a glucose value signal; d. Determining an emergency degree index based at least on the received first type, second type, and third type of data, including raising an emergency decision when it is determined that the delay value exceeds a predetermined value; e. Providing a display of the determined emergency degree index on a mobile device and executed by a processor that executes an application on the electronic device to perform the above processing An operating method of a medical device.

2. The operating method of the medical device according to claim 1, wherein the physiological state is diabetes and the emergency degree index is a blood glucose emergency degree index.

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

4. The operating method of the medical device according to claim 1, wherein the second type of data derived from the first type of data is a first derivative or a second derivative with respect to time of the first type of data.

5. The method of operating a medical device according to claim 1, wherein the data of the second type derived from the data of the first type includes a deviation from a normal glucose pattern, pattern data of glucose values over time, predicted glucose values, the duration for which the glucose value is within a specified range, the weighting of parameters or variables considered in the determination of the urgency index, or the maximum or minimum value of the data of the first type.

6. The method of operating a medical device according to claim 1, further comprising providing a warning or an alarm when the urgency index reaches a specified warning threshold or alarm threshold respectively, wherein the urgency index is a glycemic index, and the specified warning threshold or alarm threshold indicates that the user is in a hypoglycemic state or a hyperglycemic state.

7. The method of operating a medical device according to claim 1, wherein the physiological state includes one or more of obesity, malnutrition, hyperactivity, depression, or multiparity.

8. An electronic device for monitoring data related to a physiological state, comprising: a. A continuous analyte sensor configured to substantially continuously measure the concentration of an analyte in a host and provide continuous sensor data related to the concentration of the analyte in the host; b. A processor module configured to implement the method according to any one of claims 1 to 7. An electronic device comprising the above.

9. The electronic device according to claim 8, further comprising a drug delivery device configured to deliver insulin to the host, wherein the drug delivery device is operably connected to the continuous analyte sensor.

Images