Systems and methods for providing alerts optimized for user

Abstract

To provide systems and methods for providing alerts for a user.SOLUTION: Systems and methods provide smart alerts to users, e.g., alerts to users about diabetic states provided only if the alerts make sense, e.g., when the systems can predict or estimate that the users are not yet cognitively aware of their current conditions where the current conditions are diabetic states that deserve attention. Such an alert or alarm is personalized and made particularly effective for that user. Such systems and methods still alert a user when action such as a bolus or temporary basal rate change is necessary, or provide a response to a missed bolus or a need for correction, but do not alert when action is unnecessary, e.g., if the user is estimated or predicted to be cognitively aware of the diabetic state deserving attention, or if corrective action has already been taken.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] INCORPORATION BY REFERENCE OF RELATED APPLICATIONS Any and all priority claims, or any amendments to such priority claims, identified in the Application Data Sheet are incorporated herein by reference under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Application No. 62 / 330,729, filed May 2, 2016. The aforementioned applications are incorporated herein by reference in their entireties and expressly made a part hereof.

[0002] Alerts for users are provided, particularly in the medical field where physiological parameters are monitored. [Background technology]

[0003] Diabetes mellitus is a disease in which the pancreas cannot make enough insulin (Type I or insulin-dependent) and / or insulin is not effective (Type 2 or non-insulin-dependent). In the diabetic state, victims suffer from high glucose, which can lead to a series of physiological disorders related to the deterioration of small blood vessels (e.g., kidney failure, skin ulcers, or bleeding into the vitreous of the eye).

[0004] Traditionally, people with diabetes carry self-monitoring blood glucose (SMBG) monitors, which typically require an uncomfortable finger prick to obtain a blood sample for measurement. Due to the lack of comfort and convenience associated with finger pricks, people with diabetes typically measure their glucose levels only two to four times per day. Unfortunately, the time intervals between measurements can be so far apart that it may be too late for an individual with diabetes to realize they have a hyperglycemic or hypoglycemic condition, sometimes resulting in dangerous side effects. Not only are people with diabetes less likely to take SMBG values ​​in a timely manner, they are also less likely to know if their blood glucose levels are rising (getting higher) or decreasing (getting lower) based on traditional methods. Thus, diabetic patients may be prevented from making educated insulin therapy decisions.

[0005] Another device that some diabetics use to monitor their blood glucose is a continuous analyte sensor. A continuous analyte sensor typically includes a sensor that is placed subcutaneously, transdermally (e.g., transcutaneously), or intravascularly. The sensor measures the concentration of a given analyte in the body and generates a raw signal that is transmitted to electronics associated with the sensor. The raw signal is converted to an output value that is displayed on a display. The output value resulting from the conversion of the raw signal is typically expressed in a form that provides a user with meaningful clinical information, such as glucose expressed in mg / dL.

[0006] In the case where the analyte is glucose and it is a continuous glucose monitor (CGM), some CGMs will trigger various alerts or warnings when the user's glucose values ​​enter a dangerous or undesirable range. For example, many CGMs provide warnings if the user's glucose values ​​stray into the mild hypoglycemia or hyperglycemia range, and provide warnings if the condition becomes more imminent. In some cases, such warnings / alarms use predictive algorithms to determine if the user is approaching a dangerous condition and therefore whether a warning or alarm should be triggered.

[0007] Although useful, such warnings and alerts have problems. For example, users can quickly become accustomed to such warnings and alerts and begin to "turn a deaf ear" or otherwise ignore them. In some cases, users are unnecessarily re-alerted for conditions that the user is already aware of. In many of these cases, "alert fatigue" can set in, causing users to either ignore the warnings or turn them off without giving sufficient thought as to the cause of the warning or potential steps to address.

[0008] Other problems are now described. First, an example of the "high" glucose warning category is given. In the post-meal time frame, users are often annoyed when they receive a hyperglycemic warning after they have eaten and after administering for the meal. Such hyperglycemic warnings can sometimes lead to "piling up" or even administering insulin when insulin is already "working". In such cases, the user is receiving a warning for actions that the user does not need to take or that may cause the user to take unnecessary actions. Often, the response to such post-meal unnecessary warnings is that the user begins to ignore the warnings, sets a higher blood glucose warning threshold (thus preventing the user from using the appropriate threshold as the user's target range boundary), or even turns off the user's hyperglycemic warnings in some cases. Such modifications cause the user to miss future unexpected high glucose levels.

[0009] Unnecessary re-alerts is another example of the hyperglycemic alert problem. In this case, users become annoyed when they receive multiple hyperglycemic alerts for the same glucose event. Such situations are often caused by glucose levels hovering above and below the user's high threshold. In some cases, the user can enable a "snooze" time, which has some effect. However, similar to post-meal alerts, the user does not want to be re-alert for the same hyperglycemic event before the user's set snooze time. The fix for these situations is similar to the one above and involves the user ignoring the alerts or turning off these hyperglycemic alerts, again missing future unexpected high glucose levels.

[0010] Another "hyperglycemia warning" problem includes missed bolus doses. For example, a user often receives a hyperglycemia warning if the user forgets to dose for a meal. This hyperglycemia warning reminds the user to dose, but this is typically too late and does not prevent further rise. Corrections to missed bolus doses include the user setting a lower hyperglycemia warning threshold or setting a rise rate warning. However, such corrections may result in additional false warnings for the user. Additionally, hyperglycemia and rise rate warnings are sometimes not effective or accurate enough to catch missed bolus doses.

[0011] Another "hyperglycemia warning" problem is that certain users, for example those with stricter glucose control goals, want to be alerted when they are close to but below their high threshold for extended periods of time. Such users may be using their hyperglycemia warning threshold against their target zone boundaries, and in such cases, the user may not know how to accurately set or change their hyperglycemia warning threshold.

[0012] Other hyperglycemic warning problems include no change in how users respond to their initial warning settings. Still other hyperglycemic warning problems will be understood.

[0013] Other problems exist in the use of "hypoglycemia warnings." For example, the above-mentioned warning fatigue can lead to distrust of the system. For example, a user may set a higher hypoglycemia warning threshold to give themselves more time to prevent a severe hypoglycemia event. However, this can lead to more frequent warnings and a resultant source of irritation. For example, such a user may receive many warnings for low glucose levels that do not lead to severe glucose lows. While a user would like more warnings for severe glucose lows, frequent hypoglycemia warnings at a higher warning threshold cause distrust of the system.

[0014] Relatedly, false alarms caused by malfunctions such as compression can also cause distrust in the system. Alarm fatigue may cause users to occasionally set lower alarm thresholds, so that they have less time to prevent an emergency glucose hypo. As another modification, users may turn off the hypoglycemia alarm and use the decline rate alarm or the emergency hypoglycemia alarm instead. For example, the decline rate alarm may be set to -2 or -3 mg / dL. As yet another modification, users may turn off their hypoglycemia alarm and rely instead on the emergency hypoglycemia alarm. In many of these cases, the user's reaction does not prevent hypoglycemia.

[0015] Another "hypoglycemia warning" problem is similar to the hyperglycemia warning problem and constitutes the problem of unnecessary re-alarms. That is, users become annoyed when they receive multiple hypoglycemia warnings for the same low glucose event. Often such unnecessary re-alarms are caused by the user's glucose level hovering just above or just below their low threshold. Such a situation can also be caused when the user is above 55 but still below their low threshold. In response to the unnecessary re-alarms, users may sometimes begin to ignore the warnings or turn off their warnings, or may overtreat their condition, e.g., carbohydrate loading (which is often especially problematic at night). However, such corrections cause the user to miss future unexpected low glucose levels.

[0016] Another hypoglycemia warning problem is that a user may set their hypoglycemia warning threshold as the lowest boundary of their target range. Other hypoglycemia warning problems will also be appreciated.

[0017] Prior art in the field has addressed certain warning problems in the following ways.

[0018] In one approach, actionable alerts are provided based on a glycemic urgency indicator, a value more representative of the user's diabetic state than glucose values ​​alone, as disclosed in U.S. Patent Application Publication No. 2015 / 0289821, entitled "GLYCEMIC URGENCY ASSESSMENT AND ALERTS INTEFFACE," filed March 16, 2015. Another publication, U.S. Patent Application Publication No. 2014 / 0118138, entitled "SYSTEMS AND METHODS FOR PROVIDING SENSITIVE AND SPECIFIC ALARMS," granted September 1, 2015 as U.S. Patent No. 9,119,528, discusses generating alerts that may be annoying to the user, but is directed to modifications such as waiting for a specific period of time or using a time delay. In yet another publication, U.S. Patent Application Publication No. 2015 / 0119655, filed Oct. 28, 2014, entitled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES," the user interface is adapted according to certain inputs, e.g., objectives, demographic data, etc. However, there is no disclosure of adapting the alerts themselves. In a further application, U.S. Patent Application Publication No. 2014 / 0012510, filed Mar. 13, 2013, entitled "SYSTEMS AND METHODS FOR LEVERAGING SMARTPHONE FEATURES IN CONTINUOUS GLUCOSE MONITORING," disclosure is provided that, for example, alerts can be silent if the user is in a meeting. This reference discloses varying the timing of alerts, but only as part of a global setting, not in real time. In yet another publication, U.S. Provisional Patent Application No. 62 / 289,825, filed February 1, 2016, entitled "SYSTEM AND METHOD FOR DECISION SUPPORT USING LIFESTYLE FACTORS," feedback is provided to users for decision support purposes, for example, informing users of something that may be useful to them and their treatment.

[0019] All of the above cited applications are owned by the assignee of the present application and are hereby incorporated by reference in their entireties.

[0020] This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to aid in determining the scope of the claimed subject matter, nor is it to be considered as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems discussed above. [Prior art documents] [Patent documents]

[0021] [Patent Document 1] US Patent Application Publication No. 2015 / 0289821 [Patent Document 2] US Patent Application Publication No. 2014 / 0118138 (US Pat. No. 9,119,528) [Patent Document 3] US Patent Application Publication No. 2015 / 0119655 [Patent Document 4] US Patent Application Publication No. 2014 / 0012510 [Patent Document 5] U.S. Provisional Patent Application No. 62 / 289825 [Patent Document 6] U.S. Patent No. 6,001,067 [Patent Document 7] US Patent Application Publication No. 2011 / 0027127 [Patent Document 8] US Patent Application Publication No. 2006 / 0020187 [Patent Document 9] US Patent Application Publication No. 2009 / 0137887 [Patent Document 10] US Patent Application Publication No. 2007 / 0027385 [Patent Document 11] U.S. Patent Application No. 14 / 874188 [Patent Document 12] US Patent Application Publication No. 2013 / 0035575 [Patent Document 13] U.S. Patent No. 8,844,007 [Patent Document 14] US Patent Application Publication No. 2013 / 0078912 [Patent Document 15] US Patent Application Publication No. 2014 / 0273821 [Patent Document 16] US Patent Application Publication No. 2015 / 0123810 [Patent Document 17] U.S. Patent Application No. 15 / 001756 [Patent Document 18] U.S. Provisional Patent Application No. 62 / 271880 [Patent Document 19] US Patent Application Publication No. 2013 / 0325352 [Patent Document 20] US Patent Application Publication No. 2005 / 0027463 [Patent Document 21] U.S. Patent Application Serial No. 11 / 543396 [Patent Document 22] U.S. Patent Application No. 11 / 691,426 [Patent Document 23] U.S. Patent Application No. 11 / 675,063 [Patent Document 24] U.S. Patent No. 6,565,509 [Patent Document 25] U.S. Patent No. 6,579,690 [Patent Document 26] U.S. Pat. No. 6,484,046 [Patent Document 27] U.S. Patent No. 6,512,936 [Patent Document 28] U.S. Patent No. 6,477,395 [Patent Document 29] U.S. Patent No. 6,424,847 Summary of the Invention [Means for solving the problem]

[0022] Systems and methods according to the present principles meet the above needs in several ways. In particular, systems and methods according to the present principles only alert the user when it makes sense to do so (e.g., only alert the user when the system can predict or presume that the user is not yet cognitively aware of his / her current condition, e.g., a particular current condition is a diabetic condition that merits attention). In this way, the warning or alert is personalized and specifically relevant to the user. Such systems and methods still alert the user when action is required, e.g., when a bolus dose or temporary basal rate changes, or provide the need for action or correction for a missed bolus dose, but do not alert when action is not required, e.g., when the user is presumed or predicted to already be cognitively aware of a diabetic condition that merits attention, or when corrective action has already been taken.

[0023] In a first aspect, a non-transitory computer-readable medium is provided, the non-transitory computer-readable medium comprising instructions for causing a computing environment to perform a method of dynamically adjusting or tailoring a user alert based on a determination of cognitive awareness, thereby providing data regarding treatment of a diabetic condition meriting attention, the method including: (a) identifying a current or future diabetic condition meriting attention, the identification being based at least in part on a glucose concentration value; (b) estimating or predicting a user's cognitive awareness of the identified current or future diabetic condition meriting attention; and (c) if the estimation or prediction results in the user being cognitively unaware of the identified current or future diabetic condition meriting attention, alerting the user with a user prompt on a user interface of the monitoring device, the user prompt indicating the diabetic condition meriting attention; and (d) whereby the user is alerted to the diabetic condition meriting attention if and only if the user is unaware of the diabetic condition meriting attention and notification is enabled for the user.

[0024] Implementation of aspects and embodiments may include one or more of the following: Alerts may be optimized for the patient's cognitive awareness, resulting in fewer alerts than would otherwise be provided without consideration of the user's cognitive awareness. The monitoring device may be a smartphone, a smartwatch, a dedicated monitoring device, or a tablet computer. In systems and methods according to the present principles, excessive, repetitive, or nuisance prompts are minimized or avoided. In systems and methods according to the present principles, a user may build trust when the system is optimized for the user or only alerts about valid notifications. Estimating or predicting the user's cognitive awareness may include determining whether the identified current or future diabetic condition worthy of attention includes an abnormal glucose trace. An abnormal glucose trace may include an abnormal pattern or an abnormal glucose response.

[0025] The estimation or prediction of the user's cognitive awareness may include determining whether the user has previously treated a similar identified attention-worthy diabetic condition by taking an action without a user prompt. The action may be administering a medication, eating a meal, or exercising. The estimation or prediction of the user's cognitive awareness may include determining whether the user has entered meal or bolus dose data or requested a bolus dose calculation. The estimation or prediction of the user's cognitive awareness may include determining whether the user's behavior is consistent with the cognitive awareness. The estimation or prediction of the user's cognitive awareness may include receiving a user input and basing the estimation or prediction at least in part on the received input. The estimation or prediction of the user's cognitive awareness may include analyzing historical data of the user's glucose values ​​over time.

[0026] The steps of identifying and estimating or predicting are repeated until the user is estimated or predicted to be cognitively aware of the identified attention-worthy diabetic condition, and then a step of alerting the user with a user prompt is performed. Estimating or predicting the user's cognitive awareness may include receiving data from an application or website via a suitable API. The estimation or prediction may be based on location data, i.e., GPS data. The location data may be the user's location data or the location data of the user's followers.

[0027] The estimation or prediction of the user's cognitive awareness may be based at least in part on one or more of demographic data, data related to behavioral or contextual information, data related to the user's life goals, data related to user privacy settings, or combinations thereof. The estimation or prediction of the user's cognitive awareness may be based at least in part on real-time data, which may include one or more of data related to a GPS application of the monitoring device, data related to an accelerometer of the monitoring device, data related to behavioral or contextual information, data related to the location of the user's followers, data related to the user's metabolic rate, data related to the user's glycemic urgency index, heart rate data, sweat content data, data related to the user's wearable sensors, insulin data, or combinations thereof.

[0028] The estimation or prediction of the user's cognitive awareness may include recognizing one or more individualized patterns associated with the user. The individualized patterns may correspond to characteristic analyte concentration signal trace envelopes occurring before or after an event. The event may be associated with a meal, exercise, or sleep. The determination may be a determination that the user is not cognitively aware of whether the current signal trace is outside of the characteristic analyte concentration signal trace envelope.

[0029] The method may further include indicating a confidence level associated with the user prompt. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition that merits attention, the method may further include immediately displaying the user prompt. The estimation or prediction may be further based on location information of the user, where the location information indicates that the user is within a predetermined threshold proximity of a grocery store or restaurant. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition that merits attention, the method may further include alerting the user with a user prompt after a time delay, the duration of the time delay being based at least on the identified diabetic condition that merits attention and the glucose concentration value and / or the rate of change of the glucose concentration value.

[0030] The user prompt may include a query for the user to input data. The query may request data to be input by the user regarding dosing, diet, or exercise. If the data from the user interface or the data from the accelerometer associated with the monitoring device determines that the user is ignoring the user prompt, and if the user prompt does not correspond to a dangerous condition, the method may further include storing information that the user ignores the user prompt under the previous condition, and using the stored information as part of a subsequent estimation or prediction step.

[0031] Identifying a diabetic condition that merits current or future attention may include determining a clinical value of glucose concentration and / or a rate of change of glucose and / or a glycemic urgency index value. Identifying a diabetic condition that merits current or future attention may include measuring a glucose signal signature, comparing the measured signature to a plurality of binned signatures, and classifying the diabetic condition that merits attention into one of the plurality of bins based on the comparison. Identifying a diabetic condition that merits current or future attention may include determining one or more time-based trends in glucose concentration values ​​and basing the identified condition on the determined trends. A trend may correspond to whether the glucose concentration value is wandering within a range or rising or falling, where wandering corresponds to staying within a given range for a period of more than 5 minutes, or more than 10 minutes, or more than 15 minutes, or more than 30 minutes. A fuzzy boundary may be used to define the range.

[0032] The method may further include sending an indication of the diabetic condition that merits attention to the drug pump. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition that merits attention, the method may further include activating the drug pump to cause a drug bolus delivery. The drug bolus delivery may be a meal bolus of insulin. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition that merits attention, the method may further include activating the drug pump to change the basal rate. The drug may be insulin. It may further include determining whether the drug pump can fully or partially treat the diabetic condition that merits attention, and if so, not alerting the user or changing the user prompt, respectively, compared to when the drug pump cannot treat the diabetic condition. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition that merits attention, the method may further include determining when to alert the user with a user prompt. The user prompt, if displayed, may include a color or an arrow instead of or in addition to the glucose concentration value. The user prompt, if displayed, may include a prediction of the glucose concentration value. The user prompt, when displayed, may include an audible indicator, where the volume of the audible indicator is automatically adjusted to ambient noise measured by the monitoring device or a device in signal communication with the monitoring device, where adjusting to ambient noise may include increasing the volume of the audible indicator relative to the ambient noise until a threshold level of signal to noise ratio is reached. The user prompt may be associated with a diabetic condition meriting attention occurring during a period in which the user has a hypoglycemic urgency index.

[0033] If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the method may further include alerting the user with a user prompt after a delay based on the identified diabetic condition meriting attention and the glucose concentration value and / or rate of change of the glucose concentration value, rather than based on duration.If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the method may further include alerting the user with a user prompt after a delay based on individualized patterns learned by the monitoring device, rather than based on duration.

[0034] The identified diabetic condition meriting attention may correspond to an abnormal glucose response or an abnormal pattern, where the abnormal response or abnormal pattern is learned by the monitoring device and not by user input. The user prompt may be displayed on a pre-designed user interface, rather than on an adapted user interface, with dynamic timing. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the method further includes immediately alerting the user with a user prompt, regardless of instructions received from other monitoring device applications not to alert the user with a user prompt. If the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the method further includes immediately alerting the user with a user prompt, regardless of instructions based on other user-entered data or settings not to alert the user with a user prompt. The estimation or prediction of whether the user is cognitively aware of the diabetic condition meriting attention may be based at least in part on real-time data and not entirely on retrospective data.

[0035] In a second aspect, a system is provided for providing smart alerts corresponding to diabetic conditions meriting a user's attention, the system including a CGM application running on a mobile device configured to receive data from a sensor at least periodically or intermittently and to calibrate and display glucose concentration data in clinical units, and a smart alert application running on the mobile device either as a subroutine within the CGM application or as a parallel process to the CGM application and receiving data from the CGM application, the smart alert application configured to perform a method included in the medium described in the claims.

[0036] In a third aspect, a non-transitory computer-readable medium including instructions for causing a computing environment to perform a method for safely reducing alerts to a user for a diabetic condition requiring attention, the method including: (a) identifying a current or future diabetic condition meriting attention, the identification being based at least in part on a glucose concentration value; (b) determining whether the identified diabetic condition meriting attention is abnormal for the user; and (c) if the determination results in the identified diabetic condition being abnormal for the user, alerting the user with a user prompt on an interface of the user monitoring device, the user prompt indicating the diabetic condition meriting attention; and (d) whereby the user is notified of the diabetic condition meriting attention only if the identified diabetic condition is abnormal for the user.

[0037] Implementation of the aspects and embodiments may include one or more of the following: Determining whether the identified attention-worthy diabetic condition is abnormal for the user may include determining whether the identified attention-worthy diabetic condition ....

[0038] In a fourth aspect, a non-transitory computer readable medium is provided that includes instructions for causing a computing environment to perform a method of prompting a user about a diabetic condition meriting attention, the computing environment being in signal communication with a medication delivery device, the user prompts being at least partially reduced in number to optimize effectiveness to the user, the user prompts providing data related to treatment of the diabetic condition meriting attention, the method including the steps of: (a) identifying a current or future diabetic condition meriting attention, the identification being based at least in part on a glucose concentration value; (b) making a first estimate or prediction of a user's cognitive awareness of the identified current or future diabetic condition meriting attention; and (c) providing a result of the first estimate or prediction that indicates the user's cognitive awareness of the identified current or future diabetic condition meriting attention. (d) if the result of the second estimation or prediction is that the drug delivery device is unaware of the identified current or future diabetic condition meriting attention, alerting the user with a user prompt on a user interface of the monitoring device, the user prompt indicating the diabetic condition meriting attention; (e) whereby the user is notified of the diabetic condition meriting attention if and only if both the user and the drug delivery device are unaware of the diabetic condition meriting attention and notification is enabled for the user.

[0039] Implementation of the aspects and embodiments may include one or more of the following: The method may further include determining whether the drug delivery device is capable of treating the identified diabetic condition that merits current or future attention, and alerting the user with a user prompt if the determination results in the drug delivery device being unable to treat the identified diabetic condition. The current or future diabetic condition may include hypoglycemia, and the drug delivery device may be an insulin delivery device, and the method may further include ceasing or reducing activity of the insulin delivery device based on the diabetic condition of hypoglycemia. The ceasing or reducing activity may occur sooner if the user is cognitively aware of the hypoglycemia. Making the first estimate or prediction may be based at least in part on an interaction between the drug delivery device and the user.

[0040] In further aspects and embodiments, the above method features of the various aspects are described in terms of systems as in the various aspects. Any of the features of the embodiments of any of the aspects, including but not limited to any of the embodiments of any of the first to fourth aspects mentioned above, can be applied to all other aspects and embodiments disclosed herein, including but not limited to any of the embodiments of any of the first to fourth aspects mentioned above. Furthermore, any of the features of the embodiments of the various aspects, including but not limited to any of the embodiments of any of the first to fourth aspects mentioned above, can be independently combined in any manner, partially or wholly, with other embodiments described herein, e.g., one, two, three or more embodiments can be combined in whole or in part. Furthermore, any of the features of the embodiments of the various aspects, including but not limited to any of the embodiments of any of the first to fourth aspects mentioned above, can be made optional with respect to other aspects or embodiments. Any aspect or embodiment of the method may be performed by a system or apparatus of another aspect or embodiment, and any aspect or embodiment of the system or apparatus may be configured to perform the method of another aspect or embodiment, including, but not limited to, any embodiment of any of the first to fourth aspects referred to above.

[0041] People with diabetes face many problems in controlling their glucose due to the complex interactions between food, insulin, exercise, stress, activity, and other physiological and environmental conditions. There is considerable variability in how different conditions affect different individuals and what measures are effective for them, so the established principles of glucose management are sometimes incompatible, and even providing warnings or alerts is problematic, as described above, because different measures are required between different individuals for different situations. Therefore, providing customized warnings and alerts to users, as well as anticipating situations that the user is not cognitively aware of, is extremely beneficial and desirable for users.

[0042] Thus, systems and methods in accordance with the present principles provide techniques for alerting and / or warning a user regarding diabetic situations or conditions that merit the user's attention, but generally only when the system determines, e.g., estimates or predicts, that the user is not yet cognitively aware of those situations. As a result, such systems and methods in accordance with the present principles reduce the uncertainty typically associated with diabetes and improve quality of life.

[0043] Advantages of certain aspects or embodiments include one or more of the following: In particular, "smart alerts" are provided to advantageously notify a user of a diabetic condition that would otherwise be cognitively unaware of the diabetic condition. Thus, such smart alerts do not frustrate the user because they occur only when necessary and not when they are not (e.g., the smart alert feature does not alert the user when the user has administered the proper amount of insulin at the proper time for a meal). Such smart alerts alert the user of dangerous or emergency conditions more efficiently than prior art alerts, resulting in greater certainty and reliability. Such "smart" alerts further avoid the problem of alert fatigue. Specifically, alert fatigue is common with threshold-based alert algorithms, as CGM applications running on smartphones have not previously been able to quantify the cognitive state of the user. In the embodiments described herein, cognitive state data is inferred by converting physiological and non-physiological data into an estimate or prediction of the user's cognitive state, resulting in smarter alerts and reduced alert fatigue. Other advantages will be understood from the following description, including the drawings and claims.

[0044] This Summary is provided to introduce a selection of concepts in a simplified form. The concepts are further described in the Detailed Description. Elements or steps other than those described in this Summary are contemplated, and no element or step is necessarily required. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended for use as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all of the disadvantages noted in any part of this disclosure.

[0045] The present embodiments will now be discussed in detail with an emphasis on highlighting the advantageous features. These embodiments depict, for illustrative purposes only, novel and non-obvious systems and methods in accordance with the present principles as shown in the accompanying drawings, which include the following figures, in which like numerals indicate like parts: [Brief description of the drawings]

[0046] [Figure 1] 1 is a schematic diagram of a system according to the present principles; [Diagram 2] 1 is a flow chart of a first method in accordance with the present principles. [Diagram 3] 1A-1C are schematic illustrations of how a smart alert application may be implemented or instantiated in accordance with the present principles; [Figure 4] 4 is a flow chart of a second method in accordance with the present principles. [Diagram 5] FIG. 2 is a logic diagram of the inputs to the Smart Alert function or application and the resulting Smart Alert outputs. [Figure 6] 11 is a flow chart of a third method in accordance with the present principles. [Figure 7] Shown is a smart alert (FIG. 7) and a glucose trace with the smart alert appearing at the top. [Figure 8]Shown is a smart alert (FIG. 7) and a glucose trace with the smart alert appearing at the top. [Figure 9] 13 illustrates additional implementations of smart alert output on a user interface in accordance with the present principles. [Figure 10] 13 illustrates additional implementations of smart alert output on a user interface in accordance with the present principles. [Figure 11] 13 illustrates additional implementations of smart alert output on a user interface in accordance with the present principles. [Figure 12] 13 illustrates additional implementations of smart alert output on a user interface in accordance with the present principles. [Figure 13] 13 illustrates additional implementations of smart alert output on a user interface in accordance with the present principles. [Figure 14] 13 illustrates additional implementations of smart alert output on a user interface in accordance with the present principles. [Figure 15] 13 illustrates yet another additional implementation of smart alert output on a user interface in accordance with the present principles. [Figure 16] 13 illustrates yet another additional implementation of smart alert output on a user interface in accordance with the present principles. [Figure 17] 13 illustrates yet another additional implementation of smart alert output on a user interface in accordance with the present principles. [Figure 18] 13 illustrates additional implementations of smart alerts and respective glucose traces overlaid with the smart alerts. [Figure 19] 13 illustrates additional implementations of smart alerts and respective glucose traces overlaid with the smart alerts. [Figure 20] 13 illustrates additional implementations of smart alerts and respective glucose traces overlaid with the smart alerts. [Figure 21] 13 illustrates additional implementations of smart alerts and respective glucose traces overlaid with the smart alerts. [Figure 22]1 illustrates the time progression of a smart alert in accordance with the present principles. [Figure 23] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Figure 24] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Diagram 25] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Figure 26] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Figure 27] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Figure 28] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Figure 29] 1 illustrates the time progression of a smart alert in accordance with the present principles. [Diagram 30] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 31] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 32] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 33] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 34] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 35] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 36] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Figure 37] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Figure 38] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Figure 39]1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 40] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 41] 1 illustrates an example implementation of smart alerts as part of the lock screen on a smartphone. [Diagram 42] 1 is a schematic diagram of a system in accordance with the present principles incorporating data from a delivery device. [Diagram 43] 11 is a flow chart of a fourth method in accordance with the present principles. [Diagram 44] 11 is a flow chart of a fifth method in accordance with the present principles. [Diagram 45] 1 is a schematic diagram of a system according to the present principles; [Diagram 46] FIG. 2 is a more detailed schematic diagram of the sensor electronics module. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0047] Like numbers refer to like elements throughout and elements are not to scale unless otherwise noted.

