Blood glucose emergency 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 of Related Applications by Reference All claims of priority, or any amendments thereto, identified in the application data sheet for this application are hereby incorporated by reference into this specification in accordance with 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 cannot 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 the 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 accidental overdosage of insulin or following the normal administration of insulin or glucose-lowering agents accompanied by extraordinary exercise or insufficient 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 typically measure their glucose levels only 2 to 4 times a day. Unfortunately, such time intervals are so far apart that people with diabetes are likely to miss the detection of hyperglycemia or hypoglycemia, sometimes suffering dangerous side effects. Not only are people with diabetes less likely to notice and address dangerous conditions promptly, but they are also less likely to understand whether their blood glucose levels are rising (high) or falling (low) based on conventional methods. Thus, diabetic patients may be prevented from making informed insulin treatment decisions.

[0005] Another device used by some diabetic patients to monitor their blood glucose is a continuous analyte sensor, such as a continuous glucose monitor (CGM). A CGM typically includes a sensor that is placed invasively, minimally invasively, or non-invasively. The sensor measures a given analyte in the body, such as glucose, and generates a raw signal produced by the electronic device associated with the sensor. This raw signal is converted into an output value displayed on a display device. The resulting output value is generally presented in a form that provides meaningful information to the user, and in a form that the user can easily understand, such as blood glucose expressed in mg / dL. [Overview of the Initiative]

[0006] This embodiment has several features, none of which alone cause these desirable attributes. These further superior features are discussed more concisely hereby without limiting the scope of this embodiment as expressed by the subsequent claims. After considering this discussion, and especially after reading the section titled "Detailed Description," the reader will understand how the features of this embodiment provide the advantages described herein.

[0007] A system and method are disclosed that uses a number of variables or parameters in determining and / or calculating a glucose urgency index (GUI), which may be based in part on measured glucose levels, and which generally includes consideration of other factors. Other factors may include the first and / or second derivatives of glucose levels with respect to time, and / or other factors described later, such as user-entered data, data measured by other sensors or received from network sources, or historical data. The GUI is then presented to the user in an engaging manner, for example, on a mobile device such as a smartphone, via a background color or a notification means that is not easily seen by others. Thus, the GUI may be presented to the user continuously (whenever the display screen is on or otherwise activated). The GUI may also be used to activate actionable warnings and alarms (or other outputs) on an electronic device for the user. The GUI, or another index calculated from combinations of the variables and parameters described, may also be used to drive drug delivery devices such as pumps. Generally, a given GUI will generally provide the same notification (or actionable warning) to a given user, but depending on current sensitivity, how the user configures their electronic device, the modes the user allows the device to operate, etc., the user will see variations in the notification or warning.

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

[0009] A third type of data may also be received, which corresponds to other factors in addition to the analyte concentrations and parameters obtained from it. For example, data entered by the user may be a third type of data, and the data may correspond to health, exercise, dietary data, drug infusion data, or a number of other inputs. In some cases, a third type of data may be received from another device, such as an exercise application that can show exercise performed by the user running on a GPS or mobile device. Other applications may be used to monitor dietary intake, etc. An automated drug delivery device may also be linked to the system, for example, to show insulin pump operation for consideration in GUI decisions. Similarly, the GUI can influence pump operation. Like the first and second types of data, the third type of data has a functional relationship with the GUI. Specifically, the third type of data is generally a dependent variable, i.e., an independent variable that influences GUI decisions (it should be noted that it may feature parameters and variables that themselves may have some interrelationships).

[0010] The GUI display may be presented to the user on a user interface, for example, on a mobile device such as a smartphone. The GUI may be presented by means of a naturally occurring function, such as a background color or design that does not need to be overtly displayed as an indicator of the user's health. If the user is satisfied with the display, the interaction may end there. If the user desires additional data, the user may perform actions such as unlocking, swiping, or other application operations to retrieve additional details, such as how urgent the situation is, relevant measurements and parameters indicating the situation, and possible steps to take to improve the situation. If the GUI is presented by design, the function of the design may be to display current values, such as glucose concentration, the direction in which the value is changing, whether the value is improving or not, and recent historical values, as graphics (but often not numerically). The user interface may also allow the user to input parameters and variables, which may then influence the decisions of the GUI.

[0011] Monitoring devices, such as CGMs, can be embodied as applications running on mobile devices, such as smartphones, and as downloadable applications for mobile devices. Specifically, the application may run an emergency assessment module, performing a detailed assessment of the urgency of the user's blood glucose status, with a "higher" rating generally corresponding to a "higher" emergency or "higher" risk state. The mobile device may present continuous notifications or presentations via GUI displays and, if given a valid reason, may also provide warnings or alerts.

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

[0013] The first type of data may be analytes from a continuous analyte sensor implanted in the body, such as glucose data. The second type of data may be the first and / or second time derivatives of the first type of data. The third type of data may be data outside of the analyte data from the sensor, which represents factors influencing the health risks of the physiological state reflected by the analytes in the body, such as factors influencing the risk of extreme hyperglycemia or hypoglycemia, as reflected by glucose data sensed by the continuous analyte data. Specifically, the third type of data may represent factors influencing the analyte levels reflecting the physiological state, and thereby influencing the health risks.

[0014] The mobile device can be a smartphone.

[0015] This method may include outputting an audible and / or tactile warning on the mobile device, and / or ignoring other applications or processes running on the mobile device so that when the urgency index reaches or exceeds a threshold indicating a physiological state that has reached a health hazard state, such as the risk of extreme hypoglycemia or hyperglycemia, the urgency index display is shown on the mobile device regardless of other running applications or processes, unless adjustments are made by the user.

[0016] This method may include providing a display on a mobile device such that the display is visible to the user even before the mobile device's lock screen is accessed, at least when the urgency index indicates a high level of urgency with respect to the physiological state.

[0017] The determination of the urgency index can be carried out by the urgency assessment module.

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

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

[0021] The urgency assessment module may acquire duration data as a second data source, which represents the duration during which analyte data is outside the defined normal range with respect to the physiological state, for example, the duration during which analyte data continuously represents a hyperglycemic or hypoglycemic state, and the duration data tends to adjust the urgency index so 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 terms for analyte data, the first time derivative of the analyte data, the second time derivative of the analyte data, and / or terms for the duration of time in which the analyte data is outside the normal range with respect to the physiological state, wherein the data forming the terms constitute a first type of data and a second type of data.

[0023] An example of implementation of the first embodiment 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 glucose concentration. The glucose concentration may be a currently measured glucose concentration, a previously measured glucose concentration, or a predicted future glucose concentration.

[0024] Second types of data, such as a first or second derivative with respect to time, may be derived from first types of data. These second types of data may further include deviations from a normal glucose pattern, pattern data of glucose values ​​over time, predicted glucose values, durations during which glucose values ​​remain within a specified range, weightings of parameters or variables considered in determining the urgency index, or local maxima or minima of the first types of data.

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

[0026] If the physiological condition is diabetes, the urgency index may be a blood glucose urgency index, the first type of data may be glucose concentration, and the received data entered 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, anthropometric data, data on insulin previously provided to the user, stress data, health data, data on the placement of sensors measuring the first type of data, age, or sex. The received data entered by the user may include user indication of food or beverage consumed or to be consumed, or data on insulin provided to or to be provided to the user, and may further include modifying the blood glucose urgency index determined based on the received data to indicate a lower urgency.

[0027] Receiving the third type of data may include receiving data from a sensor. If 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, the user's indication of activity level, the indication of food or beverage consumed or to be consumed, body measurement data, data regarding previous insulin provided to the user, physiological data, stress data, or health data. Receiving the third type of data may also include receiving data from a query processing engine, an electronic device configured for machine-to-machine 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 state or a 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 an indication 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 indication of the urgency index is displayed regardless of other running applications or processes.

[0032] If the steps to be displayed are brought about by user action, the user action 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 urgency index may be displayed as a drawn element, such as a color, which is drawn as at least part of the home screen or background that is built into the mobile device's operating system. If the drawn element is colored, the color will vary depending on the urgency index. The drawn element may also be an icon, in which case the icon's position, size, or color will be based on the urgency index.

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

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

[0036] The step of providing a display may further include drawing functionality, for example, a set of elements may be drawn on the user interface of a mobile device, and the set of elements may indicate past or predicted future values ​​of glucose concentration. The display of the urgency index may be drawn on the mobile device, or it may be an audible or visual warning that emits sound. The method may further include displaying an input request to the user to enter data so that the user data may be relevant to the urgency index. The input request to the user to enter data may indicate the type of data, which may be selected from a group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or emotional data, which may be used to form a third type of data. The method may further include displaying at least one possible action that the user may take in response to the displayed urgency index. The display may be an actionable warning. The display of the display may include displaying bandwidth occupancy, where the bandwidth corresponds to a specified range of urgency index values.

[0037] The method may further include storing the determined urgency index in the storage device of a mobile device. The method may also 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] This method may also include displaying current analyte data values ​​indicating the physiological state, and / or displaying whether the trend of the analyte over time is increasing or decreasing, and optionally displaying an index of the rate of increase or decrease in the trend. In one implementation example, 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 angle indicating a larger amount of change.

[0039] The urgency index can be displayed by changing the color according to the level of urgency. Red may be selected to indicate the highest level of urgency.

[0040] In a second embodiment, the present invention relates to a system for carrying out any of the methods of the first embodiment.

[0041] In a third embodiment, the present invention relates to a method for determining an emergency index related to a physiological state, comprising determining an emergency index based on an analyte concentration and at least two variables selected from the group consisting of a first or second time derivative of the analyte concentration, the duration for which the analyte concentration occupied a specified range, the duration for which the first or second time derivative of the analyte concentration occupied a specified range, the second time derivative of the analyte concentration, the duration for which the second time derivative of the analyte concentration occupied a specified range, past or future dietary intake parameters entered by the user, past or future drug parameters entered by the user or received from an integrated pump, or body temperature.

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

[0043] The urgency index may represent the urgency of the need for intervention to bring the analyte concentration down from a higher health hazard level to a lower health hazard level in relation to the physiological state.

[0044] An example implementation of the second embodiment may include one or more of the following: The method may include displaying an urgency index on the user interface of a mobile device. The display step may further include ignoring other applications or processes running on the mobile device so that the urgency index is displayed regardless of other running applications or processes.

[0045] If the steps to be displayed are brought about by user action, the user action 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.

[0046] The urgency index may be displayed as a drawn element, such as a color, which is drawn as at least part of the home screen or background that is native to the mobile device's operating system. The drawn element may also be an icon, in which case the icon's position, size, or color is based on the urgency index.

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

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

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

[0050] An urgency index may be provided, which may be a graphic display on the mobile device, or an audible or visual warning.

[0051] The method may further include displaying an input request to the user so that the user data may be relevant to the urgency index. The input request to the user to enter data may indicate the type of data, which may be selected from a group consisting of exercise or activity level, dietary data, insulin data, stress or health data, or emotional data. The method may further include displaying at least one possible action that the user may take in response to a displayed indication of the urgency index. The indication may be a doable warning. The action may be to adjust the health hazard so that, when the risk of urgency is high, the analyte concentration is brought toward an acceptable level above normal with respect to the health hazard presented by the physiological condition. The indication may include displaying a bandwidth occupancy, where the bandwidth corresponds to a specified range of urgency index values.

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

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

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

[0055] The mobile device can be a smartphone.

[0056] This method may include outputting an audible and / or tactile warning on the mobile device, and / or ignoring other applications or processes running on the mobile device so that when the determined urgency index reaches or exceeds a threshold indicating a physiological state that has reached a health hazard state, such as the risk of extreme hypoglycemia or hyperglycemia, the urgency index display is shown on the mobile device regardless of other running applications or processes, unless adjustments are taken by the user.

[0057] This method may include providing an emergency risk indicator on a mobile device such that the indicator is visible to the user even before the mobile device's lock screen is accessed, at least when the urgency index indicates a high level of urgency with respect to the physiological state.

[0058] The determination of the urgency index can be carried out by the urgency assessment module.

[0059] The urgency assessment module can obtain analyte concentration as input, and as the data approaches the health hazard of a physiological state, such as the 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 the first time derivative and / or second time derivative as input in a manner that tends to adjust the urgency index to a value representing lower urgency when the first time derivative and / or second time derivative indicates that the health risk, e.g., the risk of extreme hyperglycemia or hypoglycemia in a physiological state, has decreased, or to a value representing higher urgency when the first derivative and / or second derivative indicates that the health risk, e.g., the risk of hyperglycemia or hypoglycemia in a physiological state, has worsened.

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

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

[0063] The urgency assessment module may additionally or alternatively obtain as input an index of the duration over which the analyte concentration occupies a specified range representing a defined normal range with respect to the physiological state, for example, the duration over which the analyte data continuously represents a normal blood glucose state, and the duration index tends to adjust the urgency index so that a higher urgency is determined as the duration increases.

[0064] The step of determining the urgency index may include using a mathematical danger function having terms representing the analyte concentration, the first time derivative of the analyte concentration, the second time derivative of the analyte concentration, and / or the duration during which the analyte concentration occupied a specified range.

[0065] Examples of the implementation of the third embodiment may further include one or more of the following: the physiological state may be diabetes mellitus; 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] This method may include receiving dietary intake parameters and / or drug parameters based on corresponding data entered by the user on a mobile device user interface or the like.

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

[0068] This method may include displaying a numerical value representing the analyte concentration in mg / ml, etc., and / or displaying whether the trend of the analyte concentration is increasing or decreasing, and optionally displaying an index of the rate of increase or decrease of the trend. In one implementation example, 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 angle indicating a larger amount of change. The display of an urgency index may be provided by changing the display color according to the urgency. Red may be selected to indicate the highest level of urgency. The display may be on a mobile device such as a smartphone.

[0069] In a fourth embodiment, the present invention relates to a system for carrying out any of the methods of the third embodiment.

[0070] In a fifth embodiment, the present invention relates to a device, system, or method substantially shown herein and / or in the drawings.

[0071] In a sixth aspect, the present invention relates 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 to provide continuous sensor data relating to the analyte concentration in the host, and a processor module configured to perform any one of the methods described above.

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

[0073] To facilitate understanding of 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 applicable to other continuous monitoring systems. For example, the functions discussed may be used for continuous monitoring of lactate, free fatty acids, heart rate during exercise, IgG-antigliadin, insulin, glucagon, exercise tracking, fertility, calorie intake, hydration, salt concentration, sweat / sweating (stress), ketones, adipanectin, troponin, sweating, and / or body temperature. When glucose monitoring is used as an example, one or more of these alternative examples of state monitoring may be substituted. Thus, while a GUI is described above, in similar systems, lactose urgency index, ketone urgency index, etc., may be defined.

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

[0075] The advantages of systems and methods based on this principle may include one or more of the following: The user can receive a display of their urgency assessment at any time they glance at their phone. Similarly, by using an intelligent algorithm that considers multiple inputs in determining a blood glucose emergency, the user can receive more actionable warnings, reduce the occurrence of intrusive warnings, and increase the use of CGM. Because the urgency assessment is based on inputs not previously considered by the warning algorithm, the blood glucose emergency index may correlate better with the patient's clinical diabetes management than it would be necessary to correlate it with glucose concentration (or derivative) information alone. The user can be safely and discreetly warned of a blood glucose emergency by engaging and personalized means, as well as by means of utilizing a device that the user may already carry, such as a user interface built into a mobile device. Other advantages will become apparent from the following description, including the figures and claims. [Brief explanation of the drawing]

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