[0048] definition To facilitate understanding of the preferred embodiments, several terms are defined below.

[0049] As used herein, the term "analyte" generally refers to, but is not limited to, a substance or chemical component in a biological fluid (e.g., blood, interstitial fluid, cerebrospinal fluid, lymphatic fluid, or urine) that can be analyzed. Analytes can include naturally occurring substances, man-made substances, metabolic products, and / or reaction products. In some embodiments, the analyte for measurement by the sensor head, devices, and methods is glucose. However, other analytes are contemplated as well, including but not limited to acarboxyprothrombin, acylcarnitines, adenine phosphoribosyltransferase, adenosine deaminase, albumin, α-fetoprotein, amino acid profile (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan), andrenostenedione, antipyrine, arabinitol enantiomers, arginase, benzoylecgonine (cocaine), biotinidase, biopterin, c-reactive protein, carnitine, carnosinase, CD4, ceruloplasmin, chenodeoxycholic acid, chloroquine, cholesterol, cholinesterase, conjugated 1-β hydroxycholic acid, cortisol, creatine kinase, creatine kinase MM isoenzyme, cyclosporin A, d-penicillamine, de-ethylchloroquine, dehyd. Droepiandrosterone sulfate, DNA (acetylation polymorphism, alcohol dehydrogenase, alpha 1-antitrypsin, cystic fibrosis, Duchenne / Becker muscular dystrophy, analyte-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D Punjab, beta-thalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber's hereditary optic neuropathy , MCAD, RNA, PKU, Plasmodium vivax, sex differentiation, 21-deoxycortisol), desbutylhalofantrine, dihydropteridine reductase, diphtheria / tetanus antitoxin, erythrocyte arginase, erythrocyte protoporphyrin, esterase D, fatty acids / acylglycines, free β-human chorionic gonadotropin, free erythrocyte porphyrin, free thyroxine (FT4), free tri-iodothyronine (FT3), fumarylacetoacetase,Galactose / gal-1-phosphate, galactose-1-phosphate uridyltransferase, gentamicin, analyte-6-phosphate dehydrogenase, glutathione, glutathione peroxidase, glycocholate, glycosylated hemoglobin, halofantrine, hemoglobin variants, hexosaminidase A, human erythrocyte carbonic anhydrase I, 17-α-hydroxyprogesterone, hypoxanthine phosphoribosyltransferase, immunoreactive trypsin, lactate, lead, lipoproteins (( a), B / A-1, β), lysozyme, mefloquine, netilmicin, phenobarbitone, phenytoin, phytanic acid / pristanic acid, progesterone, prolactin, prolidase, purine nucleoside phosphorylase, kinin, inverted tri-iodothyronine (rT3), selenium, serum pancreatic lipase, sisomicin, somatomedin C, specific antibodies (adenovirus, antinuclear antibody, anti-zeta antibody, arbovirus, Aujeszky's disease virus, dengue virus, guinea worm, tapeworm, entemozolomia granulosus, ameba histolytica, enterovirus, rovirus, Giardia lamblia, Helicobacter pylori, Hepatitis B virus, Herpes virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, Leptospira, Measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, Myoglobin, Onchocerca volvulus, Parainfluenza virus, Plasmodium falciparum, Poliovirus, Pseudomonas aeruginosa, Respiratory exanthema virus, Rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Kluy Examples of analytes include, but are not limited to, trypanosoma / rangellum, vesicular stomatitis virus, filariasis bancrofti, yellow fever virus), specific antigens (hepatitis B virus, HIV-1), succinylacetone, sulfadoxine, theophylline, thyrotropin (TSH), thyroxine (T4), thyroxine-binding globulin, trace elements, transferrin, UDP-galactose-4-epimerase, urea, uroporphyrinogen I synthase, vitamin A, leukocytes, and zinc protoporphyrin. Salts, sugars, proteins, fats, vitamins, and hormones that occur naturally in blood or interstitial fluids may also constitute analytes in certain embodiments. Analytes, such as metabolites, hormones, antigens, antibodies, etc., may be used to detect analytes, such as:They may be naturally present in biological fluids, or may be used to administer analytes, such as contrast agents for diagnostic imaging, radioisotopes, chemical agents, fluorocarbon-based artificial blood, or drugs such as insulin, ethanol, cannabis (marijuana, tetrahydrocannabinol, hashish), inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons), cocaine (crack cocaine), stimulants (amphetamines, methamphetamines, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine), depressants (barbiturates, methaqualone, tranquilizers, such as Valium, Librium, Milto Drugs or pharmaceutical compositions may be introduced into the body, including, but not limited to, drugs such as benzodiazepines, benzocaine, benzoylcholine ... For example, analytes such as neurochemicals and other chemicals produced in the body, such as ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5-hydroxytryptamine (5HT), and 5-hydroxyindoleacetic acid (FHIAA), may be analyzed.

[0050] As used herein, the term "calibration" generally refers to the process of determining the relationship between sensor data and corresponding reference data, with or without the use of reference data in real time, which may be used to convert the sensor data into a meaningful value substantially equivalent to the reference data. In some embodiments, i.e., in continuous analyte sensors, the calibration may be updated or recalibrated over time (at the factory, in real time, and / or retroactively) as changes occur in the relationship between the sensor data and the reference data, e.g., due to changes in sensitivity, baseline, transport, metabolism, etc.

[0051] As used herein, the terms "calibrated data" and "calibrated data stream" generally relate to data that has been converted from a raw state (e.g., digital or analog) to another state using a function, e.g., a conversion function, to provide a meaningful value to a user, but is not limited to such data.

[0052] As used herein, the term "algorithm" generally relates to a computational process (e.g., program) involved in transforming information from one state to another, for example, but not limited to, by using computer processing. In implementations described herein, algorithms may perform decision support applications / functions that take inputs from sensors, computer applications, or user inputs and transform them into outputs that are rendered to a user on a user interface or other device.

[0053] As used herein, the term "sensor" generally refers to, but is not limited to, a component or region of a device that is capable of quantifying an analyte.

[0054] The term "glucose sensor" generally refers to, but is not limited to, any mechanism (e.g., enzymatic or non-enzymatic) that can quantify glucose. For example, some embodiments utilize a membrane containing glucose oxidase that catalyzes the conversion of oxygen and glucose to hydrogen peroxide and gluconate, as exemplified by the following chemical reaction: Glucose + O2 → Gluconate + H2O2

[0055] Because there is a proportional change in the co-reactant O2 and product HO2, electrodes can be used to monitor the current change of either the co-reactant or product to determine the glucose concentration.

[0056] As used herein, the terms "operably connected" and "operably linked" generally refer to, but are not limited to, one or more components being linked to another component(s) in a manner that allows for the transmission of a signal between the components. For example, one or more electrodes may be used to detect the amount of glucose in a sample and convert that information into a signal, e.g., an electrical or electromagnetic signal, which may then be transmitted to an electronic circuit. In this case, the electrodes are "operably linked" to the electronic circuit. These terms are broad enough to include wireless connections.

[0057] As used herein, the term "variation" generally relates to, but is not limited to, the amount of deviation or variation from a point, line, or data set. In one embodiment, an estimated analyte value may have a variability that includes a range of values ​​other than the estimated analyte value, for example, representing a range of possibilities based on known physiological patterns.

[0058] As used herein, the terms "physiological parameters" and "physiological boundaries" generally refer to, but are not limited to, parameters obtained from continuous studies of physiological data in humans and / or animals. For example, a maximum sustained rate of change of glucose of about 4-5 mg / dL / min in humans and a maximum sustained rate of change of glucose of about 0.1-0.2 mg / dL / min in humans.2 The maximum acceleration of the rate of change of is considered the physiologically possible limit, and values ​​outside these limits are considered non-physiological. As another example, the rate of change of glucose is lowest at the maximum and minimum values ​​of the daily glucose range, which are areas of greatest risk in patient care, and therefore the physiologically possible rate of change may be set to the local maximum and minimum values ​​based on a continuous study of the glucose data. As a further example, it has been found that the best solution for the shape of the curve at any point along the glucose signal data stream over a certain period of time (e.g., about 20-30 minutes) is a straight line, which may be used to set the physiological limits. These terms are broad enough to include physiological parameters for any analyte.

[0059] As used herein, the term "measured analyte value" generally refers to, but is not limited to, an analyte value or set of analyte values ​​during the period in which the analyte data was measured by an analyte sensor. The term is broad enough to include data from an analyte sensor before or after data processing (e.g., data smoothing, calibration, etc.) in the sensor and / or receiver.

[0060] As used herein, the term "estimated analyte value" generally relates to, but is not limited to, an analyte value or set of analyte values ​​that are algorithmically extrapolated from a measured analyte value.

[0061] As used herein, the following abbreviations apply: Eq and Eqs (equivalents), mEq (milliequivalents), M (mole), mM (millimolar), μM (micromolar), N (normal), mol (mole), mmol (millimolar), μmol (micromolar), nmol (nanomole), g (gram), mg (milligram), μg (microgram), Kg (kilogram), L (liter), mL (milliliter), dL (deciliter), μL (microliter), cm (centimeter), mm (millimeter), μm (micrometer), nm (nanometer), h and hr (hours), min (minutes), and sec. (seconds), °C (degrees Celsius).

[0062] As used herein, the phrase "continuous glucose sensor" generally relates to a device that continuously or continuously measures glucose concentration in a bodily fluid (e.g., blood, plasma, interstitial fluid, etc.) over time intervals ranging, for example, but not limited to, fractions of a second up to, for example, 1, 2, or 5 minutes or more.

[0063] As used herein, the phrase "continuous glucose sensing" or "continuous glucose monitoring" generally refers to, but is not limited to, monitoring of the glucose concentration of a host's bodily fluid (e.g., blood, serum, plasma, extracellular fluid, tears, etc.) over a continuous or continuous period of time, for example, at time intervals ranging up to 1, 2, or 5 minutes or more. In an 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.

[0064] As used herein, the term "substantially" generally refers to the majority, but not necessarily entirely, as specified, which may include, but is not limited to, an amount greater than 50 percent, an amount greater than 60 percent, an amount greater than 70 percent, an amount greater than 80 percent, an amount greater than 90 percent, or more.

[0065] As used herein, the terms "processor" and "processor module" generally relate to, but are not limited to, computer systems, state machines, processors, and the like designed to perform arithmetic or logical operations using logic circuitry that corresponds to and processes the basic instructions that run a computer. In some embodiments, the terms may include associated ROM and / or RAM.

[0066] As used herein, the terms "decision support application" and "decision support application / function" generally relate to, but are not limited to, algorithms that use sensor data and / or other data, such as user input data, derived data, or data from other applications or sensors, to provide user prompts on a display and / or instructions to a mechanical device.

[0067] As used herein, the term "separate" generally refers to, but is not limited to, parameters and / or variables that are independent and not dependent on one another. Conversely, as used herein, the term "related" with respect to variables or parameters generally refers to, but is not limited to, parameters and / or variables that are dependent on one another in some way and derivable from one another. For example, a sensor signal time derivative is related to a sensor signal, while a user's gender and current analyte concentration are considered separate. However, it should be noted here that multiple parameters used in a decision support application / function may be related to a single action or event (e.g., the parameters may relate to the timing and duration of a movement). The term "independent" is used in the same way as "separate," and similarly "dependent" is used in the same way as "related," but "independent" may also refer to variables used in a function, whose dependency is based on an underlying independent variable.

[0068] As used herein, the term "insulin sensitivity" generally relates to, but is not limited to, the relationship between how much insulin needs to be produced to accumulate a certain amount of glucose. This is a physiological measure that everyone has, and is not limited to diabetes. Physiological measures change throughout a person's day and can be influenced by, for example, hormones, activity, and diet. Physiological measures can further change throughout a person's life and can be influenced by, for example, illness, weight, obesity, etc. This is a global measure, such as weight, blood pressure, heart rate, etc. There are healthy and unhealthy ranges for insulin sensitivity. In diabetes management, users generally need to know their insulin sensitivity factor (ISF) when making decisions regarding bolus dosing. The term "ISF" is sometimes used interchangeably with "correction factor" (CF). For example, a typical calculation that a user may need to make may be, for example, "If my blood sugar is 100 mg / dL too high, how many units of insulin do I need to take to correct that high blood sugar and lower my blood sugar by 100 mg / dL?" Many users use a default CF of 1:50, meaning that one unit of insulin reduces blood glucose by 50 mg / dL. Determining insulin sensitivity, as well as other types of sensitivity determinations, will be discussed in more detail below, but it should be noted here that knowledge of insulin sensitivity may be based on, for example, data from a CGM, activity monitor, and insulin pump data, real-time analysis of the sensors, as well as data from retrospective analysis of those sensors, and data from, for example, an electronic health record. Other factors that may be related to insulin sensitivity or ISF may include correlation of time, pain, and / or exercise; heart rate variability, stroke volume, other cardiovascular health related to metabolic issues; insulin delivery capacity; body temperature; insulin type based on insulin sensitivity scale, profile, peaks, time between peaks; air pressure (i.e., "airplane mode" may be an input); whatever activity most impacts the patient or user; etc.

[0069] As used herein, the term "insulin resistance" generally refers to, but is not limited to, a medical condition in which cells in the human body are unable to properly use insulin for the normal process of cells transporting glucose or other metabolites from the bloodstream.Insulin resistance reduces insulin sensitivity.Everyone has insulin sensitivity, but only certain people suffer from having insulin resistance.

[0070] The term "lifestyle factors" generally refers to, but is not limited to, quantitative or qualitative (but somehow convertible to quantitative) parameters that are generally not directly measured by a physiological sensor but are relevant to disease management. In some cases, "lifestyle factors" relate to trends or recurring events that, although not critical, systems and methods according to the present principles may determine or use in providing therapy prompts to a user or modifying or altering therapy prompts to a user. However, trend information does not necessarily correspond to a pattern, although some patterns do constitute trend information. In some implementations, lifestyle factors may be identical to the correlative parameters discussed elsewhere. Lifestyle factors (also referred to as "lifestyle context") may relate to certain quantities that are physiological, e.g., insulin sensitivity, but may also relate to more external parameters such as sleep sensitivity, diet sensitivity, exercise sensitivity, etc. In other words, lifestyle factors are generally quantitatively determinable, but in most cases are not directly measured by a sensor.

[0071] The terms "state" and "state model" generally refer to data structures useful for modeling a patient, for example, but not limited to, for purposes of decision support or smart alerts. In general, a patient's state model is expected to meet one of multiple states depending on various lifestyle and clinical factors. As a specific example, a patient's state may correspond to a current insulin sensitivity profile. The multiple states or state models may then be used in combination with real-time inputs, such as time, calendar, CGM glucose values, rate of change, etc., to provide a user with therapy prompts to assist in therapeutic decision making. In one implementation, several diabetes decision-making states are defined by one or more strongly correlated parameters, which may be lifestyle parameters and may be selected by a user through a user interface or may be learned over time by machine learning and / or cloud analytics.

[0072] The term "diabetic condition meriting attention" generally refers to a biological condition of a diabetic user for which it is desirable to take action. For example, a condition of hypoglycemia or hyperglycemia is a diabetic condition meriting attention. If such a condition is imminent or likely to occur, but has not yet occurred, the user is also considered to be in a diabetic condition meriting attention. A diabetic condition meriting attention may vary in its urgency, but generally refers to a condition of a user for which action is presumable or determinable, beneficial to the user, and generally leads the user toward a state of normoglycemia or toward a target range of glucose values, e.g., the center of the target range corresponding to normoglycemia.

[0073] Exemplary embodiments disclosed herein relate to the use of glucose sensors to measure a substance indicative of the concentration or presence of glucose or another analyte. In some embodiments, the glucose sensor is a continuous device, such as a subcutaneous, transdermal, transcutaneous, non-invasive, intraocular, and / or intravascular (e.g., intravenous) device. In some embodiments, the device may analyze multiple intermittent blood samples. These glucose sensors may use any method of glucose measurement, including enzymatic, chemical, physical, electrochemical, optical, photochemical, fluorescent, spectrophotometric, spectroscopic (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), polarized light, calorimetric, iontophoretic, radiative, etc.

[0074] A glucose sensor may provide a data stream indicative of 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 typically a raw data signal that is used to provide a useful value of the analyte to a user, such as a patient or health care professional (HCP, e.g., doctor, physician, nurse, caregiver) who may be using the sensor.

[0075] Although much of the description and examples are drawn to a glucose sensor capable of measuring the concentration of a glucose analyte in a host, the systems and methods of the embodiments may be applied to any measurable analyte. Some exemplary embodiments described below utilize an implantable glucose sensor. However, it should be understood that the devices and methods described herein may be applied to any device capable of detecting the concentration of an analyte and providing an output signal representative of the concentration of the analyte.

[0076] In some embodiments, the analyte sensor is an implantable glucose sensor, such as the sensors described with reference to U.S. Patent Application Publication No. 6,001,067 and U.S. Patent Application Publication No. 2011 / 0027127. In some embodiments, the analyte sensor is a transcutaneous glucose sensor, such as the sensors described with reference to U.S. Patent Application Publication No. 2006 / 0020187-A1. In yet other embodiments, the analyte sensor is a dual electrode analyte sensor, such as the sensors described with reference to U.S. Patent Application Publication No. 2009 / 0137887-A1. In still other embodiments, the sensor is configured to be implanted in a host blood vessel or outside the body, such as the sensors described in U.S. Patent Application Publication No. 2007 / 0027385-A1. These patents and references are incorporated herein by reference in their entireties.

[0077] The following description and examples describe the present embodiments with reference to the drawings, in which reference numerals indicate elements of the present embodiments, and which are reproduced below in connection with a discussion of corresponding drawing features.

[0078] Systems and methods according to the present principles provide an approach to incorporating "smart alerts" within analyte monitoring systems, and specifically continuous glucose monitoring systems. In one implementation, smart alerts may generally be provided by their own application or algorithm running in parallel with a CGM application. In another implementation, smart alerts may be implemented by additional programs / instructions added to an existing application, e.g., a CGM application. For this reason, smart alerts are generally referred to herein as smart alert applications / functions.

[0079] Certain exemplary embodiments are shown in FIG. 1. In this figure, a system 50 is illustrated in which a patient 102 wears a sensor 10 that transmits measurements using sensor electronics 12. The sensor electronics may transmit data corresponding to the analyte measurements to a smart device 18, such as a smartphone and / or smartwatch, to a dedicated receiver 16, or to other devices, such as a laptop, insulin delivery device, or other computing environment. Currently measured data, historical data, analysis, etc. may be transmitted to a server 115 and / or a follower device 114'. Such data may also be transmitted to a healthcare professional (HCP) device 117. More detailed embodiments of the sensor itself and the sensor electronics are described below with respect to FIGS. 45 and 46.

[0080] 2, a method according to an implementation of the present principles for enabling a smart alert feature in an analyte monitoring system, e.g., a continuous glucose monitor, is seen. The first step is a determination as to whether the user has a diabetic condition that merits attention (step 13). This step is performed in most implementations where if the diabetic condition does not merit attention, then generally no smart alert is provided (step 11). However, as noted, even if the user has a diabetic condition that merits attention, no alert is necessarily provided.

[0081] Specifically, an estimate or prediction is made by the system using various data, which may be historical and / or real-time data, and may be data from sensors and / or other measurement devices, regarding whether the user is cognitively aware of a diabetic condition that merits attention (step 17). If the estimate or prediction results in that the user is cognitively aware, then again, a decision is made not to alert (step 11). However, if the estimate or prediction results in that the user is not cognitively aware, then a smart alert may be provided (step 19).

[0082] Generally, the estimation or prediction is made in an automated manner and is based on stored data or received or determined data. Various kinds of input data are described below, but it is noted here that such data may relate to data having a signature of a pattern (if the user has experienced the pattern many times before, it may be assumed that the user is cognitively aware), behavioral data, historical data (including the use of retrospective analysis in some implementations), and the like. The result of the estimation or prediction may be a binary yes / no, but in many other cases it will be something like a quantitative estimation or prediction, for example, in the percentage of the possibility that the user is cognitively aware. Of course, this may be converted into a yes / no response by comparing this percentage with a single threshold. However, in various other cases, especially when multiple thresholds are involved, multiple and different responses may occur depending on the value of the percentage of the possibility.

[0083] Other alternative implementations may include the use of user input. For example, a user can affect the operation of the smart alerts feature by using a slider bar, by choosing a radio button selection, or by other user interface mechanisms. The user can also affect the sensitivity of the feature depending on what the user wants for reminders and alerts. The user can further affect the content of the reminders by selecting what information they want to review when one or more categories of alerts / events occur. Thus, through suitable selections, the user can affect the operation, timing, and display of smart alerts.

[0084] The details of the above mentioned functions are now described.

[0085] With reference to FIG. 3, the smart alert function may operate as a secondary application 25 running in parallel with the primary analyte monitoring application, e.g., the primary CGM application, on the smart device 18, or the function may be provided as a function within the CGM app (or another app) running on the smart device 18. In either case, other functions may be executed as part of such secondary application or function. When executed as a secondary application running in parallel with the primary monitoring application, additional or subsequent update functions may be tested without affecting the functionality of the main CGM application. In general, the smart alert function brings technology improvements such as lower computational cost, battery power savings, etc. to the operation of the monitoring application, since fewer alerts are typically required. In addition, the device itself is equipped with technology capabilities related to data that previous systems did not have, e.g., data about whether the user is cognitively aware of their diabetic condition.

[0086] 4, further details are provided regarding step 17, i.e., the system utilizing machine learning and stored and / or real-time data to determine whether the user is cognitively aware of a diabetic condition that merits attention. As mentioned above, in some implementations, this step may be expressed as configuring a machine or system learning to predict or estimate whether the user is cognitively aware of a diabetic condition that merits attention (step 22). That is, the system determines a metric that is used in machine learning but is also used to obtain or determine in real time data that is somehow compared to other data, e.g., compared to a threshold, to provide a prediction or estimate regarding the user's cognitive awareness, which is then used in the determination to provide a smart alert.

[0087] One way in which the system can determine such metrics that enable a prediction or inference of the user's cognitive awareness of such a diabetic condition is by determining whether the diabetic condition, or in other words the physiological glucose response experienced, exhibits characteristics of data previously seen and / or experienced by the user (step 24). If the machine learning has learned data that is typical data for that user, and if the obtained or determined metrics indicate that the current real-time data is similar to such typical data, then in many cases the system's determination may be that the user is already cognitively aware, i.e., the result of the inference or prediction may be a determination that the user is likely aware of a diabetic condition that merits attention, and therefore no warning needs to be given. Such similarity of the data may be determined in several ways, including determining whether the real-time current glucose trace has a characteristic signature that is similar to a previously determined characteristic signature, e.g., duration, rise time, width, FWHM, etc. Conversely, if the physiological response is abnormal for the user, the quantitative likelihood of the user having such cognitive awareness is correspondingly decreased, in which case it will be appreciated that a smart alert may be generated based on the data of the decreased quantitative likelihood, the smart alert resulting in the rendering on a screen or display of an indication of the diabetic condition meriting attention, where such rendering results in altering the user interface depicted on such screen or display. For example, the physiological response may include a series of measured glucose values ​​over time. If the series of measured glucose values ​​is similar, e.g., the quantified similarity is greater than a predetermined threshold criterion, to a previous series of measured glucose values ​​encountered over the same or similar time period, such similarity increases the likelihood that the user is aware of their meriting diabetic condition.

[0088] In certain implementations, it may be determined whether the physiological response is part of an established pattern of the user (step 26). Here, the term "pattern" is used to relate, for example, a repeating data sequence identified in the data received in glucose monitoring to an occurrence of "nocturnal hypoglycemia" that commonly occurs to the user. If the physiological response is part of a pattern that the user has previously encountered, then again, the estimate or prediction of the likelihood of user recognition may be higher, or in a more quantitative and / or granular calculation, elevated or boosted. The degree of boost or boost may be based at least in part on the frequency or number of times the user has previously experienced the pattern. Identification of an established pattern may generally include the following steps related to a series of measured glucose values ​​over time. Identification includes quantifying the similarity in the data received over two or more time periods and identifying the similarity as an established pattern if the quantified similarity is greater than a predetermined threshold criterion. Exemplary identified patterns may include overnight hypoglycemia, post-prandial hyperglycemia, post-prandial hypoglycemia, hyperglycemia at certain times of day, hypoglycemia at certain times of day, weekend vs. weekday hyperglycemia / hypoglycemia, post-event hyperglycemia / hypoglycemia, and best day. To the extent that these identified patterns occur for a given patient, they are likely to be cognitively aware, and the smart alert feature may be configured to not alert the patient. It is further noted that in many cases, an event occurs prior to a physiological response, and such an event may be detected and identified as common to and / or occurring prior to the repeating data sequences that make up the detected pattern, e.g., appearing in two or more data sequences, appearing in half of the data sequences, appearing in 75% of the data sequences, etc. In this sense, the term "common" is used to refer to appearing in two or more data sequences that make up the pattern, and generally not necessarily common to the user. The occurrence of an event may be measured with reference to a predetermined percentage ratio, such as appearing in at least 25%, 50%, 75%, 90%, 95%, 99%, etc. of the data sequences that make up the pattern.To the extent that an alert is predicted regarding the occurrence of an event, and to the extent that an alert includes a listing of an event as a cause, the smart alert feature may again be further configured to silence or not alert for a particular event because it may be presumed or predicted that the user is cognitively aware of the event.

[0089] It should be noted that in certain implementations, past systems predicted the issuance of an alert based on exceeding a glucose alert threshold before sounding an alert when the user went out of range. A predictive algorithm is used to develop predicted data using a predictive algorithm, which is then compared to a threshold to give the user advance warning when they go out of range. However, in both cases, the system signals the issuance of an alert until some current or expected out-of-range glucose variation occurs.

[0090] However, in systems and methods consistent with the present principles, historical data and current real-time data corresponding to glucose responses to events such as exercise or meals can be leveraged by machine learning to identify responses that are typical for the user. When the user has a typical response, the system may suppress the issuance of an alert, or the system may not generate an alert in the first place.

[0091] However, if the system or method identifies that the current glucose trace is not typical compared to previous glucose traces, i.e., the user has an abnormal response, the user is alerted to take appropriate action. For example, the user may be determined to have an abnormal glucose response at lunchtime that rose 2 mg / dL within an hour, resulting in hyperglycemia of 160-220 mg / dL. If the smart alert feature indicates an abnormal response, e.g., the glucose trace rose 3 mg / dL within 30 minutes or reached a range above 160 mg / dL, the system may base a smart alert on the abnormal trace and cause a smart alert display to be rendered or displayed on the screen to alert the user that they are likely to have high glucose. Importantly, such a notification is not based solely on the glucose trace exceeding a threshold or predicted glucose value as in previous systems, but rather is based on the glucose response being abnormal or anomalous, i.e., that the glucose level was likely uniquely elevated just after this lunch. Thus, the smart alert feature operates in a unique and very different manner than previous systems.

[0092] A particular benefit of this implementation is not simply to notify the user that their glucose is out of range or will soon be out of range, but rather to inform the user of additional information, namely that their glucose response is not typical for them. That is, based on the determined or acquired data, a unique and customized smart alert notification is depicted on the user interface rendered on the display or screen, displaying types of data not previously displayed, and even previously calculated. Such notification allows the user to take additional precautions to manage and treat this more unique scenario that were not apparent using the technology of previous systems.

[0093] 5, the smart alert function 28, which may be executed in a suitable subroutine or module and may run in parallel with or provide functionality within the monitoring application, accepts various types of input data 30 and generates smart alerts 32 in response to the input data. In so doing, the smart alert function or module may perform a relative continuous evaluation. That is, the application generally does not simply delay providing an alert for a predetermined time to render the alert more convenient to the user. Rather, the application continuously evaluates the data input 30 and determines when or whether to generate an alert based on that data, or based on other data. For example, if the system and method has learned that a particular user typically goes off the rails of "post-lunch hyperglycemia" (post-prandial hyperglycemia) 45 minutes after a meal, it will not generate an alert as long as the actual observed glucose trace indicating hyperglycemia matches a pattern or typical user response. If the physiological response is inconsistent with a pattern or typical user response, for example, if the measured and calibrated glucose data trace data from the glucose sensor differs substantially from the typical glucose data trace, for example by more than a predetermined threshold, thus rendering the response abnormal, the system presumes or predicts that the user is not cognitively aware, and a smart alert is generated and an indication is rendered on a screen or display. Individualized or personalized user information / data, particularly once this information / data is converted into data usable for estimating or predicting the cognitive awareness of a typical user, is typically used in determining whether (or when) to generate a smart alert, and the cognitive awareness estimation and prediction data can then be used to determine the timing of the alert, the manner in which the alert is provided, the content of the alert, the format of the alert, etc. In general, the generation of the smart alert and / or the content or other features of the alert are personalized or dynamically adapted or adjusted to the user.

[0094] The individual inputs are described below and may include data received as measured by the signal, calibrated data, data from the user interface of the monitoring device (including dedicated devices and smartphones / watches), such as keystrokes, taps, frequency of interactions, apps used, etc. It should be noted that the mechanism of cognitive awareness estimation or prediction, i.e. how smart alerts work, may typically include a comparison to a baseline (step 34). For example, the baseline may include known patterns and glucose traces, e.g., a physiological response corresponding to a diabetic condition worthy of attention may be compared to the known pattern (baseline) in determining whether the physiological response is typical. For example, similarity in shape, rise slope / time, duration, time of day, day of week, etc. may be evaluated.

[0095] input Analyte concentration A variety of metrics may be used to construct appropriate algorithms to operate such smart alert features, which metrics separately or in combination are shown to derive estimates or predictions of cognitive awareness of a diabetic condition worthy of attention. In some cases such metrics are converted into estimated or predicted data, and in other cases algorithms are used to derive estimated or predicted data. Such metrics include rate of change, time to glucose level threshold (e.g., how quickly the first 20 mg / dL changes), amount of residual insulin, etc. The primary drivers of the smart alert feature are real-time analyte concentration values, e.g., glucose values ​​measured by a glucose sensor, and glucose change rates derived from the glucose values ​​measured by the sensor. However, other physiological quantities may also be used. While in some cases data reception / data calibration / data display are performed by a single physical device, in other cases multiple devices may be used, and in such cases data may be transmitted from one device to another as needed and according to appropriate data transmission protocols.

[0096] Another quantity that may be used besides quantities measured or derived from glucose sensor data is the glycemic urgency index, which is described in U.S. Patent Application Publication No. 2015 / 0289821, entitled "GLYCEMIC URGENCY ASSESSMENT AND ALERTS INTERFACE," filed March 16, 2015, which is owned by the assignee of the present application and is incorporated by reference in its entirety herein.

[0097] User input or behavior User input or behavior collected by data input into a system according to the present principles may also be used in inferring or predicting cognitive awareness. For example, a particular user behavior may be indicative of cognitive awareness because it is consistent with the user's self-treatment of a diabetic condition that merits attention.

[0098] In one particular example, machine learning combined with system data about user interface usage may be used to learn that the user responds to the first alert but never responds to subsequent alerts. Thus, in this embodiment, the first alert may be made more noticeable because it is known that future alerts will be ignored.

[0099] User "clicks" or "activations" of icons determined from user interface usage data may further be used to determine cognitive awareness. For example, if glucose trace data indicates that a user has entered a diabetic condition meriting attention, but the user immediately checks the user's monitoring application, e.g., begins calculating a bolus dose or rescue carb amount, such activity is a strong indication that the user is cognitively aware of his or her diabetic condition, i.e., tends to raise the likelihood of cognitive awareness in quantitative estimation or prediction higher. In such cases, smart alerts may be suppressed or not generated at all.

[0100] Similarly, input of certain types of data may be used in the estimation or prediction algorithm. For example, if a user has a diabetic condition that merits hypoglycemia attention, but the user inputs current meal data, the user input data indicates cognitive awareness of the hypoglycemic condition and therefore causes the smart alert to be suppressed or not generated. In some cases of "closer to the situation," such calculations may involve converting the user input data into carbohydrate data to determine whether the user intended to treat hypoglycemia or simply ate without such awareness. This also applies to inputting bolus dose data in response to hyperglycemia, etc. Input of data (by the user) for bolus dose calculation may further indicate cognitive awareness of the user, since input of data (by the user) sets parameters of a user interface, e.g., manipulating or adjusting a slider bar. The values ​​of the parameters themselves, e.g., low aggressiveness, medium aggressiveness, high aggressiveness, may themselves be used as separate inputs to the smart alert function. Thus, in these implementations, the relevant data includes (1) the data input into the health and diabetes management applications, as well as (2) the value of the data itself.

[0101] The entry of meal data may trigger other changes in processing, which may further affect the generation or suppression of smart alerts. In some implementations, these aspects act as triggers to record insulin and carbohydrates. For example, if a user records a significant amount of carbohydrates, the monitoring application may automatically raise the alert threshold level by a predetermined amount for a predetermined duration (e.g., the hyperglycemia alert level may be automatically raised by 100 mg / dL for 2 hours). In this way, the application "desensitizes" the hyperglycemia alert level to post-meal spikes. In other words, instead of basing the alert on cognitive awareness of a diabetic condition that merits attention, this aspect modifies the system definition of a diabetic condition that merits attention. In implementations, the amount of alert level increase may be configurable, for example, from 0 to 200 mg / dL in increments of 25 mg / dL, with a default level of 100 mg / dL. If the level increase is 0, such an application essentially turns off the feature. The duration may be configurable, for example, from 30 minutes to 3 hours in 15 minute increments, with a default duration of 2 hours. The carbohydrate threshold level at which the sensitivity suppression subroutine begins may vary, but this level may be, for example, two or three carbohydrate units. It should be understood that such a level will typically depend on the insulin / carbohydrate ratio. If known, parameters such as the amount of residual insulin and the amount of residual carbohydrate may be considered in the sensitivity suppression subroutine. The advantages of such a sensitivity suppression subroutine are many-fold, including the addition of only one setup screen, and no initial setup is required if default values ​​are applicable. If the user has a connected pump and insulin / carbohydrate ratio data is communicated from the pump's bolus dose calculator using an appropriate transmission protocol, setup is automatic and no additional data entry is required. Systems or machine learning may also be advantageously used in the implementation of this function, where machine learning may be performed to determine when the user typically enters meal data versus when meal data is actually consumed, e.g., after carbohydrate consumption, before carbohydrate consumption, etc.Such records, when combined with glucose data indicating a potential hypoglycemic situation, can be analyzed and used to suppress the generation of smart alerts that may be given unnecessarily at the expected post-prandial rise.

[0102] Other relevant data may include user-entered content data, which may be entered from or using multiple selection radio buttons, etc. For example, the user may be requested to directly comment on the usefulness of a given alert. The user may be prompted to acknowledge the alert by pressing a button selected from a convenient and easily understood user interface. Buttons such as "thank you" or "dismiss" may be provided. Responses such as these may allow the user to acknowledge the alert promptly, and may be converted into highly useful data for future calculations in the smart alert function. For example, if an alert was provided 2 hours after a meal, but the user indicated that it was not useful, the next iteration may alert the user 2.5 hours after the meal (and other alert criteria are met). As another example, if an alert is explicitly indicated as not useful, the alert will not be repeated (i.e., defining criteria for future smart alert determinations). If an alert is ignored, it may be determined that it was intentionally ignored, and the alert may not be repeated, if other data may be used to indicate that the user is aware of the diabetic condition. If it is not clear whether the ignore was intentional, the alert may be repeated. The present system and method may also determine data based on machine learning from either purposeful ignore or by the user activating an "ignore" button. For example, the present system and method may alert the user multiple times at 180 mg / dL (and rising) in the absence of a response or activation of the "ignore" button. In such a situation, a monitoring app using the smart alert feature may ask the user if they do not want this level of alert, e.g., if they do not want to be alerted again in a similar situation. Such data may then cause changes in how such smart alerts are output, i.e., providing additional tailoring or personalization to the user.In other words, such data can then be used in algorithms that optimize the generation of smart alerts by applying calculations that take into account user interaction data (determined by user interface interactions) or other non-physiological data and physiological data. Such algorithms can operate in smartphone-type devices and other devices, such as smart watches.

[0103] For example, if the user is about to engage in or participate in an event that may affect his / her glucose value, other relevant user input data may include event data. For example, if the user is about to engage in an exercise, e.g., a long workout, that he / she knows will put his / her glucose outside of his / her normal range, he / she may enable a setting on the monitor (e.g., click a button on his / her smartphone to enable a special "training" alert schedule). Such a training alert schedule may provide different alert values, duration of the event. Other such events that may have special alert schedules may include eating, sleeping, etc.

[0104] Data regarding user feedback may be received from the user interface at various times during the resolution of a diabetic condition that merits attention, for example, during the event, well after the event, etc.

[0105] Prompts or other questions for the user's response may be provided at various times to learn directly about the user's cognitive awareness or to learn about "signs" that indicate the user's cognitive awareness. More specifically, prompts or other requests for data input may be provided to collect certain required data, i.e., some dated, that are determined to be particularly useful in determining the user's awareness. Such data may be specific to a user, or a group of users, e.g., a cohort of users, or a larger population. In other words, a system using machine learning may prompt a user to input certain types of data so that the system receives data that is determined to be particularly useful. Such received or transmitted data relates not only to the existence of an interaction with the user, but also to the actual content and value of the interaction with the user.

[0106] Besides using directly entered user information, inferred user information may also be used in the smart alert feature. For example, lack of user action may be used. For example, if the user is at 40 mg / dL and no action has been taken after an hour, the alert may be more extensive. This situation may be detected by a firmware or software routine configured to measure the amount of time the user is in a dangerous or undesirable range, and having keystroke or tap data from the user interface as additional input. As another example, if the user begins to check their display device with a high degree of interaction, the system may learn that the user is now in a mode that requires a significant amount of interaction and information, and therefore the alert may become more active, interactive, or aggressive. Similarly, data from the user interface may be used to measure what is a "significant" amount of user interaction versus a "normal" or "typical" amount. For example, the normal or typical amount may be determined by user input data over time, for example, by the average number of applications opened or tapped per minute or hour. The number may be used as a threshold criterion, and if more such taps are measured or detected, a user "high interaction" mode may be defined and used. In other words, increased user interaction with the device may have a similar effect as a user moving a slider bar of a configuration parameter to a more aggressive state. Such automatic setting of the parameter may depend in part on the extent to which the user interaction indicates the user's cognitive awareness. The user interaction may not be related to a diabetic condition that merits attention, for example, if the user is responding to emails or watching a video. Thus, the user interaction may be differentiated in that only interactions related to analyte monitoring, such as CGM, bolus dose calculations, etc., are taken into account. Unplanned and hectic interactions of such applications may indicate the user's cognitive awareness and desire to interact. In some implementations, the measurement of unplanned and hectic interactions may take into account accelerometer data, for example, if the device is being handled in a hectic manner.In this case, a smart alert will be generated. On the other hand, user-focused interactions, such as deliberate and "typical" execution of bolus dose calculations, within a range considered "acceptable" or "normal" or "typical," for example, with a keystroke or tap frequency that is typical for that user, will indicate cognitive awareness of the user and thus not cause the generation of a smart alert. A complete lack of accelerometer signal fluctuations may indicate that the user has fallen or lost consciousness. In this case, if the alert is not acknowledged or the lack of movement continues, the smart alert function may be configured to send an alert to a follower or another caregiver associated with the user. In general, any user interaction that is determinable or measurable in real time from the user interface of the device on which the health-related application runs, especially when used in combination with real-time glucose data, may be used to determine when and / or whether to use the application to change the user interface, for example, to provide an alert, and not only behaviors taken by the user on the user interface are defined as such user interactions.

[0107] Prior or past user responses (either physiological or through the user interface) may be used to develop, generate, or improve future smart alert features, for example, to eliminate or reduce "back and forth" user responses. More specifically, such prior or past user responses are typically captured in some form of data file, and retrieval, e.g., transmission, and analysis of such stored data may be used to generate and improve the smart alert feature to determine which smart alerts have previously resulted in desirable physiological responses (and conversely, which types of smart alerts have previously resulted in undesirable physiological responses). Such analysis may include analysis of glucose trace data (and associated event data, if applicable) to determine characteristics of desirable and undesirable responses, and then analysis of current physiological data to determine the presence of a diabetic condition that currently merits attention. If a smart alert is determined to be appropriate for generation, the smart alert feature may allow selection of a type of smart alert that previously resulted in desirable physiological responses.

[0108] Pattern Detection and Use Patterns in glucose can be useful to help patients understand and manage their diabetes and how physicians manage their patients. Efforts have been made to determine patterns that require attention by the user or highlight areas that require attention.

[0109] U.S. Patent Application No. 14 / 874,188, filed October 2, 2015, entitled "SYSTEMS AND METHODS FOR DATA ANALYTICS AND VISUALIZATION," and U.S. Patent Application Publication No. 2013 / 0035575, filed August 3, 2012, entitled "SYSTEMS AND METHODS FOR DETECTING GLUCOSE LEVEL DATA PATTERNS," are both owned by the assignee of the present application and are hereby incorporated by reference in their entireties.

[0110] As discussed above, the pattern data may be used in determining the user's awareness of the diabetic condition, since if the user has a pattern of a particular physiological response, it may be assumed that if such a physiological response occurs again, the user will recognize the pattern and take appropriate action. In other words, the user may be assumed to recognize a pattern previously experienced, raising the estimation or prediction of the user's cognitive awareness. As further discussed above, the recurrence of a pattern may be determined by storing and analyzing previous data, particularly data identified as a pattern (but not necessarily a pattern), and comparing these data with the currently measured (occurring) glucose trace to determine whether the currently occurring glucose trace has a curve or signature characteristic similar to the previously identified trace.

[0111] One way to determine such patterns or detect occurrences of glucose events that deviate from a pattern is by "binning" certain events defined by certain characteristics: that is, portions of the glucose trace that meet certain criteria indicative of a particular diabetic challenge, e.g., rebound hypoglycemia, may be detected, and the pattern may then be looked for among these appropriately "binned" events (or determined not to be within such a binned pattern).

[0112] In more detail, and with reference to the flowchart 300 of FIG. 6, a "signature" or "fingerprint" in the glucose sensor data may be identified or differentiated within an individual patient based on some predefined criteria (step 36). Such criteria may include time-based criteria and / or specific events detected within certain constraints. In the present system, bins may be differentiated by different criteria in accordance with the present principles. A supervised learning algorithm may be used that allows more bins to be learned for each individual's specific patterns. For example, bins may be based on insulin data, the rate of change of glucose data (or its acceleration / deceleration), patterns of data previously identified and used to characterize the data, such as events occurring before a small meal, the individual's responsiveness to the individual's glucose information, etc.

[0113] The next step is to characterize the event based on, for example, the decay curve or waveform signature (step 38). Exemplary events may include, for example, a meal bolus indicator based on insulin data, which may be categorized into small, medium, and large meal bins. Such events may be correlated with insulin data. Different meal types may also be characterized, which may then be sub-binned into different meal configurations. These may be correlated with the rate of change of acceleration / deceleration. Events may also be characterized based on the correlation of the event with pre-meal events, such events corresponding to patterns of data described above. Events may further be based on behavioral patterns, for example, how often a user reviews their glucose data or responds to an alarm, such events may be correlated with the response data described above. It will be appreciated that other bins may also be used. Thus, not only the data about the event, but also the user's response data may be patterned, which may further provide data useful in algorithms to infer or predict the user's cognitive awareness when such an event and / or user's response occurs again.

[0114] The characterized events can then be placed into bins (step 40). The bins can then be adjusted for a particular patient's physiology by synchronizing on an event-by-event basis. The bins can then be normalized, i.e., a normal distribution of events within the bins can be defined (step 42).

[0115] The normalized bin information can then be actively used as data input to a smart alert feature (step 44), for example, in estimating or predicting user awareness. The binning technique may be used to determine when a patient pays attention to their own data based on behavioral input, which may then allow for inference, estimation, or prediction of the user's cognitive awareness.

[0116] Another application of such binning techniques is to identify good or successful warning signatures (step 43), e.g., warning signatures that represent diabetic conditions and warning types that the patient responded well to, from bad or failed warning signatures (step 45), i.e., warning signatures that represent diabetic conditions and warning types that the patient ignored. A smart warning can then be provided based on this information, i.e., the smart warning can determine when and how to warn by comparison with the good warning signature (if the diabetic condition is within a predefined vicinity (in the glucose trace) of the good warning signature, this can result in the triggering of a smart warning). In this case, the use of the good warning signature does not depend on an estimation or prediction of the user's cognitive awareness, although the signature may be used in combination with such an estimation or prediction.

[0117] Patterns may also be identified by recognizing that conditions or events occur repeatedly across CGM wear. To find these repeat occurrences, an algorithm may synchronize the CGM data stored, for example, in a buffer or data file, for each epoch (day, week, or month) and calculate the average or distribution of CGM values ​​as a function of time. Synchronization may be done by absolute time, for example, to look for nocturnal hypoglycemia or early morning or afternoon hyperglycemia / hypoglycemia. One problem with this approach is that users do not always eat at the same time or take insulin at the same time, and thus patterns may not be clearly evident. Thus, in systems and methods according to the present principles, patterns corresponding to times of food intake or insulin administration may be identified. Such patterns may be identified using the techniques described above. For example, a sudden change in glucose within a given duration in the morning may be identified as "breakfast." By using data communication between a smartphone and a pump and a monitoring application, data corresponding to communication from the pump before a meal bolus may be transmitted to a monitoring device, such as a smartphone, and used as an indicator of food intake. Other such indicators include, for example, data from a GPS app determining likely changes in glucose with respect to food intake that may occur at a favorite restaurant, changes in movement determined by accelerometer data with respect to movement-related effects on the CGM, etc. In this way, patterns can be (machine) learned about the closest response in "temporal proximity" to a meal or night, or the closest response in "geographical proximity," e.g., how far the user is from home or a food source.

[0118] Once a particular time of synchronization is selected, the data corresponding to the CGM traces at each of these epochs can be overlaid on top of each other to generate statistics. For example, an average of the traces can be used to distinguish between random occurrences and true effects. Any true glucose effects due to repetitive patient physiology are likely to be accentuated, and other random effects are likely to be removed or averaged out.

[0119] The data corresponding to the distribution of CGM over time provides the most likely glucose value after a synchronization event, as well as the associated minimum and maximum values. These can then be used to create a typical glucose fluctuation in an individual due to a synchronization event. For example, if glucose is synchronized based on food intake at lunch, the glucose change after lunch captures the typical change for that individual. Any glucose change that exceeds a predefined threshold may have a predicted underlying cause. For example, inappropriate or missed bolus doses, the effect of insulin stacking, etc.

[0120] Trends in glucose patterns (average, high, or low) may also indicate gradual changes in behavior that may be detected and alerted as well. For example, gradual trends in average glucose or minimum or maximum glucose determined by machine learning may indicate changes in physiological parameters related to insulin administration, such as carbohydrate to insulin ratio, or insulin sensitivity. Adjustments of these parameters using machine learning algorithms may also be made using these patterns if different parameters are required for different times, weeks, or months. If such trends are determined by the system to be occurring without a corresponding change in user behavior, for example as determined by dietary data, exercise data, data entered on a user interface, etc., the algorithm may use such data to estimate or predict whether the user is cognitively unaware of the change, and if so, a smart alert may be generated and displayed. For example, if the estimate or prediction indicates a likelihood of cognitive awareness above a threshold reference level (which is generally true for all estimates or predictions described herein).

[0121] These analyses can be performed by algorithmic routines in the background while the user enjoys other features of the smartphone, and such routines use individual patient data to learn from the data over time in a supervised or unsupervised manner. Thus, over time, pattern recognition can occur and smart alerts make more effective alerts possible and acceptable.

[0122] As discussed above, implementing a smart alert requires more than simply shifting or delaying the alert in time so that the alert is more useful to the user. However, the time scale determined by the timing circuit or algorithm may be used in conjunction with additional information, such as behavioral or contextual information, in predicting or estimating the user's cognitive awareness and in determining when and how to provide a smart alert. For example, a computing environment may identify an alert condition, e.g., a diabetic condition, that merits attention, but may determine when to provide a smart alert based on other input variables, including behavioral and contextual data, which are often variables that participate in the determination of the smart alert function. Even if a smart alert is delayed on this basis, the determination of the delay is still based at least in part on real-time data, as discussed above.

[0123] Behavioral and Contextual Input Various types of behavioral and contextual information may also be used as inputs to the smart alerts feature to determine, predict, or infer the user's cognitive awareness.

[0124] Contextual and behavioral information is data that generally corresponds to how a patient uses their mobile device / monitoring app and thus provides context to certain data determined by the device. Behavioral input information may be obtained through the system and includes interaction volume, glucose alert / alarm status, sensor data, number of screen taps, alert analysis, events (e.g., characteristics related to user response, time to respond, glycemic control related to response, user feedback related to alert, acknowledgment of alert or alert, not acknowledging alert or alert within X minutes, time to acknowledgement of alert / alarm, time of alert state, etc.), diabetes management data (e.g., CGM data, insulin pump data insulin sensitivity, patterns, activity data, calorie data), data related to fatty acids, heart rate during exercise, IgG antigliarylin, stress level (sweat / perspiration) from skin patch sensor, free amino acids, troponin, ketones, adiponectin, sweat, body temperature, user feedback, etc. Input may be provided by sensors in data communication with the monitoring device. In some implementations, the information may be obtained through an intermediary such as a remote data storage device. The user data discussed above in relation to user interactions is one example of behavior data.

[0125] Contextual information may include the user's location as determined, for example, by GPS, WiFi, or the locations of sharers and followers. Contextual information may relate to a person's biology, location, sensing of surroundings (e.g., light, volume), environmental data (e.g., weather, temperature, humidity, air pressure). These inputs may be received peer-to-peer or over a mesh network via machine-to-machine communications. Contextual information may include daily routine information from a calendar application (which may vary, especially between weekdays and weekends). Contextual information may include how often the monitoring device was touched or grabbed, even in the absence of interaction, for example, based on an accelerometer in the device and / or sensed movement of the device from an application.

[0126] A photo from the user's smartphone may be converted into contextual data using image recognition algorithms. For example, a photo of one or more of a glucose meter reading, an insulin pen or pump IOB, a location (e.g., gym, park, home, Italian restaurant), or a meal may be used to provide contextual information. The photo may be processed using image recognition algorithms, for example, to identify the caloric intake of the meal shown in the photo. The type of insulin used, which may be determined by a barcode imaged by the smartphone camera or the like, may also be provided to the monitoring system as a useful input for estimating or predicting cognitive awareness. Indeed, the receipt of such insulin type data, especially in combination with other data related to the user's cognitive awareness, may itself indicate that the user is cognitively aware. Context may also be provided by basal or bolus dosing settings provided or determined by the monitoring device. Such settings may be transmitted to the monitoring device using known data transmission methods and protocols, e.g., Bluetooth. Transmission may occur periodically on a push or pull basis, or on another basis.

[0127] Since the behavioral / contextual data may indicate the user's awareness of his / her diabetic condition, the data may be used in predicting or estimating whether the user is cognitively aware. At one extreme, the contextual GPS data may indicate that the user is in a clinic, implying that the user is highly cognitively aware. At another extreme, the behavioral data may indicate sleep via accelerometer data, thus indicating high cognitive unawareness. Such time idleness, warnings and alarms may be appropriately modified, e.g., automatically enabled or disabled. For example, if a sleep state is determined, the warning / alarm system may enter a "night mode" or "sleep mode" that is more conservative with respect to glucose and more aggressive with respect to small alarms. The warning / alarm system may then adjust the behavior of the system, including the warning / alarm, and dynamically further adjust the target range, significantly improving the user's convenience. For example, in such an overnight mode, the target range may be adapted so that alarms for hypoglycemia are more aggressive, e.g., somewhat higher than in the "day mode." Invoking or initiating these modes may programmatically redirect the monitoring device so that processing on the monitoring device occurs in a different manner than before, improving the efficiency of the computing device.

[0128] Other inputs to the cognitive awareness algorithm's estimation or prediction that constitute context / behavior data may include exercise information, such as from a fitness bike, or glucose sensor information from a blood glucose sensor (BG) meter or CGM, or insulin delivery from an insulin delivery device, the results of calculations of the remaining insulin amount for the device, and certain data types referenced elsewhere, such as information provided or calculated by other devices. Other context / behavior data inputs may include hydration level, heart rate, target heart rate, internal temperature, external temperature, external humidity, body analytes, hydration input, power output (cycling), sweat rate, cadence, and adrenaline level, stress, illness / disease, metabolism / calorie burn rate, lipolysis rate, current weight, BMI, desired weight, target (consumed) calories per day, target (expanded) calories per day, location, favorite foods, and physical activity level.

[0129] For example, a high external temperature coupled with low stress and high calorie intake may be determined by the system to be consistent with the user being on vacation, which may indicate a lack of attention to diabetic conditions in some individuals. In this case, the system may determine that the user is likely not cognitively aware of a diabetic condition that merits attention, and therefore may determine that a smart alert should be generated.

[0130] In this regard, it is further noted that high external temperatures may cause the user to render a smart alert regarding ensuring that the user's diabetic essentials are in refrigerated containers and are not exposed to high environmental temperatures.

[0131] For any of the above referenced behavioral or contextual inputs, the system may be configured to receive and / or generate analytical metrics based on the inputs. For example, a composite value may be generated based on glucose level, temperature, and time of data generation index for the user. The composite value may then be factored into an estimation or prediction of cognitive awareness.

[0132] This information may be collected from various sensors inside or outside the device, such as accelerometer, GPS, and camera data, as well as third party tracking applications, including sleep cycle applications, and may also affect the output. For example, when in a moving car, GPS may be used to determine the speed of movement to suppress a smart alert on the mobile device. However, in this context, a smart alert may be sent and rendered on the smartwatch. Thus, real-time measured sensor (glucose) data is used to determine a diabetic condition that merits attention, and other data, which may be real-time or not (or a combination thereof), is used to determine whether a smart alert should be generated. If a smart alert should be generated, other real-time data, in the above example GPS data, may be used to further determine the form of the smart alert and in particular the device to which the data is sent and rendered.

[0133] As mentioned, the alert may be affected by the proximity of the sharer and follower. For example, if the sharer is in close proximity to the follower, the alert may be annoying because the alert may be triggered in two locations, e.g., on the sharer's pump, receiver, or smart device, and on the follower's smart device. In one implementation, the follower's app may detect this situation and delay or suppress the alert on the follower's device. For example, when the follower's app receives an alert, the app may initiate a radio frequency, e.g., Bluetooth, to scan for the sharer's mobile device (or dedicated receiver or pump). If the app detects the sharer's device, for example, within 30 feet (for Bluetooth detection), the app may check the RSSI (received signal strength) to determine how close (e.g., very close, close, far) it is from the sharer's device. If the follower's device determines that it is near or very near the sharer, the follower's application may delay the alert for a minute or two to give the sharer a chance to respond. Alternatively, the follower's app may suppress the alert. In either case, if the sharer responds within a predetermined time frame, e.g., a minute or two, the alert may be suppressed on the follower's device.See, for example, U.S. Patent No. 8,844,007, granted on September 23, 2014, entitled "SYSTEMS AND METHODS FOR PROCESSING AND TRANSMITTING SENSOR DATA," U.S. Patent Application Publication No. 2013 / 0078912, filed on September 21, 2012, entitled "SYSTEMS AND METHODS FOR PROCESSING AND TRANSMITTING SENSOR DATA," U.S. Patent Application Publication No. 2014 / 0273821, filed on March 14, 2013, entitled "SYSTEMS AND METHODS FOR PROCESSING AND TRANSMITTING SENSOR DATA," and U.S. Patent Application Publication No. 2015 / 0123810, filed on November 5, 2014, entitled "SYSTEMS AND METHODS FOR A CONTINUOUS MONITORING OF ANALYSIS Beacon technology may also be used for this purpose, as disclosed in U.S. patent application Ser. No. 15 / 001,756, filed Jan. 20, 2016, entitled "CONTINUOUS GLUCOSE MONITOR COMMUNICATION WITH MULTIPLE DISPLAY DEVICES," and U.S. patent application Ser. No. 62 / 271,880, filed Dec. 28, 2015, entitled "INTELLIGENT WIRELESS COMMUNICATION FOR CONTINUOUS ANLAYTE MONITORING," all of which are owned by the assignee of the present application and are incorporated herein by reference in their entireties.

[0134] In some cases, certain unexpected spikes in glucose, as determined by analysis of the glucose trace, may temporarily disable the sharer functionality to avoid embarrassment for the user and to achieve user privacy goals and considerations. Such unexpected spikes may include certain health or stress events. In one implementation, a threshold level for unexpected spikes is predefined, and data of the unexpected spike is compared to the threshold level to determine whether the sharer functionality should be used to share data about the spike.

[0135] Heart rate data measured by a heart rate sensor may be used in estimating or predicting the user's cognitive awareness. For example, a commercially available heart rate sensor may be used, and the measured results are communicated to a monitoring device or other device providing a smart alert function by an appropriate transmission protocol. In another implementation, the sensor electronics or transmitter (see FIG. 45 / 46 below) may include a strong light and optical sensor (not shown) for detecting the heart rate. Such heart rate data may be used by itself in estimating or predicting the user's cognitive awareness, or the data may be used to indirectly infer when the user is exercising, stressed, asleep, etc. (this data may then be used in the estimation or prediction). In such a direct use, the user may have a diabetic condition that deserves attention. The accelerometer of the smart device may be used to determine that the device has just been operated, and that the operation included viewing a glucose monitoring app user interface. If the heart rate appears to have suddenly increased, it may be inferred that the user is informed of a diabetic condition that deserves attention, and no smart alert needs to be given.

[0136] Additionally, context and behavior may also be determined by using available social networking information about the user, with social networking feeds associated with the user configured to provide a source of data for the smart alert feature. User recognition data may be determined in some cases by analysis of such data in social networking feeds, for example, posts of the user's "blood glucose is low right now" or posts with content similar to that posted when the user's blood glucose was previously low. Techniques such as natural language processing may be used to determine the meaning of posts, thus allowing a quantifiable measure of similarity to previous posts. Thus, posts may not only be used directly for their content ("blood glucose is low right now"), but also to infer that the user is in a similar state to when he or she posted a similar comment previously.

[0137] By using such systems and methods according to the present principles, problems faced by previous monitoring devices that did not take such context / behavioral aspects into account can be effectively addressed. In particular, if available data from sensors and other sources, including context / behavioral aspects, allow for an estimation or prediction of whether a user is cognitively aware of a diabetic condition that merits attention, the monitoring device can be significantly improved by using cognitive awareness as a means to suppress alerts when they are not necessary, which provides a significant technical advantage over monitoring devices that based alerts solely on thresholds (or even on thresholds plus predictions). Thus, the monitoring device provides a significant technical advantage over previous monitoring devices where such cognitive awareness was not taken into account at all. Further details regarding context and behavioral information can be found in U.S. Patent Application Publication No. 2015 / 0119655, entitled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES," filed October 28, 2014, which is owned by the assignee of the present application and is incorporated by reference in its entirety into this specification, specifically FIG. 4 and the accompanying text.

[0138] Behavioral and contextual inputs may also be used to provide other useful alerting features. For example, if there are multiple CGM receivers in a home, it becomes important for the user to be able to identify each one individually. There is currently no visual aid for individual identification other than different units being colored differently to help distinguish one from another. Thus, systems and methods according to the present principles may require the user, as part of the setup procedure for a new receiver, or a receiver to be used by a new user, to select a unique identifiable indicia, such as initials, a screen background, a color theme, a screen saver, animation, or a combination thereof, to be displayed within the screen area when displaying CGM information. For example, initials may be displayed in a corner of the screen or in a status bar. A screen saver may be applied when the screen is not displaying CGM information. A screen saver may be applied to entities such as fonts, backgrounds, etc. Animations may be displayed within various selectable areas of the screen. This allows a CGM receiver or CGM smartphone application to display the associated user's indicia when displaying the user's CGM data, thus avoiding confusion when multiple data sources (e.g., hosts with sensors) transmit data at a common location at a substantially common time.

[0139] As part of the setup procedure, thresholds may also be set and the user may indicate the different types of alerts or warnings he or she would like to receive, e.g., whether he or she would like to receive alerts before meals versus after meals. The smart alerts feature or app may then be configured to query the user from time to time or periodically after setup to determine, for example, whether the user is satisfied with his or her setup selections or whether the user would like to change their selections, e.g., whether he or she would like to select to receive alerts before meals. The feature or app may prompt or allow the user to change the alert thresholds to better suit the user's lifestyle.

[0140] Other Inputs Other data sources besides glucose data, including user input, derived data such as rate of change and pattern data, and sources of behavioral / contextual data may also be used.

[0141] For example, derived data regarding signal trends (other than patterns) may also be used in the smart alert function. For example, the smart alert may be based on the proximity and duration of, for example, an alertable zone, also called "loitering". That is, in many cases, the user should be alerted if the user is near a danger zone for an extended period of time, even if the user is not within the danger zone. The smart alert function may be used to provide an alert in this situation. In other words, in a loitering situation, a smart alert is generated when the user is typically not cognitively aware that he is close to the danger zone. In this case, the data indicative of loitering is determined by an analysis of the measurement data, duration data, and the location of the threshold. If the user is close to the zone threshold, for example, + / - 10% of a predetermined duration, and other data described above or below indicates that the user is not cognitively aware of the loitering situation, the smart alert function causes a smart alert to be generated, where the smart alert indicates the existence of a loitering situation.

[0142] In another signal trend, a notification may be provided once the dangerous or undesirable range is no longer an issue, thus potentially reducing the user's stress and informing the user that they are once again within the target. This is similar to the home automation aspect of a dimmer switch. Specifically, when a dimmer switch is turned off, the following steps are involved: the light is on, the home automation sends a command to turn the light off, the light sends a command that the light begins to turn off, and finally the light sends a command when the light is off. Similarly, in a garage door situation, the garage is open, then the home automation system sends a command to close the garage, then the garage sends a command that the garage is beginning to close, and finally the garage sends a command when the garage is closed.

[0143] For the garage, this feature is important because if something blocks the sensor and does not allow the door to close, it is important that the user is aware (through the home automation system) that the garage is not closed. In this case, such a notification may occur because the user did not receive the last command. In this case, if the patient is hypoglycemic or hyperglycemic and attempts to remedy the situation by taking medical measures, the sensor electronics may send a notification indicating that glucose is beginning to curve and rise (or fall). The sensor electronics may then send a notification that the user is no longer in the hypoglycemic (or hyperglycemic) range. Rather than waiting for periodic (e.g., every 5 minutes) measurements to determine if the patient is outside of the undesirable range, a more proactive approach may be taken to push a notification that the patient is no longer in the undesirable range. Thus, in this case, the smart alert may be based on whether a second notification was not received. In particular, if the system strictly waits for an "out of danger" state to be determined, if such a determination does not occur, the system may infer that the user is still in a dangerous situation and therefore a smart alert should be generated. This is because the user may be aware of the fact that the system is not aware of the fact that the user is still in danger and therefore a smart alert should be generated. This is especially true when a user takes a remedial action intended to treat a diabetic condition that is worthy of attention. In the latter case, the user may wait, without further thought, for the user to get out of the dangerous situation. If this does not occur, the smart alert may become even more important. It will be appreciated that this functionality may be accomplished in a number of ways. For example, the "out of danger" notification may take the form of a flag that is set after an inflection point is detected. If known, the location during the remedial action may also be used in the calculation, determination, and subsequent setting of the "out of danger" flag. If the user does not get out of the dangerous situation within a predefined duration (which may be determined from user history and patterns) after the remedial action, the smart alert may be generated again.

[0144] Another input may include the user's life goals. In particular, diabetes management goals, such as reducing hypoglycemia risk, reducing time out of range, reducing warnings / alarms, post-meal optimization, reducing rebound, etc., may be used as inputs to the prediction and estimation of cognitive awareness. The user sets a goal, or even sets multiple different goals for different times of day, and the system changes or modifies the settings to allow the user to more easily achieve their desired goal. For example, a person may use a goal of reducing hypoglycemia risk at night, and the system may use predictive hypoglycemia warnings with higher threshold settings. For these settings, it is presumed that the user is typically not cognitively aware, for example, if the values ​​are used at night, since the user is likely asleep. As another example, such a user may also have a post-meal optimization setting that reminds the user to take a bolus about 30 minutes before their typical lunch time, or provides a reminder to include protein in their meal, if it is presumed or predicted that the user is not cognitively aware.

[0145] Other inputs include data and signals from insulin sensors or from other data sources related to insulin. For example, insulin sensor data can be used to detect insulin delivery, which then provides a way to estimate cognitive awareness of a diabetic condition that merits attention based on an estimate of when insulin was injected. More specifically, if a hyperglycemic diabetic condition that merits attention has occurred, but the smart alerts app uses data from the insulin sensor to detect that some residual insulin amount is present, the smart alerts app may suppress an alert until a point where it is determined that the current insulin is no longer able to control the hyperglycemia and the user is not cognitively aware that more insulin is needed. Insulin sensor data can also be fed in for other uses. For example, information about the timing of bolus administration, in addition to the residual insulin amount, may be used to modify the behavior of the smart alerts for both hypoglycemia and hyperglycemia. For example, if the user has recently administered a bolus of insulin, a threshold alert may be delayed or a predictive alert may temporarily suspend or raise its own target threshold based on the user's cognitive awareness of the likely occurrence and / or the user's reduced risk from the situation, e.g., reduced risk of a "diabetic condition worthy of attention." As a specific example, if a prediction was used at 200 mg / dL, bolus knowledge may set the alert at 250 mg / dL for one hour. Similarly, with respect to a low glucose alert, insulin knowledge may increase or decrease the sensitivity of the alert if the calculation suggests that the amount of insulin suggests a more conservative or aggressive glucose lowering.

[0146] Use of insulin sensor data in this context generally requires some degree of machine learning, especially since each user has a different insulin sensitivity, and this sensitivity may change over time. Thus, knowledge of current insulin sensitivity may be a prerequisite for using insulin sensor data, especially when high accuracy is required.

[0147] As another example, if information or data regarding the amount of remaining insulin is known or subsequently or simultaneously input by the patient, these information or data may be used in determining when to provide a smart alert. Such information regarding the amount of remaining insulin may be input by the patient or received from a drug delivery device, such as a pump or pen. In one implementation, the user may input how much insulin they have taken, and then a calculation may be made as to how much insulin will remain in the user's system over the next few hours. The value of the amount of remaining insulin may then be used to inform when to notify, e.g., warn or alert, the patient. In one implementation, if the patient normally wants to be alerted when they exceed 200 mg / dL, and the system detects that the user is above that value or predicts that the user will exceed that value, the system may determine or receive data regarding the amount of remaining insulin. If the user has a lot of insulin in their system, e.g., 5 units, the system may determine that the patient does not need to be immediately alerted because that insulin will treat a potential hyperglycemic condition. Similar steps may be taken as an approach to hypoglycemia in a patient. For example, if a patient desires to be notified when they fall below 80 mg / dL and the system detects that the user is above this value but has significant levels of insulin in their system, the system may be triggered to warn the user sooner that they are heading towards hypoglycemia, i.e., using the smart alert feature.

[0148] Another potential input includes the type of diabetes of a given user and the specific manifestation of diabetes. The cognitive awareness of a type I patient may differ from the cognitive awareness of a type II patient. Thus, the generation of smart alerts may differ between the two, and the timing of the alerts may differ as well. In one implementation, the difference between these two situations is limited to the threshold level at which the estimation or prediction determines cognitive awareness. In other words, the threshold level is varied between these two types of diabetes, and this threshold level is compared to the estimated or predicted cognitive awareness, which results in the generation (or non-generation) of a smart alert.

[0149] Other different and individualized physiological effects and patterns of influence may be seen. For example, it may be common for a patient to hover around 70 mg / dL, but it may be extremely rare for that patient to suddenly slow down after exceeding 60 mg / dL. In this example, by determining a glucose concentration value and including the rate of change of this glucose concentration value in an estimate or prediction, an abnormal response may be detected and, if detected, an alert may be issued.

[0150] Systems and methods according to the present principles that incorporate cognitive awareness in the decision to alert the user are customized and / or bi-specific for each individual user, with the customization / adjustment occurring by machine learning, for example, using the data and sources described above. Other important sources of customization or individualization include varying the operation of the smart alert feature based on the patient's physiology, age, precise diagnosis, etc. Thus, implementation of systems and methods according to the present principles provides significant benefits in reducing the burden on the user or clinician to set alarms and alert thresholds that may not even be known in some cases due to day-to-day fluctuations. That is, in many cases, without the present systems and methods and subsequent technological advances in predicting or estimating cognitive awareness, there is no easy way for a user to think of how to customize their alerts.

[0151] In other variations, the systems and methods may generate multiple profiles for a patient depending on activity, illness, pregnancy, menstrual and other cycles, and the like.

[0152] Still other data sources may include telemetry and metabolic rates, etc. Still other potential data and data sources may include correlation data (such as a user's perception of daytime versus nighttime), pain data, heart rate variability, stroke volume, cardiovascular health, insulin delivery capacity, body temperature (which affects insulin absorption rate), insulin type (based on insulin sensitivity measurements, profile, peak, time between peaks), barometric pressure (affects CGM and insulin absorption), insulin sensitivity, a determination of which factor is most influential for a given user, e.g., exercise versus diet, health or physiological conditions known to affect certain parameters, illness, whether the smart device is in a particular mode such as airplane mode, exception management, (e.g., identifying what is normal for a particular patient and implementing exception management rules), whether the smart device is in training mode to perform the smart alert function, clinician-set parameters, response elicitation data, etc. Thus, user awareness may relate not only to whether the user is aware of hyperglycemia or hypoglycemia, but also whether the user is experiencing a situation with a highly complex response that the user simply cannot be aware of cognitively due to the inherent complexity of the situation.

[0153] For any given input, ambiguous logic may be used in determining the value of the input. In some cases, ambiguous processing and ambiguous output may also be used. More specifically, alerts or warnings, including smart alerts and alarms, may be triggered in a manner that is not entirely dependent on the glucose value crossing a threshold. In one implementation, an algorithm may be used that triggers an alert when the user's glucose value hovers slightly below the hyperglycemia warning threshold or slightly above the hypoglycemia warning threshold for a given predefined duration, even if the threshold is not crossed. This implementation is similar to the hovers implementation described above. For example, the user's hyperglycemia warning threshold may be set to 180 mg / dL, and the user's consecutive glucose values ​​may be 178 mg / dL, 175 mg / dL, 177 mg / dL, and 178 mg / dL. Although the user's glucose value did not reach 180 mg / dL, the algorithm recognizes that the glucose value is close to the threshold and provides the user with a smart alert after 20 minutes (or other duration that may be configurable by the user). Such implementations are useful because the user may be prompted to take corrective action, such as a small bolus or exercise, at a time when the user would not otherwise have paid attention to their glucose values. In another implementation, an algorithm may be used to attenuate the warning / alarm if the user's glucose values ​​are fluctuating between and exceeding the warning threshold, but at a slow rate of change. As an example, the user's hyperglycemia warning threshold may be set at 180 mg / dL, and the user's consecutive glucose values ​​may be 170 mg / dL, 178 mg / dL, 182 mg / dL, 179 mg / dL, 181 mg / dL, 178 mg / dL, and 182 mg / dL. An alarm is triggered for a transition from 178 mg / dL to 182 mg / dL, but the alarm is not triggered for a subsequent transition from 179 mg / dL to 181 mg / dL if the user acknowledges or dismisses the alarm. Such an implementation may be particularly useful as it helps avoid frustrating situations faced by users when they are aware of borderline glucose values ​​and do not want, desire, or need repeated alerts.In some implementations, use of this technique may be safer at hyperglycemic and then hypoglycemic warning thresholds.

[0154] Other variations may include variations in the frequency at which input data is received or output data is displayed. In particular, systems and methods according to the present principles may be configured to receive additional data when dynamic risks are imminent, for example by updating more frequently, e.g., every minute instead of every 5 minutes. For example, if impending hypoglycemia is predicted based on the current glucose level and glucose change rate, the display may be updated every minute instead of every 5 minutes. In such implementations, more advanced information may also be displayed, such as an indication of whether the glucose up or down trend is accelerating. More advanced visual appeals may also be used to show this inferred, calculated, estimated, or predicted information. In this way, the user is provided with better and more frequent information at the time the user needs it most. Also, using the most accurate information may enable the system to further suppress warnings, for example, when a dangerous situation corrects itself. In this way, the user is further prevented from becoming annoyed with unnecessary warnings.

[0155] As another example of input to the estimation or prediction of cognitive awareness, signal metadata may be used. For example, an inflection point that, once determined, causes a convergence on the inflection region may be used. As a particular example, the system may sample more frequently at inflection points than at non-inflection points. Such inflection points may include points where the glucose signal changes direction, or other points where fine tuning or additional data may be useful in determining parameters useful to the user, including parameters that are critical or useful in determining whether the user is aware of a diabetic condition that merits attention. The benefits of which are as described above. In this regard, it is noted that by sampling more at such points, sampling at different points may be reduced, which may be particularly useful in saving battery life, reducing power requirements, sensor and monitor life, etc. More frequent sampling and subsequent transmission of data for rendering may also be used in situations where the user is approaching or is hypoglycemic or hyperglycemic. In other words, zones, etc. may be used as the inflection points described above.

[0156] In some implementations, inputs may be received from wearable sensors. In one implementation, data available from a smartwatch may be used either alone or to augment other data. In a particular example, sensors and signals collected by smartwatches such as the Apple Watch and Microsoft Band may be used to augment hypoglycemia detection. Such signals may include signals from a heart rate sensor, sympathetic / parasympathetic balance (which may be inferred from heart rate), sweat / emotion / stress from a conductance sensor, and motion data from an accelerometer. Such signals may be used in addition to the CGM signals. The algorithms used to process these auxiliary signals may be trained by the patient's own data using the CGM to aid in training. These algorithms may be optimized offline, e.g., in the cloud. Detection criteria may then be transmitted to the patient's smartphone and / or smartwatch. Although the CGM may not be able to detect hypoglycemia, when augmented with auxiliary signals indicative of possible hypoglycemia, the patient may be alerted to the suspected hypoglycemia, thereby enabling the effects to be avoided. Alternatively, after the algorithms used to process the auxiliary signals have been trained, the smartwatch signal may be able to detect hypoglycemia without the use of a CGM. In this use case, adjustments to the algorithm may be necessary to optimize sensitivity or specificity.

[0157] In other implementations, smartwatch sensors and machine learning can be used to detect and quantify sleep. For example, if the user is asleep, as determined by motion data from the accelerometer, it can be inferred that the user is not cognitively aware of any diabetic condition that merits attention, or even any diabetic condition at all. Thus, the alert changes can be configured to not suppress any smart alerts if the system infers or predicts that the user is asleep. Other sleep sensors can also be used in the estimation or prediction of cognitive awareness.

[0158] As an example of an alternative type of sleep sensor, temperature may be used as a mechanism for determining whether a patient is asleep. For example, such a sleep sensor may be used to monitor time spent asleep versus awake time. In implementations, a temperature sensor placed on the skin, which may be a separate temperature sensor or a sensor implemented in an adhesive patch attached to the patient, may take advantage of the strong correlation between temperature data and time spent asleep.

[0159] Further inputs may be understood as disclosed in U.S. Patent Application No. 62 / 289,825, filed February 1, 2016, entitled "SYSTEM AND METHOD FOR DECISION SUPPORT USING LIFESTYLE FACTORS," which is owned by the assignee of the present application and is hereby incorporated by reference in its entirety.

[0160] output The output of the smart alert function is generally a displayed output, however the algorithm itself may have an "output" in the sense of calculating, estimating, or predicting user awareness, and thus suppressing an alert (e.g., when the user is estimated or predicted to be cognitively aware of a diabetic condition that merits attention), or simply causing the alert generation step to not occur, is also considered an "output" in this sense.

[0161] The output of the smart alert function can also be in several forms, such as visual displays, audible indications, and tactile indications. Such displays / indications may be combined in various ways to support the smart alert function. For example, a visual display may be used to provide an indication of the diabetic state, but an audible or tactile indication may be provided by the smart alert function based on cognitive awareness. Alternatively, a visual display may be used to provide an indication of the diabetic state (e.g., value and trace graph), but another visual display, e.g., overlaid on the first, may be used to provide the smart alert. In another implementation, a prompt on the display may be used to test the user's cognitive awareness, and if this test indicates that the user is not cognitively aware, a smart alert may be generated. How the prompt and its response indicate cognitive awareness may vary. The prompt on the display may be explicit, asking if the user is aware of an impending diabetic state that merits attention, or may be more subtle or implicit, requiring less information but providing the data necessary for an estimation or prediction of cognitive awareness. Such implicit or subtle prompts or questions may be more appropriate for younger or less experienced users, or for sophisticated users, or for users who have less experience with the biological symptoms of the diabetic condition. Thus, systems and methods according to the present principles may use user profile information in determining or calculating what types of prompts or questions to render in the user interface.

[0162] The rendered user interface resulting from the output of the smart alert function is tightly tied to the calculated estimate or prediction of the user's cognitive awareness. If the user is predicted or predicted to be cognitively aware of a diabetic condition that merits attention, the user interface typically does not display the smart alert. Conversely, if the user is predicted or predicted to be cognitively unaware, the smart alert is typically displayed, which typically involves a change in the user interface. Such an output is typically considered much more effective and efficient for the user, and then varies only based on the threshold value, for reasons given above, e.g., smart alerts cause less re-alerts, less alert fatigue, etc. This further allows for significant savings in battery power and computing cycles.

[0163] In a given rendered output, the smart alert may further be displayed with a representation of the confidence or uncertainty. The confidence or uncertainty level may be calculated by the system and method according to the present principles based on error bars calculated on the data, known or determined calibration ranges or errors, known or determined sensor errors, etc. The confidence or uncertainty may be represented to foster trust between the user and the system. This trust is increased when the system performs additional machine learning steps and has enough data to make accurate and highly personalized suggestions and recommendations to the user. At such time, the system and method according to the present principles may reduce the display of the uncertainty representation in the smart alert output, since it is no longer applicable. As a specific example, a hypoglycemia warning occurring during a possible artifact (e.g., a "drop and recover" failure) may be represented with a degree of uncertainty. Insulin dose recommendations may be made to account for the uncertainty in the glucose estimation. Such recommendations may occur, for example, on the first day of a CGM session. The recommendation then expresses this uncertainty to the user in a manner that fosters trust in the monitoring app and smart alerts functionality, since the user knows that the system will "guess" or predict rather than making a definite recommendation. In this way, the smart alerts engage the user and foster trust in the system. Later, after the fault no longer exists, the monitoring app and smart alerts functionality can represent the data without or with a reduced degree of uncertainty, increasing confidence in the monitoring app not only in its accuracy, but also in its noticing and handling of errors.

[0164] Smart alerts are generated and rendered, which may be configured on the user interface to be minimally intrusive to the user, such that the rendering of the glucose values ​​themselves is de-emphasized while trend information is emphasized, which may be accomplished by rendering various arrows or zones on a display or screen. This may be accomplished by a physician- or user-adjusted control setting that adjusts the rendering of the display to focus on the trend or trend arrows, with the glucose count being less visible.

[0165] The aggressiveness of the smart alert function can be adjusted by a user-configurable setting, e.g., a slider bar. The slider bar can affect not only the input but also the output. That is, the slider bar can be used to affect the operation of the smart alert function on the input side as well as the output side. For a user who desires a high aggressiveness setting, more smart alerts are usually provided than a user who desires a lower aggressiveness. In other words, if the user interface setting is set to a high aggressiveness, the system can automatically control the threshold level of cognitive awareness (on which the smart alerts are based) to be higher. Since the cognitive awareness threshold level is more difficult to achieve, more smart alerts are generated when the threshold level is higher. In this way, the system becomes more aggressive. Conversely, if the user controls the user interface setting to a lower aggressiveness level, the threshold level of cognitive awareness can be reduced, causing fewer smart alerts.

[0166] Dynamic risk can affect how quickly input data is accumulated. Dynamic risk can also affect how frequently data is updated, providing a more granular and accurate way for users to receive notification of their risk assessment. This risk can be measured by suitable calculations based on glucose values ​​and rates of change, and can include more advanced calculations, such as including the glycemic urgency index described in the patent applications incorporated by reference above. That is, based on dynamic risk calculations, which can include glucose values, glucose rates of change, and other complex derived values ​​(typically involving one or more of these real-time values), the system can automatically adjust data transmission settings, such as frequency, whether to use pushed or pulled data, screen refresh rate, data update and recalculation rate, and calibration frequency.

[0167] A smart alert is generated and rendered on a display, or more specifically, on a user interface rendered on the display, and the smart alert can take several forms, including having various levels of predictive levels. For example, referring to FIG. 7, a smart alert may indicate a diabetic condition that merits attention and may further provide details of the current glucose value, the predicted, e.g., predicted glucose value within a certain time frame, e.g., 20 minutes, etc. The smart alert shown in FIG. 7 may be overlaid on top of a trace graph, which is shown in FIG. 8. As can be seen, the smart alert in FIG. 7 provides a detailed warning to a user who is unaware of their diabetic condition that merits attention, in this case impending hypoglycemia (indicated by the local minimum in FIG. 8).

[0168] 9-29 illustrate an exemplary user interface and smart alerts built around consideration of interface usability and other factors. For example, the use of displayed arrows can be helpful to users at times, and the meaning of the arrows is sometimes unclear. For example, while the arrows tend to convey urgency or the need to take action, users may be confused as to whether the arrows point to a prediction or a trend. Thus, in one implementation, it has been found useful to display on the user interface the following: the current value of glucose, a threshold alert level, e.g., the most relevant threshold alert or alarm level given the current value of glucose, e.g., "55", a symbol, and a color, e.g., yellow or red for a diabetic condition that deserves attention that the user is not cognitively aware of, with the particular color depending on the urgency of the condition.

[0169] The symbols may be as shown in Figures 9-14, such as a dotted line starting with a bold dot and ending at a threshold (Figure 9), a dotted line with a directional arrow (Figure 10), a dotted line that indicates a direction when read from left to right (Figure 11), a line segment with a directional arrowhead (Figure 12). In some cases, for example, for sophisticated users, only an alarm is needed, which is shown in Figure 13. An alarm with trend arrows and color indicators is shown as an alternative user interface in Figure 14. All of these elements, and combinations of these, are useful to provide context to the smart alert. Symbols may be particularly convenient for use with children, as they are instantly identifiable and easy to communicate with parents.

[0170] As can be seen in Figures 9-14, smart alerts are usually provided as an overlay on top of another user interface typically associated with a CGM monitoring application. Thus, the overlay is often over a trend graph that may or may not include a forecasting element, sometimes indicated by an arrow or dotted line. In general, it has been found that having two different arrows appear on the screen can confuse the user, and thus if trend arrows appear in the smart alerts, they should not appear or should suppress the underlying glucose trace chart.

[0171] It has also been found useful to indicate the end point of the trend, and this is shown in Figures 15-17. This end point may indicate a time (quantitative, such as "within 20 minutes," or qualitative, such as "soon"), a value, or both. In Figures 15-17 the time portion of the end point is indicated qualitatively or quantitatively by a segment on the clock indicating 20 minutes, and within the text alert itself. The value portion of the end point is indicated in this case by the hypoglycemia alert threshold, e.g., 55 mg / dL. The current value is also shown in Figures 15-17 along with a trend arrow and a color indicator. The color indicator is typically based on the urgency of the smart alert, which is determined by the current glucose value, its rate of change, etc.

[0172] Figures 18 and 19 show a glucose trace chart (Figure 19) and a smart alert (Figure 18) superimposed thereon, and similarly Figures 20 and 21 show a glucose trace chart (Figure 21) and a smart alert (Figure 20) superimposed thereon. These figures show a smart alert that has been found to be useful, which includes a text alert "Imminent Hypoglycemia Imminent", the current value of glucose, i.e., 93 mg / dL, a trend arrow, an indication of the associated threshold, i.e., 55, and a time indication shown by clock segments. Figures 20 and 21 further include an indication of the time end point within the text portion of the smart alert alert.

[0173] In many cases, it has been found to be beneficial to display a quantitative time-based alert rather than a qualitative alert, as illustrated by Figures 22-29. Figures 22-29 illustrate a time sequence of smart alerts showing a time progression over a 15 minute period. Figures 23, 25, 27, and 29 show the underlying glucose trace graphs with their respective smart alerts shown by Figures 22, 24, 26, and 28. The initial time point is shown by Figures 22, 23, the 5 minute time point is shown by Figures 24 / 25, the 10 minute time point is shown by Figures 26 / 27, and the very first 15 minute time point is shown by Figures 28 / 29.

[0174] As mentioned above, the use of the color red has been found to be beneficial in providing smart alerts. However, the color red may be modified based on the urgency of the smart alert. For less urgent smart alerts, for example, a lighter shade of red may be used.

[0175] In another implementation, the smart alert may be provided on the lock screen of a smartphone. Figures 30-41 show such an implementation, both generally and in the context of low glucose alerts. As can be seen, when the user sees the notification on their smartphone (Figures 30, 34, and 38), the user may unlock their phone and see a "pop-over" notification of the alert (Figures 31, 35, and 39). An "OK" button is shown and, once activated, a trends screen may be displayed (Figures 32, 36, and 40). In these figures, the banner covers other navigation buttons within the application, and the inability to access such navigation functions reaffirms the importance of the alert. The user can close the banner alert by tapping the X button and continue to use the application. Alternatively, the banner disappears once the user corrects their glucose to raise their glucose value to a good level. In an alternative implementation, the alert banner may be repositioned below the navigation pane, allowing the user to use navigation functions even though the alert is displayed. This can be configured to be based on the urgency of the alert.

[0176] In a displayed user interface implementation, or in any other implementation, tapping on an appropriate icon displayed on the screen, e.g., a magnifying glass, may cause the display of additional information or invoke other functionality. For example, tapping on an appropriate icon may display various levels of forecasts, e.g., showing the user what to expect over the next 10 or 15 minutes. Such forecasts may be provided by text indicators, dotted lines on a glucose trace graph, arrows, endpoints indicating time and glucose, etc.

[0177] In another embodiment, the smart alert function may be implemented such that the volume of the alert or warning sound is automatically adjusted to be appropriate taking into account the detected ambient noise level. In other words, the volume of the alert or warning sound may be adjusted taking into account the detected ambient noise so that the signal-to-noise ratio is sufficient to allow the user to hear the alert or warning. Such volume may also be customizable by the user. The detection of the ambient noise level may be performed by including a microphone or other sensor to detect the ambient noise level. In a smartphone implementation, the microphone of the phone may be used. In other words, the system measures or detects the ambient noise level and automatically adjusts the volume of the alert or warning sound to achieve a desired predetermined signal-to-noise ratio or alternatively SINR.

[0178] A default volume setting may be provided that is sufficiently louder than the estimated ambient noise level. If the measured noise level is greater than the noise level estimated by default or the noise level detected or estimated during customization, the volume of the warning / alarm may be automatically increased gradually or suddenly to a level such that the warning or alarm is audible to the user. For example, the decibel level of the warning / alarm may be set to have a predetermined relationship to the ambient noise level, e.g., to achieve a predetermined signal-to-noise ratio as described above. The noise level in such an implementation may be advantageously measured immediately prior to issuance of the warning / alarm.

[0179] In other implementations of the output, where the user is experiencing an unpleasant event, e.g., hypoglycemia, hyperglycemia, uncontrolled glucose, etc., systems and methods according to the present principles may automatically generate a post-event smart alert that shows some degree of forensics, informs the user as to how the event occurred, and provides helpful advice to prevent such events in the future. Such automatic generation of forensic information may be provided in particular in cases where the system is able to independently identify the cause of the unpleasant event thanks to the determination or detection of signal characteristics or other diagnostic information. By providing such forensics, the user is well aware that the smart alert function is configured to track, detect, and programmed to alert such unpleasant events, increasing the user's reliability and trust in the system. Additionally, data regarding such events may be advantageously used to improve the operation of the smart alert application / function through the use of machine learning algorithms.

[0180] The system may further be configured to show a note or other modifier associated with the smart alert. For example, the system may provide an indication such as "Waiting for 1 hour before issuing an alert because we are waiting for [known "working" therapeutic aspects, e.g., insulin or food or exercise] to take effect. However, please be aware that you may be alerted or warned about this condition in the near future." Such an indication provides a compromise where the system may have some confidence in its estimate or prediction of the user's cognitive awareness, but this confidence is not clear and equivalently, the level of estimate or prediction is not sufficient to establish without question whether the user is cognitively aware or the user is not cognitively aware. In certain implementations, such a note or modifier may be configured to appear with the smart alert (via various string manipulation subroutines) whenever the estimate or prediction of cognitive awareness is within 5% of a threshold level. It will be appreciated that the content of the string modification will vary depending on the type and content of the smart alert.

[0181] Certain smart alert features may be utilized even during the warm-up period of the sensor. More specifically, once a new sensor is installed, there is typically a period of time during which no information is available, e.g., two hours. During this time, blood glucose values ​​are not guaranteed to be accurate. However, trend values ​​can still be obtained and these indications are beneficial to the user. Fingertip blood glucose values ​​may be used during this warm-up period to obtain accurate glucose values, and in some cases, system analysis of trend indications obtained during the warm-up period may be used as a trigger to obtain such fingertip values. In an implementation, if the glucose monitoring algorithm used the last known measurement from a removed sensor, the algorithm may automatically cause an indication or user prompt indicating that the user should perform a fingertip blood draw as a safety check. For example, if the last known glucose value from a removed sensor was 76 and had a downward trend, a drop in ion count during warm-up may indicate that the user is prone to a hypoglycemic event. When actual glucose value data is unavailable during warm-up, the estimate or prediction of the user's cognitive awareness of a diabetic condition that merits attention will be correspondingly lower. In this situation, a smart alert may be generated that the user should perform a fingertip blood draw. In another example, if the last known glucose value from a removed sensor was 76 and relatively stable, but a reduced real-time ion count was measured during warm-up, this again may indicate that the user is not cognitively aware of a potential hypoglycemic situation, especially since the user did not even have the benefit of a downward trend indication during the previous sensor session. In summary, the smart alert function may use previous sensor session data or real-time trend information in the generation of the smart alert, where the generation is typically based on the user's level of cognitive awareness compared to a threshold criterion, which itself may depend on one or more data inputs.

[0182] It should be noted that in further implementations, the CGM and low glucose warning thresholds help the user identify impending hypoglycemia so that the user can take steps to avoid or minimize hypoglycemic episodes. Such functionality is particularly useful when patients have difficulty identifying low glucose based on physiological symptoms such as shivering and sweating, which is the case for users with reduced hypoglycemic awareness. Hypoglycemic awareness can vary by episode and has been shown to be affected by recent hypoglycemic events. Notably, recent hypoglycemic events reduce the user's awareness of subsequent episodes.

[0183] Thus, in further implementations of systems and methods according to the present principles, the characteristics of the alert may be modified as a function of the recent history of hypoglycemic episodes, such that an alert is more likely to be provided sooner or more prominent in situations where the patient is less likely to be aware of his or her hypoglycemia as a result of his or her symptoms. Exemplary alert characteristics that are modified include, for example, thresholds, intensity, visual display, etc. Such implementations minimize the number and / or annoyance of nuisance alerts (alerts provided when the patient is already aware of hypoglycemia or more frequently than desired) when alerts are less helpful, and maximize the sensitivity and / or prominence of the alert when the patient cannot rely so much on the symptoms. In other words, the user's cognitive awareness may be further based on the recent history of hypoglycemic episodes, since hypoglycemic episodes have been shown to desensitize users to subsequent episodes. In implementations, a recent history of hypoglycemic episodes may be collected from past or historical data and used in combination with real-time data, e.g., glucose data, glucose change rates, etc., particularly real-time data indicative of potential hypoglycemia, to provide a data output useful in estimating or predicting a user's cognitive awareness. The data output useful in estimating or predicting a user's cognitive awareness may be used, for example, to raise or lower a threshold at which the user is estimated or predicted to be cognitively aware. If there is a recent history of hypoglycemic episodes, the threshold may be raised, thus resulting in additional smart alerts. If user data indicates that the frequency of hypoglycemic episodes has decreased, e.g., due to better diabetes management by the user, the threshold may be raised conversely, decreasing the number of smart alerts.

[0184] In alternative implementations, the smart alerts displayed on the user interface may incorporate or have outputs that may take any of the forms described in U.S. Patent Application Publication No. 2015 / 0289821, entitled "GLYCEMIC URGENCY ASSESSMENT AND ALERTS INTERFACE," which is owned by the assignee of the present application and is incorporated herein by reference in its entirety.

[0185] Use with Pumps and Other Delivery Devices Smart alerts may be beneficially used in combination with data from infusion pumps and other such delivery devices. To some extent, the use of smart alerts depends on the use of the delivery device, whether an open-loop, closed-loop, or semi-closed-loop system.

[0186] In an open loop system, if it is estimated or predicted that the user is cognitively aware of a diabetic condition that merits attention, smart alerts may be used as described above to provide, for example, alerts regarding bolus administration information. For example, in the case of meal boluses, machine learning may be used to determine the user's meal pattern, and if a glucose trace is encountered after a meal that is not part of the typical meal pattern, a smart alert may be generated based on such data to suggest a bolus administration. Besides determining that a bolus administration should be injected, machine learning and smart alerts may also be used to determine a timing that is preferably not too late or too early. Such learning typically involves analysis of past data to learn at what point during a "meal event" the bolus administration should be delivered. In this case, the past data, the meal event data, is used in combination with real-time data that indicates, for example, that the user is about to eat or is approaching a typical meal time (which may be determined by clock data or event data, etc.). Similarly, machine learning may be used to determine that the user often takes over-boluses, for example, or so-called "rebound" or "frenzy" boluses. This may be particularly relevant for a smart alert app or feature to receive data from a pump or pen. If the system can determine that the user has a tendency or pattern toward such over-bolusing, this tendency or pattern information may be used to provide a smart alert to remind the user not to over-bolt. More generally, this information may be used to broadly inform the smart alert feature. Such use may be particularly important since users are particularly susceptible to over-bolusing when they are trending upwards, e.g., toward hyperglycemia.

[0187] As another example of the use of smart alerts in the context of delivery devices, when a user changes an infusion set, there is a higher than normal risk of not having adequate insulin absorption or having an occluded infusion site or cannula. Although an occlusion alarm is present, this alarm is not usually useful in detecting problems related to the infusion site, especially if the cannula is not completely occluded. Standard care dictates that users check their blood glucose levels two hours after changing their infusion set to ensure that they are receiving adequate insulin delivery. Undetected cannula problems can lead to hyperglycemia and even potentially life-threatening ketoacidosis, constituting a major risk of multiple daily injections versus the use of pump therapy.

[0188] Systems and methods according to the present principles can detect problems with infusion sets early, before the patient develops ketones, and can use smart alerts to provide warnings of diabetic conditions that merit such attention to users who are not normally fully cognitively aware that a problem exists in such situations. For example, knowing when a patient changes their infusion set can be used to determine the probability of a bad infusion site, and such data can be further used to distinguish between other rises in blood glucose and infusion set problems. In particular, the system can use data about cannula fills, reservoir changes, and pump triggers to determine the events in which a user has changed all or part of their infusion set, and such data can be used in combination with CGM data as part of an estimate or prediction of the user's cognitive awareness, and fluid pressure data is useful for learning personalized alerts for possible infusion set problems and can be used in a similar manner. CGM data and pump data used separately are usually insufficient to detect infusion set problems, but together these data provide more specific alerts that can prevent dangerous events, especially hyperglycemic events. Specifically, this can be used to determine and warn of problems with the infusion set and can alert the user to address the problem before medical problems occur, including ketoacidosis.

[0189] Specifically, with reference to system 350 of FIG. 42, the system of FIG. 1 is illustrated as also receiving data from pump 52 (or a source of pump data). By analyzing the pump data, for example by comparing the received pump data with known pump data patterns or signatures particularly related to problems that prevent the pump from operating properly, the CGM app can detect cannula / infusion set problems and provide smart alerts therefor. Such problems are particularly difficult and notoriously difficult for a user to detect, and therefore may be weighted in the prediction or estimation of the user's cognitive awareness of a diabetic condition that merits attention. Thus, and with reference to flowchart 400 of FIG. 43 (based on flowchart 101 of FIG. 2), a method for providing smart alerts may include receiving pump data (step 54), which may be used in the calculation of an estimation or prediction of the user's cognitive awareness.

[0190] The pump data received in step 54 may include data regarding bolus information, pump stop data, pump alarms, pump rewind (time), pump water infusion (time), cannula fill (timing and volume), fluid pressure or other data used to generate occlusion alerts, etc. In one implementation, an API that allows access to such data may be used in the monitoring application. Conversely, the smart alerts functionality may also be provided within the context of an application that operates and controls the delivery device, in which case data from the CGM application or other monitoring app may be used via an appropriate API for the smart alerts functionality running on the delivery device.

[0191] Thus, in cases where the user is not cognitively aware of a pump problem such as a blockage, a smart alert is provided to inform the user of a diabetic condition that merits attention, and thus may provide a more useful alert to the user than a traditional alert.

[0192] In other implementations of smart alerts in the context of a pump / pen or other delivery device, the user interface of such delivery device may be used to acknowledge receipt of the smart alert, and conversely, the user interface of the monitoring device may be used to acknowledge receipt of alerts initiated by the delivery device. In other words, data relating to a smart alert generated by one device may be communicated to, rendered, and possibly acknowledged by, another device using an appropriate transmission protocol. If acknowledged, this acknowledgment may be communicated back to the generating device using an appropriate transmission protocol.

[0193] When implemented in an open-loop system, the smart alert function may provide a smart alert to prompt the user to take various actions based on the user's cognitive awareness. In a closed-loop or semi-closed-loop system, both the user's cognitive awareness and the machine's cognitive awareness may be considered, where the latter relates to whether the machine is aware of a diabetic condition that merits attention. This implementation is illustrated by the flowchart 450 of FIG. 44. Similarly, in the flowchart 450 based on the flowchart 101 of FIG. 2, after the step of determining the user's cognitive awareness (step 17), a step of determining whether the system is cognitively aware of a diabetic condition that merits attention (step 21) may be used. If the machine is cognitively aware of the condition, then again there is no need for a smart alert, and the smart alert may be suppressed or not generated (step 11). If the machine is not cognitively aware of the condition, a smart alert may be provided (step 19). Note that while the estimation or prediction of the user's cognitive awareness is itself a task performed by the machine, it is different from the machine's cognitive awareness of step 19, as the latter relates to whether a delivery device is connected and treating or preparing to treat a diabetic condition. For example, if the system determines that the user may be hypoglycemic, e.g., based on glucose values ​​and rate of change, the machine's cognitive awareness may stop the pump. This is distinct from the determination of step 17, where the user is aware of the potential for impending hypoglycemia and takes steps to treat the hypoglycemia, which is part of a typical pattern in which the user treats by, e.g., consuming carbohydrates.

[0194] As an additional step is provided before a smart alert is generated, in a closed loop system, smart alerts are generated less frequently than are generated in an open loop or semi-closed loop system, and typically only when the system itself is unable to treat a diabetic condition that merits attention.

[0195] A particular implementation is described in the context of a user approaching a hypoglycemic situation. Instead of simply using a threshold that automatically stops the insulin pump if it exceeds a low glucose threshold, if the smart alert function estimates or predicts the user's cognitive awareness such that the user is cognitively aware of a diabetic condition that merits attention, the pump may be stopped sooner than if the user were not cognitively aware to avoid a dangerous hypoglycemic situation. A typical situation in which the user is unaware is at night while the user is asleep.

[0196] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Systems and methods are described for providing users with smart alerts that can alert users to diabetic conditions that merit attention in a more effective manner than conventional work.

[0197] Variations will be appreciated. For example, the system and method may interact with and use other applications to provide alerts. For example, if the system estimates or predicts that the user is not cognitively aware of a diabetic condition that merits the attention of impending hypoglycemia, but data from a GPS app on the user's smart device indicates proximity to a source of food, e.g., a gas station or food store, an alert may appear on the GPS app regarding the impending condition and where remedial action can be taken. Generally, data from the GPS app is data that provides information regarding the location of the source of food, but data from other apps, e.g., a food tracking app that can also provide information regarding restaurant locations, may also be leveraged. Such alerts generally use appropriate APIs between the GPS app and the CGM app, and other inter-app APIs used. In some cases, data from the GPS app indicates that the user is moving in a direction toward a commonly accessed food source, e.g., a restaurant that the user frequently goes to. In particular, the determination may be made explicitly that there are no other places that the user commonly frequents in that direction, and then such GPS data may be used to at least temporarily suppress the generation of a smart alert in the event of a potential mild hypoglycemia. Generally speaking, the GPS data used in this manner can be advantageously used in estimating or predicting the user's cognitive awareness.

[0198] Implementation of systems and methods according to the present principles to enable smart alerts / features. A variety of systems may be used to implement smart alert functionality in accordance with the present principles. For example, in one implementation, a mobile computing device dedicated to health and diabetes management, e.g., a smart device, e.g., a smartphone, may be used. The mobile computing device may be a dedicated health / diabetes management device or a more general device specifically adapted for health and diabetes management. The device may be configurable by the user to fit their lifestyle and preferences. The mobile device may be based on Android or iOS (or other) operating systems and may utilize a touch screen interface. In some cases, the operating system may be customized or controlled, e.g., with respect to management services to provide data to the cloud and optimize / control elements of the user experience. The device may include one or more common wireless communication links, such as Bluetooth® Low Energy. The device may also include WiFi or other data connectivity technologies for remote monitoring, data transfer, and software updates.

[0199] A mobile computer may be used in conjunction with ("tethered" to) a wearable computing device such as a smart watch, which may function usefully without being directly connected (tethered) to a mobile device. Such a watch or other such wearables may include sensors such as a heart rate monitor, and data from such a monitor may also be used to inform the smart alerts function. For example, such a monitor may be used (perhaps in combination with accelerometer data) to determine whether a user is exercising, and if so, whether the user may desire more or fewer alerts / alerts.

[0200] Such wearable devices may also allow the possibility to configure the smart alert function to render a visual display, providing greater privacy and discretion in social situations and utility in, for example, sleep. The smart alert function may be configured to first provide an alert to the wearable if a wearable with a tactile display is detected, and subsequently alert other devices, for example a smartphone, if the wearable's alert or alarm is ignored.

[0201] The user may choose from a curated ecosystem of apps. This selection may include, for example, apps from Databetes (meal memory), TrainingPeaks (activity / fitness), Tidepool, MyFitnessPal, Nike+, Withings. Other apps may include apps for retrospective insight / pattern recognition aimed at optimizing therapy and determining if the user is cognitively aware of a diabetic condition that merits the user's current attention. The ecosystem may further include an app that provides basic diabetes management instructions for a user (or the user's parent) who is newly diagnosed with type I diabetes. A different set of instructions may be included for users who are newly diagnosed with type I diabetes.

[0202] The mobile computer enables data connectivity between the user (patient) and clinician via the EMR (e.g., Epic). The mobile computer platform enables and facilitates the user / provider dialogue.

[0203] In another particular implementation, the mobile computer may be configured to not include functionality unrelated to health care.

[0204] Safety settings are generally implemented. For example, the smart alert function may be disabled for a period until CGM data is collected. In this way, the settings may be data-driven and data-validated. For example, one week's worth of data may be required, two weeks' worth of data may be required, one month's worth of data may be required, etc. As mentioned above, the initial setting or training may be performed without data or using data from a conventional user's device (associated with the target user). This may be followed by subsequent optimization, in particular the smart alert function may perform a data analysis or diagnostic subroutine to determine whether sufficient data has been collected to enable the function associated with the smart alert to, for example, predict or estimate the user's cognitive awareness, or may alert the user or HCP to do so. Alternatively, the smart alert function may be performed automatically but may require confirmation from the user or HCP.

[0205] As previously mentioned, users are often annoyed by receiving multiple warning or alarm notifications, but the smart alert feature according to the present principles may serve to minimize such sources of annoyance. However, if multiple notifications are requested and provided, the smart alert feature may also be configured to allow subsequent notifications to include additional information so that the user receives a full collection of actual or potential warnings. For example, if an initial notification provides an indication that the user is heading for hypoglycemia, the system may understand not to alert the user again via the smart alert feature or suppress the warning / alarm until another warning threshold is reached, and then the subsequent notification may include a different substantive message, for example, "Low for 20 minutes now."

[0206] Systems and methods according to the present principles may further be used to detect missed opportunities or chances of action. In particular, machine learning may be used to learn when users typically take actions, especially actions that result in positive outcomes. If a similar situation is encountered but the user does not act in a positive way, for example, the user is away from a smart device or the like and is unaware of the opportunity, then a smart alert may be provided regarding the missed opportunity.

[0207] In particular, systems and methods are described for achieving smart alerts based on inferences or predictions of whether a user is cognitively aware of a diabetic condition that merits attention. Numerous variations of the above will be understood given this description.

[0208] Sensor Systems 45 illustrates an example system 100 according to some example implementations. The system 100 includes a continuous analyte sensor system 8, which includes sensor electronics 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 glucose meter 4. The continuous analyte sensor 10 may be physically connected to the sensor electronics 12 and may be integral (e.g., non-releasably attached) or releasably attachable to the continuous analyte sensor 10. The sensor electronics 12, drug delivery pump 2, and / or glucose meter 4 may be coupled to one or more devices, such as display devices 14, 16, 18, and / or 20.

[0209] In some exemplary implementations, the system 100 may include a cloud-based analyte processor 490 configured to analyze analyte data (and / or other patient-related data) provided over the network 406 (e.g., via wired, wireless, or combinations thereof) from the sensor system 8 and other devices, such as the display devices 14-20, associated with the host (also referred to as a user or patient), and generate reports that provide high level information, such as statistical data about the analytes measured over a particular time frame. A thorough discussion of using a cloud-based analyte processing system can be found in U.S. Patent Application No. 13 / 788,375, entitled "CALCULATION ENGINE BASED ON HISTOGRAMS," filed March 7, 2013 and published as U.S. Patent Application Publication No. 2013 / 0325352, which is incorporated herein by reference in its entirety. In some implementations, one or more steps of the factory calibration algorithm may be performed in the cloud.

[0210] In some exemplary implementations, the sensor electronics 12 may include electronic circuitry associated with measuring and processing the data generated by the continuous analyte sensor 10. This generated continuous analyte sensor data may also include algorithms that may be used to process and calibrate the continuous analyte sensor data, although these algorithms may be provided in other manners as well. The sensor electronics 12 may include hardware, firmware, software, or a combination thereof to provide measurements of the level of an analyte via a continuous analyte sensor, such as a continuous glucose sensor. Exemplary implementations of the sensor electronics 12 are further described below with respect to FIG. 46.

[0211] In one implementation, the factory calibration algorithm described herein may be performed by the sensor electronics.

[0212] Sensor electronics 12 may be coupled (e.g., wirelessly, etc.) with one or more devices, such as display devices 14, 16, 18, and / or 20, as described. Display devices 14, 16, 18, and / or 20 may be configured to present (and / or alert) information, such as sensor information, transmitted by sensor electronics 12 for display on display devices 14, 16, 18, and / or 20.

[0213] The display devices may include a relatively small key fob-type display device 14, a relatively large handheld display device 16, a mobile phone 18 (e.g., smartphone, tablet, etc.), a computer 20, and / or any other user device configured to present at least information (e.g., smart alerts, medication delivery information, separate self-monitoring glucose readings, heart rate monitor, calorie intake monitor, etc.). In some cases, the display device may be, for example, a user's automobile, where the automobile is in signal communication with, for example, the user's smartphone. For example, the automobile may be in Bluetooth communication with or Bluetooth paired with the smartphone. Other display devices may include televisions, smart refrigerators, etc.

[0214] In one implementation, the factory calibration algorithm may be performed at least in part by the display device.

[0215] In some example implementations, the relatively small key fob display device 14 may include a wristwatch, a belt, a necklace, a pendant, jewelry, an adhesive patch, a pager, a key fob, a plastic card (e.g., a credit card), an identification (ID) card, and / or the like. The small display device 14 may include a relatively small display (e.g., smaller than the large display device 16) and may be configured to display certain types of displayable sensor information, including smart alerts, such as numbers, arrows, or color codes.

[0216] In some example implementations, the relatively large handheld display device 16 may include a handheld receiver device, a palmtop computer, and / or the like. This large display device may include a relatively large display (e.g., larger than the small display device 14) and may be configured to display information including smart alerts, such as graphical representations of continuous sensor data, including current and historical sensor data, output by the sensor system 8.

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

[0218] In some exemplary implementations, the continuous analyte sensor 10 may include a glucose sensor configured to measure glucose in blood or interstitial fluid using one or more measurement techniques, such as enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, etc. In implementations in which the continuous analyte sensor 10 includes a glucose sensor, the glucose sensor may include any device capable of measuring the concentration of glucose and may provide data, such as a data stream indicative of the concentration of glucose in a host, using a variety of techniques to measure glucose, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring). The data stream may be sensor data (raw and / or filtered), which may be converted to a calibrated data stream that is used to provide glucose values ​​to a host, such as a user, patient, or caregiver (e.g., a parent, relative, guardian, teacher, doctor, nurse, or any other individual interested in the health of the host). Additionally, the continuous analyte sensor 10 may be embedded as at least one of the following types of sensors: Implantable glucose sensors, transcutaneous glucose sensors implanted in the host vasculature or extracellular, subcutaneous sensors, replaceable subcutaneous sensors, intravascular sensors.

[0219] In some example implementations, when a user's diabetes needs are low, smart alerts may be provided to alert the user and then automatically render or prompt the user to reorder. For example, in some situations, the system may learn that the user typically orders two days in advance, and the system may be aware of the fact that the sensor has two days of life remaining. In this case, the system may provide smart alert information to inform the user that it is time to order new needs.

[0220] If user acknowledgment is used, the acknowledgment may be acknowledged at the receiver, mobile device, or other such device. In some cases, the alert or warning may be acknowledged directly at the transmitter. In some cases, fingerprint recognition may be used in the acknowledgment to prevent non-users from detrimentally acknowledging a user's alert or warning, thereby potentially preventing the user from receiving such alert or warning.

[0221] The disclosure herein refers to some implementations including a continuous analyte sensor 10 including a glucose sensor, however, the continuous analyte sensor 10 may include other types of analyte sensors as well. Additionally, while some implementations refer to the glucose sensor as an implantable glucose sensor, other types of devices capable of detecting the concentration of glucose and providing an output signal representative of the glucose concentration may be used as well. Additionally, while the disclosure herein refers to glucose as the analyte to be measured, processed, etc., other analytes may be used as well, including, for example, ketone bodies (e.g., acetone, acetoacetate and β-hydroxybutyrate, lactate, etc.), glucose, acetyl-CoA, triglycerides, fatty acids, intermediates in the citric acid cycle, choline, insulin, cortisol, testosterone, etc.