[0077] [Figure 1] This is a graph of output records illustrating the effect of setting the low threshold to a lower or higher value. [Figure 2] This is a graph of output records illustrating that even relatively stable glucose levels can trigger a warning. [Figure 3] This is a block diagram of a preferred embodiment of an integrated system including a continuous glucose sensor and a drug delivery device. [Figure 4] This is an elevation view of an electronic device configured for use with this system and method. [Figure 5] Figure 4 is a functional block diagram of the electronic device. [Figure 6] Figure 3 depicts a logical diagram of a specific component of the system. [Figure 7] This describes the range of parameters or variables that may be used in GUI calculations. [Figure 8] This flowchart illustrates a method that follows this principle. [Figure 9] This graph shows how various combinations of parameters and variables can be used in determining the GUI. [Figure 10] This is another graph showing how various combinations of parameters and variables can be used, particularly in determining GUIs that use patterns. [Figure 11] This is another graph showing how various combinations of parameters and variables can be used in GUI decisions, especially when using data related to critical events. [Figure 12A] This provides examples of glucose concentration as a function of time, static hazards, and dynamic hazards. [Figure 12B] This provides examples of glucose concentration as a function of time, static hazards, and dynamic hazards. [Figure 13] This illustrates how the urgency of blood glucose levels increases with duration in cases of hypoglycemia. [Figure 14] This example illustrates how using acceleration as a parameter or variable in GUI decisions can help avoid false alarms regarding hazardous conditions. [Figure 15A] Various probability distributions corresponding to example parameters and variables are illustrated. [Figure 15B] Various probability distributions corresponding to example parameters and variables are illustrated. [Figure 15C] Various probability distributions corresponding to example parameters and variables are illustrated. [Figure 15D] Various probability distributions corresponding to example parameters and variables are illustrated. [Figure 15E] Various probability distributions corresponding to example parameters and variables are illustrated. [Figure 15F] Various probability distributions corresponding to example parameters and variables are illustrated. [Figure 16A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 16B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 17A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 17B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 18A]This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 18B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 19A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 19B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 20A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 20B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 21A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 21B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 22A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 22B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 23] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 24]This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 25A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 25B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 26] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 27A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 27B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 28A] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 28B] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 29] This document illustrates various user interfaces that can be used to display GUI notifications and / or actionable warnings based on a calculated GUI. [Figure 30] This is a flowchart illustrating an example method for providing GUI notifications and / or actionable warnings. [Figure 31A] This is an example of a user interface that prompts the user for input. [Figure 31B] This is an example of a user interface that prompts the user for input. [Figure 32A]This is a flowchart of another example method for implementing a retrospective algorithm. [Figure 32B] This graph illustrates the use of the method shown in Figure 32A. [Figure 32C] This graph illustrates the use of the method shown in Figure 32A. [Modes for carrying out the invention]

[0078] Consider specific examples of continuous glucose monitoring. For diabetic patients, glucose monitoring can literally be a matter of life and death. However, blood glucose levels presented on a CGM can be ambiguous. For example, three users may all have the same blood glucose level measured by a CGM, but each may require different treatment depending on whether their blood glucose level is decreasing, remaining the same, or rising. This is especially true because current CGMs activate alerts based on low and / or high thresholds, for example, predicted or actual glucose concentration thresholds, sometimes including consideration of the rate of change. Predicted values ​​are generally highly susceptible to noise, and the use of alerts based on such thresholds does not give users enough time to react before encountering a dangerous or hazardous situation.

[0079] For example, and referring to Figure 1, the standard hypoglycemia threshold warning may be set to 70 mg / dL. If the user's glucose level is dropping rapidly, such a low threshold warning may not give the user enough time to prevent very low glucose levels, for example, below 55 mg / dL. Even if the low threshold warning was set to 80 mg / dL, the user would only hear the warning 10 minutes before dropping below 55 mg / dL. In the 30 minutes before dropping below 55 mg / dL, the user was dropping at an average rate of 2.5 mg / dL / min, and it is clear from the CGM output record in Figure 1 that the user was in a very dangerous situation well before reaching the 70 mg / dL threshold.

[0080] While it is always possible to increase sensor sensitivity, such increases often lead to false alarms and user "warning fatigue." This is especially true when monitoring is done via a smartphone, which typically already alerts the user through multiple means, such as application notifications, text messages, and emails. For example, if a low threshold is set higher, e.g., 80 or 90 mg / dL, in an effort to ensure there is sufficient time to prevent very low glucose levels, such a setting will likely lead to many false alarms. As another example, and referring to Figure 2, there is no need to warn about stable glucose levels hovering around 80 mg / dL, but if the threshold is set to 80 mg / dL, many warnings will be triggered.

[0081] Furthermore, while current systems can provide users with warnings based on blood glucose levels and thresholds, the user interfaces associated with such systems fail to meet user expectations. Both the lack of reliable warnings and the lack of a safe and discreet user interface hinder the use and adoption of such monitoring.

[0082] Similarly, current systems that integrate insulin pump operation with CGM use a simple glucose threshold to make decisions such as withholding basal insulin. However, a simple glucose threshold does not provide sufficient information about the user's emergency condition. For example, using a threshold of 70 mg / dL to withhold insulin delivery may be appropriate when glucose is gradually decreasing, but if 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 numerous false-positive disadvantages.

[0083] Other aspects relating to the measurement of blood glucose and the provision of related warnings are described in concurrently pending U.S. Patent Nonprovisional Application No. 13 / 742,694, filed January 16, 2013, owned by the applicant of this application, which is incorporated herein by reference in its entirety.

[0084] One non-limiting benefit of the features described herein is that, considering warnings or alarms, they provide warnings and alarms that are more useful to the user, i.e., more "actionable," in the sense that they indicate appropriate actions to be taken that the user can notice or easily infer. Such warnings and alarms are also more accurate in the sense that they more accurately reflect the user's current assessment of the urgency of their blood glucose levels. In addition to providing actionable warnings and / or alarms, they can provide the user with continuous notifications of their assessment of urgency, and can be presented to the user in a highly engaging manner using a user interface that is already built into a device that the device user commonly carries, such as a mobile device like a smartphone, thus eliminating the need for the user to carry an additional device.

[0085] Various terms are listed below.

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

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

[0088] The term “substantially” as used herein is a broad term that provides its ordinary and customary meaning to those skilled in the art (and is not limited to any special or individualized meaning), and means, but not limited to, the majority of a given, but not necessarily all of it, which may include more than 50 percent, more than 60 percent, more than 70 percent, more than 80 percent, or 90 percent or more.

[0089] The terms “processor” and “processor module,” as used herein, are broad terms, providing to those skilled in the art their ordinary and customary meanings (and not limited to any special or individualized meanings), and refer to, but not limited to, computer systems, state machines, processors, etc., designed to perform arithmetic or logical operations using logic circuits that correspond to or process basic instructions that operate a computer. In some embodiments, the terms may include ROM and / or associated RAM.

[0090] Examples of embodiments disclosed herein relate to the use of glucose sensors for measuring the concentration of glucose or another analyte or the concentration of a substance indicating its presence. In some embodiments, the glucose sensor is a continuous device, e.g., 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., absorption spectroscopy, Raman spectroscopy, etc.), optical rotatory, calorimetry, ionophoresis, radiometric methods, etc.

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

[0092] While many of the descriptions and examples focus on glucose sensors capable of measuring glucose concentration in a host, the systems and methods of the embodiments can be applied to any measurable analyte. Several exemplary embodiments described below utilize implantable glucose sensors. However, it should be understood that the devices and methods described herein can be provided to any device capable of detecting the concentration of an analyte and providing an output signal representing the concentration of the analyte.

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

[0094] The following description and examples illustrate this embodiment in relation to the drawings. In the drawings, reference numbers indicate elements of this embodiment. These reference numbers are reproduced below in relation to the consideration of the corresponding drawing features.

[0095] Figure 3 is a block diagram of an integrated system of 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 several 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 electronic device 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 electronic device module 12 and may be integrated with the continuous analyte sensor 10 (e.g., may be non-removably mounted) or may be removablely mounted. Alternatively, the continuous analyte sensor 10 may be physically separated from the sensor electronic device module 12 but electrically coupled via inductive coupling or the like. Furthermore, the sensor electronic device 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 sufficient processors, memory, storage devices, and other components to run applications that include an emergency assessment module.

[0096] In some implementation examples, the system 100 in Figure 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 over the network 24 from one or more of the sensor system 8, drug delivery pump 2, reference analyte 4, and display devices 14, 16, 18, and 20. Based on the received data, the processor 22 can further process the data, generate reports providing statistics based on the processed data, trigger notifications on electronic devices associated with the host or the host's caregiver, or provide the processed information to any of the other devices in Figure 3. In some example implementation examples, 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 isolated from one another. 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 several example implementations, the sensor electronic device module 12 may include electronic circuits related to the measurement and processing of data generated by the continuous analyte sensor 10. The generated continuous analyte sensor data may also include algorithms, which may also be used to process and calibrate the continuous analyte sensor data, although these algorithms may also be provided by other means, for example, by devices 14, 16, 18, and / or 20. The sensor electronic device module 12 may include hardware, firmware, software, or a combination thereof, for providing measurement of analyte levels via a continuous analyte sensor such as a continuous glucose sensor.

[0098] The sensor electronic device module 12 may be coupled (for example, wirelessly) to one or more devices such as any or all of the display devices 14, 16, 18, and 20, as described above. 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 electronic device module 12 for display on the display devices. The display devices 14, 16, 18, and 20 may also activate alarms based on the analyte sensor data.

[0099] In Figure 3, display device 14 is a key fob-like display device, display device 16 is a handheld, purpose-specific computer device 16 (e.g., a DexCom G4® 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® OS, an Apple® iPhone®, iPad®, or iPod touch® commercially available from Apple Inc.), and display device 20 is a computer workstation 20. In some example implementations, the relatively small key fob-like display device 14 may be a computer device embodied in a wristwatch, belt, necklace, pendant, a piece of jewelry, an adhesive patch, a pager, a key fob, a plastic card (e.g., a credit card), and / or an identification card (ID). This small display device 14 may include a relatively small display device (for example, smaller than display device 18) and may be configured to display a limited set of displayable sensor information, such as numerical values ​​26 and arrows 28. Some systems may 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 November 14, 2013, the entire disclosure of which is expressly incorporated herein by reference. The wearable device 21 may include any device(s) attached to or integrated with the user's vision, clothing, and / or body.Examples of devices include wearable devices, anklets, eyeglasses, rings, necklaces, armbands, pendants, belt clips, hair clips / ties, pins, cufflinks, tattoos, stickers, socks, sleeves, gloves, clothing (e.g., shirts, trousers, underwear, bras, etc.), “clothing accessories” (e.g., zipper pulls, buttons, watches, shoes, contact lenses, subcutaneous implants, eyeglasses, cochlear implants, shoe insoles, orthopedics (oral), orthopedics (torso), medical bandages, sports bands (wristbands, headbands), hats, adhesive bandages, hair extensions, manicures, artificial joints / body parts, orthopedic pins / devices, implantable cardiac or neural devices, etc. The small display device 14 and / or wearable device 21 may include relatively small display devices (e.g., smaller than the display device 18) and may be configured to display a graphical and / or numerical representation of sensor information such as numerical values ​​26 and / or arrows 28. Conversely, display devices 16, 18, and 20 may be larger display devices capable of displaying a larger set of displayable information, such as a trend graph 30 projected on the handheld receiver 16, in addition to numerical data and other information such as arrows.

[0100] It is understood that any other user device (e.g., a computer device) configured to present information (e.g., drug delivery information, separate self-monitoring analyte measurements, heart rate monitoring, calorie intake monitoring, etc.) may be used in addition to or instead of those discussed with respect to Figure 3.

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

[0102] In some example implementations shown in Figure 3, the continuous analyte sensor 10 may include a glucose sensor configured to measure glucose in the blood using one or more measurement techniques, such as enzymatic, chemical, physical, electrochemical, fluorescent, spectrophotometric, optical rotatory, calorimetry, ionophoretic, radiometric, or immunochemical techniques. In embodiments in which the continuous analyte sensor 10 includes a glucose sensor, the glucose sensor may include any device capable of measuring glucose concentration and may provide data such as a data stream indicating glucose concentration in the host using a variety of 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 the host, such as a user, patient, or caregiver (e.g., parent, relative, guardian, teacher, doctor, nurse, or any other individual interested in the host's health). Furthermore, 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 intravascular sensor.

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

[0104] Figure 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 the illustrated embodiment, which also functions as an I / O device, the electronic device 200 is a smartphone, and the display device 202 includes a touchscreen that also functions as an I / O device. In other embodiments, the electronic device 200 may include a device or a device other than a smartphone, such as a receiver for a CGM system, a smartwatch, a tablet computer, a mini-tablet computer, a handheld personal digital assistant (PDA), a game console, a multimedia player, a wearable device, such as those described above, a screen in a car or other vehicle, etc. While the electronic device 200 is illustrated as a smartphone in the figure, the electronic device 200 may be any other electronic device that incorporates any or all of the functionality of any or all of the electronic devices referred to herein and / or other electronic devices, including those in which some or all of the functionality is embodied on a remote server.

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

[0106] The electronic device 200 further includes a processor 208 (also referred to as a central processing unit (CPU)), memory 210, storage device 212, and 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 local memory bus 216. The processor 208 may be one or more programmable general-purpose or specific-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), etc., or a combination of such hardware-based devices.

[0107] Memory 210 provides a processor 208 that accesses data and program information stored in memory 210 during runtime. Generally, memory 210 includes random access memory (RAM) circuitry, read-only memory (ROM), flash memory, or a combination of such devices.

[0108] The storage device 212 may comprise one or more internal and / or external mass storage devices, which may be or include any conventional medium for storing large amounts of data in a non-volatile manner. For example, the storage device 212 may 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 may also comprise "cloud" storage using so-called cloud computing. Cloud computing enables convenient, on-demand network access to a shared pool of configurable computing resources that can be quickly set up and made publicly available with minimal administrative effort or interaction with service providers, relating to computing functions that provide an extract between computing resources and their underlying technological structures (e.g., servers, storage devices, networks).

[0109] The electronic device 200 can perform various processes, such as relating data to each other, pattern analysis, and other processes. In some embodiments, the electronic device 200 may perform such processes independently. Alternatively, such processes may be performed by one or more other devices, such as one or more cloud-based processors 22 described above. In further embodiments, these processes may be performed in part by the electronic device 200 and in part 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. Furthermore, as used herein, the term “electronic device” should be interpreted to include one or more other devices with which the electronic device 200 interacts, such as 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 devices, and other devices via a network. While the illustrated embodiment includes the transceiver 214, in alternative embodiments, a separate transmitter and a separate receiver may replace the transceiver 214.