[0222] 46 illustrates one example of sensor electronics 12 according to some example implementations. Sensor electronics 12 may include sensor electronics configured to process sensor information, such as sensor data, and generate transformed sensor data and displayable sensor information, for example, via a processor module. For example, the processor module may transform the sensor data into one or more of the following: filtered sensor data (e.g., one or more filtered analyte concentration values), raw sensor data, calibrated sensor data (e.g., one or more calibrated analyte concentration values), rate of change information, trend information, acceleration / deceleration information, sensor diagnostic information, position information, alarm / alert information, calibration information that may be determined, for example, by a configuration algorithm, sensor data smoothing and / or filtering algorithms, and / or the like.

[0223] In some embodiments, the processor module 214 is configured to accomplish a significant portion, if not all, of the data processing. The processor module 214 may be integral with the sensor electronics 12 and / or may be located remotely, such as in one or more of the devices 14, 16, 18, and / or 20, and / or the cloud 490. In some embodiments, the processor module 214 may include multiple smaller subcomponents or submodules. For example, the processor module 214 may include an alert module (not shown), or a prediction module (not shown), or any other suitable module that may be utilized to efficiently process data. When the processor module 214 is comprised of multiple submodules, the submodules may be located within the processor module 214, including within the sensor electronics 12 or other associated devices (e.g., 14, 16, 18, 20, and / or 490). For example, in some embodiments, the processor module 214 may be located at least partially within the cloud-based analyte processor 490 or elsewhere within the network 406.