[0112] In some embodiments, the processor 208 may run a CGM application that can be downloaded to the electronic device 200 over various applications, such as the Internet and / or a cellular network. Data for 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 emergency assessment module and / or may include processing sufficient to activate the emergency assessment functions and methods described below.

[0113] In a particular embodiment, the sensor 10 of the continuous analyte sensor system 8 shown in Figure 3 is inserted into the host's skin. A new sensor session is then started with the sensor 10, the sensor electronic device 12, and the electronic device 200. Numerous methods can be used to initialize the sensor 10. For example, initialization may be triggered when the sensor electronic device 12 engages with the sensor 10. In another embodiment, initialization may be triggered by a mechanical switch, such as a switch (not shown) on a snap-fastening base that receives the sensor electronic device 12. The switch is activated automatically when the sensor electronic device 12 is snapped into the base. In another embodiment, initialization may be menu-driven, and the user may be prompted by a user interface on the display device 202 of the electronic device 200 to initiate initialization by making a selection on the user interface, for example, by pressing a button on the display device 202 (which may have a touchscreen) or by touching a designated area. In another embodiment relating to a non-invasive sensor applied to the wearer's skin, the sensor 10 may be automatically activated upon sensing contact with the skin. Furthermore, the analyte sensor system 8 can also detect the use of a new sensor 10 using any of the methods described above, and automatically prompt the user to confirm the new sensor session via an input request means on the system 8's user interface, and start initialization in response to the user's confirmation in response to the input request. An additional example of the initialization of sensor 10 can be found in U.S. Patent Application No. 13 / 796,185, filed March 12, 2013, the entire disclosure of which is incorporated herein by reference.

[0114] Figure 6 illustrates a logical diagram of an example of a continuous analyte monitoring system 100, specifically illustrating the components involved in the description of determining and calculating sensor results, and determining urgency based on those results and other factors. Specifically, measurements from sensor 10 are processed by sensor electronic device 12 and transmitted to a mobile device 18, which is generally a smartphone. While a smartphone is described herein, 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 alarms based thereon. Furthermore, a smartphone (or a device with similar smartphone capabilities) may transmit displayed notifications, results, warnings, and alarms to various devices coupled to it, for example, via Bluetooth®. Such devices include head-mounted display devices such as Google Glass®, watches, and the like.

[0115] The mobile device 18 runs a CGM application 209, which provides various monitoring and display functions based on signals received from the sensor electronic device 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 herein, it is understood that such an evaluation module may be replaced by a functionality appropriate for performing the method described herein.

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

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

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

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

[0120] Figure 7 illustrates how measured blood glucose levels may be combined with other parameters or variables to produce a calculated or otherwise determined GUI value 252, which is then presented on the mobile device's display screen and may 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 may be determined entirely or partially by the server 222, or even, in some cases, by the sensor electronic device 12. It should be understood that not all parameters and variables are involved in all implementation examples of determining the GUI value 252.

[0121] Various parameters and variables are described, followed by examples of how they may be combined to produce GUI values ​​on which presented notifications and / or warnings or alarms may be based, in order to achieve the aforementioned benefits and advantages. Without any intention of limiting the scope of arrangements, particularly useful combinations are thought to include combinations of the current glucose value or the glucose value and the first derivative of the glucose value with respect to time. However, as will be understood by those skilled in the art who are receiving this teaching, numerous combinations are useful, and therefore the scope of the invention is not limited by specific embodiments. Furthermore, while a single calculated or determined value of GUI252 may be used in various implementation examples, it will also be understood that multiple values ​​related to the risk or urgency of blood glucose may be calculated or determined, which may be combined to activate warnings or alarms, for example, GUI1=GUI1(parameter, variable), GUI2=GUI2(parameter, variable), etc., or actually used for general presentation of results to the user. Where the combined GUI can be said to define a blood glucose emergency, this is the basis for the warning and / or alarm.

[0122] In Figure 7, GUI252 is illustrated based at least on data254 corresponding to the currently measured glucose value, and / or data256 corresponding to previously measured glucose values, and / or data258 that is not directly related to the measured glucose value and is therefore called “external data”. Data254 is generally, for example, the currently measured glucose value measured in mg / dL. Data256 corresponds to previously measured glucose values, which can be divided into data262 called “recent” measured glucose data and data264 called “more recent” measured glucose data. Recent data262 may have been measured over several minutes or hours prior to the current measured glucose data254 and may therefore be particularly useful for analyzing the current trend. More recent data264 may have been measured over several days, weeks, months, or even years prior to the current measurement and may therefore be particularly useful in calculating or determining the overall pattern or trend (data262 may also be used in 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, these can be used to calculate data 268 corresponding to the rate of change of glucose data over time, such as the first derivative with respect to time, the second derivative with respect to time, and so on.

[0124] Data 258 may correspond to past or present user indications, such as how the user felt or what the user ate. Therefore, Data 258 may have an indirect correlation with glucose levels, but this is not directly based on measured glucose values ​​in a functional sense. Data 258 may also comprise numerous other variables, as described below.

[0125] Various parameters and variables based on the above types of data are described below. Again, it should be noted that the determination of the GUI in a particular implementation example does not need to include all the various types of data described, and in many cases will include only two or three types of data. Furthermore, other types of data not described below may also be used, as the following explanation is merely illustrative. 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 many variables in its determination of the GUI. While these variables are evaluated algorithmically simultaneously or nearly simultaneously, the following explanation partially considers 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 notifications presented on the user interface of the mobile device, which may further result in “actionable warnings” (or alerts) that suggest one or more actions to be displayed to and performed by the user. In some implementation examples, the notification seen by the user may simply be an indication of the user's status, for example, that the user has a normal GUI. In other cases, the presentation may be, for example, the display of a warning or alert state, which may appear in red on the screen, thus implying that some action must be taken. By unlocking the mobile device, performing a "swipe" operation, or otherwise "digging down" to the data in which the presence of the warning or alert state is inherent, the user can see the clear operation to be performed. Further details of such user interfaces are described below in relation to Figures 16-29.

[0126] The first type of data that may be used, and which is relevant to most implementations, is the measured glucose value. This first type of data may be in numerical form with units in mg / dL or other formats, or it may 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 may be used in its raw form as received from the sensor electronics without significant processing, and / or may also be processed by the sensor electronics. Processing may then be performed, if desired, on a mobile device (or other device) running an urgency assessment module or related application for determining the GUI. The first type of data may be further received from an intermediate module or transformation (e.g., from another application running on a smartphone). Generally, this first type of data may be processed, for example, to calibrate, smooth, filter, or otherwise "clean up" the signal representing the data.

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

[0128] In determining the GUI, all other factors are equal; high glucose levels tend to shift the GUI value towards a higher value indicating a hyperglycemic state. Conversely, low glucose levels tend to shift the GUI value towards a higher value indicating a hypoglycemic state. Moderate glucose levels tend to shift the GUI value towards a value indicating a normal blood glucose state. In very limited examples, a normal blood glucose state may be associated with a GUI of 0, extreme hypoglycemia may be associated with a GUI of -5, and extreme hyperglycemia may be associated with a GUI of +5. Naturally, many other schemes can also be understood and used based on this teaching. While positive and negative values ​​from 0 to 5 are exemplified as representing the risk of hyperglycemia versus the risk of hypoglycemia, the risk index does not have to be limited to the risk of hyperglycemia versus the risk of hypoglycemia; for example, it could simply be 0 to 5, where 0 represents no risk and 5 represents the highest risk (or regardless of hypoglycemia or hyperglycemia). The indicators can be qualitatively classified into risk buckets, such as "no risk," "low risk," "moderate risk," and "high risk." Other quantitative or qualitative risk indices may be assumed, as understood by those skilled in the art, that risk indices do not necessarily correlate with blood glucose levels, but rather with the urgency of clinical intervention to avoid dangerous blood glucose levels. Time information, such as the time to the next urgency index or the time to a specific blood glucose level, may also be provided.

[0129] Other types of data can be obtained 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 "rate" of the glucose value, i.e., whether the glucose value is increasing or decreasing, and how quickly such a change is occurring. Thus, the data value representing the first derivative can be used in the initial estimation of future glucose value predictions and in the determination of the GUI. For example, a user with a high glucose value might start with a GUI value of 5, but a negative first derivative could reduce the GUI to 3. Furthermore, the direction and amplitude of the first derivative can be used to determine the weighting of the same information in the determination of the GUI.

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

[0131] Another type of data that can be obtained based on glucose values ​​and their first derivative is the second derivative of the glucose value with respect to time, i.e., acceleration. Such data provides information about the rate at which changes in glucose levels are occurring and can often be used to our advantage in determining how stable or deviating from a desired value the changes in glucose levels will be.

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

[0133] In some implementations, the determination of a blood glucose emergency or index indicating such a state may be based, at least in part, on the measured glucose value and the first or second derivative of the measured glucose value with respect to time, or both. Such implementations allow for a considerable degree of confidence that an activated warning or alarm will actually lead to a situation requiring user (or other) intervention, using minimal warnings or alerts in situations that are likely to resolve without user intervention. In some implementations, the calculation of a blood glucose emergency or index may be based on the above factors in combination with other factors described below. For example, glucose values, e.g., the time derivative, combined with other types of data based on glucose values, may be used in combination with duration data (discussed below) to determine that the blood glucose emergency index has reached a point where user intervention is required. Similarly, glucose values ​​and / or time derivatives may be used in combination with food intake data to determine whether or not to activate an alert; for example, if the user has a low glucose level but has just eaten a snack bar, the alert may be suppressed (all other aspects are equal). Insulin data may be used similarly. Other example combinations are listed below.

[0134] It should be noted here that the concept of warning suppression is used to indicate that a warning condition has been reached, but this will not be shown to the user due to various other factors. However, it is clear that in other implementations, the concept of suppression can be replaced by simply recalculating the variables on which the warning or alarm is based, for example, by recalculating 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 data may further include higher-order derivatives with respect to time, a graph of glucose output records over a period of time, the level and duration of the last significant glucose value deviation, for example, the level of the last glucose peak. For example, if a user has GUI 3, but the last significant glucose value deviation was large and lasted for a long time, such a situation may tend to move the GUI upwards in the GUI decision (for example, to 4 or 5).

[0136] Another type of data related to sensors and electronic devices that measure glucose values, but not necessarily directly related to the glucose value itself, is information on the accuracy, confidence level, and / or noise in glucose measurement. Specifically, a blood glucose urgency index is only as accurate as the intrinsic data being processed. Therefore, GUIs, etc., can be made more reliable by including accuracy information for certain available inputs, and in some cases, an urgency assessment module can determine how much weight to give to a particular input based on the accuracy information. Alternatively, for various outputs, a range (instead of a single number) may be displayed to indicate that those outputs are subject to some degree of uncertainty. Accuracy information can take various forms, including, for example, the level of noise, the level of confidence, percentages, numbers, or categories. Particularly important quantities in this regard are the qualities of the sensor signal itself, including aspects of glucose data, signal quality, error, and confidence level.

[0137] For example, if the GUI value is only slightly high at 5, and the sensor data raises concerns about the accuracy and confidence of the sensor value, such a situation may tend to increase the GUI value to provide the most conservative and reliable measurement for the user. If the situation persists, appropriate warnings may be provided to reset the sensor or electronics.

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

[0139] In the relevant types of data, input to the urgency assessment module may be provided by sensor electronics or processing circuits or software on a mobile device (or server), indicating the amount of processing performed on the glucose value signal, and therefore the value of delay associated with the signal. Such processing may include amounts such as calibration, filtering, and smoothing. More signal processing results in the creation of more delay in the signal. Therefore, if a large amount of processing is performed, or if it is required on the signal, or if the processing is delayed for any reason, the signal will have more delay, and since a delayed signal can be significantly more difficult to resolve than a non-delayed signal, it can be assumed that this signal itself may be considered more important (or associated with a greater weight) in the urgency assessment module. Specifically, there is a higher probability of unconfirmed deviations from the last known value. Therefore, for example, if the GUI value is 3, but a significant delay is determined, the GUI may cause an upward trend in the determination of the GUI for similar reasons as in the case of a low-precision signal. Similarly, such data is generally available from sensors and associated sensor electronics. However, such data can also be determined from an analysis of the raw signal data itself, for example, from the most recent measured glucose concentration.

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

[0141] Systems and methods based on this principle enable a wider prediction range than previously possible. For example, while some levels of prediction allow for the detection of hypoglycemic events occurring within a certain period in the future, the prediction range can be significantly expanded by using several parameters and variables in the GUI decision-making. Example prediction ranges may include 10 minutes, 20 minutes, 30 minutes, 45 minutes, 1 hour, 90 minutes, or even longer.

[0142] For example, if the GUI value is 3, but the predicted GUI value indicates that the user is heading towards a higher blood glucose state, the GUI value may be raised, for example, to 4 or higher. Furthermore, while the GUI itself is not a glucose value, the glucose value can influence the GUI.

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

[0144] The duration for which the measured glucose level falls within a specified range is yet another type of data that can be used in the calculation, and this can be determined by an analysis of glucose values, specifically values ​​over time. The specified range can be defined arbitrarily, but generally may indicate a specific emergency state, such as high or low hyperglycemia, high or low hypoglycemia, or normal blood glucose.

[0145] More specifically, to address the prior lack of consideration of such duration, the time spent by the user within the range (or other range) of responding to an emergency can provide important input to the emergency assessment module, as this time may correlate with the risk faced by the user, especially if the emergency is hypoglycemic or hyperglycemic. For example, if a user has a GUI of -3 (based on other factors), but the duration of a relatively low hypoglycemic event is considerable, the GUI may be further reduced to -4 based on duration, as the likelihood of further downward deviation increases significantly, thus increasing the urgency. In using duration as a factor, the emergency assessment module may use duration itself, or the time a particular emergency exceeded a threshold duration, or other relevant parameters as input. Such data is generally available through the analysis of stored glucose values ​​over time. Additional details are discussed below in relation to Example 1.

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

[0147] Further types of data that can be used in GUI determination include more historically measured glucose values. In one instance, and as mentioned above, patterns in glucose values ​​can be determined and used to indicate a measured baseline value where deviations that constitute a significant deviation from the baseline value may be significant. Pattern data is partly, but not necessarily, based on time or time of day. Specifically, users often follow very regular patterns based on eating, exercise, or other activities that occur at specific times that may be related to glucose levels. These can be used to their advantage in determining whether deviations are expected to fall outside normal levels. When time solidifies a pattern, the determined GUI can become more predictive and confident, and can provide more useful feedback. The use of pattern data in GUI algorithms helps address the problem of normal GUI values ​​generating warnings or alarms, and thus avoid the problem of "warning fatigue." Naturally, such pattern data is generally available through the analysis of stored glucose values.

[0148] For example, a user may generally experience lower glucose levels in the morning than in the afternoon. The urgency assessment module may fit this pattern and predict lower readings in the morning and higher readings in the afternoon. Similarly, a user may typically consume an oatmeal meal in the morning, which may result in a spike in the user's glucose levels. Rather than necessarily triggering a warning or alarm, the urgency assessment module may determine that such meals at roughly the same time each morning constitute a pattern, which may suppress the activation of an alarm because it is simply considered "normal" based on the GUI assessment. As mentioned above, "suppression" can simply be a recalculation of the GUI that results in not activating an alarm. Therefore, taking into account patterned values ​​of the baseline results in the analysis of the spike not classifying it as a spike at all. Naturally, other factors will influence the GUI calculation, and in combination, these will determine the emergency GUI and trigger a warning or alarm.

[0149] In the above situation, a sharp rise in glucose levels due to oatmeal can lead to an elevated glucose tolerance (GUI) that deviates from normal blood glucose levels if pattern information is not available. However, recognizing patterns in GUI determination can lead to a more accurate maintenance of that value.

[0150] While eating and sleeping are disclosed elsewhere in this specification, it is understood that patterns may be recognized or generated in relation to other events such as meetings, work, and exercise, and used in GUI decisions. Time information may be acquired from a server or from any clock circuit or application, such as from a mobile device or sensor electronic device. Patterns may be based on detected events occurring in any kind of periodicity, such as a daily, weekly, or monthly cycle. Such data is generally available through the analysis of stored glucose values, and various pattern recognition software applications may be advantageously used. In some cases, a pattern may be detected, and the user may be prompted for input to determine if there is a specific cause of the pattern, such as a typical mealtime or a regular exercise class that occurs at a set time. Such input requests may be particularly used when an urgency assessment module uses machine learning to determine a given user's daily or other periodic patterns or behaviors.

[0151] By the same means, deviations outside the recognized pattern may result in similar user input requests. For example, a deviation may cause the urgency assessment module to ask the user, "Did you do something different?" Such a question may enable, for example, analysis and resolution of missed boluses versus insufficient boluses.

[0152] Such pattern data can even provide anticipated notifications or warnings. While details of the user interface for such notifications, warnings, and alerts are described in more detail below, it should be 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 might send a notice such as, "It's almost 2pm and we know you're often low at 2pm. You should review X and take possible action Y," where X is a user-recognizable variable such as glucose level, and Y is the appropriate action to take given the current determined GUI.

[0153] It will be understood that other types of data may be used in relation to deviations from a normal glucose pattern, but these are not necessarily time-based. Such situations may include cases where exercise (detected, for example, by movement or heart rate) is typically associated with a decrease in glucose levels. A “normal glucose pattern” can be learned for a specific user using a known pattern recognition algorithm. Deviations from such a normal pattern can then be defined and used as input to GUI decisions. Where this may be the case, an event of non-normal blood glucose may be a predictor of a higher-risk state, at least in part due to the unexpectedness of the event, which may determine different types of output to the user, i.e., different types of notifications, warnings, or alarms, i.e., displayed on the display of a mobile device or output to an insulin delivery device, i.e., a pump. In this way, 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, would also be relevant. For example, a recent glucose output record, such as over a 6-hour period, could be used to inform the current GUI calculation or decision.

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

[0156] For example, if all other factors are equal, a user may have a determined GUI of 6. If the user is obese, the GUI may rise to 7 because, based on this factor, the urgency or danger to such an individual is greater than that to a non-obese individual.

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

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

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

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

[0161] Further relevant types of data correspond to sleep information or state. Specifically, people with diabetes are known to be more likely to experience unnoticed hypoglycemic events during sleep. Exercise or lack thereof and other factors can be used to detect sleep and assess the risk accordingly. Other factors may include, for example, heart rate and user input. Monitoring devices, such as mobile devices running emergency assessment modules, may be equipped with a user-installable "night mode" function or module that can be used to assist in detecting sleep. Exercise detection for such purposes can be carried out, as mentioned above, by using, for example, an accelerometer worn on the body. For example, a CGM sensor or transmitter may incorporate such an accelerometer or other motion detection circuit. A telephone or other motion detector placed adjacent to the user can, in addition, detect how often the user moves, indicating sleep. In some cases, the motion detector of an alarm device may 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 sleep states. For example, if a user is not interacting with their mobile device at all, as determined by button presses, swipes, or other similar interactions, such a state may be associated with or consistent with a sleep state, or this may be learned by an urgency assessment module associated with such a state. Conversely, if a user is interacting with their mobile device, it may be assumed that the user is not asleep.

[0162] In an embodiment following this principle, if a user was not in a normal blood glucose state with a GUI of approximately 0, but is currently inactive and has a decreased heart rate, the user may be assumed to be asleep, and therefore the emergency assessment module may assess a higher risk that the user is experiencing a hypoglycemic event that they are unaware of. This risk may be included as a factor in determining the GUI, for example, resulting in a more prominent warning or alert, such as one corresponding to a GUI of (-)4 or (-)5. The mobile device running the emergency assessment module may be equipped with a "sleep mode" function, which the user can activate if no assumptions about sleep or sleep detection are required.

[0163] Such "sleep mode," "night mode," or sleep detection functionality can offer several advantages in certain implementations. Specifically, by assessing the higher risk status for blood glucose events during the day compared to the nighttime, the system understands that the user is less likely to be aware of their diabetes risk status, and therefore blood glucose events should be addressed differently. In this way, issues of user inattention during sleep, or skewed glucose levels encountered during sleep, can be effectively addressed.

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

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

[0166] Another type of physiological data is blood pressure information. Specifically, the effects of diabetes on blood vessels tend to increase the risk of hypertension. Therefore, monitoring blood pressure can be useful and may be included as a factor in GUI decisions. Various wearable blood pressure monitors are available that can transmit blood pressure data via wired or wireless means to a device running an emergency assessment module. Alternatively, the user can measure their own blood pressure and manually enter it into the device.

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

[0168] Body temperature data can be acquired by introducing a temperature sensor into a 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 / 747746, filed on January 23, 2013, owned by the applicant of this application, titled "DEVICES, SYSTEMS, AND METHODS TO COMPENSATE FOR EFFECTS OF TEMPERATURE ON IMPLANTABLE SENSOR," published as U.S. 2014 / 0005508A1, which is incorporated herein by reference in its entirety. Temperature information may also be entered manually, either qualitatively or quantitatively.

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

[0170] The level of interaction between the monitor and the user has been mentioned above in relation to determining or detecting sleep states. Such levels of interaction can generally be used to determine the level of user-desired level of management of or notification regarding the user's diabetes, at least with respect to the level of interaction between the user and the user's glucose monitor. Specifically, the level of interaction the user has with their CGM, for example, a mobile device running an application whose GUI is determined by an urgency assessment module, can be used as a factor in determining the GUI. For example, a high level of user interaction may indicate a strong awareness of the user's blood glucose status and, correspondingly, a lower risk. Conversely, a low level of user interaction may indicate a low or even no awareness of the blood glucose status, and, in particular, if glucose is on the "boundary" of normal blood glucose levels and this input (distance from the target range) can be included in the GUI determination, this can correspondingly result in a higher risk assessment, and therefore a higher GUI. Such levels of user interaction can be measured by the amount of time the screen is powered on, the number of buttons pressed or swiped, the orientation determined by an accelerometer, etc. However, it should be noted that such data can be modified or notified in various ways by user pattern data. For example, pattern data may indicate that a user does not use their mobile device after 8 p.m. In this case, the user cannot be considered a “low-aware” user based on the lack of interaction between the user and the device late at night, and is simply associated with the pattern for that reason. However, if the same user generally interacts with their device frequently during the day but suddenly stops interacting for extended periods in the afternoon, such a case may warrant an increased urgency assessment, as it could be assumed that the user is unaware of their current blood glucose risk status.

[0171] For example, a user at risk of hyperglycemia may be warned, and, for instance, an analysis of one or more temporal changes in glucose levels may determine that the condition should be treated appropriately. If the user interacts frequently with electronic devices, such as mobile devices, the GUI may maintain current values ​​with appropriate subsequent warnings (which may or may not be necessary). If the user interacts less with the monitoring device than usual, the GUI may show an upward trend to gain the user's attention, resulting in additional warnings (or an increased display frequency of the GUI on the user interface).

[0172] Using such monitoring device user interface data, the problem of treating patients with different usage habits of monitoring devices can be effectively addressed. Usage data is generally obtained using the operating system of the monitoring device, for example, a mobile device.

[0173] Similar types of data, including contextual and behavioral information, may be used in GUI determination. Specifically, such information may correspond to how the patient uses their mobile device and thus contextualize specific data determined by the device. Behavioral input information may be obtained through the system and may include the amount of interaction, glucose warning / alarm status, sensor data, number of screens tapped, alarm analysis, events (e.g., characteristics related to user response, time to response, blood glucose management related to response, user feedback related to alarm, failure to acknowledge warning / alarm within X minutes, time to acknowledge warning / alarm, duration of warning state, etc.), diabetes management data (e.g., CGM data, insulin pump data, insulin sensitivity, pattern, activity data, calorie data), fatty acids, heart rate during exercise, IgG-antigliadin, stress levels from skin patch sensors (sweating / perspiration), free amino acids, troponin, ketones, adipanectin, sweat, body temperature, etc. Input may be provided by sensors communicating data with the monitoring device. In some implementation examples, information may be obtained through intermediates such as remote data storage devices.

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

[0175] Photographs can provide contextual information. For example, one or more photographs of glucose meter readings, insulin pen or pump IOBs, locations (e.g., gym, park, home, Italian restaurant), or meals may be used to provide contextual information. Photographs may be processed, for example, to identify the calorie intake of the meal shown in the photograph. The type of insulin used may also be provided to the monitoring system as useful input for GUI decisions. Context may also be provided by the monitoring device, or by the basis or bolus settings determined by it.

[0176] Other inputs to the GUI determination that constitute contextual / behavioral data may include types of data mentioned elsewhere that are not contextual / behavioral inputs, such as exercise information from a fitness bike, glucose sensor information from a blood glucose (BG) meter or CGM, insulin delivery amount from an insulin delivery device, the result of the device's residual insulin calculation, and information provided or calculated by other devices. Other contextual / behavioral data inputs to the GUI determination may include hydration level, heart rate, target heart rate, internal temperature, external temperature, external humidity, internal analytes, hydration input, power output (cycling), sweat rate, gait, and adrenaline level, stress, pathological state / illness, metabolic rate / calorie burning rate, lipolysis rate, current weight, BMI, desired weight, daily (consumed) target calories, daily (expanded) target calories, location, favorite foods, and work level.

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

[0178] This information can be collected from various sensors inside or outside the device, such as accelerometers, GPS, camera data, etc., and from tracking applications, including third-party sleep cycle applications. For example, such tracking applications may use geolocation information to determine context and behavior. Furthermore, context and behavior may also be determined by using available social networking information about the user, and social networking feeds related to the user are prepared to provide data sources to the emergency assessment module and / or provide outputs to the emergency assessment module.

[0179] By using such systems and methods in accordance with this principle, the problem of the lack of consideration of such context / behavioral modes can be effectively addressed. Further details regarding context and behavioral information can be found specifically in Figure 4 and the accompanying text in U.S. Patent Application No. N61 / 898,300, filed October 31, 2013, owned by the applicant of this application, entitled “ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES,” which is incorporated herein by reference in its entirety.

[0180] Other types of data that may be used in determining the GUI include information on ingested foods and beverages, as well as insulin. Appropriate variables or parameters for these types of data may include information on their quantities, types, and the time and duration of their intake.

[0181] When food and beverages are consumed as part of a meal, such data can be captured by several means, for example, by the user manually entering food and beverage information into a device, for example, on a spreadsheet, using a camera on a mobile device to capture photos of the meal, or by data entry from a third-party food application that can enable users to "check" food items (which have data already entered into the application) at a given restaurant as they are consumed and enter them into a decision. In some cases, the user may be prompted to enter such information, for example, if the device detects a spike in glucose levels. Meal data may even be assumed (requiring user confirmation) 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 enter confirmation that they have ordered their "usual meal," which may then automatically add food data with meal parameters, or, if the user deviates from their usual choices, the input request may offer an opportunity to enter other food choices. Generally, dietary data may be provided along with details such as the amount consumed, the timing of intake, and other dietary data that enable the determination of clinically significant GUIs. Using such information, problems currently encountered in diabetes treatment based on the absence of such factors (and other factors) can be effectively addressed.

[0182] In one example of using meal data in GUI determination, a user in a mild hypoglycemic state may have a GUI of -2. If the user eats a meal with a significant intake of carbohydrates and / or sugars, the GUI may be modified to -1 to reflect the fact that the user's urgency assessment has been revised. It should be further noted that the modification may occur immediately after the user is notified that they are eating, well before any change in blood glucose levels is observed.

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

[0184] For example, a user with hyperglycemia may have a GUI of 3. If the user injects a bolus of insulin, the GUI may be modified to 1 to reflect the fact that the user's urgency assessment has been revised. In a system and method following this principle, the modification can occur immediately after notification that the user has injected a bolus, well before any change in blood glucose levels is detected. Using such insulin data, problems encountered before diabetes management, such as the lack of immediate updates to risk status based on user-entered data regarding dietary intake, can be effectively addressed.

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

[0186] Relevant types of data that may be used in GUI decisions include current health, which may overlap with current emotional state. Such measurements may be manually captured via the device or retrieved from cloud information, including by using the same types of emotional icons for stress as described above. Current health and emotions, as well as anthropometric data, are known to have a significant impact, particularly on type II glucose management and insulin resistance. Health data may include information about current illnesses, the severity of the illness, and how long the user has had the illness.

[0187] For example, a user with a GUI that is otherwise not dangerous may have an elevated GUI if they are currently experiencing a significant level of stress or poor health. Such an elevation reflects the fact that these factors are known to cause harmful increases or decreases in blood glucose levels. Using this type of data, past questions related to a user's current stress or lack of health considerations can be effectively addressed.

[0188] Demographic data such as age or sex may also be used. Specifically, demographic data may be collected from online stores, networks, or crowdsources, or manually entered into the device, and such data may provide useful information in GUI decisions. For example, pediatric users are known to have a tendency towards faster and higher blood glucose fluctuations. As another example, a user's risk status may be higher for certain blood glucose deviations compared to younger users with the same blood glucose deviation, particularly in older users and especially users with type II diabetes.

[0189] In certain cases, an elevated risk status, for example, a child user with a calculated GUI of 3, may have their risk status raised to 4 to reflect the child user's tendency toward faster and higher blood glucose fluctuations.

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

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

[0192] Another factor that may influence GUI decisions, if known, is the cause of an increase or decrease in blood glucose levels. It should be noted that some changes in glucose levels are caused by stress, and others by food intake. Such data may be pre-processed, pre-associated, or associated before data entry into the urgency assessment module. For example, food data may be processed in conjunction with glucose levels to determine whether the increase in glucose was due to food or another cause such as stress. Using such data, past problems that lacked consideration of such causes and effects can be effectively addressed.

[0193] As mentioned above, glucose values ​​(and derivative data) can be weighted by the evaluation module based on signal quality, confidence level, etc. Such weighting is generally performed automatically by the electronic device based on the analysis of signal data from sensor electronic devices. However, any of the above variables or parameters can be entered into GUI calculations in a weighted form, and the weighting is performed automatically, for example, by signal analysis from intrinsic sensors, such as accelerometers and scales, or by using manually entered data from physicians or patients. Using such data, problems seen in the past that lacked consideration of such factors can be effectively addressed.

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

[0195] Figure 8 illustrates flowchart 40 illustrating the general use of the parameters and variables discussed above. In the first step, multiple inputs related to a disease such as diabetes are received, the inputs correspond to variables or parameters, which can be measured, entered by the user, or otherwise obtained via, for example, 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 may change, or a warning or alert may be provided when the GUI reaches a certain value or threshold (step 278). Similarly, various types of advanced outputs (additional processing or additional details regarding GUI processing, e.g., information about the inputs) can also be provided (step 282). In some implementation examples, the determined GUI may serve to activate an integrated pump for a drug (step 275), as further detailed below.

[0196] Several variations may be understood. For example, notifications, displays, warnings, or alarms, and advanced output may be provided to the patient or another user, such as a caregiver, physician, or family member. Generally, means of displaying or notifying the user's status are available and provided. In more urgent cases, warnings or alarms may be provided to the user so that they can take appropriate action. Furthermore, not all of these must be provided to the user in a given situation. In some cases, the user may simply want to review the user interface of their mobile device to check their status, in which case a display is provided even if no warning, alarm, or advanced output occurs. In relevant cases, only advanced output may be desired by the user. In other cases, when important information is a warning or alarm, the warning or alarm may be provided without providing a specific general display of the status to avoid distracting the user. Other variations may also be understood.

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

[0198] Example 1 solves the problem that when a “recovery” event is about to occur, the rate of change information alone (the first derivative) cannot accurately predict the glucose value, which will resolve in the long term. By using acceleration information, the “recovery” event can be predicted more accurately, avoiding overcorrection or false alarms.

[0199] In a specific implementation example, for example, at 0 mg / dL / min / min (without detection of acceleration or deceleration), the emergency assessment module may rely only on the first and second inputs for determining the blood glucose emergency index. However, at 1 or 2 mg / dL / min / min, the emergency assessment module may also rely on other inputs, including acceleration, to determine the type of “improvement” event and its predicted impact.

[0200] Example 2 In another example implementation, the first input is the same as in Example 1, the second input is the rate of 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 consideration in the GUI determination.

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

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

[0203] In another specific implementation example of the embodiment, and referring to graph 50 in Figure 9, output records of glucose values ​​283 (applicable to axis 289) and GUI values ​​285 (applicable to axis 291) are plotted against time axis 287 to illustrate. As can be seen, in region I, the user is initially in a hyperglycemic state and has a low to medium range GUI. Another type of GUI is illustrated here, ranging from 0 (low urgency) to higher values ​​(indicating higher urgency). However, by considering the rate of change of glucose values ​​that tend towards the target range, the GUI, and therefore the urgency assessment, may be lowered towards the "no urgency" region or band. If the glucose value had a positive rate of change rather than a negative rate of change, or had an acceleration showing a tendency toward higher values, the GUI will rise toward a more urgency assessment, even if the glucose value itself was decreasing.

[0204] In region II, glucose levels appear to occupy the hyperglycemic range (e.g., 180-400 mg / dL) for a period of Δt1. Assuming that time Δt1 exceeds a specified threshold, as is the case in Figure 9, such a situation may explain why the GUI increases, even if the user is only mildly hyperglycemic or has not experienced any further increases in the user's glucose levels. Region II in Figure 9 illustrates the hyperglycemic range, and it is understood that occupying the hypoglycemic range also increases the GUI value, particularly because the duration of the user occupying the hypoglycemic range is related to the predicted deviation of further hypoglycemia.

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

[0206] For example, by tracking the duration or amount of time spent below a threshold for a specific event or period, it is possible to effectively correct and refine blood glucose emergency states or indices, more accurately reflecting the risks and clinical significance to the user.

[0207] Referring again to Figure 9, region III indicates the beginning of the time when the user indicated a mitigating factor in the hyperglycemic event, such as a bolus insulin infusion (by entering data into an electronic device). For example, the user entered data indicating that a bolus was delivered, whether in response to an input request from the emergency assessment module or not (the integrated pump may also provide such data). The emergency assessment module may bring about an immediate decrease in the GUI, and such a decrease in the GUI may occur well before the decrease in glucose concentration is actually observed. In the case of Figure 9, such a delay is indicated by time Δt2.

[0208] By considering parameters and variables beyond glucose levels alone, and even beyond simply considering increases or decreases in glucose levels, notifications, including continuous notifications, warnings, and alarms, can be more finely tailored to a given user using systems and methods following this principle, thus offering several advantages, including a reduction in nuisance alarms. For example, using the system described above, if the threshold is set to 70, but the user is at 69 and their level is rising, the previous system would continue to warn because the user is still below the threshold. Systems and methods following the current principle recognize that the user has an rising glucose level and therefore does not need to be warned in the first place. Even if the user was not measured when their level was rising, but they had just eaten, systems and methods following this principle would immediately recognize, based on the GUI, that the user has an rising glucose level, thus avoiding nuisance warnings or alarms that would otherwise be activated.

[0209] Region IV indicates a region where the glucose values ​​are somehow noisy, and therefore a low level of confidence may be associated with this part of the signal. Thus, the GUI may appear elevated under the perception that glucose values ​​with low confidence are associated with a higher or more urgent urgency assessment. A similar elevation in the urgency assessment would occur if it is determined that a significant delay has occurred in the signal.

[0210] Region V exemplifies another parameter or variable that may influence GUI decisions. Specifically, in Region V, it is assumed that the user has become more interactive with their mobile device, as determined by a significant number of key presses, touch screen activations, and movements determined by the accelerometer. Therefore, the GUI and emergency assessment may be reduced because the user is more likely to see updates, warnings, and alerts regarding the emergency assessment, thus increasing the likelihood that the user can take prompt action.

[0211] Area VI shows a situation where the predicted glucose level of 313 indicates an increase in glucose levels, and such predictions are calculated by the predictive analysis tool as described above. In this case, this may lead to an increase in the GUI by recognizing the prediction of an increase in blood glucose levels. Such predictions may also have the advantage of compensating for delays in glucose levels.

[0212] Area VII represents another situation where elevated glucose levels do not necessarily warrant a significant increase in the urgency assessment based on user-entered data. Specifically, Area VII indicates that the user is heading towards a mild hyperglycemic state. However, if recent data indicates that the user is about to engage in significant physical activity, such as exercise, the tendency towards a mild hyperglycemic state may be mitigated by the expected effects of exercise. Therefore, GUI285 in Area VII does not need to increase significantly.

[0213] The variations will be understood. For example, while GUI axis 291 is used in only one direction, the GUI axis may be used in two directions (not indicated) to show the urgency of hyperglycemia and the urgency of hypoglycemia. While a single GUI axis 291 is used, in order to remove ambiguity of the type of urgency and therefore to provide a notification or actionable warning, the algorithm providing it is aware of glucose values ​​and other variables and parameters that constitute the GUI determination, and therefore the notification or actionable warning displayed takes into account whether the user is hyperglycemic or hypoglycemic.

[0214] Furthermore, in some cases, users may view output log 285 showing the GUI or see numerical indices representing the GUI, while most notifications or actionable warnings provide a visual representation of the GUI through other means, such as the use of colors, icons, etc., as will be further detailed below. In other words, many users do not need to see the GUI itself, but rather what the GUI represents.

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

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

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

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

[0219] Figure 11 shows Graph 70 illustrating the effect of a previous significant glucose deviation. Specifically, a significantly hyperglycemic event 303 is exemplified in the glucose concentration. This also appears to resolve over time in Graph 70. However, a subsequent rise 305 can be seen, and instead of simply resulting in a gradual rise in GUI, the subsequent rise 305 may result in a sharp rise in GUI 307, as it can be assumed that the previous significant hyperglycemic deviation may be repeating itself (a rebound). Therefore, the assessment of urgency is superior to simply relying on glucose values ​​alone.

[0220] Other embodiments may also be understood. For example, a user who otherwise has a “low-risk” urgency assessment based on, for example, glucose levels and rate of change, may be given a higher-risk urgency assessment if they are overweight, have a high BMI, high blood pressure, high stress, or are dehydrated. Body temperature, anthropometric data, and disease status, as well as demographic data, may further modify the GUI so that contextual and behavioral information can be corrected. Sensor location may also modify the determined GUI. For example, a user may have a low GUI and therefore a low-risk urgency assessment, but if the sensor location is such that a significant delay in glucose levels is expected, the GUI and urgency assessment may be increased to reflect a lack of confidence in the current measured glucose level.

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

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

[0223] For example, if a user's glucose level remains below a specified threshold for more than 15-20 minutes, even after carbohydrate intake, such a situation may be presented on the device's user interface. In this way, the user becomes aware of the significant duration during which the low glucose level was ineffectively treated.

[0224] As another example, a user's glucose level may exceed a specified threshold, but is expected to decrease in the near future. In this case, for example, predicted glucose levels over a 20-minute forecast period would provide the user with a useful and actionable warning, enabling clear action (or a group of action) to be taken.

[0225] In another example, a user's glucose levels may exceed a specified threshold for an extended period. In this case, indicating how long the user's levels were above the threshold can help warn the user about the seriousness of the situation.

[0226] In yet another example, a user's glucose level remains above the specified threshold for an extended period and fails to decrease. In this case, indicating the duration of the high value and the percentage of time it takes for the level to return to normal blood glucose levels provides the user with important and actionable information.

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

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

[0229] Other inputs that may exacerbate a user's risk state include the acceleration or duration of hypoglycemia or hyperglycemia, and the duration of a constant rate or acceleration of blood glucose levels. One example is shown in Figures 12A and 12B, where the risk to the subject increases as blood glucose levels remain above 180 mg / dL for longer periods.

[0230]

number

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

[0232] In the equation, if f(g) < 0, then r1(g) = r(g), otherwise it is 0.

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

[0234] g is the glucose concentration,

[0235]

number

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

[0237] Figure 13 provides a chart illustrating the increasing health risks associated with the duration of hyperglycemia. This chart illustrates glucose levels in users who are hyperglycemic but not continuously rising. However, the chart shows that the risk continues to increase over time as the duration of hyperglycemia increases.

[0238] Figure 14 illustrates an example of avoiding false risk states by using acceleration as a parameter or variable in GUI determination. In this figure, acceleration or the second time derivative indicates that the glucose value is decreasing while simultaneously being in an improving process, returning towards a normal blood glucose state. However, a continued increase may result in an elevated risk assessment, and therefore a higher GUI, due to the possibility of a hyperglycemic event.

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

[0240]

number

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

[0242] Other functionalities may also be brought into the analytical framework to support it. For example, adaptive learning may be applied, which is broadly described in U.S. Provisional Patent Application No. 61 / 898,300, filed October 31, 2013, entitled “ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES,” and U.S. Application No. 13 / 827,119, filed March 14, 2013, owned by the applicant of this application, entitled “ADVANCED CALIBRATION FOR ANALYTE SENSORS,” the entirety of which is incorporated herein by reference. In one application of adaptive learning, a monitoring device, such as a mobile device, may adaptively learn the user’s behavior over time as the user experiences hypoglycemia and hyperglycemia events. For example, each time the user’s blood glucose level falls below 55 mg / dL, the data preceding that event may be used as a positive test case by a machine learning algorithm, such as a support vector machine (SVM) or linear discriminant analysis (LDA). Furthermore, cases where a user's glucose level remained between 70 and 110 could be used as a poor test case by the machine learning algorithm. The machine learning algorithm could be trained regularly or irregularly, for example monthly, to optimize the classification of hypoglycemia in the very near future. For example, the algorithm could learn the state of a particular user one or one and a half hours prior to a hypoglycemic event. Examples of inputs to the machine learning algorithm used for classification could include glucose output records over the past six hours, current glucose level, current rate of change in glucose level, current glucose acceleration, time of the last insulin bolus, size of the last insulin bolus, number of carbohydrates reported, time of carbohydrate reporting, level of the last glucose peak, last time the user interacted with the monitoring device, time of last exercise, time between insulin bolus and meal peak, etc. Once the classifier is optimized, it can be applied to the data in real time to determine whether hypoglycemia is likely to occur within a certain expected time window.

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

[0244] Another type of functionality that can be used involves the “decision fusion” method. Specifically, decision fusion provides an alternative framework for determining a user’s risk status from multiple inputs. Decision fusion uses a statistical model to optimally combine risk information from multiple inputs to generate a likelihood value for any event, such as hypoglycemia, that is likely to occur. Such a method is particularly useful for aligning heterogeneous inputs, such as the rate of glucose change over the past 20 minutes and the number of times the receiver button was pressed, onto a single likelihood scale. Prior information on the sensitivity and specificity of each input in predicting undesirable events, such as hypoglycemia, is used to determine how much weight to give to each input in the final risk output, as will be further detailed below.

[0245] The fusion determination method can be used, for example, to determine whether a given user is likely to have a blood glucose level below 55 mg / dL within the next hour. In this way, different data parameters can be used to determine whether hypoglycemia will occur within a given time, e.g., within the next hour. Data analysis may be performed to determine the optimal detection parameters and their optimal presence / absence 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 the determination and the associated sensitivities and specificities. It should be noted here that while the sensitivity 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 ambiguous, 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. Generally, the best predictors have both high sensitivity and specificity, such as that the predicted glucose level is less than 55 mg / dL.

[0247] [Table 2]

[0248] Each parameter can be compared in real time with 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. The 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 calculated by dividing the probability of making a decision when the subject is likely to experience hypoglycemia by the probability of making a decision when the subject is unlikely to experience hypoglycemia. For a decision of "yes" or 1, the likelihood value can be considered as sensitivity divided by (1 - specificity), i.e., the probability of a false alarm.

[0253]

number

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

[0255] Heuristic methods are yet another type of mathematical method that can be applied to analytical frameworks. In such methods, experience informs the development of possible solutions. For example, an urgency assessment module may have experience-based data that suggests a given user would typically have high glucose levels if they are at a given set of GPS coordinates, which happen to be a coffee shop, and the user has an additional staff meeting scheduled for the next day. The glucose levels may be related to stress or related to eating. In the development of such heuristic solutions, related methods such as regression models, MPC, if-then logic, expert systems, logistic regression analysis, neural networks, fuzzy logic, and weight functions (which were weightings that could be applied to risk inputs of higher-risk blood glucose) may also be used. As a specific example of the use of regression models, A1C may be assumed as a current indicator of good / poor diabetes management. Some or many parameters or variables disclosed herein may be derived from a statistically significant number of users, and regression analysis may be performed to determine which of these factors significantly influence A1C. The resulting multipliers can then be adjusted, for example, to present easily interpretable risk points on a scale of 1 to 100.

[0256] Therefore, the GUI can be calculated by several means and using several different variables and parameters, some of which are measured, and others which are entered by the patient or other user. However, the GUI can be calculated and then used to dynamically provide a display to the patient (or caregiver) of a blood glucose emergency, and the emergency status can be iteratively updated over time. While the emergency status may be related to hypoglycemia, hyperglycemia, or normal blood glucose levels, this provides much more granular information than simply whether the glucose value (or predicted glucose value) has exceeded a threshold. The display to the user is generally a chart of the emergency, and the built-in functions of mobile devices such as smartphones can be advantageously utilized. The user interface of a smartphone can also be used to provide warnings / alerts to the user.

[0257] Additional information provided that is not available to systems that simply indicate that a glucose level has exceeded a threshold may include one or more of the following: The displayed information may include predictions about whether the glucose level is likely to rebound to a desired value or whether the deviation from normal blood glucose levels will continue. The displayed information may include (or may take into account) predictions about future emergency situations, which are distinguished from simply providing a predicted glucose level. The displayed information may include considerations about whether the glucose level follows or deviates from a known pattern.

[0258] An emergency assessment module running on a mobile device (or elsewhere) can provide a framework for distinguishing levels of danger and urgency for action that simple thresholds cannot provide, thus providing the user with actionable warnings without over-warning when unnecessary, thus preventing warning fatigue. In this regard, it should be noted that when smartphones are used for glucose monitoring, users receive continuous notifications from their phones for, for example, email, texts, phone calls, applications, etc., making it increasingly important to distinguish which warnings are important for the user to notice. It is important that particularly dangerous conditions requiring immediate attention are differentiated from such general phone sounds, perhaps by providing a special sound or vibration or even light / color to warn the user. Furthermore, it is important that the warning noticeably increases in stages if the user does not respond immediately, and the aforementioned parameters and variables can be used to determine when such increases should occur. The display can be provided by several means, such as using color, vibration, icons, heatmaps, predictive representations, representation of danger as a number, voice input requests, pop-up messages, etc.

[0259] In some cases, the user may be warned, preferably in a different format. Such a warning may be particularly appropriate when the user is with people who are not currently aware of the user's condition. Therefore, a warning may be provided, which is a vibration, but a particularly long vibration, that can alert the user to check their mobile device and determine what action is needed. Another type of vibration, for example, a long vibration, but for a duration such as 5 seconds, 10 seconds, etc., and at a frequency such as once per minute, twice per minute, etc., may be used for the alarm, applied periodically until stopped by the user.

[0260] If vibration-based warnings and alarms do not result in user action by the user pressing a button to at least indicate their recognition, the warnings or alarms may be provided audibly by a ringtone, including a ringtone specifically selected for such conditions.

[0261] If neither vibration nor audible sound prompts user interaction, an automated phone call or text message may be placed on another number, for example, by a physician or a family member to alert the user.

[0262] Assuming the user does not respond to a warning or alarm, the first typical response might be to pick up or otherwise hold their smartphone. In some cases, the user may have to perform a swipe gesture or enter a code to gain access to the smartphone's user interface. Given this scenario, an indication of the emergency situation may be provided on the user interface by several means. Firstly, the indication may be provided regardless of whether the phone is being held. This may be appropriate if the user leaves their phone in a position where it can be used, for example, on a desk face up on a docking station (e.g., background screen, home screen, periodic push notifications). Secondly, the indication may 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. Thirdly, the indication may be provided after access to the smartphone user interface is obtained, for example, via a swipe gesture, entering a code, etc.

[0263] With respect to the first and second means, the display provided on the user interface may contain somewhat less information than that provided by the third means, recognizing that others may also be able to see the display. With respect to the third means, if the user has already picked up the phone and is operating it, it can be inferred that the user has obtained the desired level of privacy. Therefore, the display in the first and second means may be, for example, a color or other indicator that the user is familiar with that indicates an emergency. For example, bright red on the user interface may indicate a high level of urgency, such as an impending hypoglycemia or hyperglycemia event. Red may be placed by the emergency assessment module through manipulation of the mobile device's background or wallpaper, or it may be the background of an application running the emergency assessment module, such as a CGM application, and this background and application are positioned to stand out in the event of an increased emergency.

[0264] In another implementation example, the colors may be accompanied by numbers or arrows, such numbers or arrows indicating additional details about whether the GUI is assessing the significant risk of hyperglycemia versus hypoglycemia. Such numbers or arrows may provide useful information to the user while retaining certain less prominent details of the user's condition.

[0265] Regardless of how the display occurs, user interaction with the application allows the user to become aware of relevant details of their state and possible steps to take in adjusting it. In other words, the user can decide if they wish to "dig deeper" into the numbers, in which case the application interaction allows the user to do so. Variations of the above embodiment may also be seen. For example, instead of a red screen, a red border or a large red circle around the user's home screen may be used. Different colors or positions may be used to indicate hyperglycemia versus hypoglycemia, or the user may need to illustrate the application to find their current state. Different positions or parallel line patterns may be advantageous as options for users who are colorblind.

[0266] Several types of functions available on mobile device user interfaces are described below to indicate actionable warnings based on GUI values. Such user interfaces are purely illustrative, and it is understood that other such user interfaces are also possible. The user interfaces may display various levels of information, specifically, the blood glucose urgency index and blood glucose or glucose information, sometimes together on the screen. The display of GUI values ​​can be done by several means, such as visualization or representation, including the use of elements such as colors or icons. While specific icons are discussed below, it is understood that these can vary in many ways, for example, they may be represented by 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 food (hypoglycemia) or a syringe or pump (hyperglycemia), or numerical values.

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

[0268] Referring to Figures 16A and 16B, two user interfaces 550 presenting different states are illustrated. In Figure 16A, the first lead 504 is illustrated by the color of the device (indicated by a parallel line pattern). 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 by a quick glance, the user may thus be notified of their GUI or blood glucose status. In this case, the urgency assessment may be yellow to indicate to the user that their glucose level is relatively normal, slightly elevated, or approaching the borderline of normal blood glucose levels. In Figure 16B, a red urgency assessment may indicate to the user that their blood glucose status requires immediate attention based on the GUI. Additionally or alternatively, rather than yellow or red to indicate high glucose, low glucose, etc., colors may be used to convey other types of information, such as positive (e.g., purple) or negative (e.g., orange) percentage changes. While the user will understand the meaning of the colors, others may not realize that diabetes information is being conveyed due to the abstract nature of the background design.

[0269] In the implementation example in Figure 16, an optional second lead 502 is also provided, which represents the glucose value itself. As mentioned above, urgency assessments generally use glucose values ​​in their determination, but other values ​​are also used and may be equally important in the determination. Additional leads, such as GUI inputs, patterns, insights, and treatment suggestions, may be accessed via the CGM.

[0270] In this and other implementation examples, the home screen of a mobile device running an emergency assessment module or CGM application in the background may continuously display a colored screen showing the glucose status. The colored screen generally displays a GUI status, such as "normal" or a GUI that does not warrant a warning, even when there are no warnings or alerts. The user does not need to swipe or enter a password to access this information. Such a screen can be quickly viewed by pressing the power button on the mobile device or by the accelerometer, which determines whether the mobile device is being held, as described above.

[0271] Referring to the user interface 560 of FIG. 17, color is still used, but in this case, the first lead is not the color of the home screen 506, but rather the color of the circle (circle 508 in FIG. 17A and circle 508' in FIG. 17B) located on the home screen. The second lead can be the speed or acceleration exemplified by the size of the circle 508 or 508', e.g., the radius of the circle, and the arrow 512 or 512' indicating the direction. For example, the arrow can exemplify the first derivative of whether the glucose value is increasing or decreasing, and the size of the circle can indicate how fast the glucose value is increasing or decreasing (the second derivative). Alternatively, the circle can qualitatively represent the potential risk due to the increase or decrease. For example, a large circle can represent that the increase is accelerating away from normal, while a small circle can represent that the increase is decelerating. The 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 suggestions for possible steps for the user to take or input requests.

[0272] Referring to Figures 18A and 18B, an alternative user interface 570 presented on the home screen 516 of a mobile device is illustrated. Figure 18A illustrates an example of an increasing glucose level, and Figure 18B illustrates an example of a decreasing glucose level. Specifically, arrows and a series of circles 518(518'), as well as their colors, may be used to indicate to the user whether their urgency assessment is increasing (Figure 18A) or decreasing (Figure 18B). Specifically, referring to Figure 18A, the increase itself is illustrated by an arrow, and the progression of color from off-white to red illustrates that the urgency assessment is also increasing, 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 Figure 18B, the progression of color from red to white indicates a return to a more desirable urgency state. The arrows, the fading of circles corresponding to more recently measured urgency assessments, and the progression from left to right indicate progression from previous urgency states to later urgency states, and finally to the current urgency state. Alternatively, a series of circles (or icons) 518 may represent a predicted glucose value or range as a first lead, which may include a predicted glucose value in 522 and a display of a predicted range (predicted value over time) indicated by the number of circles (or icons), for example, 5 minutes per circle, or in this embodiment, 15 minutes per circle. A second lead may be access by other user actions that may provide additional insights or information related to swiping or predictions.

[0273] Variations are understood to be 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 visually appealing elements, may also be used. For example, it could be an image of the moon shown in its gradual progression from new moon to full moon. For example, the size and color of the circles may indicate an urgency assessment. A subsequent sequence of sizes may indicate how rapidly the value is changing. For example, progression from very small circles to very large circles may indicate a rapid increase in the urgency assessment. Conversely, progression from "medium-small" circles to "medium-large" circles may indicate a much more gradual increase. Additional indicators or leads 524 may be used to provide icons that can be read at a glance in order to quickly indicate to the user the urgency of the user's assessment. Such indicators may appear without the mobile device being held, or following being held as determined by an accelerometer or other sensor, or automatically after a swipe / unlock step. This may be achieved by an audible warning to notify the user of the emergency situation.

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

[0275] In Figure 19, seven zones are presented with a low-risk or no-risk zone 526d in the center of the zone's range. For the urgency assessment shown in Figure 19A, the assessed urgency is low or no, i.e., there is little risk to the user. However, the urgency assessment shown in Figure 19B represents a higher urgency condition, in this case related to elevated glucose levels. The position and color of the highlighting may be used to provide indication. In Figure 19A, the highlighting is in the center and the color is white, indicating low urgency. In Figure 19B, the highlighting is within a high zone and colored red, indicating a higher urgency condition. When the highlighting, or other lead indicators, are positional or textual rather than color-based, this may be used to the advantage of individuals with color blindness. Figure 19 also shows glucose value arrows 528 and numerical descriptions 532. From the numerical descriptions 532, the user may be informed of their glucose value. From the arrows 528, the user may be informed of the direction their glucose value is heading. (As shown in Figure 19B) Arrows of the same color may indicate a more rapid or accelerating increase. These factors, and generally more factors, enter into the GUI decision, and the representation of this decision result is the highlighted range, indicating the determined urgency assessment.

[0276] Advanced output 534 is also displayed, providing the user with additional information about possible causes of hyperglycemia, possible steps to a lower urgency assessment, etc.

[0277] The ranges within different zones do not need to represent equally spaced levels of urgency; it is understood that they may provide quantitative or qualitative levels of urgency based on a determined GUI. The ranges may 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 would apply to other embodiments of the user interface disclosed herein.

[0278] In Figures 20A and B, a user interface 590 having a scale 536 similar to that of 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 may be indicated by a highlighted horizontal bar 542, past glucose levels may be indicated by a more faded horizontal bar 544, and horizontal bars of varying shades in between indicate changes in glucose values ​​over time. In some implementations, a background color of the same color may indicate a third lead or third level of information, such as Wi-Fi status or glucose communication (data sharing) with other mobile devices.

[0279] The colors of both the present and past horizontal bars can indicate relative or absolute urgency assessments. For example, the color of horizontal bar 542 could be white, while horizontal bar 546 (Figure 20B) could be red. Brightness indicates an urgency assessment that is one of several or many factors, although glucose value is a contributing factor. Therefore, horizontal bar 542, while depicted as white in the figure, could be depicted as red in another situation if, even with the same glucose value, the value was rising and accelerating (or otherwise deviating).

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

[0281] In some implementations, rows may represent snapshots of urgency assessments at that time or in the recent past. For example, the leftmost row might represent the recent past assessment, the middle row the current assessment, and the rightmost row the predicted future assessment. Alternatively, the rightmost row might represent the current assessment, with the left and middle rows representing recent past assessments. Other variations are also conceivable.

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

[0283] As in other embodiments, however in this example relating to grid spaces 552 and 554, the highlighting occurs in conjunction with a specific color, the indication of glucose values, and the indication of the direction in which the glucose values ​​are moving. As seen in Figure 21B, the highlighting may also be provided in other grid spaces, shown here as grid spaces 556 and 558 for indicating recent historical values ​​of measured glucose.

[0284] Figures 22A and 22B illustrate alternative user interfaces 620 that may be used to indicate urgency. In these figures, a glucose value graph 562 is provided to allow the user to view recent past values. Such graphs may be particularly important for users who desire a higher degree of knowledge about their current level. As illustrated in Figure 22A, the current glucose value 566 and a box 564 bordering the value and generally indicating where the current time is represented on the graph may also be provided. Screen colors 572 may be used to indicate GUI-based urgency assessments. For example, in Figure 22A, a light red background 572 may indicate an elevated level but a low urgency assessment. In Figure 22B, a blue background 572' may indicate normal blood glucose levels and zero urgency assessments. Figure 22B also shows that box 564 may be used to show a portion of a glucose output record graph with, for example, higher fidelity, additional processing (e.g., detected patterns). In the user interface shown in Figure 22, a horizontal threshold bar is not necessary, yet the use of a colored background still makes the user aware of their urgency assessment "area."

[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 therefore past behavior at that time. Specifically, the user interface 630 includes a background 574, which may indicate an urgency assessment, e.g., blue, green, yellow, red, etc. Alternatively, the color of a box 576 may indicate an urgency assessment, and this box also displays the current (or predicted) glucose value 578. A horizontal scale 582 is relative to time, and therefore the output record graph of glucose level 584 may 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 previously observed for a given user at a given time.

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

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

[0288] As described above, glucose levels and other factors influence GUI decisions and, consequently, the urgency assessment. The urgency assessment may be indicated to the user via the user interface 640 by the color of the background 614 or by the display of text 612, etc., which in Figure 24 indicates that the assessment is that the user is "okay". The user interface 640 also displays the current glucose level 606 and the direction in which the glucose is moving, indicated by an arrow 608. In some implementations, the gradient, size, or other aspect of the arrow 608 may indicate how quickly the glucose level is rising or falling.

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

[0290] In this and other implementations, rate of change and acceleration information may be added to the output record graph arrows. While the rate of change may be evident from the output record graph itself, colored or curved arrows may be used to indicate the acceleration or deceleration of glucose levels. In one implementation, a red arrow may indicate an undesirable acceleration, while a blue arrow indicates a desirable value. In another implementation, a curve in the arrow moving away from normal blood glucose may indicate undesirable acceleration, while a curve towards normal blood glucose may indicate a desirable trend.

[0291] Referring to Figures 25A and 25B, a user interface 650 containing additional data is displayed on the mobile device. Specifically, the user interface 60 includes an output record graph 618 corresponding to glucose levels and numerical values ​​622. While numerical values ​​622 can provide the user with instantaneous or current levels, the output record graph 618 can show the user what value they are at, even without a y-axis. The colors on screen 616 may provide another lead and may indicate a current urgency assessment. A qualitative graph 624 may be used to provide the user with an at-a-glance lead regarding the areas occupied by target, hyperglycemia, or hypoglycemia. In this figure, the pie segments may represent the percentage of time in these areas per day, per month, or over any other period. Alternatively, although not shown, the pie graph may be "overlaid" on a clock to show, for example, that the user had high GUI during the green segment 12-2 o'clock and then low GUI during 2-4 o'clock. An area of ​​the user interface 650 may be provided as a challenge area 626, which qualitatively shows the user how well they are doing with the challenge they have set for themselves to keep their glucose levels within a target range. Part of the user interface 60 may 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 may be displayed and reviewed. For example, each person can see how well others are doing with the goals or challenges they have set.

[0292] Figure 26 illustrates another user interface 660 that could be used to its advantage. User interface 660 is similar to user interface 630 in Figure 23, but includes additional details of prediction. Specifically, user interface 660 includes points 632 plotted to correspond to predicted glucose levels based on predictive analysis as described above. Instantaneous glucose levels 634 are displayed as numerical values ​​to provide a user-readable display.

[0293] Advanced 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 may notify the friends or followers to take some action towards the user. For example, friends or followers may be urged to reach out to the user if the user's urgency assessment tends to be high or low. Advanced Output 636 can also be used to urge the user themselves to, for example, suggest action guidelines or otherwise provide action. Additional details of advanced outputs are provided below.

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

[0295] Based on this instruction, other appropriate forms for social networking will be understood. For example, in various other embodiments, the evaluation module 211 may be used in combination with the contact module to provide updates to the social network. In some embodiments, the smartphone 200 may use the user's location and / or other attributes related to the user (e.g., type of diabetes, age, gender, demographic data, etc.) and / or similar CGM devices or smartphone applications to find other people in that area who have similar attributes, in order to suggest person-to-person connections. For example, a CGM application and / or a social media site in conjunction with a CGM application may allow the user to choose from options such as finding other people with diabetes, finding other people with diabetes near me, or finding recommendations for diabetes-friendly restaurants in that area.

[0296] In some embodiments (see Figure 6), the CGM application 209 (either alone or in combination with an evaluation module 211 that does not necessarily run within the CGM application 209 but generally runs within it) allows users to selectively upload or share information about their evaluations electronically and / or via social networking sites. Shareable embodiment information may include success evaluation criteria, current EGV values, screenshots, results, awards, pattern trend graphs, activity information, location information, and / or any other parameters described elsewhere herein as possible inputs to or outputs 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 user-selectable operations, such as sharing EGV on Facebook, sharing EGV on Twitter, sharing screens via Facebook, Twitter, email, MMS, sending trend screens to a printer, etc. Additionally or alternatively, the CGM application 209 may allow users to add pre-set and / or custom headings, or change the status of their shared information, such as "Watch my no-hit game," which can be shared selectively and / or automatically (by the user or based on parameters). In one embodiment, a user may "like" a specific GUI or its display directly on a specific social site. In a particular embodiment, when a user chooses to share information, options may be displayed on the display device 202 (Figure 6) that allow the user to choose what to share and with whom. A user may pre-define groups and / or individuals with whom to share information. For example, a user may create a group of friends, and when the user chooses to share something with the defined friends, a notification is then sent to each person in the group. This functionality is useful, for example, for parents who want to monitor their child's blood glucose.The child can choose to share their BG value, then select either their parents, or their mother or father, and the BG value will then be sent to the selected person(s).

[0297] In some embodiments, the CGM application 209 may be configured to work with social networks to allow users to compare EGV, trends, the number of lows, etc., with friends or groups on social network sites (e.g., Facebook). In some embodiments, the CGM application 209 uses CGM information from multiple users to compare one or more parameters for determining comparisons of data from one person to an average (e.g., grouped by some similarity). In some embodiments, the CGM application 209 can calculate achievements, scores, badges, or other awards based on predetermined criteria (e.g., maintaining blood glucose within a target range, CGM use) and post these selectively or automatically to social network sites (e.g., Facebook). In some embodiments, when a user wants to share what they have learned from the CGM application 209 or the evaluation module 211, for example, food photos and the resulting EGV or trend graphs, the CGM application 209 allows the user to selectively upload information to the site. In this context, what has been learned is an event or a first situation and the resulting effects, outputs, or trends.

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

[0299] The discussion of the user interface shown in Figures 28A and 28B continues to the possible outcomes of user interface 680. User interface 680 displays particularly inconspicuous results that would likely only be known to the user. Thus, the user's health status is not displayed on the user interface in any particularly obvious way. Specifically, referring to Figure 28A, a balloon with color 642 and an arbitrary numerical value 644 is shown. The color indicates the result of the GUI decision in an inconspicuous and subtle way. The numerical value 644 provides an additional lead, such as one related to the current glucose value in this implementation example. In addition to the balloon, a number of other icons or images may be used and, in fact, may be selected by the user. Thus, for example, the user may select a car whose color is related to the GUI decision (e.g., red, yellow, green, etc.). In the balloon embodiment, additional information or leads may also be provided. For example, the height of the balloon may indicate that the GUI has become more urgent or less urgent, or that the glucose value is rising or falling. Other variations may also be seen.

[0300] Figure 29 illustrates another user interface 690 that may be used to indicate the level of urgency to the user. In user interface 690, a tachometer-like display device has a green section representing a low-urgency state, a yellow section representing a medium-urgency state, and a red section representing a higher-urgency state. The position of the needle indicates the current state and is related to the determined GUI.

[0301] The above description of the user interface is purely illustrative, and it should be understood that numerous variations will be seen. For example, GUI decision-making and actionable warnings may be provided within the game either to conceal data so that only the user can discern them, or by means of such that a preferred GUI decision leads to a preferred game outcome. In other words, if the user controls their urgency assessment, the user wins the game. Furthermore, notification and actionable warnings may be provided by means of differentiating 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 so that warnings from the urgency assessment module 211 must be dealt with before the user can use the phone, so that warnings from the urgency assessment module 211 do not ignore specific or all other warnings, or that an urgency warning or alert is not inadvertently missed. As stated, warnings or alerts may escalate in stages as the urgency assessment increases, i.e., becoming more urgent. Initially, a warning may be displayed on the user interface when the device is unlocked, while such warnings can be progressively expanded to audible alarms as the urgency increases.

[0302] Further information provided by the user interface may include values ​​that allow the user to be notified of conditions such as rebound highs and rebound lows, and may offer possible user actions. In this case, the user can easily compare and recognize the causes and effects of such conditions, and since both are still fresh in the user's awareness, they can easily associate the causes with actions.

[0303] In several implementations, the data output to the user can be made to operate adaptively by creating various modes in which the emergency assessment module can operate. Furthermore, the emergency assessment module can adapt to real-time input from the user, physician / caregiver, or other criteria deemed useful.

[0304] Specifically, users may not want a warning if their GUI simply follows a known pattern, for example, if their GUI has a small deviation towards a mild emergency. Users may not want to be notified that their glucose is temporarily elevated after eating, as they expect the GUI, which may be determined based on pattern input as described further elsewhere in this specification, to be elevated. Users may not want to be alerted to glucose fluctuations if they spend a day with poor glucose management as a result of “bad behavior,” such as choosing to eat a birthday cake and have a little alcohol with friends to celebrate their birthday, when they are deliberately taking a day off from trying to achieve optimal management. Users do not want to be protected, but not always alerted. Therefore, in one implementation example, the user can set the emergency assessment module to an “operational mode” in which the user is notified only in potentially dangerous scenarios, such as “below 55,” “below 70 for more than 30 minutes,” or “above 300 and still rapidly rising,” etc. Providing an emergency assessment module with such functionality solves the problem of CGM users often being given information at inconvenient or potentially bothersome times. It also makes it possible to display appropriate information or warnings when users are not checking their CGM, and when they are checking their CGM regularly.

[0305] Refer to flowchart 720 in Figure 30 for a method following this principle for displaying a warning. In the first step, the GUI is determined as described above (step 646). The result of the GUI is then determined, which may be an output of a warning, alarm, or simply the current state of urgency (step 648). The output may also be based on adaptive learning, and specifically on learning about user characteristics, including patterns and trends 652 of the GUI and glucose levels, characteristics of mobile device usage, and other parameters and variables described above. Such may include user input 654 indicating, for example, that the user wants to be notified only of dangerous conditions. Adaptive learning may also be based on the mode 653 in which the urgency assessment module is operating. For example, if the mode indicates that the user wants to be warned only of dangerous conditions, such a mode may be included as a factor in determining the result in step 648. Similarly, users may input a mode 653 in which they desire a considerable level of intervention or suggestion. Based on this teaching, other modes will be understood in the same way. Other data 655 can also be used in determining the learning-based outcome.

[0306] Once an outcome is determined, the outcome may be presented to the user or physician / caregiver (step 656). In the presentation, the outcome may be displayed on a screen, audibly generated, or otherwise drawn. The outcome may be a general presentation such as data, warnings, or alerts. Alternatively, the outcome may simply be the display of the initial icon (step 658). The icon may provide an indication of the urgency assessment, but may be inconspicuous. Thus, the user makes a decision regarding receiving additional information, i.e., "digging deeper" into additional information. Such additional information may be requested by several means, e.g., by swiping the icon or by navigating to the app. The urgency assessment module receives the request (step 652) and provides the additional information (step 664), which may, in some cases, be the same as or similar to that provided in step 656.

[0307] Requests for receiving additional information may be handled by several other means, which may in some cases coincide with the specific advanced outputs mentioned 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 specific user, such as a child.

[0308] In another implementation of the user interface, as illustrated by the user interface 730 shown in Figures 31A and 31B, various scenarios based on an urgency assessment are presented to the user. Thus, the focus is on possible actions to take, rather than on enhancing specific measurements. For example, referring to Figure 31A, the user interface 730 may show a situation 666 and present various scenarios 668 that the user can choose from. Figure 31B shows a different situation.

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

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

[0311] Possible actions may be stern notifications, sometimes similar to warnings, or milder input requests that users only see when they look at their CGM screen. In such cases, the pushed data may be updated instantly without delay. Criteria may also be set for notifications based on potential danger scenarios, such as severely low glucose levels.

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

[0313] In addition to providing the user or caregiver / physician with information regarding the assessment of urgency, the GUI can be translated or converted into an insulin pump operation display using appropriate mappings, reference tables, or functions. The GUI can be displayed to the user for input as a pump operation display on a separate pump, or it can be provided directly to the pump to dispense insulin in a closed-loop system. More specifically, the GUI can be used to mitigate insulin delivery based on a blood glucose risk state, e.g., to withhold, reduce, or increase basal or bolus insulin delivery. By basing pump functionality on an urgency assessment such as a GUI, the user's emergency state is considered in a far more useful way, using factors other than just the current (or even predicted) glucose level exceeding a threshold. For example, a particular implementation may request a bolus insulin dispensing if the GUI 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 that are network-connected for communication.

[0314] The metrics for GUI-based notifications, as well as for warnings and alarms, may be factory-configured or user-individualizable, with the thresholds for triggering warnings and alarms also being set. The system may also provide for changes to warnings based on trends or other factors in the GUI, either automatically or triggered by the user. Therefore, the system allows for dynamic and / or iterative updates of urgency metrics and statuses over time, as additional data is received and based on user actions.

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

[0316] The urgency assessment module may allow for different sensitivities based on, for example, time of day (day vs. night), while driving, exercising or playing sports, napping, or when ill. Sensitivity may also be adjusted based on user requests. For example, if a user desires a significant amount of feedback, including positive feedback, such a user may adjust the sensitivity to a high setting (or a low discriminant level) to allow a significant amount of information to be presented. Other feedback provided may be inherently positive, such that the urgency begins to resolve as soon as it is assessed, and the user interface may display messages indicating improvement in the situation, such as "Your treatment appears to be working." In this way, the user can be influenced to their advantage even before reaching the optimal correction point, further advantageously preventing insulin and food stacking that could lead to harmful overcompensation. Further details of such types of feedback are described below.

[0317] Conversely, other users may only desire warnings or information when entering a dangerous or potentially dangerous emergency assessment. For such users, sensitivity may be set to a low setting (or a high discrimination level) 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 a user moves from a more urgent blood glucose state to a less urgent one, i.e., from a higher risk to a lower risk, the output may similarly indicate that the user's treatment has begun to correct the emergency blood glucose risk state, and furthermore, prevent insulin and food overload.

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

[0320] By using these types of outputs and by continuously updating blood glucose status, GUI or urgency assessment trend information that is clearly distinguishable from outputs based solely on glucose threshold exceedances or even from glucose trends can provide users with information they would otherwise not receive.

[0321] While the above information is based on a generally expected assessment of blood glucose urgency, selective alerts can also be based on retrospective algorithms that look for specific types of blood glucose deviations that may indicate long-term glycemic complications. Such retrospective algorithms were described above in relation to GUI decisions, but it should be noted here that retrospective algorithms can also be the basis for various user interface displays and / or input requests. For example, a retrospective investigation may reveal a large deviation from low to high or high to low. An example of a retrospective alert system intended to draw the user into a CGM event is illustrated below. Retrospective alerts may issue warnings on the user's smartphone when meaningful information is found in their data.

[0322] An example of such a method is illustrated by flowchart 740 in Figure 32A. In the first step, the retrospective algorithm examines the data for various blood glucose events, e.g., significant deviations from normal values ​​or values ​​determined to be typical according to reference values, unfolded patterns, etc. (step 672). In this process, the algorithm may examine recent minimums and maximums as soon as new sensor packets of data arrive. An example is illustrated by graph 750 in Figure 32B. Output recording point 678 illustrates a CGM output record, 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 may be based on the difference between values ​​in mg / dL, the percentage difference between the start and end of the event, or other factors such as whether the deviation exceeds the standard deviation outside a typical deviation. By setting such thresholds appropriately, the system ensures that only meaningful events are displayed to the user, and that spam alerts are minimized. Advantageously, it may be possible to easily collect user information useful for pattern recognition and, in general, teach the user about an individual's blood glucose events, patterns, or profiles.

[0324] If an event is outside the threshold and therefore significant, this triggers a warning or other resulting output (step 676). For example, a push notification may be delivered, an icon may be represented on the trend graph, or a batch number may increase, etc. Other such notifications would also be understood. The displayed warnings generally differ 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 might be, "We have noticed a large glucose deviation. Would you like to enter carbohydrate and / or insulin information regarding this event?" The trend graph segment may be highlighted in a different color, while a warning is triggered indicating that the user has not dealt with it. Such a situation may be shown in graph 760 of Figure 32C by a different color (line or dot) within segment 686.

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

[0326] Modifications based on these instructions will also be understandable to those skilled in the art. For example, trends, particularly trends in a determined GUI, can be used to present information to a user on a mobile device user interface, while trends can be used as a teaching tool for physicians or caregivers to draw attention to identified patterns, incidences, or events that users should be aware of.

[0327] The connections between elements are shown in the diagram illustrating an example communication channel. Additional communication channels, either directly or via an intermediate, may be included to further facilitate the exchange of information between elements. A communication channel may be a two-way channel that allows elements to exchange information.

[0328] As used herein, the term “determine” encompasses a wide range of operations. For example, “determine” may include calculating, computing, processing, extracting, investigating, referencing (e.g., referring to a table, database, or other data structure), verifying, etc. It may also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. It may also include resolving, selecting, choosing, establishing, etc.

[0329] As used herein, the term “message” encompasses a wide range of forms for transmitting information. A message may include a machine-readable collection of information, such as an XML document, a fixed-field message, or a comma-separated message. In some implementations, a message may also include a signal used to transmit one or more representations of information. While quoted in the singular, a message is understood to consist of multiple parts, for example, being composed of / transmitted / stored / received.

[0330] The various operations of the above-described method may be performed by any suitable means capable of operating various hardware and / or software components, circuits, and / or modules. In general, any operations illustrated in the figures may be performed by corresponding functional means capable of performing the operation.

[0331] Various exemplary logical blocks, modules, and circuits described in connection with this disclosure (e.g., the blocks in Figures 5 and 6) may or may be implemented using general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate array signal (FPGA) or other programmable logic devices (PLDs), isolated gate or transistor logic, isolated hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in alternative examples, the processor may be any commercially available processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computer devices, e.g., a DSP and a microprocessor, multiple microprocessors, a combination of one or more microprocessors combined with a DSP core, or any other such configuration.

[0332] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on a computer-readable medium or transmitted as instructions or code on one or more of them. Computer-readable mediums include both computer storage media and communication media, including any media that facilitate the transfer of computer programs from one location to another. Storage media may be any available medium accessible by a computer. Without limitation, by the means of the embodiments, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices 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 is accessible by a computer. Any connection may also be appropriately referred to as computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology, such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology, such as infrared, radio, and microwave, are included in the definition of medium. Disks and discs, as used herein, include compact discs (CDs), laserdiscs®, optical discs, digital multipurpose discs (DVDs), floppy disks, and Blu-ray® discs, where a disk typically reproduces data magnetically, while a disc reproduces data optically using a laser. Therefore, in some embodiments, a computer-readable medium may include non-temporary computer-readable media (e.g., tangible media). Furthermore, in some embodiments, a computer-readable medium may include temporary computer-readable media (e.g., signals). Combinations of the above are also included within the scope of computer-readable media.

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

[0334] Certain embodiments may include a computer program product for performing the operations described 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. In certain embodiments, the computer program product may include packaging material.

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

[0336] Furthermore, it should be understood that modules and / or other suitable means for carrying out the methods and techniques described herein may be downloadable and / or otherwise available to user terminals and / or base stations where applicable. For example, such devices may be coupled with a server to facilitate the transfer of means for carrying out the methods described herein. Alternatively, the various methods described herein may be available to user terminals and / or base stations by coupling with them, or may be provided via storage means (e.g., RAM, ROM, physical storage media, e.g., compact discs (CDs) or floppy disks) that provide storage means to the device. Furthermore, any other suitable means for providing the methods and techniques described herein to the device may be utilized.

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

[0338] Unless otherwise specified, all terms (including technical and scientific terms) are not limited to special or individualized meanings unless their ordinary and customary meanings are shown to those skilled in the art and they are expressly defined herein. It should be noted that the use of any particular technical term should not be taken as meaning that it is redefined herein so as to be limited to including any particular feature of the relevant function or aspect of the disclosure when describing a particular function or aspect of the disclosure. Terms and expressions used in this application and their variations should be construed as unlimited, as opposed to limited, especially in the appended claims, unless expressly specified otherwise. As mentioned above, the term "including" should be read as meaning "including, but not limited to," "not limited to, but including," etc. The term "comprising," as used herein, means the same as "including," "containing," or "characterized by," encompassing or not limiting, and not excluding additional unlisted elements or steps of method. The term "has" should be interpreted as "has at least," the term "includes" should be interpreted as "including, but not limited to," and the term "example" is used to provide an example of the item under discussion. Rather than being a complete or limited list, adjectives such as “known,” “common,” “standard,” and similar terms should not be interpreted as limiting the items described to those available for a given period or at a given time, but rather as encompassing known, common, or standard technologies that may be available or known now or in the future; and the use of terms such as “preferred,” “suitable,” “desired,” or “desirable,” and similar words should not be understood as meaning that certain features are critical, essential, or even important to the structure or function of the invention, but rather as merely intended to highlight alternatives or additional features that may or may not be available in particular embodiments of the invention.Similarly, groups of items connected by the conjunction "and" should not be interpreted as requiring each of these items to exist within the group, but rather as "and / or" unless explicitly specified. Likewise, groups of items connected by the conjunction "or" should not be interpreted as requiring mutual exclusivity between the groups, but rather as "and / or" unless explicitly specified.

[0339] If a range of values ​​is provided, it is understood that the upper and lower limits of the range, as well as each intermediate value between the upper and lower limits, are included within the embodiment.

[0340] With regard to the use of substantially any plural and / or singular terms herein, those skilled in the art can paraphrase from plural to singular and / or singular to plural as appropriate to the context and / or use. Various singular / plural substitutions may be explicitly stated herein for clarity. The indefinite articles “a” or “an” do not exclude the plural. A single processor or other unit may perform the functions of several items enumerated in the claims. The mere fact that certain measurements are enumerated in different dependent claims does not imply that combinations of these measurements cannot be used for merit. None of the reference numerals in the claims should be construed as limiting the scope.

[0341] Where a particular number of introduced claims are intended to be enumerated, such intent is clearly enumerated in the claims, and where there is no such enumeration, such intent is not present, as will be further understood by those skilled in the art. For example, for the sake of understanding, the claims attached below may include the use of introductory clauses “at least one” and “one or more” to introduce an enumeration of claims. However, the use of such clauses should not be interpreted as meaning that the introduction of an enumeration of claims by the indefinite article “a” or “an” means that any particular claim containing such an introduced enumeration of claims is limited to only one embodiment containing such an enumeration (for example, “a” and / or “an” should typically be interpreted as meaning “at least one” or “one or more”), and this also applies to the use of definite articles used to introduce an enumeration of claims. Furthermore, even if a specific number of claims being introduced is explicitly listed, a person skilled in the art will understand that such a list should typically be interpreted as meaning at least the number listed (for example, the blatant list of “two lists” without other modifiers typically means at least two lists, or two or more lists). Moreover, in these cases where conventions similar to “at least one of A, B, and C, etc.” are used, such interpretation is generally intended to mean that a person skilled in the art will understand the convention to include, for example, any combination of listed items that include a single element (for example, “a system having at least one of A, B, and C” would include, but not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.).In these instances where a convention similar to "at least one of A, B, or C, etc." is used, such interpretation is generally intended in the sense that a person skilled in the art would understand the convention (for example, "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 will further be understood by a person skilled in the art that any substantially separate word and / or clause presenting two or more different terms, whether in the description, claims, or drawings, should be understood to intend the possibility of including one of the terms, neither of the terms, or both terms. For example, the expression "A or B" will be understood to include the possibility of "A" or "B" or "A and B".

[0342] All numerical values ​​used herein to represent quantities of components, reaction states, etc., are understood to be modified in all cases by the term "approximately." Therefore, unless otherwise indicated, numerical parameters described herein are approximations that may vary depending on the desired properties to be obtained. In any case, and not as an attempt to limit the application of the principles of and equivalents to any claims of any application asserted prior to this application, each numerical parameter should be interpreted with respect to a considerable number of decimal places and common rounding methods.

[0343] All references cited herein are incorporated herein in their entirety by reference. To the extent of publications and patents or patent applications incorporated herein by reference in a manner that conflicts with this disclosure, this specification is intended to supersede and / or take precedence over any such conflicting material.

[0344] Headings are included herein for reference and to aid in finding various sections. These headings are not intended to limit the scope of the concepts described therein. Such concepts may be applicable throughout this specification.

[0345] Furthermore, although the foregoing has been described in some detail by means of the figures and embodiments for the sake of clarity and understanding, it will be obvious to those skilled in the art that certain changes and modifications can be made. Therefore, the description and embodiments should not be construed as limiting the scope of the invention to the specific embodiments and examples described herein, but rather to include all modifications and alternatives that come with the true scope and spirit of the invention. [Explanation of symbols]

[0346] 2. Drug delivery pump 4 Reference meter 8 Sensor Systems 10 Continuous Analytical Sensors 12 Sensor Electronic Devices 14 Display Devices 16 devices 18 Mobile devices 20 Computer Devices 21 Compatible devices 22 Cloud-Based Processors 24 Network 26 numerical values 200 Electronic Devices 202 Display device

Claims

1. A method for assessing the risk of blood glucose and responding to the risk of blood glucose, wherein the method is Obtaining glucose concentration data measured in the host's body fluids over a certain period of time, The processor module analyzes the glucose concentration data to determine a measure of blood glucose urgency, wherein the measure of blood glucose urgency is determined at least in part on an evaluation of the variability of the glucose concentration data. The processor module enables the display of the blood glucose urgency scale on the mobile device's user interface using non-numerical visual elements. The processor module compares the blood glucose urgency scale with one or more thresholds of blood glucose risk, In response to the determination that the blood glucose urgency scale exceeds at least one of the one or more blood glucose risk thresholds, insulin delivery is modified by generating one or more modified insulin delivery commands. Outputting one or more modified insulin delivery commands for use by an insulin delivery device, Methods that include...

2. The method according to claim 1, wherein the glucose concentration data includes continuous glucose sensing data measured by a continuous glucose sensor.

3. The method according to claim 1, wherein the period is at least one day.

4. The method according to claim 1, wherein the variability of the glucose concentration data includes the rate of change of the glucose concentration data.

5. The method according to claim 1, wherein the variability of the glucose concentration data includes the acceleration of the rate of change of the glucose concentration data.

6. The method according to claim 1, wherein the variability of the glucose concentration data includes a measure of deviation from one or more normal glucose patterns of the host.

7. The method according to claim 1, wherein the variability of the glucose concentration data includes a measure of one or more deviations from the predicted glucose concentration of the host or the reference glucose concentration of the host.

8. The method according to claim 1, wherein the blood glucose urgency scale is determined based on at least the glucose concentration data, the variability of the glucose concentration data, and at least one user input.

9. The method according to claim 1, wherein the measure of blood glucose urgency is determined based on at least one indicator of glucose concentration data, the variability of the glucose concentration data, and insulin delivered received from the insulin delivery device.

10. The aforementioned one or more thresholds for the risk of blood glucose, Physiological conditions that indicate a risk of hypoglycemia, and / or The method according to claim 1, including a physiological state indicating a risk of hyperglycemia.

11. The method according to claim 1, wherein modifying insulin delivery includes reducing, withholding, or increasing insulin delivery.

12. The aforementioned threshold for the risk of blood glucose includes a physiological condition indicating a risk of hypoglycemia, Modifying insulin delivery includes reducing and / or withholding insulin delivery in response to the blood glucose urgency measure exceeding the threshold of blood glucose risk, including physiological conditions indicating a risk of hypoglycemia. The method according to claim 1.

13. The aforementioned threshold for the risk of blood glucose includes a physiological condition that indicates a risk of hyperglycemia, Modifying insulin delivery includes increasing insulin delivery in response to the blood glucose urgency measure exceeding the threshold of blood glucose risk, which includes physiological conditions indicating a risk of hyperglycemia. The method according to claim 1.

14. The method according to claim 1, further comprising generating a warning or alert in response to determining that the blood glucose urgency scale exceeds the at least one threshold of the blood glucose risk.

15. A system for assessing the risk of blood glucose and responding to the risk of blood glucose, wherein the system is A control device, By acquiring glucose concentration data over a certain period, The glucose concentration data is analyzed to determine a measure of blood glucose urgency, and the measure of blood glucose urgency is determined at least in part on an evaluation of the variability of the glucose concentration data. The blood glucose urgency scale is displayed on the user interface of the control device using non-numerical visual elements. The aforementioned blood glucose urgency scale is compared with one or more thresholds of blood glucose risk, and the one or more thresholds of blood glucose risk are: Physiological conditions that indicate a risk of hypoglycemia, and / or A physiological condition that indicates a risk of hyperglycemia. Includes, In response to determining that the measure of blood glucose urgency exceeds at least one of the one or more thresholds of blood glucose risk by modifying insulin delivery, Based on the modified insulin delivery, one or more modified insulin delivery commands are generated. The generated one or more modified insulin delivery commands are sent to the insulin delivery device. A system including a control device configured in such a way.

16. The system according to claim 15, wherein the aforementioned period is less than one day.

17. The variability of the glucose concentration data is The rate of change of the glucose concentration data mentioned above, The acceleration of the rate of change of the glucose concentration data, A measure of deviation from one or more normal glucose patterns in a host, and / or A measure of one or more deviations from the predicted glucose concentration of the host or the reference glucose concentration of the host, The system according to claim 15, including the system described in claim 15.

18. The control device is If the blood glucose urgency exceeds at least one of the one or more thresholds for blood glucose risk, including physiological conditions indicating a risk of hypoglycemia, generate at least one insulin delivery command instructing the insulin delivery device to reduce or withhold insulin delivery, and / or If the blood glucose urgency exceeds at least one of the one or more thresholds for blood glucose risk, including physiological conditions indicating a risk of hyperglycemia, the system generates at least one insulin delivery command that instructs the insulin delivery device to increase insulin delivery. The system according to claim 15, configured to modify insulin delivery.

19. The system according to claim 15, wherein the control device is one of a mobile device, a remote server, or an electronic circuit of the insulin delivery device.

20. An integrated system for assessing the risk of blood glucose and responding to the risk of blood glucose, wherein the system is A continuous glucose sensor configured to generate glucose concentration data, wherein the glucose concentration data represents glucose concentration measured in the host's body fluids over a period of at least one day. An insulin delivery device configured to deliver insulin according to one or more generated insulin delivery commands, A control device operably connected to the continuous glucose sensor and the insulin delivery device, Includes, The control device is At least one processor, and At least one non-temporary computer-readable storage medium for storing instructions Includes, When the instruction is executed by the at least one processor, the control device will be instructed to: Receiving glucose concentration data from the continuous glucose sensor, The glucose concentration data is analyzed to determine a measure of blood glucose urgency, wherein the measure of blood glucose urgency is determined at least in part on an evaluation of the variability of the glucose concentration data, and the variability of the glucose concentration data is The rate of change of the glucose concentration data mentioned above, The acceleration of the rate of change of the glucose concentration data, A measure of deviation of one or more normal glucose patterns of the host, and / or A measure of one or more deviations from the predicted glucose concentration of the host or the reference glucose concentration of the host, This includes analyzing and making decisions, The control device's user interface displays the blood glucose urgency scale using non-numerical visual elements, The method involves comparing the aforementioned blood glucose urgency scale with one or more thresholds of blood glucose risk, wherein the one or more thresholds of blood glucose risk are: Physiological conditions that indicate a risk of hypoglycemia, and / or Physiological conditions that indicate a risk of hyperglycemia, Including comparison, Responding to the determination that the blood glucose urgency scale exceeds at least one of the one or more thresholds of blood glucose risk by modifying insulin delivery, wherein modifying insulin delivery is If at least one of the thresholds for blood glucose risk includes a physiological condition indicating a risk of hypoglycemia, generate one or more insulin delivery commands to reduce or withhold insulin delivery, and / or If at least one of the thresholds for the risk of blood glucose includes a physiological condition indicating a risk of hyperglycemia, generate one or more insulin delivery commands to increase insulin delivery. Including responding, The process involves transmitting one or more of the generated insulin delivery commands to the insulin delivery device. A system that executes an action.

Images