[0224] In some exemplary implementations, the processor module 214 may be configured to calibrate the sensor data, and the data storage 220 may store the calibrated sensor data points as transformed sensor data. Additionally, the processor module 214 may be configured in some exemplary implementations to wirelessly receive calibration information from a display device, such as devices 14, 16, 18, and / or 20, to enable calibration of the sensor data from the sensor 12. Additionally, the processor module 214 may be configured to perform additional algorithmic processing on the sensor data (e.g., the calibrated and / or filtered data and / or other sensor information), and the data storage 220 may be configured to store the transformed sensor data and / or sensor diagnostic information associated with the algorithm. The processor module 214 may further be configured to store and use calibration information determined from the calibration.

[0225] In some example implementations, the sensor electronics 12 may include an application specific integrated circuit (ASIC) 205 coupled to a user interface 222. The ASIC 205 may further include a potentiostat 210, a telemetry module 232 for transmitting data from the sensor electronics 12 to one or more devices, such as devices 14, 16, 18, and / or 20, and / or other components for signal processing and data storage (e.g., processor module 214 and data storage 220). Although FIG. 46 illustrates the ASIC 205, other types of circuits may be used as well, including a field programmable gate array (FPGA), one or more microprocessors configured to provide some (if not all) of the processing performed by the sensor electronics 12, analog circuits, digital circuits, or combinations thereof.

[0226] 46, through a first input port 211 for sensor data, the potentiostat 210 is coupled to a continuous analyte sensor 10, such as a glucose sensor, to generate sensor data from the analyte. The potentiostat 210 may also provide a voltage to the continuous analyte sensor 10 via data line 212 to bias the sensor for measurement of a value (e.g., a current value) indicative of the analyte concentration in the host (also referred to as the analog portion of the sensor). The potentiostat 210 may have one or more channels depending on the number of working electrodes of the continuous analyte sensor 10.

[0227] While in some exemplary implementations the potentiostat 210 may include a resistor that converts the current value from the sensor 10 to a voltage value, in some exemplary implementations a current to frequency converter (not shown) may also be configured to continuously incorporate the measured current value from the sensor 10, for example using a charge counting device. In some exemplary implementations an analog to digital converter (not shown) may digitize the analog signal from the sensor 10 into so-called "counts" to allow processing by the processor module 214. The resulting counts may be directly related to the current measured by the potentiostat 210, which may be directly related to an analyte level, such as a glucose level, within the host.

[0228] The telemetry module 232 may be operatively connected to the processor module 214 and may provide hardware, firmware, and / or software to enable wireless communication between the sensor electronics 12 and one or more other devices, such as a display device, a processor, a network access device, etc. Various wireless technologies that may be implemented in the telemetry module 232 include Bluetooth, Bluetooth Low-Energy, ANT, ANT+, ZigBee, IEEE 802.11, IEEE 802.16, cellular radio access technology, radio frequency (RF), inductance (e.g., magnetic), near field communication (NFC), infrared (IR), paging network communication, magnetic induction, satellite data communication, spread spectrum communication, frequency hopping communication, near field communication, and / or the like. In some example implementations, the telemetry module 232 includes a Bluetooth chip, although Bluetooth technology may also be implemented in a combination of the telemetry module 232 and the processor module 214.

[0229] The processor module 214 may control the processing performed by the sensor electronics 12. For example, the processor module 214 may be configured to process data (e.g., counts) from the sensor, filter the data, calibrate the data, perform fail-safe checks, and / or the like.

[0230] In some exemplary implementations, the processor module 214 may include a digital filter, such as an infinite impulse response (IIR) or finite impulse response (FIR) filter. The digital filter may smooth the raw data stream received from the sensor 10. Generally, the digital filter is programmed to filter data sampled at predetermined time intervals (also referred to as a sampling rate). In some exemplary implementations, such as when the potentiostat 210 is configured to measure an analyte (e.g., glucose and / or the like) at discrete time intervals, these time intervals determine the sampling rate of the digital filter. In some exemplary implementations, the potentiostat 210 may be configured to measure an analyte continuously, for example, using a current-to-frequency converter. In these current-to-frequency converter implementations, the processor module 214 may be programmed to request digital values ​​from an integrator of the current-to-frequency converter at predetermined time intervals (collection time). These digital values ​​obtained by the processor module 214 from the integrator may be averaged over the collection time by the continuity of the current measurements. Thus, the acquisition time may be determined by the sampling rate of the digital filter.

[0231] The processor module 214 may further include a data generator (not shown) configured to generate data packages for transmission to devices such as the display devices 14, 16, 18, and / or 20. Additionally, the processor module 214 may generate data packets for transmission to these external sources via the telemetry module 232. In some example implementations, the data packages may be customizable for each display device as described, and / or may include any available data, such as timestamps, displayable sensor information, converted sensor data, identifier codes for the sensors and / or sensor electronics 12, raw data, filtered data, calibrated data, rate of change information, trend information, error detection or correction, and / or the like.

[0232] The processor module 214 may also include program memory 216 and other memory 218. The processor module 214 may be coupled to a communications interface, such as a communications port 238, and a power source, such as a battery 234. In addition, the battery 234 may be further coupled to a battery charger and / or regulator 236 to provide power to the sensor electronics 12 and / or charge the battery 234.

[0233] The program memory 216 may be implemented as a pseudo-static memory for storing data such as identifiers (e.g., sensor identifiers (IDs)) for coupled sensors 10, and for storing code (also referred to as program code) for calibrating the ASIC 205 to perform one or more of the operations / functions described herein. For example, the program code may configure the processor module 214 to process and filter data streams or counts, perform calibration methods, perform fail-safe checks, etc.

[0234] The memory 218 may also be used to store information. For example, the processor module 214 including the memory 218 may be used as a cache memory for the system, with temporary storage provided for recent sensor data received from the sensors. In some example implementations, the memory may include storage components such as read-only memory (ROM), random access memory (RAM), dynamic RAM, static RAM, non-static RAM, easily erasable programmable read-only memory (EEPROM), rewriteable ROM, flash memory, and the like.

[0235] The data storage 220 may be coupled to the processor module 214 and may be configured to store various sensor information. In some example implementations, the data storage 220 stores one or more days of continuous analyte sensor data. For example, the data storage may store 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20, and / or 30 days (or more) of continuous analyte sensor data received from the sensor 10. The stored sensor information may include one or more of the following: timestamp, raw sensor data (one or more raw analyte concentration values), calibrated data, filtered data, converted sensor data, and / or any other displayable sensor information, calibration information (e.g., reference BG values ​​and / or previous calibration information, e.g., from a factory calibration), sensor diagnostic information, etc.

[0236] The user interface 222 may include various interfaces such as one or more buttons 224, a liquid crystal display (LCD) 226, a vibrator 228, an audio transducer (e.g., speaker) 230, a backlight (not shown), and / or the like. The components that comprise the user interface 222 may provide controls for interacting with a user (e.g., host). The one or more buttons 224 may enable, for example, toggles, menu selections, option selections, status selections, yes / no responses to on-screen questions, a "turn off" function (e.g., for alarms), an "acknowledged" function (e.g., for alarms), a reset, and / or the like. The LCD 226 may provide, for example, visual data output to the user. The audio transducer 230 (e.g., speaker) may provide audible signals in response to the triggering of certain alerts, such as current and / or predicted hyperglycemic and hypoglycemic conditions. In some exemplary implementations, the audible signal may be differentiated by tone, volume, duty cycle, pattern, duration, and / or the like. In some exemplary implementations, the audible signal may be configured to be muted (e.g., acknowledged or turned off) by pressing one or more buttons 224 on the sensor electronics 12 and / or by signaling the sensor electronics 12 using a button or selection on a display device (e.g., a key fob, cell phone, and / or the like). In some cases, the audible alert may be muted while the visual alert is still rendered. As a particular example, the user may still be able to view the glucose trace and / or threshold line, but the audible alarm may be muted. In this way, the user can still be informed that they are high or low, but avoid the irritation of an audible alert.

[0237] Audio and vibration alerts are described with respect to Figure 46, although other alert mechanisms may also be used. For example, in some example implementations, tactile alerts are provided, including a poking mechanism configured to "poke" or make physical contact with the patient in response to one or more alarm conditions.

[0238] In one exemplary implementation, a default method of alert, e.g., display on a screen, may be used, but if an alert or warning using the default mode is not acknowledged within a predetermined period of time, the alert and warning may escalate with subsequent reminder alerts or warnings, often using alternative means of notification, including the use of a connected device such as a medication delivery device. For example, if the original or first alert and warning is not acknowledged, at the next subsequent or reminder alert or warning, which may occur after, e.g., 5 minutes, the mobile device and / or connected medication device may emit an auxiliary or secondary alert, e.g., an audible alert, e.g., a cell phone sound. If this warning or alarm is also not acknowledged and if the pump or pen is connected to a mobile device (e.g., with reference to FIG. 45, if the drug delivery pump 2 is connected to a respective processing device, e.g., the mobile device 18 or the processor 490, or even possibly the sensor electronics 12), the drug delivery device (pump or pen) may cause an audible or tactile or visual warning or alarm, e.g., having a medium amplitude, e.g., a medium volume, for a predefined period, e.g., 20 seconds. Similarly, if these warnings or alarms are also not acknowledged and again the pump or pen is connected to a respective processing device, this may cause an audible or tactile or visual warning or alarm, e.g., having a high amplitude, e.g., a high volume, for a predefined period, e.g., 20 seconds.

[0239] Other means may also be used to render the warning or alarm. For example, dogs are increasingly being used as diabetic alert dogs or as companion animals. In either case, the components of the system may be configured with an ultrasonic transmitter such that if the user's glucose concentration value is approaching a dangerous value, the ultrasonic transducer is triggered to render an ultrasonic pulse. Diabetic alert dogs generally detect impending hypoglycemic or hyperglycemic situations, but if the dog does not, the ultrasonic pulse may provide a reminder. Similarly, companion animals that are not trained as diabetic alert dogs may be trained to recognize the pulse as a reason to alert their owner. Even if such a dog is not specifically trained, the ultrasonic pulse may cause a degree of provocation that provides a wake-up call to the user that something is wrong. The ultrasonic transmitter may be signally coupled to various parts of the system, such as a transmitter, smartphone, receiver, or other device. As the severity of the danger increases, the ultrasonic tone may change so that the diabetic companion can be trained to respond accordingly.

[0240] In another example, a user may be informed of their glucose alerts, warnings, and notifications without looking at their monitoring device by using characteristic haptic or vibration patterns that may be rendered on a smart device or watch. The haptic / vibration patterns may be rendered and constructed according to relative urgency or safety concerns using similar principles of audio or visual alarms and prioritization of the alerts. For example, higher vibration rates, closer intervals between vibrations, and longer durations may be used for higher priority alarms, and vice versa for lower priority alarms. The user may be able to fit a specific vibration profile or curve that follows the user's own instructions and design. In this way, the user may be informed of alerts or warnings and may receive information about the type and / or urgency of the alert without having to look at a display screen or hear the alarm (the latter of which may also be frustrating as it may disturb others in the user's vicinity).

[0241] The battery 234 may be operatively connected to the processor module 214 (and possibly other components of the sensor electronics 12) and provide the necessary power for the sensor electronics 12. In some exemplary implementations, the battery is a lithium manganese dioxide battery, but any appropriately sized and powered battery may be used (e.g., AAA, nickel cadmium, zinc carbon, alkaline, lithium, nickel metal hydride, lithium ion, zinc air, zinc mercury oxide, silver zinc, or sealed). In some exemplary implementations, the battery is rechargeable. In some exemplary implementations, multiple batteries may be used to power the system. In still other implementations, the receiver may be powered transcutaneously, for example, via inductive coupling.

[0242] The battery charger and / or conditioner 236 may be configured to accept energy from an internal and / or external charger. In some exemplary implementations, the battery conditioner (or balancer) 236 regulates the recharging process by bleeding off excess charge current to allow all cells or batteries in the sensor electronics 12 to be fully charged without overcharging other cells or batteries. In some exemplary implementations, the battery(ies) 234 are configured to be charged via an inductive and / or wireless charging pad, although any other charging and / or power mechanism may be used as well.

[0243] One or more communication ports 238, also referred to as external connector(s), may be provided to enable communication with other devices, for example, a PC communication (com) port may be provided to enable communication with systems that are separate from or integral to the sensor electronics 12. For example, the communication port may include a serial (e.g., Universal Serial Bus or "USB") communication port to enable communication with another computer system (e.g., a PC, a personal digital assistant or "PDA", a server, etc.). In some example implementations, the sensor electronics 12 can transmit historical data to a PC or other computing device for retrospective analysis by the patient and / or HCP. As another example of data transmission, factory information may also be transmitted to the algorithm from the sensor or from a cloud data source.

[0244] These one or more communication ports 238 may further include a second input port 237 through which calibration data may be received, and an output port 239 that may be used to transmit calibrated or calibrated data to a receiver or mobile device. Figure 46 illustrates these aspects diagrammatically. While the ports may be physically separate, it will be appreciated that in alternative implementations, a single communication port may provide the functionality of both the second input port and the output port.

[0245] Exemplary embodiments Non-transitory computer-readable medium 1: A non-transitory computer-readable medium comprising instructions for causing a computing environment to perform a method of dynamically adjusting or tailoring user alerts based on a determination of cognitive awareness, thereby providing data regarding the treatment of a diabetic condition meriting attention, the method including the steps of identifying a current or future diabetic condition meriting attention, the identification being based at least in part on a glucose concentration value; estimating or predicting a user's cognitive awareness of the identified current or future diabetic condition meriting attention; and if the result of the estimation or prediction is that the user is not cognitively aware of the identified current or future diabetic condition meriting attention, alerting the user with a user prompt on a user interface of the monitoring device, the user prompt indicating the diabetic condition meriting attention, whereby the user is alerted to the diabetic condition meriting attention if and only if the user is not aware of the diabetic condition meriting attention and notification is enabled for the user.

[0246] Non-transitory computer readable medium 2: An embodiment of non-transitory computer readable medium 1, in which the alerts are optimized for the patient's cognitive awareness, thereby resulting in fewer alerts than would otherwise be provided without consideration of the user's cognitive awareness.

[0247] Non-Transitory Computer-Readable Medium 3: An embodiment of Non-Transitory Computer-Readable Medium 1 or 2, wherein the monitoring device is a smartphone, a smartwatch, a dedicated monitoring device, or a tablet computer.

[0248] Non-Transitory Computer-Readable Medium 4: An embodiment of any one of Non-Transitory Computer-Readable Medium 1 to 3, in which excessive, repetitive, or nuisance prompts are minimized or avoided.

[0249] Non-transitory computer-readable medium 5: An embodiment of any one of non-transitory computer-readable media 1 to 4, in which a user can build trust in the system and the system only alerts about notifications that are optimized or valid for the user.

[0250] Non-transitory computer readable medium 6: An embodiment of any one of non-transitory computer readable media 1 to 5, wherein estimating or predicting a user's cognitive awareness includes determining whether an identified current or future diabetic condition worthy of attention includes an abnormal glucose trace.

[0251] Non-transitory computer readable medium 7: An embodiment of non-transitory computer readable medium 6, wherein the abnormal glucose trace comprises an abnormal pattern or an abnormal glucose response.

[0252] Non-transitory computer-readable medium 8: An embodiment of any one of non-transitory computer-readable media 1 to 7, wherein estimating or predicting a user's cognitive awareness includes determining whether the user has previously treated a similar identified diabetic condition meriting attention by taking action without a user prompt.

[0253] Non-Transient Computer Readable Medium 9: The embodiment of Non-Transient Computer Readable Medium 8, wherein the treatment is administration of a drug.

[0254] Non-transitory computer readable medium 10: An embodiment of non-transitory computer readable medium 8, in which the measure is to eat a diet.

[0255] Non-transitory computer readable medium 11: An embodiment of non-transitory computer readable medium 8, wherein the action is exercise.

[0256] Non-transitory computer readable medium 12: An embodiment of any one of non-transitory computer readable media 1 to 11 including an estimation or prediction of cognitive awareness, including determining whether a user has entered meal or bolus dose data or requested a bolus dose calculation.

[0257] Non-transitory computer-readable medium 13: An embodiment of any one of non-transitory computer-readable media 1 to 12, wherein estimating or predicting a user's cognitive awareness includes determining whether the user's behavior is consistent with the cognitive awareness.

[0258] Non-transitory computer-readable medium 14: An embodiment of any one of non-transitory computer-readable media 1 to 13, wherein estimating or predicting a user's cognitive awareness includes receiving user input and basing the estimation or prediction at least in part on the received input.

[0259] Non-transitory computer-readable medium 15: An embodiment of any one of non-transitory computer-readable media 1 to 14, wherein estimating or predicting a user's cognitive awareness includes analyzing historical data of the user's glucose values ​​over time.

[0260] Non-transitory computer readable medium 16: An embodiment of any one of non-transitory computer readable media 1 to 15, wherein the identifying and estimating or predicting steps are repeated until such a time that it is estimated or predicted that the user will be cognitively aware of the identified diabetic condition worthy of attention, and then a step of alerting the user with a user prompt is performed.

[0261] Non-transitory computer-readable medium 17: An embodiment of any one of non-transitory computer-readable media 1 to 16, wherein estimating or predicting a user's cognitive awareness includes receiving data from an application or website via an appropriate API.

[0262] Non-transitory computer readable medium 18: An embodiment of any one of non-transitory computer readable media 1 to 17, wherein the estimation or prediction is based at least in part on location data, i.e. GPS data.

[0263] Non-transitory computer readable medium 19: An embodiment of the non-transitory computer readable medium 18, wherein the location data is user location data.

[0264] Non-transitory computer readable medium 20: An embodiment of non-transitory computer readable medium 18, wherein the location data is location data of the user's followers.

[0265] Non-transitory computer-readable medium 21: An embodiment of any one of non-transitory computer-readable media 1 to 20, wherein the estimation or prediction of the user's cognitive awareness is based at least in part on one or more of demographic data, data related to behavioral or contextual information, data related to the user's life goals, data related to user privacy settings, or combinations thereof.

[0266] Non-transitory computer-readable medium 22: An embodiment of any one of non-transitory computer-readable media 1 to 21, wherein the estimation or prediction of the user's cognitive awareness is based at least in part on real-time data, the real-time data including one or more of data related to a GPS application of the monitoring device, data related to an accelerometer of the monitoring device, data related to behavioral or contextual information, data related to the location of the user's followers, data related to the user's metabolic rate, data related to the user's glycemic urgency indicator, heart rate data, sweat content data, data related to the user's wearable sensors, insulin data, or combinations thereof.

[0267] Non-transitory computer-readable medium 23: An embodiment of any one of non-transitory computer-readable media 1 to 22, wherein estimating or predicting a user's cognitive awareness includes recognizing one or more personalized patterns associated with the user.

[0268] Non-transitory computer readable medium 24: An embodiment of non-transitory computer readable medium 23, wherein the individualization pattern corresponds to an envelope of a characteristic analyte concentration signal trace occurring before or after an event.

[0269] Non-transitory computer readable medium 25: An embodiment described in non-transitory computer readable medium 24, wherein the event is related to eating, exercise, or sleep.

[0270] Non-transitory computer readable medium 26: An embodiment described in non-transitory computer readable medium 25, wherein the determination is a determination that the user is not cognitively aware whether the current signal trace is outside the envelope of the characteristic analyte concentration signal trace.

[0271] Non-transitory computer-readable medium 27: An embodiment of any one of non-transitory computer-readable media 1 to 26, wherein the method further includes indicating a confidence level associated with the user prompt.

[0272] Non-transitory computer readable medium 28: An embodiment of any one of non-transitory computer readable media 1 to 27, where the result of the estimation or prediction is that the user is cognitively unaware of a diabetic condition that merits attention.

[0273] Non-transitory computer-readable medium 29: An embodiment of any one of non-transitory computer-readable media 1 to 28, wherein the estimation or prediction is further based on location information of a user, the location information indicating that the user is within a predetermined threshold proximity of a grocery store or restaurant.

[0274] Non-transitory computer readable medium 30: An embodiment of any one of non-transitory computer readable media 1 to 29, wherein if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition meriting attention, the user is alerted with a user prompt after a time delay, the duration of the time delay being based at least on the identified diabetic condition meriting attention, and the glucose concentration value and / or the rate of change of the glucose concentration value.

[0275] Non-transitory computer readable medium 31: An embodiment of any one of non-transitory computer readable media 1 to 30, wherein the user prompt includes a query for the user to input data.

[0276] Non-transitory computer readable medium 32: An embodiment of non-transitory computer readable medium 31, in which the query requests user-entered data regarding dosing, diet, or exercise.

[0277] Non-transitory computer readable medium 33: An embodiment of any one of non-transitory computer readable media 1 to 32, in which if data from a user interface or data from an accelerometer associated with the monitoring device determines that a user is ignoring a user prompt, and if the user prompt does not correspond to a dangerous condition, information that the user ignored the user prompt under the preceding conditions is stored and the stored information is used as part of a subsequent estimation or prediction step.

[0278] Non-transitory computer readable medium 34: An embodiment of any one of non-transitory computer readable media 1 to 33, wherein identifying a diabetic condition meriting current or future attention includes determining a clinical value of glucose concentration and / or a rate of change of glucose and / or a glycemic urgency index value.

[0279] Non-transitory computer readable medium 35: An embodiment of any one of non-transitory computer readable media 1 to 34, wherein identifying a diabetic condition meriting current or future attention includes measuring a glucose signal signature, comparing the measured signature to a plurality of binned signatures, and classifying the diabetic condition meriting attention into one of the plurality of bins based on the comparison.

[0280] Non-transitory computer readable medium 36: An embodiment of any one of non-transitory computer readable media 1 to 35, wherein identifying a diabetic condition meriting current or future attention comprises determining one or more time-based trends in glucose concentration values ​​and basing the identified condition on the determined trends.

[0281] Non-transitory computer readable medium 37: An embodiment of non-transitory computer readable medium 36, wherein the trend corresponds to whether the glucose concentration value is wandering within a range or rising or falling, where wandering corresponds to staying within a predetermined range for a period of more than 5 minutes, or more than 10 minutes, or more than 15 minutes, or more than 30 minutes.

[0282] Non-transitory computer-readable medium 38: An embodiment of the non-transitory computer-readable medium 37 in which vague boundaries are used to define ranges.

[0283] Non-transitory computer readable medium 39: An embodiment of any one of non-transitory computer readable media 1 to 28, further comprising sending an indication of a diabetic condition meriting attention to a drug pump.

[0284] Non-transitory computer readable medium 40: An embodiment described in non-transitory computer readable medium 39, further comprising activating a drug pump to cause a drug bolus administration if the result of the estimation or prediction is that the user is cognitively unaware of a diabetic condition that merits attention.

[0285] Non-transitory computer readable medium 41: An embodiment of non-transitory computer readable medium 40, wherein the medication bolus dose is a prandial bolus of insulin.

[0286] Non-transitory computer readable medium 42: An embodiment described in non-transitory computer readable medium 42 further comprising activating a drug pump to alter the basal rate if the result of the estimation or prediction is that the user is cognitively unaware of a diabetic condition that merits attention.

[0287] Non-transitory computer readable medium 43: An embodiment of non-transitory computer readable medium 40, wherein the agent is insulin.

[0288] Non-transitory computer readable medium 44: An embodiment of non-transitory computer readable medium 39 further including determining whether the drug pump is capable of fully or partially treating a diabetic condition that merits attention, and if so, not warning the user or changing the user prompt, respectively, compared to a case in which the drug pump is unable to treat the diabetic condition.

[0289] Non-transitory computer readable medium 45: An embodiment of any one of non-transitory computer readable media 1 to 44 that determines when to alert the user using a user prompt if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition that merits attention.

[0290] Non-transitory computer readable medium 46: An embodiment of any one of non-transitory computer readable media 1 to 45, wherein the user prompt, if displayed, includes a color or an arrow instead of or in addition to the glucose concentration value.

[0291] Non-transitory computer readable medium 47: An embodiment of any one of non-transitory computer readable media 1 to 46, wherein the user prompt, if displayed, includes a prediction of the glucose concentration value.

[0292] Non-transitory computer readable medium 48: An embodiment of any one of non-transitory computer readable media 1 to 47, wherein the user prompt, when displayed, includes an audible indicator, and the volume of the audible indicator is automatically adjusted to ambient noise measured by the monitoring device or a device in signal communication with the monitoring device, and the adjustment to ambient noise includes increasing the volume of the audible indicator relative to the ambient noise until a threshold level of the signal-to-noise ratio is reached.

[0293] Non-transitory computer readable medium 49: An embodiment of any one of non-transitory computer readable media 1 to 48, wherein the user prompt is associated with a diabetic condition meriting attention occurring during a period when the user has a hypoglycemic urgency index.

[0294] Non-transitory computer readable medium 50: An embodiment of any one of non-transitory computer readable media 1 to 49, in which if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition that merits attention, the user is alerted after a delay with a user prompt based on the identified diabetic condition that merits attention, and the glucose concentration value and / or the rate of change of the glucose concentration value, rather than based on duration.

[0295] Non-transitory computer readable medium 51: An embodiment of any one of non-transitory computer readable media 1 to 50, where if the result of the estimation or prediction is that the user is cognitively unaware of a diabetic condition that merits attention, then after a delay, the user is alerted with a user prompt based on individualized patterns learned by the monitoring device rather than duration.

[0296] Non-transitory computer readable medium 52: An embodiment of any one of non-transitory computer readable media 1 to 51, wherein the identified diabetic condition meriting attention corresponds to an abnormal glucose response or abnormal pattern, and the abnormal response or abnormal pattern is learned by the monitoring device and not by user input.

[0297] Non-transitory computer-readable medium 53: An embodiment of any one of non-transitory computer-readable media 1 to 52, in which user prompts are displayed on a pre-designed user interface rather than on an adapted user interface with dynamic timing.

[0298] Non-transitory computer readable medium 54: An embodiment of any one of non-transitory computer readable media 1 to 53, in which if the result of the estimation or prediction is that the user is cognitively unaware of a diabetic condition that merits attention, the user is immediately alerted with a user prompt, regardless of instructions received from other monitoring device applications not to alert the user with a user prompt.

[0299] Non-transitory computer readable medium 55: An embodiment of any one of non-transitory computer readable media 1 to 54, in which if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition that merits attention, the user is immediately alerted with a user prompt, regardless of instructions not to alert the user with a user prompt based on data or settings entered by other users.

[0300] Non-transitory computer readable medium 56: An embodiment of any one of non-transitory computer readable media 1 to 55, wherein the estimation or prediction of whether a user is cognitively aware of a diabetic condition worthy of attention is based at least in part on real-time data and not entirely on retrospective data.

[0301] Non-transitory computer-readable medium 57: An embodiment of any one of non-transitory computer-readable media 1 to 56, wherein alerting the user using a user prompt on a user interface of the monitoring device includes rendering an ultrasound pulse.

[0302] Non-transitory computer-readable medium 58: An embodiment of any one of non-transitory computer-readable media 1 to 57, wherein alerting a user with a user prompt on a user interface of the monitoring device results in a prompt on a second user interface of the monitoring device if the user ignores the first alert.

[0303] Non-transitory computer-readable medium 59: An embodiment of the non-transitory computer-readable medium 58, wherein the monitoring device is a mobile cellular device and the second user interface includes an audio channel.

[0304] Non-transitory computer readable medium 60: An embodiment of the non-transitory computer readable medium 59, wherein the prompt is an audible prompt and is played through an audio channel.

[0305] Non-transitory computer readable medium 61: An embodiment of non-transitory computer readable medium 58, in which the monitoring device is a mobile cellular device and the second user interface includes a vibratory, force-sensing, or haptic rendering system.

[0306] Non-transitory computer readable medium 62: An embodiment described in non-transitory computer readable medium 61, wherein the prompt is a vibratory prompt and is played through a vibratory, haptic, or tactile rendering system.

[0307] Non-transitory computer-readable medium 63: An embodiment described in non-transitory computer-readable medium 62, wherein the monitoring device is a mobile cellular device, the second user interface includes an audio channel, the prompt is an audible prompt that is played through the audio channel, and if the audible prompt is not acknowledged by the user, rendering of a vibratory prompt is triggered.

[0308] Non-transitory computer-readable medium 64: An embodiment of any one of non-transitory computer-readable media 1 to 63, wherein alerting a user with a user prompt on a user interface of a monitoring device causes a prompt on a second user interface of a second device if the user ignores the first alert.

[0309] Non-transitory computer readable medium 65: An embodiment of the non-transitory computer readable medium 64, wherein the second device is a medication delivery device and the prompt is audible or vibratory.

[0310] Non-transitory computer-readable medium 66: An embodiment of any one of non-transitory computer-readable media 1 to 65, wherein alerting the user using a user prompt on a user interface of the monitoring device includes rendering a haptic or vibratory signal.

[0311] Non-transitory computer readable medium 67: An embodiment of the non-transitory computer readable medium 66, in which the rendering is on the monitoring device.

[0312] Non-transitory computer readable medium 68: An embodiment of the non-transitory computer readable medium 66, in which the rendering is on a device in signal communication with the monitoring device.

[0313] Non-transitory computer readable medium 69: An embodiment of the non-transitory computer readable medium 68, in which the monitoring device is a smartphone and the device in signal communication with the monitoring device is a smartwatch.

[0314] Non-transitory computer readable medium 70: An embodiment of non-transitory computer readable medium 66, in which the rendering includes rendering a user prompt in a pattern, the pattern corresponding to a diabetic condition that merits attention.

[0315] System 71: A system for providing smart alerts corresponding to diabetic conditions meriting a user's attention, comprising: a CGM application running on a mobile device configured to receive data from a sensor at least periodically or from time to time and to calibrate and display glucose concentration data in clinical units; and a smart alert application running on the mobile device as a subroutine within the CGM application or as a parallel process to the CGM application and receiving data from the CGM application, the smart alert application configured to perform a method contained in the non-transitory computer readable medium described in the medium 1.

[0316] Non-transitory computer-readable medium 72: A non-transitory computer-readable medium having instructions for causing a computing environment to perform a method for safely reducing alerts to a user for diabetic conditions requiring attention, the method including the steps of identifying a current or future diabetic condition meriting attention, the identification being based at least in part on a glucose concentration value; determining whether the identified diabetic condition meriting attention is abnormal for the user; and if the result of the determination is that the identified diabetic condition is abnormal for the user, alerting the user with a user prompt on an interface of the user monitoring device, the user prompt indicating the diabetic condition meriting attention, whereby the user is notified of the diabetic condition meriting attention only if the identified diabetic condition is abnormal for the user.

[0317] Non-transitory computer readable medium 73: An embodiment described in non-transitory computer readable medium 72, wherein determining whether an identified diabetic condition worthy of attention is abnormal for the user includes determining whether the identified diabetic condition includes a glucose trace that follows a pattern that is not characteristic of other patterns associated with the user.

[0318] Non-transitory computer readable medium 74: An embodiment described in non-transitory computer readable medium 72 or 73, wherein determining whether an identified diabetic condition worthy of attention is abnormal for the user includes determining whether the identified diabetic condition includes a glucose trace that follows a trend that is not characteristic of other trends associated with the user.

[0319] Non-transitory computer readable medium 75: A non-transitory computer readable medium comprising instructions for causing a computing environment to perform a method of prompting a user about diabetic conditions meriting attention, the computing environment being in signal communication with a medication delivery device, the user prompts being at least partially reduced in number to optimize effectiveness to the user, the user prompts providing data regarding treatment of the diabetic conditions meriting attention, the method including the steps of identifying current or future diabetic conditions meriting attention, the identification being based at least in part on glucose concentration values; making a first estimate or prediction of the user's cognitive awareness of the identified current or future diabetic conditions meriting attention; and a result of the first estimate or prediction being updated to indicate the user's cognitive awareness of the identified diabetic conditions meriting attention. making a second estimation or prediction of the drug delivery device's computerized awareness of the identified current or future diabetic condition meriting attention if the result of the second estimation or prediction is that the drug delivery device is unaware of the identified current or future diabetic condition meriting attention, and if the result of the second estimation or prediction is that the drug delivery device is unaware of the identified current or future diabetic condition meriting attention, alerting the user with a user prompt on a user interface of the monitoring device, the user prompt indicating the diabetic condition meriting attention, whereby the user is notified of the diabetic condition meriting attention if and only if both the user and the drug delivery device are unaware of the diabetic condition meriting attention and notification is enabled for the user.

[0320] Non-transitory computer readable medium 76: An embodiment described in non-transitory computer readable medium 75, wherein the method further includes the steps of determining whether the drug delivery device is capable of treating an identified diabetic condition that merits current or future attention, and if the result of the determination is that the drug delivery device is not capable of treating the identified diabetic condition, alerting the user with a user prompt.

[0321] Non-transitory computer readable medium 77: An embodiment of non-transitory computer readable medium 75 or 76, wherein the current or future diabetic condition includes hypoglycemia and the drug delivery device is an insulin delivery device, further comprising ceasing or reducing activity of the insulin delivery device based on the diabetic condition of hypoglycemia.

[0322] Non-transitory computer readable medium 78: An embodiment described in non-transitory computer readable medium 77, wherein cessation or reduction of activity occurs sooner if the user is cognitively aware of hypoglycemia.

[0323] Non-transitory computer readable medium 79: An embodiment of any one of non-transitory computer readable media 75 to 78, wherein making the first estimation or prediction is based at least in part on a user's interaction with the drug delivery device.

[0324] In some continuous analyte sensor systems, the on-skin portion of the sensor electronics may be simplified to minimize the complexity and / or size of the on-skin electronics, for example, providing only raw, calibrated, and / or filtered data to a display device configured to perform calibration and other algorithms required to display the sensor data. However, the sensor electronics 12 (e.g., via the processor module 214) may be implemented to perform predictive algorithms used to generate the converted sensor data and / or displayable sensor information, including, for example, algorithms to assess clinical acceptability of reference and / or sensor data, assess calibration data for best calibration based on inclusion criteria, assess calibration quality, compare predicted analyte values ​​to time-corresponding estimated analyte values, analyze variability in estimated analyte values, assess stability of the sensor and / or sensor data, detect signal artifacts (noise), replace signal artifacts, determine rate of change and / or trend of sensor data, perform dynamic and intelligent analyte value estimation, perform diagnostics on the sensor and / or sensor data, set modes of operation, evaluate data for anomalies, and / or estimate or predict cognitive awareness of the user, etc.

[0325] Although separate data storage and program memory are shown in Figure 46, various configurations may be used. For example, one or more memories may be used to provide storage space to support data processing and storage requirements in the sensor electronics 12.

[0326] In one preferred embodiment, the analyte sensor is an implantable glucose sensor, such as those described with reference to U.S. Patent Application Publication No. 6,001,067 and U.S. Patent Application Publication No. 2005 / 0027463-A1. In another preferred embodiment, the analyte sensor is a transcutaneous glucose sensor, such as those described with reference to U.S. Patent Application Publication No. 2006 / 0020187-A1. In yet other embodiments, the sensor is configured to be implanted within or outside a host's blood vessel, as described in U.S. Patent Application Publication No. 2007 / 0027385-A1, co-pending U.S. patent application Ser. No. 11 / 543,396, filed Oct. 4, 2006, co-pending U.S. patent application Ser. No. 11 / 691,426, filed Mar. 26, 2007, and co-pending U.S. patent application Ser. No. 11 / 675,063, filed Feb. 14, 2007. In one alternative embodiment, the continuous glucose sensor includes a transcutaneous sensor, such as described in U.S. Patent No. 6,565,509 to Say et al. In another alternative embodiment, the continuous glucose sensor includes a subcutaneous sensor, such as described in U.S. Patent No. 6,579,690 to Bonnecaze et al. and U.S. Patent No. 6,484,046 to Say et al. In another alternative embodiment, the continuous glucose sensor includes a pluggable subcutaneous sensor, such as described in U.S. Patent No. 6,512,939 to Colvin et al. In another alternative embodiment, the continuous glucose sensor includes an intravascular sensor, such as described in U.S. Patent No. 6,477,395 to Schulman et al. In another alternative embodiment, the continuous glucose sensor includes an intravascular sensor, such as described in U.S. Patent No. 6,424,847 to Mastrototaro et al.

[0327] The connections between elements shown in the drawings represent exemplary communication paths. Additional communication paths, either direct or through intermediaries, may be included to further facilitate the exchange of information between the elements. The communication paths may be bidirectional communication paths that enable the elements to exchange information.

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

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

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

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

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

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

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

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

[0336] Unless otherwise defined, all terms (including technical and scientific terms) shall have their ordinary and customary meanings as indicated to those skilled in the art, and shall not be limited to any special or customized meanings unless expressly defined as such herein. It should be noted that the use of a particular term when describing a particular feature or embodiment of the present disclosure should not be interpreted as implying that the term is redefined herein to be limited to include any particular characteristic of the feature or embodiment of the present disclosure to which it pertains. Particularly in the appended claims, the terms and phrases used in this application, and variations thereof, should be interpreted as open-ended as opposed to limiting, unless expressly stated otherwise. As examples of the above, the term "including" should be interpreted to mean "including without limitation," "including but not limited to," etc.; the term "comprising," as used herein, is synonymous with "including," "containing," or "featuring," is inclusive or open-ended, and does not exclude additional, unrecited elements or method steps; the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," the term "example" is used to provide illustrative examples of the items under discussion rather than an exhaustive or exclusive list of those items, and should not be construed as meaning "known," "ordinary," or "conventional," Adjectives such as "," "standard," and terms of similar import should not be construed to limit the subject matter described to that available in a given period or at a given time, but rather should be construed to encompass known, conventional, or standard technology that may be available or known at any time now or in the future, and the use of terms such as "preferably," "preferred," "desired," or "desirable" and terms of similar import should not be understood to imply that a particular feature is critical, essential, or even important to the structure or function of the invention, but rather should be intended merely to highlight alternative or additional features that may or may not be utilized in a particular embodiment of the invention.Similarly, groups of items joined by the conjunction "and" should not be construed as requiring the presence of every single one of those items in the group, but rather, unless otherwise stated, should be construed as "and / or." Similarly, groups of items joined by the conjunction "or" should not be construed as requiring mutual exclusivity between the groups, but rather, unless otherwise stated, should be construed as "and / or."

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

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

[0339] It will be further understood by those skilled in the art that, when a specific number is intended in an introduced claim recitation, such intent shall be clearly stated in the claim, and that in the absence of such a statement, no such intent exists. For example, to aid in understanding, the following appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce the claim recitation. However, the use of such phrases should not be construed as implying that the introduction of a claim recitation with the indefinite article "a" or "an" limits a particular claim that includes such an introduced claim recitation to an embodiment that includes only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should typically be construed to mean "at least one" or "one or more"), which also applies to the use of definite articles used to introduce claim recitations. In addition, even if a specific number of recitations of an introduced claim is explicitly recited, a person skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., a mere recitation of "two recitations" without other modifiers typically means at least two recitations, or more than two recitations). Furthermore, when a conventional expression similar to "at least one of A, B, and C, etc." is used, such a structure is generally intended to include any combination of the recited items, including, for example, a single member, in the sense that a person skilled in the art would understand the conventional expression (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, and C, etc.).When a conventional expression similar to "at least one of A, B, or C, etc." is used, such a structure is generally intended in the sense that one of ordinary skill in the art would understand the conventional expression (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, and C, etc.). It will be further understood by those of ordinary skill in the art that virtually any disjunction and / or phrase indicating two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B" or "A and B."

[0340] It is to be understood that all numbers expressing quantities of ingredients, reaction conditions, and the like used herein are in all instances modified by the term "about." Accordingly, unless indicated to the contrary, the numerical parameters set forth herein are approximations that may vary depending upon the desired properties sought to be obtained. At the very least, and not as an attempt to limit the application of the doctrine of equivalents to the scope of any claims in any application claiming priority to this application, each numerical parameter should be construed in light of the number of significant digits and ordinary rounding approaches.

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

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

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

[0344] The system and method may be fully executed on any number of computing devices. Typically, instructions are located on a computer-readable medium, which is generally non-transitory, and these instructions are sufficient for a processor of the computing device to execute the methods of the aspects and embodiments. The computer-readable medium may be a hard drive or solid-state storage device with instructions that, when executed, are loaded into a random access memory. For example, input to the application from multiple users, or from any one user, may be by any number of suitable computer input devices. For example, a user may use a keyboard, mouse, touch screen, joystick, trackpad, other pointing device, or any other such computer input device for inputting data related to the calculation. Data may also be input by way of an inserted memory chip, a hard drive, a flash drive, flash memory, optical media, magnetic media, or any other type of medium that stores files. Output may be delivered to the user by way of a video graphics card or integrated graphics chipset coupled to a display that the user can view. Alternatively, a printer may be used to output a hard copy of the results. It is understood that any number of other tangible outputs are also contemplated in view of this teaching. For example, the output may be stored on a memory chip, a hard drive, a flash drive, flash memory, optical media, magnetic media, or any other type of output. It should also be noted that aspects and embodiments may be performed on any number of different types of computing devices, such as personal computers, laptop computers, notebook computers, network computers, handheld computers, personal digital assistants, mobile phones, smartphones, tablet computers, and even devices designed specifically for these purposes. In one implementation, a user of a smartphone or wi-fi connected device downloads a copy of the application from a server to their device using a wireless internet connection.Appropriate authentication procedures and secure transaction processes can provide for payments to be paid to the merchant. The application may be downloaded over a mobile connection or via a WiFi or other wireless network connection. The application may then be executed by the user. Such a networked system may provide a suitable computing environment for multiple users to run, providing separate inputs to the system and method. In the following systems where smart alerts are contemplated, multiple inputs may allow multiple users to simultaneously enter relevant data. [Explanation of symbols]

[0345] 2. Drug delivery pumps 4 Glucose Meter 8. Continuous Analyte Sensor Systems 10 Sensors (Continuous Analyte Sensors) 12 Sensor Electronics 14. Key fob display device 16 Handheld display device (dedicated receiver) 18 Mobile Phones (Smart Devices) 20. Computers 25 Smart Warning Applications 50 Systems 52 Pump or source of pump data 100 Systems 102 patients 114 Follower Devices 115 Server 117 Healthcare Professional (HCP) Devices 205 Application Specific Integrated Circuits (ASIC) 210 Potentiostat 214 Processor Module 216 Program Memory 218 Memory 220 Data Storage Memory 222 User Interface 224 User Button 226 Liquid Crystal Display 228 Vibrator motor 230 Audio Converter 232 Telemetry Module 234 Batteries 236 Battery Charger / Regulator 238 communication port 350 System 406 Network 490 Cloud-Based Analyte Processors

Claims

1. 1. A non-transitory computer-readable medium comprising instructions for causing a computing environment to perform a method for dynamically adjusting or tailoring a user alert based on a determination of cognitive awareness, thereby providing data regarding treatment of a diabetic condition that merits attention, the method comprising: identifying a diabetic condition meriting current or future attention, said identification being based at least in part on the glucose concentration value; inferring or predicting whether the user is cognitively aware of the identified current or future diabetic condition worthy of attention; if the estimation or prediction results in the user being cognitively unaware of the identified current or future diabetic condition meriting attention, alerting the user with a user prompt on a user interface of a monitoring device, the user prompt indicating the diabetic condition meriting attention; A medium whereby the user is alerted to the diabetic condition meriting attention if, and only if, the user is unaware of the diabetic condition meriting attention and the alert is valid for the user.

2. 2. The medium of claim 1, wherein the alerts are optimized for the user's cognitive awareness such that fewer alerts are generated than would otherwise be provided without consideration of the user's cognitive awareness.

3. The medium of claim 1 or 2, wherein the monitoring device is a smartphone, a smartwatch, a dedicated monitoring device, or a tablet computer.

4. 4. The medium of claim 1, wherein excessive, repetitive, or nuisance prompts are minimized or avoided.

5. The medium of claim 1 , wherein the user can build trust in the system, and the system only alerts about notifications that are optimized or valid for the user.

6. The medium of claim 1 , wherein the estimation or prediction of the user's cognitive awareness includes determining whether the identified current or future diabetic condition meriting attention includes an abnormal glucose trace.

7. The medium of claim 6 , wherein the abnormal glucose trace comprises an abnormal pattern or an abnormal glucose response.

8. 8. The medium of claim 1 , wherein estimating or predicting the user's cognitive awareness includes determining whether the user has previously treated a similar identified diabetic condition meriting attention by taking action without a user prompt.

9. The medium according to claim 8 , wherein the treatment is administration of a drug.

10. The medium according to claim 8 , wherein the measure is to eat a meal.

11. The medium of claim 8 , wherein the measure is exercise.

12. 12. The medium of claim 1, wherein estimating or predicting the cognitive awareness of the user includes determining whether the user has entered meal or bolus dose data or requested a bolus dose calculation.

13. The medium of claim 1 , wherein estimating or predicting the cognitive awareness of the user includes determining whether behavior of the user is consistent with cognitive awareness.

14. 14. The medium of claim 1, wherein estimating or predicting the cognitive awareness of the user includes receiving user input and basing the estimation or prediction at least in part on the received input.

15. The medium of claim 1 , wherein estimating or predicting the cognitive awareness of the user comprises analyzing historical data of the user's glucose levels over time.

16. The medium of any one of claims 1 to 15, wherein the identifying and estimating or predicting steps are repeated until it is estimated or predicted that the user is cognitively unaware of the identified diabetic condition that deserves attention, and then a step of alerting the user with the user prompt is performed.

17. The medium of claim 1 , wherein estimating or predicting the cognitive awareness of the user includes receiving data from an application or website via a suitable API.

18. The medium of claim 1 , wherein the estimation or prediction is based at least in part on location data, i.e. GPS data.

19. The medium of claim 18 , wherein the location data is location data of the user.

20. The medium of claim 18 , wherein the location data is location data of followers of the user.

21. 21. The medium of claim 1, wherein the estimation or prediction of the cognitive awareness of the user is based at least in part on one or more of demographic data, data related to behavioral or contextual information, data related to the user's life goals, data related to user privacy settings, or combinations thereof.

22. 22. The medium of claim 1, wherein the estimation or prediction of the user's cognitive awareness is based at least in part on real-time data, the real-time data including one or more of data associated with a GPS application of the monitoring device, data associated with an accelerometer of the monitoring device, data associated with behavioral or contextual information, data associated with locations of the user's followers, data associated with the user's metabolic rate, data associated with the user's glycemic urgency index, heart rate data, sweat content data, data associated with the user's wearable sensors, insulin data, or combinations thereof.

23. 23. The medium of claim 1, wherein estimating or predicting the cognitive awareness of the user comprises recognizing one or more personalized patterns associated with the user.

24. 24. The medium of claim 23, wherein the individualized pattern corresponds to an envelope of a characteristic analyte concentration signal trace occurring before or after an event.

25. The medium of claim 24 , wherein the event is related to eating, exercise, or sleep.

26. 26. The medium of claim 25, wherein the determination is a determination that the user is not cognitively aware whether a current signal trace is outside the envelope of a characteristic analyte concentration signal trace.

27. 27. The medium of claim 1, wherein the method further comprises indicating a confidence level associated with the user prompt.

28. 28. The medium of claim 1, wherein if the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the user prompt is displayed immediately.

29. 29. The medium of claim 1, wherein the estimation or prediction is further based on location information of the user, the location information indicating the user is within a predetermined threshold proximity of a grocery store or restaurant.

30. 30. A medium as described in any one of claims 1 to 29, wherein if the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the user is alerted with the user prompt after a time delay, the duration of the time delay being based at least on the identified diabetic condition meriting attention and the glucose concentration value and / or the rate of change of the glucose concentration value.

31. 31. The medium of claim 1, wherein the user prompt comprises a query for the user to input data.

32. 32. The medium of claim 31, wherein the query requests data to be entered by the user regarding dosing, diet, or exercise.

33. A medium as described in any one of claims 1 to 32, wherein if data from the user interface or data from an accelerometer associated with the monitoring device determines that the user is ignoring the user prompt and if the user prompt does not correspond to a dangerous condition, information that the user ignored the user prompt under previous conditions is stored and the stored information is used as part of a subsequent estimation or prediction step.

34. 34. A medium according to any one of claims 1 to 33, wherein the identification of a diabetic condition meriting current or future attention comprises determining a clinical value of glucose concentration and / or a rate of change of glucose and / or a glycemic urgency index value.

35. 35. The medium of claim 1, wherein identifying the diabetic condition meriting current or future attention comprises measuring a glucose signal signature, comparing the measured signature to a plurality of binned signatures, and classifying the diabetic condition meriting attention into one of a plurality of bins based on the comparison.

36. 36. The medium of claim 1, wherein identifying a diabetic condition meriting current or future attention includes determining one or more time-based trends in the glucose concentration values ​​and basing the identified condition on the determined trends.

37. 37. The medium of claim 36, wherein the trend corresponds to the glucose concentration value wandering within a range or rising or falling, where wandering corresponds to remaining within a predetermined range for a period of more than 5 minutes, or more than 10 minutes, or more than 15 minutes, or more than 30 minutes.

38. 38. The medium of claim 37, wherein vague boundaries are used to define the ranges.

39. 39. The medium of any one of claims 1 to 38, wherein the method further comprises the step of transmitting an indication of the diabetic condition meriting attention to a drug pump.

40. 40. The medium of claim 39, wherein the method further comprises activating the drug pump to cause a drug bolus administration if the result of the estimation or prediction is that the user is cognitively unaware of the diabetic condition meriting attention.

41. 41. The medium of claim 40, wherein the medication bolus is a prandial bolus of insulin.

42. 40. The medium of claim 39, wherein the method further comprises activating the drug pump to alter the basal rate if the result of the estimation or prediction is that the user is cognitively unaware of the diabetic condition meriting attention.

43. The medium of claim 40, wherein the drug is insulin.

44. 40. The medium of claim 39, wherein the method further includes the steps of determining whether the drug pump is capable of fully or partially treating the diabetic condition meriting attention, and if so, not warning the user or changing the user prompt, respectively, compared to a case in which the drug pump is unable to treat the diabetic condition.

45. 45. The medium of claim 1, wherein the user prompt is used to determine when to warn the user if the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition that merits attention.

46. 46. ​​The medium of any one of claims 1 to 45, wherein the user prompt, if displayed, includes a color or an arrow instead of or in addition to a glucose concentration value.

47. 47. The medium of any one of claims 1 to 46, wherein the user prompt, if displayed, includes a prediction of a glucose concentration value.

48. 48. The medium of any one of claims 1 to 47, wherein the user prompt, when displayed, includes an audible indicator, the volume of the audible indicator being automatically adjusted to ambient noise measured by the monitoring device or a device in signal communication with the monitoring device, the adjustment to the ambient noise including increasing the volume of the audible indicator relative to the ambient noise until a threshold level of signal-to-noise ratio is reached.

49. 49. The medium of any one of claims 1 to 48, wherein the user prompt is associated with a diabetic condition meriting attention occurring during a period in which the user has a hypoglycemic urgency index.

50. A medium as described in any one of claims 1 to 49, wherein if the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the user is alerted with the user prompt after a delay based on the identified diabetic condition meriting attention and the glucose concentration value and / or rate of change of the glucose concentration value rather than on duration.

51. A medium as described in any one of claims 1 to 50, wherein if the result of the estimation or prediction is that the user is cognitively unaware of the diabetic condition meriting attention, the user is alerted with the user prompt after a delay based on individualized patterns learned by the monitoring device rather than duration.

52. 52. The medium of any one of claims 1 to 51, wherein the identified diabetic condition meriting attention corresponds to an abnormal glucose response or abnormal pattern, the abnormal response or abnormal pattern being learned by a monitoring device and not by user input.

53. 53. The medium of claim 1, wherein the user prompts are dynamically timed and displayed on a pre-designed user interface rather than on an adapted user interface.

54. A medium as described in any one of claims 1 to 53, wherein if the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the user is immediately alerted with the user prompt regardless of instructions received from other monitoring device applications not to alert the user with a user prompt.

55. A medium described in any one of claims 1 to 54, wherein if the result of the estimation or prediction is that the user is not cognitively aware of the diabetic condition meriting attention, the user is immediately alerted with the user prompt regardless of an instruction not to alert the user with a user prompt based on data or settings entered by other users.

56. 56. The medium of claim 1, wherein the estimation or prediction of whether the user is cognitively aware of the diabetic condition meriting attention is based at least in part on real-time data and not entirely on retrospective data.

57. 57. The medium of claim 1, wherein the alerting the user with a user prompt on a user interface of a monitoring device includes rendering an ultrasound pulse.

58. 58. The medium of any one of claims 1 to 57, wherein the warning to the user with a user prompt on a user interface of a monitoring device includes causing a prompt on a second user interface of the monitoring device if the user ignores a first warning.

59. 60. The medium of claim 58, wherein the monitoring device is a mobile cellular device and the second user interface includes an audio channel.

60. 60. The medium of claim 59, wherein the prompt is an audible prompt and is played over the audio channel.

61. 60. The medium of claim 58, wherein the monitoring device is a mobile cellular device and the second user interface includes a vibratory, force-sensory, or haptic rendering system.

62. 62. The medium of claim 61, wherein the prompt is a vibratory prompt and is played through the vibratory, haptic, or tactile rendering system.

63. 63. The medium of claim 62, wherein the monitoring device is a mobile cellular device, the second user interface includes an audio channel, the prompt is an audible prompt played through the audio channel, and if the audible prompt is not acknowledged by a user, rendering of the vibratory prompt is triggered.

64. 64. The medium of any one of claims 1 to 63, wherein the warning to the user with a user prompt on a user interface of a monitoring device includes causing a prompt on a second user interface of a second device if the user ignores the first warning.

65. 65. The medium of claim 64, wherein the second device is a medication delivery device and the prompt is audible or vibratory.

66. 66. The medium of claim 1, wherein the alerting the user with a user prompt on a user interface of a monitoring device includes rendering a haptic or vibratory signal.

67. 67. The medium of claim 66, wherein the rendering is on the monitoring device.

68. 67. The medium of claim 66, wherein the rendering is on a device in signal communication with the monitoring device.

69. 69. The medium of claim 68, wherein the monitoring device is a smartphone and the device in signal communication with the monitoring device is a smartwatch.

70. 67. The medium of claim 66, wherein the rendering includes rendering the user prompt in a pattern, the pattern corresponding to the diabetic condition meriting attention.

71. 1. A system for providing smart alerts corresponding to diabetic conditions meriting a user's attention, comprising: a CGM application running on the mobile device, the CGM application configured to at least periodically or intermittently receive data from the sensor and to calibrate and display the glucose concentration data in clinical units; A system comprising: a smart alert application that runs on the mobile device as a subroutine within the CGM application or as a parallel process with the CGM application and receives data from the CGM application, the smart alert application being configured to perform the method contained in the medium of claim 1.

72. 1. A non-transitory computer readable medium comprising instructions for causing a computing environment to perform a method for safely reducing alerts to a user for a diabetic condition requiring attention, the method comprising: identifying a diabetic condition meriting current or future attention, said identification being based at least in part on the glucose concentration value; determining whether the identified diabetic condition meriting attention is abnormal for the user; if the result of the determination is that the identified diabetic condition is abnormal for the user, alerting the user with a user prompt on a user interface of a monitoring device, the user prompt indicating the diabetic condition meriting attention; A medium whereby the user is notified of the diabetic condition that merits attention only if the identified diabetic condition is abnormal to the user.

73. 73. The medium of claim 72, wherein determining whether the identified diabetic condition meriting attention is abnormal for the user comprises determining whether the identified diabetic condition includes a glucose trace that follows a pattern that is not characteristic of other patterns associated with the user.

74. The medium of claim 72 or 73, wherein determining whether the identified diabetic condition worthy of attention is abnormal for the user includes determining whether the identified diabetic condition includes a glucose trace that follows a trend that is not characteristic of other trends associated with the user.

75. 1. A non-transitory computer readable medium comprising instructions for causing a computing environment to perform a method for prompting a user regarding a diabetic condition meriting attention, the computing environment being in signal communication with a medication delivery device, the user prompts being at least partially reduced in number to optimize effectiveness to the user, the user prompts providing data regarding treatment of the diabetic condition meriting attention, the method comprising: identifying a diabetic condition meriting current or future attention, said identification being based at least in part on the glucose concentration value; making a first estimate or prediction of said user's cognitive awareness of said identified current or future diabetic conditions worthy of attention; if the first estimation or prediction results in the user being cognitively unaware of the identified current or future diabetic condition meriting attention, making a second estimation or prediction of the drug delivery device's computer awareness of the identified current or future diabetic condition meriting attention; if the result of the second estimation or prediction is that the medication delivery device is unaware of the identified current or future diabetic condition meriting attention, alerting the user with a user prompt on a user interface of a monitoring device, the user prompt indicating the diabetic condition meriting attention; This medium allows the user to be notified of the diabetic condition meriting attention if, and only if, both the user and the medication delivery device are unaware of the diabetic condition meriting attention and the alert is valid for the user.

76. The medium of claim 75, wherein the method further includes the steps of determining whether the drug delivery device is capable of treating the identified diabetic condition meriting current or future attention, and alerting the user with the user prompt if the result of the determination is that the drug delivery device is not capable of treating the identified diabetic condition.

77. 77. The medium of claim 75 or 76, wherein the current or future diabetic condition includes hypoglycemia and the drug delivery device is an insulin delivery device, the method further comprising the step of ceasing or reducing activity of the insulin delivery device based on the diabetic condition of hypoglycemia.

78. 80. The medium of claim 77, wherein the cessation or reduction in activity occurs sooner if the user is not cognitively aware of the hypoglycemia.

79. 80. The medium of any one of claims 75 to 78, wherein making the first estimate or prediction is based at least in part on a user interaction with the medication delivery device.

Images