A system and method for providing user-optimized warnings.

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 to related applications Any and all priority claims identified in the application data sheet, or any amendments to such priority claims, are hereby incorporated by reference into this specification under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Patent Application No. 62 / 330,729, filed May 2, 2016. The foregoing application is hereby incorporated by reference in its entirety into this specification and is expressly made a part hereof.

[0002] Warnings are provided for a user, particularly in the medical field where physiological parameters are monitored.

Background Art

[0003] Diabetes mellitus is a disease in which the pancreas cannot produce sufficient insulin (type I or insulin-dependent), and / or insulin is ineffective (type 2 or non-insulin-dependent). In a diabetic state, the victim suffers from high glucose, which can cause a series of physiological disorders associated with deterioration of small blood vessels (e.g., kidney failure, skin ulcers, or bleeding into the vitreous body of the eye).

[0004] Traditionally, people with diabetes carry self-monitoring blood glucose (SMBG) monitors, which typically require an unpleasant finger prick to obtain a blood sample for measurement. Due to the lack of comfort and convenience associated with finger prick, people with diabetes usually measure their glucose levels only 2 to 4 times a day. Unfortunately, the time intervals between measurements can be so long that individuals with diabetes may not realize they are experiencing hyperglycemia or hypoglycemia until it is too late, sometimes leading to dangerous side effects. Not only are people with diabetes less likely to measure their SMBG values ​​in a timely manner, but they are also less likely to know, based on conventional methods, whether their blood glucose levels are rising (getting higher) or falling (getting lower). Therefore, people with diabetes may be prevented from making informed decisions about their insulin therapy.

[0005] Another device used by some diabetic patients to monitor their blood glucose levels is a continuous analyte sensor. Continuous analyte sensors typically include sensors placed subcutaneously, transdermally (e.g., transcutaneously), or intravascularly. The sensor measures the concentration of a given analyte in the body, generates a raw signal, which is transmitted to an electronic device associated with the sensor. The raw signal is converted into an output value, which is displayed on a screen. The output value resulting from the conversion of the raw signal is typically presented in a form that provides the user with meaningful clinical information, such as glucose expressed in mg / dL.

[0006] When the analyte is glucose and a continuous glucose monitor (CGM) is used, some CGMs generate various warnings or alarm activations when the user's glucose levels enter a dangerous or undesirable range. For example, many CGMs provide a warning if the user's glucose levels deviate into the range of mild hypoglycemia or hyperglycemia, and a further warning if the condition becomes more urgent. In some cases, such warnings / alarms use predictive algorithms to determine whether the user is approaching a dangerous condition and therefore whether a warning or alarm should be activated.

[0007] While useful, such warnings and alerts have their problems. For example, users quickly become accustomed to them and begin to "not heed the warnings and alerts," or simply ignore them. In some cases, users are unnecessarily re-warned about conditions they are already aware of. In many of these cases, "warning fatigue" begins, leading users to either ignore the warnings or turn them off without giving sufficient consideration to the cause of the warning or the potential steps that should be taken.

[0008] Other issues will be described below. First, let's look at an example of the "high" glucose warning category. In the post-meal time frame, users are often frustrated when they receive a high glucose warning after they have eaten and after administering insulin in response to the meal. Such high glucose warnings can sometimes lead to "accumulation" or even insulin administration when insulin is already "working." In such cases, the user is being warned about actions that they do not need to take, or that may cause the user to take unnecessary actions. Often, responses to such unnecessary post-meal warnings include the user starting to ignore the warning, setting a higher glucose warning threshold (thus preventing the user from using an appropriate threshold as the user's target range boundary), or even, in some cases, turning off the user's high glucose warnings. Such modifications cause the user to miss future unexpected high glucose levels.

[0009] Unnecessary re-warnings are another example of the hyperglycemia warning problem. In this case, the user becomes frustrated when they receive multiple hyperglycemia warnings for the same glucose event. Such situations often arise when glucose levels fluctuate above or below the user's high threshold. In some cases, the user may enable a "snooze" time, which can have some effect. However, as with post-meal warnings, the user does not want to be re-warned for the same hyperglycemia event before their set snooze time. Corrections for these situations are similar to those above and involve the user ignoring the warnings or turning off these hyperglycemia warnings, which again misses future unexpected high glucose levels.

[0010] Another "hyperglycemia warning" problem is missed bolus doses. For example, users often receive a hyperglycemia warning if they forget to administer the medication with a meal. While this warning reminds the user to take the medication, it is typically too late and fails to prevent further increases. Corrections for missed bolus doses include users setting a lower hyperglycemia warning threshold or setting a rate of increase warning. However, such corrections may result in additional false warnings for the user. In addition, hyperglycemia and rate of increase warnings are sometimes not effective or accurate enough to detect missed bolus doses.

[0011] Another "high blood glucose alert" issue is that certain users, for example, those with stricter glucose management goals, may want to be alerted when they are close to their higher threshold but below it over a longer period. Such users may be using their high blood glucose alert threshold against their target zone boundary, and in such cases, they may not know how to accurately set or change their high blood glucose alert threshold.

[0012] Other issues with high blood sugar warnings include inconsistent user response to their initial warning settings. Further issues with high blood sugar warnings may also be understood.

[0013] Other issues arise when using "hypoglycemia warnings." For example, the aforementioned warning fatigue can lead to distrust of the system. For instance, a user might set a higher hypoglycemia warning threshold to give themselves more time to prevent severe hypoglycemic events. However, this can lead to more frequent warnings and the resulting frustration. For example, such a user might receive many warnings for low glucose levels that do not lead to severe hypoglucose. While the user may want more warnings for severe hypoglucose, frequent hypoglycemia warnings at a higher warning threshold can lead to distrust of the system.

[0014] Related to this, false alarms caused by malfunctions such as compression can also lead to distrust of the system. Due to alarm fatigue, users may occasionally set lower alarm thresholds, resulting in them having less time to prevent emergency hypoglycemia. As another modification, users may turn off hypoglycemia warnings and use rate of descent warnings or emergency hypoglycemia warnings instead. For example, rate of descent warnings may be set to -2 or -3 mg / dL. As yet another modification, users may turn off their hypoglycemia warnings and rely on emergency hypoglycemia warnings instead. In many of these cases, the user's response fails to prevent hypoglycemia.

[0015] Another "hypoglycemia warning" problem, similar to the hyperglycemia warning problem, constitutes the problem of unnecessary re-warnings. That is, users become frustrated when they receive multiple hypoglycemia warnings for the same low glucose event. Often, such unnecessary re-warnings are caused by the user's glucose level hovering just above or just below their low threshold. Such situations can also occur when the user's level is above 55 but still below their low threshold. In response to unnecessary re-warnings, users may occasionally begin ignoring the warnings, or turn them off, or over-treat their condition, such as by stacking carbohydrates (which is often particularly problematic at night). However, such modifications cause users to miss future unexpected low glucose levels.

[0016] Another issue with hypoglycemia warnings is that users may set their hypoglycemia warning threshold as the lowest boundary of their target range. Other issues with hypoglycemia warnings are also understandable.

[0017] Prior art in this field has addressed a specific warning problem using the following methods.

[0018] One method, disclosed in U.S. Patent Application Publication No. 2015 / 0289821, filed March 16, 2015, titled "GLYCEMIC URGENCY ASSESSMENT AND ALERTS INTEFFACE," discloses that actionable warnings are provided based on a blood glucose emergency indicator, a value that represents the user's diabetic status rather than just glucose levels. Another publication, U.S. Patent Application Publication No. 2014 / 0118138, granted U.S. Patent No. 9,119,528 on September 1, 2015, titled "SYSTEMS AND METHODS FOR PROVIDING SENSITIVE AND SPECIFIC ALARMS," discusses the generation of alarms that may be annoying to the user, but focuses on modifications such as the use of a specific waiting period or time delay. Another publication, U.S. Patent Application Publication No. 2015 / 0119655, filed October 28, 2014, titled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES," describes how a user interface can be adapted according to certain inputs, such as purpose or demographic data. However, there is no disclosure of adapting the warning itself. A further application, U.S. Patent Application Publication No. 2014 / 0012510, filed March 13, 2013, titled "SYSTEMS AND METHODS FOR LEVERAGING SMARTPHONE FEATURES IN CONTINUOUS GLUCOSE MONITORING," provides a disclosure that, for example, a warning can be silenced if the user is attending a meeting. This reference discloses changing the timing of the warning, but only as part of a global setting, not in real time. Another publication, U.S. Patent Provisional Application No. 62 / 289,825, filed February 1, 2016, titled "SYSTEM AND METHOD FOR DECISION SUPPORT USING LIFESTYLE FACTORS," describes how feedback is provided to users for the purpose of supporting decision-making, for example, to inform users of something useful for 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 entirety into this specification.

[0020] This background art is provided to introduce a brief context for the following summary of the invention and the description of the embodiments for carrying out the invention. This background art is intended to assist in determining the scope of the subject matter recited in the claims and should not be construed as limiting the implementation of the subject matter recited in the claims to implementations that solve any or all of the above disadvantages or problems.

Prior Art Documents

Patent Documents

[0021]

Patent Document 1

Patent Document 2

Patent Document 3

Patent Document 4

Patent Document 5

Patent Document 6

Patent Document 7

Patent Document 8

Patent Document 9

Patent Document 10

Patent Document 11

[0022] Systems and methods adhering to this principle satisfy the above requirements in several ways. Specifically, systems and methods adhering to this principle warn the user only when it is reasonable to do so (for example, only when the system can predict or estimate that the user is not yet cognitively aware of their current condition, for example, in particular that their current condition is a diabetic condition of note). In this way, the warning or alert is personalized and particularly effective for that user. Such systems and methods still warn the user or provide the need for action or correction for a missed bolus dose when action is needed, for example, when the bolus dose or transient baseline rate changes, but do not warn when action is not needed, for example, when it is estimated or predicted that the user is already cognitively aware of a diabetic condition of note, or when corrective measures have already been taken.

[0023] In a first embodiment, a non-temporary computer-readable medium is provided, the non-temporary computer-readable medium comprises instructions causing a computing environment to perform a method of dynamically adjusting or adjusting user alerts based on a determination of cognitive awareness, thereby providing data relating to the treatment of a diabetic condition of concern, the method comprising: (a) identifying a current or future diabetic condition of concern, the identification being at least partially based on a glucose concentration value; (b) estimating or predicting the user's cognitive awareness of the identified current or future diabetic condition of concern; (c) warning the user using a user prompt on the user interface of a monitoring device if the result of the estimation or prediction is that the user is not cognitively aware of the identified current or future diabetic condition of concern, the user prompt indicating a diabetic condition of concern; and (d) thereby the user is warned of a diabetic condition of concern only if the user is not aware of the diabetic condition of concern and the notification is effective to the user, and only at these times.

[0024] Implementations of the aspects and embodiments may include one or more of the following: Warnings may be optimized for the patient's cognitive awareness, thereby resulting in fewer warnings than warnings would otherwise be provided without considering the user's cognitive awareness. The monitoring device may be a smartphone, smartwatch, dedicated monitoring device, or tablet computer. In systems and methods following these principles, excessive prompting, repetitive prompting, or intrusive prompting is minimized or avoided. In systems and methods following these principles, the user can build trust if the system is optimized for the user or only warns about effective notifications. Estimation or prediction of the user's cognitive awareness may include determining whether an identified current or future diabetic condition worthy of attention includes an abnormal glucose trace. An abnormal glucose trace may include an abnormal pattern or abnormal glucose response.

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

[0026] The identification and estimation or prediction steps are repeated until it is estimated or predicted that the user will become cognitively aware of the identified attention-worthy diabetic condition, and then the user is alerted using a user prompt. Estimating or predicting the user's cognitive awareness may involve receiving data from an application or website via an appropriate 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] Estimates or predictions of user cognitive awareness may be based at least in part on one or more of the following: demographic data, behavioral or contextual information-related data, user life goals-related data, user privacy settings-related data, or a combination thereof. Estimates or predictions of user cognitive awareness may also be based at least in part on real-time data, which may include data related to the GPS application of the monitoring device, data related to the accelerometer of the monitoring device, behavioral or contextual information-related data, data related to the location of the user's followers, data related to the user's metabolic rate, data related to the user's blood glucose urgency index, heart rate data, sweat content data, data related to the user's wearable sensors, insulin data, or a combination thereof.

[0028] Estimating or predicting user cognitive awareness may involve recognizing one or more individualized patterns associated with the user. These individualized patterns may correspond to the envelope of a characteristic analyte concentration signal trace occurring before or after an event. The event may be associated with eating, exercise, or sleep. The determination may be whether the user is cognitively unaware that the current signal trace is outside the envelope of the characteristic analyte concentration signal trace.

[0029] The method may further include indicating confidence in the user prompt. If the estimation or prediction results in the user being unaware of a diabetic condition of concern, the method may further include displaying a user prompt immediately. The estimation or prediction is further based on the user's location information, where the location information indicates that the user is within a predetermined threshold of a grocery store or restaurant. If the estimation or prediction results in the user being unaware of a diabetic condition of concern, the method may further include warning the user with a user prompt after a certain time delay, the duration of which is based on at least the identified diabetic condition of concern, as well as the glucose concentration value and / or the rate of change in the glucose concentration value.

[0030] User prompts may include queries for the user to enter data. Queries may request data for the user to enter regarding dosage, diet, or exercise. If data from the user interface or data from an accelerometer associated with a monitoring device determines that the user is ignoring a user prompt, and the user prompt does not address a dangerous condition, the method may further include storing information that the user ignored the user prompt under the aforementioned conditions, and using the stored information as part of a subsequent estimation or prediction step.

[0031] Identifying current or future diabetic conditions requiring attention may include determining clinical values ​​of glucose concentration and / or the rate of glucose change and / or the blood glucose emergency index value. Identifying current or future diabetic conditions requiring attention may include measuring glucose signal signatures, comparing the measured signatures to multiple binned signatures, and classifying the diabetic conditions requiring attention into one of the multiple bins based on the comparison. Identifying current or future diabetic conditions requiring attention may include determining one or more time-based trends in glucose concentration values ​​and basing the identified conditions on the determined trends. Trends may correspond to glucose concentration values ​​hovering within a range, or rising or falling within a range, where hovering corresponds to remaining 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. Ambiguous boundaries may be used to define the range.

[0032] The method may further include transmitting an indication to the drug pump that the user is unaware of a diabetic condition requiring attention. If the estimation or prediction results in the user being unaware of a diabetic condition requiring attention, the method may further include activating the drug pump to produce a drug bolus. The drug bolus may be a meal bolus of insulin. If the estimation or prediction results in the user being unaware of a diabetic condition requiring attention, the method may further include activating the drug pump to change the basal rate. The drug may be insulin. The method may further include determining whether the drug pump can treat the diabetic condition requiring attention completely or partially, and if it determines that it can treat the condition, either not alerting the user or changing the user prompt, compared to the case where the drug pump cannot treat the diabetic condition. If the estimation or prediction results in the user being unaware of a diabetic condition requiring attention, the method may further include determining when to alert the user using a user prompt. The user prompt, if displayed, may include a color or arrow instead of, or in addition to, a glucose concentration value. The user prompt, if displayed, may include a prediction of a glucose concentration value. User prompts, if displayed, may include an audible indicator, the volume of which is automatically adjusted to ambient noise measured by the monitoring device or a device communicating with the monitoring device, wherein the adjustment to ambient noise may include increasing the volume of the audible indicator to ambient noise until a threshold level of signal-to-noise ratio is reached. User prompts may be associated with attention-worthy diabetic conditions that occur during periods when the user has a hypoglycemic emergency index.

[0033] If the estimation or prediction results in the user being unaware of a diabetic condition of concern, the method may further include alerting the user with a user prompt after a certain delay, based on the identified diabetic condition of concern, as well as the glucose concentration value and / or the rate of change in the glucose concentration value, rather than on duration. If the estimation or prediction results in the user being unaware of a diabetic condition of concern, the method may further include alerting the user with a user prompt after a certain delay, based on a personalized pattern learned by the monitoring device, rather than on duration.

[0034] Identified diabetic conditions requiring attention may correspond to abnormal glucose responses or abnormal patterns, which are learned by the monitoring device and not by user input. User prompts may be displayed at dynamic timing on a pre-designed user interface rather than an adapted user interface. If the estimation or prediction results in the user being unaware of a diabetic condition requiring attention, the method further includes immediately alerting the user using a user prompt, regardless of any instructions received from other monitoring device applications not to alert the user using a user prompt. If the estimation or prediction results in the user being unaware of a diabetic condition requiring attention, the method further includes immediately alerting the user using a user prompt, regardless of any instructions not to alert the user using a user prompt based on data or settings entered by other users. Estimations or predictions of whether a user is unaware of a diabetic condition requiring attention may be based at least partially on real-time data and not entirely on retrospective data.

[0035] In a second embodiment, a system is provided for providing smart alerts in response to a user's attention-worthy diabetic condition, the system including a CGM application running on a mobile device, configured to receive data from sensors at least periodically or occasionally, 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 with the CGM application, and receiving data from the CGM application, configured to perform the method contained in the medium described in the claim.

[0036] In a third aspect, a non-temporary computer-readable medium is provided which includes instructions for causing a computing environment to perform a method for safely reducing warnings to a user of a diabetic condition requiring attention, the method comprising: (a) identifying a current or future diabetic condition requiring attention, the identification being at least in part based on a glucose concentration value; (b) determining whether the identified diabetic condition requiring attention is abnormal to the user; (c) if the determination is that the identified diabetic condition is abnormal to the user, warning the user using a user prompt on the interface of a user monitoring device, the user prompt indicating a diabetic condition requiring attention; and (d) thereby the user is notified of a diabetic condition requiring attention only if the identified diabetic condition is abnormal to the user.

[0037] The execution of the embodiments and models may include one or more of the following: Determining whether an identified diabetes condition warranting attention is abnormal for the user may include determining whether the identified diabetes condition may include glucose traces that follow a pattern that does not exhibit other pattern features relevant to the user. Determining whether an identified diabetes condition warranting attention is abnormal for the user may include determining whether the identified diabetes condition may include glucose traces that follow a pattern that does not exhibit other pattern features relevant to the user.

[0038] In a fourth aspect, a non-transient computer-readable medium is provided which includes instructions for causing a computing environment to perform a method of prompting a user about a diabetic condition of concern, the computing environment communicating with a drug delivery device, the user prompts being optimized for effectiveness to the user by at least partially reducing their number, the user prompts providing data relating to the treatment of a diabetic condition of concern, the method comprising: (a) identifying a current or future diabetic condition of concern, the identification being at least partially based on glucose concentration values; (b) making a first estimate or prediction of the user's cognitive awareness of the identified current or future diabetic condition of concern; and (c) the result of the first estimate or prediction being used by the user to determine the current diabetic condition of concern. (d) If the result is that the drug delivery device is not cognitively aware of a current or future diabetes condition of concern, the step of making a second estimation or prediction of the drug delivery device's computer awareness of an identified current or future diabetes condition of concern; and (e) if the result of the second estimation or prediction is that the drug delivery device is not aware of an identified current or future diabetes condition of concern, the step of alerting the user using a user prompt on the monitoring device's user interface, the user prompt being an alert indicating a diabetes condition of concern; and (f) thereby, if both the user and the drug delivery device are unaware of a diabetes condition of concern and the notification is effective for the user, and only at these times the user will be notified of a diabetes condition of concern.

[0039] The implementation of the embodiments and models may include one or more of the following: The method may further include the step of determining whether a drug delivery device can treat an identified current or future diabetic condition worthy of attention, and if the determination is that the drug delivery device cannot treat the identified diabetic condition, the step of warning the user using a user prompt. The current or future diabetic condition may include hypoglycemia, the drug delivery device may be an insulin delivery device, and the method may further include stopping or reducing the activity of the insulin delivery device based on the diabetic condition of hypoglycemia. Stopping or reducing the activity may occur sooner if the user is cognitively aware of hypoglycemia. Making the first estimation or prediction may be based at least in part on interaction between the drug delivery device and the user.

[0040] In further aspects and embodiments, the method features of various aspects described above will be explained in terms of systems as they exist in various aspects. Any feature of any embodiment of any of the first to fourth aspects mentioned above, including but not limited to any embodiment of any of the first to fourth aspects mentioned above, is applicable to all other aspects and embodiments revealed herein, including but not limited to any embodiment of any of the first to fourth aspects mentioned above. Furthermore, any feature of any embodiment of various aspects, including but not limited to any embodiment of any of the first to fourth aspects mentioned above, can be combined in any way, partially or entirely independently, with other embodiments described herein, for example, one, two, three or more embodiments may be combined whole or partially. Furthermore, any feature of any embodiment of various aspects, including but not limited to any embodiment 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 carried out by a system or apparatus of another aspect or embodiment, and any aspect or embodiment of the system or apparatus may be configured to carry out a method of another aspect or embodiment, including, but not limited to, any embodiment of any of the first to fourth aspects mentioned above.

[0041] Individuals with diabetes face numerous challenges in controlling their glucose levels due to the complex interactions between food, insulin, exercise, stress, activity, and other physiological and environmental conditions. Because there is considerable variability in how different conditions affect different individuals and what measures are effective for them, established principles of glucose management are sometimes inadequate. As mentioned above, different situations require different measures for different individuals, making even providing warnings or alerts problematic. Therefore, providing customized warnings and alerts to users, as well as anticipating situations that users may not be consciously aware of, is extremely beneficial and desirable.

[0042] Therefore, systems and methods following this principle provide techniques for issuing warnings and / or alerts to a user regarding diabetic conditions or states that warrant the user's attention, but only when the system determines, for example, estimates or predicts, that the user is still not cognitively aware of those conditions. As a result, such systems and methods following this principle reduce the uncertainties typically associated with diabetes and improve quality of life.

[0043] Advantages of a particular aspect or embodiment include one or more of the following: In particular, “smart alerts” are provided to inform the user of a diabetic condition that would otherwise be unconsciously missed by the user. Thus, such smart alerts do not cause frustration to the user because they occur only when necessary and not when unnecessary (for example, the smart alert function does not alert the user if the user has administered the appropriate amount of insulin at the appropriate time for a meal). Such smart alerts alert the user to dangerous or urgent conditions more efficiently than conventional alerts, resulting in greater certainty and reliability. Such “smart” alerts further avoid the problem of alert fatigue. Specifically, in CGM applications running on smartphones, alert fatigue is common with threshold-based alert algorithms because it was previously not possible to quantify the user’s cognitive state. In the embodiments described herein, cognitive state data is inferred by converting physiological and non-physiological data into estimates or predictions 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 of the invention is provided to introduce a selection of concepts in a simplified form. Concepts are further described in forms for carrying out the invention. Other elements or steps not described in this summary of the invention are conceivable, and no elements or steps are necessarily required. This summary of the invention is not intended to identify any major or essential features of the subject matter described in the claims, nor is it intended to be used as an aid in determining the scope of the subject matter described in the claims. The subject matter described in the claims is not limited to implementations that resolve any or all of the disadvantages described in any part of this disclosure.

[0045] Herein, these embodiments are discussed in detail, with an emphasis on highlighting their advantageous features. These embodiments depict, for illustrative purposes only, novel and non-obvious systems and methods following the present principle as shown in the accompanying drawings. These drawings include the following figures, in which similar figures indicate similar parts. [Brief explanation of the drawing]

[0046] [Figure 1] This is a schematic diagram of a system that follows this principle. [Figure 2] This is a flowchart of the first method, which follows this principle. [Figure 3] A schematic diagram illustrates how a smart warning application can be implemented according to this principle, or how it can be shown with specific examples. [Figure 4] This is a flowchart of the second method, which follows this principle. [Figure 5] This is a logical diagram of the input to the smart warning function or application, and the resulting smart warning output. [Figure 6] This is a flowchart of the third method, which follows this principle. [Figure 7] Figure 7 shows a smart warning and a glucose trace with the smart warning appearing at the top. [Figure 8]Figure 7 shows a smart warning and a glucose trace with the smart warning appearing at the top. [Figure 9] This document provides an example of an additional implementation of smart warning output on a user interface that adheres to this principle. [Figure 10] This document provides an example of an additional implementation of smart warning output on a user interface that adheres to this principle. [Figure 11] This document provides an example of an additional implementation of smart warning output on a user interface that adheres to this principle. [Figure 12] This document provides an example of an additional implementation of smart warning output on a user interface that adheres to this principle. [Figure 13] This document provides an example of an additional implementation of smart warning output on a user interface that adheres to this principle. [Figure 14] This document provides an example of an additional implementation of smart warning output on a user interface that adheres to this principle. [Figure 15] Further examples of additional implementations of smart warning output on a user interface, in accordance with this principle, are provided. [Figure 16] Further examples of additional implementations of smart warning output on a user interface, in accordance with this principle, are provided. [Figure 17] Further examples of additional implementations of smart warning output on a user interface, in accordance with this principle, are provided. [Figure 18] This document provides examples of additional implementations of smart warnings and glucose traces overlaid with those smart warnings. [Figure 19] This document provides an example of an additional implementation of smart warnings and glucose traces overlaid with those smart warnings. [Figure 20] This document provides examples of additional implementations of smart warnings and glucose traces overlaid with those smart warnings. [Figure 21] This document provides an example of an additional implementation of smart warnings and glucose traces overlaid with those smart warnings. [Figure 22]This example illustrates the time progression of a smart warning system based on this principle. [Figure 23] This example illustrates the time progression of a smart warning system based on this principle. [Figure 24] This example illustrates the time progression of a smart warning system based on this principle. [Figure 25] This example illustrates the time progression of a smart warning system based on this principle. [Figure 26] This example illustrates the time progression of a smart warning system based on this principle. [Figure 27] This example illustrates the time progression of a smart warning system based on this principle. [Figure 28] This example illustrates the time progression of a smart warning system based on this principle. [Figure 29] This example illustrates the time progression of a smart warning system based on this principle. [Figure 30] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 31] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 32] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 33] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 34] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 35] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 36] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 37] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 38] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 39]This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 40] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 41] This example illustrates the implementation of smart warnings as part of the lock screen on a smartphone. [Figure 42] This is a schematic diagram of a system following this principle, incorporating data from a delivery device. [Figure 43] This is a flowchart of the fourth method, which follows this principle. [Figure 44] This is a flowchart of the fifth method, which follows this principle. [Figure 45] This is a schematic diagram of a system that follows this principle. [Figure 46] This is a more detailed schematic diagram of the sensor electronics module. [Modes for carrying out the invention]

[0047] Similar reference numbers refer to the same elements throughout. Elements are not scaled unless otherwise specified.

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

[0049] As used herein, the term “analyte” generally refers to a substance or chemical component in an analyzable biological fluid (e.g., blood, interstitial fluid, cerebrospinal fluid, lymph, or urine). Analytes may include naturally occurring substances, artificial substances, metabolites, and / or reaction products. In some embodiments, the analyte for measurement by sensor heads, devices, and methods is glucose. However, other analytes were also planned, and these other analytes include acarboxyprothrombin, acylcarnitine, adenine phosphoribosyltransferase, adenosine deaminase, albumin, α-fetoprotein, amino acid profile (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan), andrenostenedione, antipyrine, arabinitol enantiomer, 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 isozyme, cyclosporine A, d-penicillamine, de-ethylchloroquine, and de-ethylchloroquine. Droepiandrosterone sulfate, DNA (acetylated polymorphism), alcohol dehydrogenase, α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, β-thalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber's hereditary optic neuropathy MCAD, RNA, PKU, Plasmodium vivax, sex differentiation, 21-deoxycortisol), desbutylhalofantrin, dihydropteridine reductase, diphtheria / tetanus antitoxin, erythrocyte arginase, erythrocyte protoporphyrin, esterase D, fatty acids / acylglycine, free β-human chorionic gonadotropin, free erythrocyte porphyrin, free thyroxine (FT4), free triiodothyronine (FT3), fumarylacetase,Galactose / gal-1-phosphate, galactose-1-phosphate uridyltransferase, gentamicin, analyte-6-phosphate dehydrogenase, glutathione, glutathione peroxidase, glycocholic acid, glycosylated hemoglobin, halofantrin, hemoglobin variant, hexosaminidase A, human erythrocyte carbonic anhydrase I, 17-α-hydroxyprogesterone, hypoxanthine phosphoribosyltransferase, immunoreactive trypsin, lactate, lead, lipoprotein (( a) B / A-1, β) Lysozyme, Mefloquine, Netylmycin, Phenobarbiton, Phenytoin, Phytanic acid / Pristanic acid, Progesterone, Prolactin, Prolidase, Purine nucleoside phosphorylase, Kinin, Inverted triiodothyronine (rT3), Selenium, Serum pancreatic lipase, Shisomycin, Somatomedin C, Specific antibodies (Adenovirus, Antinuclear antibody, Anti-zeta antibody, Arbovirus, Aujeszky's disease virus, Dengue fever virus, Guinea worm, Echinococcus granulosus, Entamoeba histolytica, Entamoeba histolytica) Rovirus, Giardia lamblia, Helicobacter pylori, Hepatitis B virus, Herpesvirus, HIV-1, IgE (atopic disease), Influenza virus, Donovan leishmania, Leptospirosis, Measles / Mumps / Rubella, Mycoplasma leprae, Mycoplasma pneumoniae, Myoglobin, Irocystitis rotundifolia, Parainfluenza virus, Plasmodium falciparum, Poliovirus, Pseudomonas aeruginosa, Respiratory rash virus, Rickettsia (scrub typhus), Schistosomiasis mansoni, Toxoplasma gondii, Treponema pallidum, Creutzia crus-galli Examples of analytes include, but are not limited to, *Trypanosoma lanceols*, *Trypanosoma brunneoblastonii*, *Trypanosoma bancroftis*, *Trypanosoma leukemia*, *Trypanosoma virulence*, *Trypanosoma stomatitis*, *Trypanosoma brunneoblastoniiIt can be naturally present in biological fluids. Alternatively, it can be found in analytes, such as contrast agents for diagnostic imaging, radioisotopes, chemical agents, fluorocarbon-based artificial blood, or insulin, ethanol, cannabis (marijuana, tetrahydrocannabinol, hashish), inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons), cocaine (crack cocaine), stimulants (amphetamine, methamphetamine, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine), and inhibitors (barbiturates, methacarone, tranquilizers, e.g., Valium, Librium, Milto). Drugs or pharmaceutical compositions that may be introduced into the body include, but are not limited to, wn, Serax, Equanil, Tranxene, hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin), narcotics (heroin, codeine, morphine, opium, meperidin, Percocet, Percodan, Tussionex, Fentanyl, Darvon, Talwin, Lomotil), designer drugs (fentanyl, meperidin, amphetamine, methamphetamine, and analogs of phencyclidine, e.g., Ecstasy), anabolic steroids, and nicotine. Metabolites of drugs and pharmaceutical compositions may also be considered as analytes. For example, analytes such as ascorbic acid, uric acid, dopamine, norepinephrine, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5-hydroxytryptamine (5HT), and 5-hydroxyindoleacetic acid (FHIAA), as well as other neurochemicals and chemicals produced in the body, can be analyzed.

[0050] As used herein, the term “calibration” generally refers to a process of determining the relationship between sensor data and corresponding reference data, whether or not reference data is used in real time, which may be used to convert sensor data into values ​​that are substantially equivalent in meaning to the reference data. In some embodiments, i.e., in a continuous analyte sensor, calibration may be updated or recalibrated over time (in the factory, in real time, and / or retrospectively) as changes occur in the relationship between sensor data and reference data due to changes in, for example, sensitivity, baseline, transport, metabolism, etc.

[0051] As used herein, the terms “calibrated data” and “calibrated data stream” generally relate to data that has been transformed from a raw state (e.g., digital or analog) to another state using a function, such as a transformation function, in order to provide meaningful value to the user.

[0052] As used herein, the term “algorithm” generally refers to a computational process (e.g., a program) that involves, for example, the use of computer processing to transform information from one state to another. In the implementations described herein, an algorithm may perform a decision-support application / function that takes input from a sensor, a computer application, or user input and transforms these into outputs that are rendered to the user on a user interface or on another device.

[0053] As used herein, the term “sensor” generally refers to a component or area of ​​a device capable of quantifying an analyte, but is not limited to this.

[0054] The term "glucose sensor" generally refers to any mechanism (e.g., enzymatic or non-enzymatic) capable of quantifying glucose, though this is not limited to such mechanisms. For example, some embodiments utilize a membrane containing a 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] Since there is a proportional change in co-reactant O2 and product H2O2 for each glucose molecule metabolized, the glucose concentration can be determined by using electrodes to monitor the current change of either the co-reactant or the product.

[0056] As used herein, the terms “operably connected” and “operably coupled” generally relate to one or more components being coupled to another component in a manner that enables the transmission of signals between components, but are not limited to these. For example, one or more electrodes may be used to detect the amount of glucose in a sample, and this information may be converted into a signal, such as an electrical or electromagnetic signal, which may then be transmitted to an electronic circuit. In this case, the electrodes are “operably coupled” to the electronic circuit. These terms are broad enough to include wireless connections.

[0057] As used herein, the term “variation” generally relates to a deviation or change from a point, line, or dataset, but is not limited to this. In one embodiment, the estimated analyte value may have variance 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 parameters derived from ongoing studies of physiological data in humans and / or animals, but are not limited to these. For example, the maximum sustained rate of change of glucose in humans is approximately 4–5 mg / dL / min and approximately 0.1–0.2 mg / dL / min.2 The maximum acceleration of the rate of change is considered a 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 represent the area of ​​greatest risk in patient treatment; therefore, the physiologically possible rate of change can be set at the maximum and minimum values ​​based on continuous study of glucose data. As yet another example, the best solution for the shape of the curve at any point along a glucose signal data stream over a specific period (e.g., about 20–30 minutes) is recognized to be a straight line, which can be used to set a physiological limit. These terms are broad enough to include physiological and parameteristic aspects of any analyte.

[0059] As used herein, the term “measured analyte value” generally refers to the analyte value or set of analyte values ​​over a period of time during which the analyte data was measured by the analyte sensor. The term is broad enough to include data from the 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 refers to an analyte value or set of analyte values ​​extrapolated by an algorithm from measured analyte values, but is not limited to these.

[0061] As used herein, the following abbreviations apply: Eq and Eqs (equivalents), mEq (milliequivalents), M (moles), mM (millimoles), μM (micromoles), N (normal), mol (moles), mmol (millimoles), μmol (micromoles), nmol (nanomoles), g (grams), mg (milligrams), μg (micrograms), Kg (kilograms), L (liters), mL (milliliters), dL (deciliters), μL (microliters), cm (centimeters), mm (millimeters), μm (micrometers), nm (nanometers), h and hr (hours), min (minutes), and sec. (seconds), and °C (degrees Celsius).

[0062] As used herein, the term “continuous glucose sensor” generally refers to a device that continuously or continuously measures the glucose concentration of body fluids (e.g., blood, plasma, interstitial fluid, etc.) over time intervals ranging from fractions of a second to, for example, 1, 2, or 5 minutes or more.

[0063] As used herein, the terms “continuous glucose sensing” or “continuous glucose monitoring” generally refer to a period of continuous or sustained monitoring of glucose concentrations in host fluids (e.g., blood, serum, plasma, extracellular fluid, tears, etc.) at time intervals of, for example, up to 1, 2, or 5 minutes or more. In one exemplary embodiment, the glucose concentration in the host's extracellular fluid is measured every 1, 2, 5, 10, 20, 30, 40, 50, or 60 seconds.

[0064] As used herein, the term “substantially” generally refers to an express, majority but not necessarily complete amount, which may include more than 50 percent, more than 60 percent, more than 70 percent, more than 80 percent, or more than 90 percent.

[0065] As used herein, the terms “processor” and “processor module” generally refer to computer systems, state machines, processors, etc., designed to perform arithmetic or logical operations using logic circuits that correspond to and process basic instructions that drive 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 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 and / or commands to mechanical devices on a display.

[0067] As used herein, the term “separate” generally refers to parameters and / or variables that are independent and do not depend on each other, but is not limited to them. Conversely, as used herein, the term “related” refers generally refers to parameters and / or variables that are related in some way to each other and can be derived from each other, but is not limited to them. For example, the time derivative of a sensor signal is related to the sensor signal, while the user’s gender and the current analyte concentration are considered separate. However, it should be noted here that multiple parameters used in a decision support application / function may relate to a single action or event (for example, such parameters may relate to the timing and duration of an action). The terms “independent” are 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 underlying independent variables.

[0068] As used herein, the term “insulin sensitivity” generally refers to the relationship between how much insulin needs to be produced to store a certain amount of glucose, though this is not limited to diabetes. 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. These are overall measures, such as weight, blood pressure, and heart rate. Insulin sensitivity has a healthy range and an unhealthy range. In diabetes management, users generally need to know their insulin sensitivity factor (ISF) when making decisions regarding bolus administration. The term “ISF” is sometimes used interchangeably with “correction factor” (CF). For example, a typical calculation a user might need to perform is, for example, “If my blood glucose is 100 mg / dL too high, how many units of insulin do I need to take to correct that high blood glucose and lower my blood glucose 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. The determination of insulin sensitivity, as well as other types of sensitivity, will be discussed in more detail below, but it should be noted here that knowledge of insulin sensitivity can be obtained based on data from, for example, CGM, activity monitor, and real-time analysis of insulin pump data, as well as data from retrospective analysis of those sensors, and data from, for example, electronic health records. Other factors that may be related to insulin sensitivity or ISF may include correlations with time, pain, and / or exercise; other cardiovascular health related to heart rate variability, stroke volume, and metabolic problems; insulin distribution capacity; body temperature; insulin type based on insulin sensitivity measures, profile, peak, and time between peaks; atmospheric pressure (i.e., "airplane mode" may be an input); and any activity that most affects the patient or user.

[0069] As used herein, the term “insulin resistance” generally refers to a medical condition in which cells in the human body are unable to adequately utilize insulin for the normal process by which cells transport glucose or other metabolites from the bloodstream. Insulin resistance reduces insulin sensitivity. While everyone has insulin sensitivity, only certain individuals suffer from insulin resistance.

[0070] The term “lifestyle factors” generally refers to quantitative or qualitative (but in some way convertible to quantitative) parameters related to disease management that are not directly measured by physiological sensors, but are not typically directly measured by physiological sensors. In some cases, “lifestyle factors” relate to trends or recurring events that are not critical but can be determined or used when systems and methods following this principle provide therapeutic prompts to a user, or when modifying or altering therapeutic prompts to a user. However, trend information does not necessarily have to correspond to a certain pattern, although some patterns constitute trend information. In some implementations, lifestyle factors may be identical to correlated parameters considered elsewhere. Lifestyle factors (also called “lifestyle context”) may relate to a specific amount that is physiological, such as insulin sensitivity, but may also relate to more external parameters such as sleep sensitivity, food sensitivity, or exercise sensitivity. In other words, lifestyle factors are generally quantitatively determined but, in most cases, are not directly measured by sensors.

[0071] The terms “state” and “state model” generally refer to a data structure useful for modeling a patient, for example, for decision support or smart alerting purposes, though this is not a limiting definition. Generally, a patient state model is assumed to satisfy one of several states, which depend on various lifestyle and clinical factors. As a specific example, a patient state may correspond to a current insulin sensitivity profile. Multiple states or state models may then be used in combination with real-time inputs, such as time, calendar, CGM glucose values, and rate of change, to provide therapy prompts to support therapeutic decision-making for the user. In one implementation, several diabetes decision states are defined by one or more strongly correlated parameters, which may be lifestyle parameters and may be selected by the user through a user interface or learned over time by machine learning and / or cloud analytics.

[0072] The term "diabetic condition requiring attention" generally refers to a biological condition in a diabetic user for which intervention is desirable. For example, hypoglycemia or hyperglycemia are diabetic conditions requiring attention. If such a condition is imminent or likely to occur but has not yet occurred, this user is also considered to be in a diabetic condition requiring attention. A diabetic condition requiring attention can vary in urgency, but generally refers to a user condition for which intervention is predictable or determinable, beneficial to the user, and generally leads the user towards a state of normal blood glucose or towards a target range of glucose values, for example, the center of the target range corresponding to normal blood glucose.

[0073] The exemplary embodiments disclosed herein relate to the use of glucose sensors to measure a substance indicating the concentration or presence of glucose or another analyte. In some embodiments, the glucose sensor is a continuous device, e.g., subcutaneous, transdermal, transcutaneous, non-invasive, intraocular, and / or intravascular (e.g., intravenous) device. In some embodiments, the device may analyze multiple intermittent blood samples. These glucose sensors may use any method of glucose measurement, including enzymes, chemicals, physicals, electrochemistry, optics, photochemistry, fluorescence systems, spectrophotometry, spectroscopy (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), polarization, calorimetry, iontophoresis, radiation, and the like.

[0074] A glucose sensor may provide a data stream indicating the concentration of an analyte within a host using any known detection method, including invasive, minimally invasive, and non-invasive detection techniques. The data stream is typically a raw data signal used to provide a useful value of the analyte to a user, such as a patient or healthcare professional (HCP, e.g., a doctor, physician, nurse, or caregiver), who may be using the sensor.

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

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

[0077] The following description and examples illustrate this embodiment with reference to the drawings. In the drawings, reference numerals indicate elements of this embodiment. These reference numerals are reproduced below in connection with the discussion of the corresponding drawing features.

[0078] Systems and methods following this principle provide techniques for incorporating “smart alerts” into analyte monitoring systems, specifically continuous glucose monitoring systems. In one implementation, smart alerts may be provided by a smart alert application or algorithm of its own, generally running in parallel with the CGM application. In another implementation, smart alerts may be implemented by an additional program / instruction attached to an existing application, such as the CGM application. For this reason, in this specification, smart alerts are generally referred to as smart alert applications / functions.

[0079] A particular exemplary embodiment is shown in Figure 1, which illustrates a system 50 in which a patient 102 wears a sensor 10, and the sensor transmits measurements using a sensor electronic device 12. The sensor electronic device may transmit data corresponding to analyte measurements to a smart device 18, e.g., a smartphone and / or smartwatch, to a dedicated receiver 16, or to other devices, e.g., 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 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 electronic device are described below with respect to Figures 45 and 46.

[0080] Referring to flowchart 101 in Figure 2, we can see how this principle is implemented to enable the smart alert function within an analyte monitoring system, for example, within a continuous glucose monitor. The first step is to determine whether the user has a diabetic condition that warrants attention (step 13). This step is performed in most implementations where, if the diabetic condition does not warrant attention, a smart alert is generally not given (step 11). However, as mentioned, even if the user has a diabetic condition that warrants attention, an alert is not necessarily given.

[0081] Specifically, the estimation 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 measuring devices, regarding whether the user is cognitively aware of a diabetic condition worth paying attention to (Step 17). If the estimation or prediction result indicates that the user is cognitively aware, it is again determined that no warning is issued (Step 11). However, if the estimation or prediction result indicates that the user is not cognitively aware, a smart warning may be provided (Step 19).

[0082] Generally, estimations or predictions are performed in an automated manner and are based on stored data or received or determined data. Various types of input data are described below, but it should be noted that such data may relate to data with pattern signatures (if the user has experienced that pattern many times before, it can be inferred that the user is cognitively aware), behavioral data, historical data (including the use of retrospective analysis in some implementations), etc. The results of the estimation or prediction may be binary yes / no, but in many other cases, they may be quantitative estimates or predictions, for example, in terms of the percentage of likelihood that the user is cognitively aware. Naturally, this can be translated into a yes / no response by comparing this percentage to a single threshold. However, in various other cases, especially when multiple thresholds are involved, multiple and different responses may result depending on the value of the percentage of likelihood.

[0083] Other alternative implementations may include the use of user input. For example, by using a slider bar, by selecting radio buttons, or by other user interface mechanisms, the user can influence the operation of the smart alert function. The user can also influence the sensitivity of the function depending on what the user wants from the reminders and alerts. The user can further influence the content of the reminders by selecting what information they want to review when one or more categories of alerts / events occur. Thus, through preferred choices, the user can influence the operation, timing, and display of smart alerts.

[0084] Details of the above-mentioned features are described here.

[0085] Referring to Figure 3, the smart alert function may operate as a secondary application 25 running in parallel with a primary analyte monitoring application, such as a primary CGM application, on the smart device 18, or the function may be provided as a function within a CGM app (or another app) running on the smart device 18. In either case, other functions may be performed as part of such a secondary application or function. Running as a secondary application running in parallel with the primary monitoring application allows additional or subsequent update functions to be tested without affecting the functionality of the primary CGM application. Generally, since fewer alerts are usually required, the smart alert function brings technical improvements to the operation of the monitoring application, such as lower computational costs and battery power savings. In addition, the device itself has technical functions related to data that previous systems did not have, such as data on whether the user is cognitively aware of their diabetic condition.

[0086] Next, referring to Chart 200 in Figure 4, further details are provided regarding step 17, namely, the system's use of machine learning, as well as stored and / or real-time data, to determine whether the user is cognitively aware of a diabetic condition worth attention. As mentioned above, in some implementations, this step may be expressed as a configuration of machine or system learning for predicting or estimating whether the user is cognitively aware of a diabetic condition worth attention (step 22). That is, the system determines metrics used in machine learning to provide predictions or estimates about the user's cognitive awareness, but which are also used to acquire or determine data in real time that are compared in some way with other data, for example, with a threshold, and which are then used in a determination to provide smart alerts.

[0087] One method by which a system can determine such metrics that enable prediction or estimation of a user's cognitive awareness of such a diabetic state is to determine whether the diabetic state, or in other words, the experienced physiological glucose response, exhibits features of data previously observed and / or experienced by the user (step 24). If machine learning has learned data that is typical for that user, and the obtained or determined metrics indicate that the current real-time data is similar to such typical data, then often the system's determination may be that the user is already cognitively aware, i.e., the result of the estimation or prediction is that the user is likely aware of a diabetic state that warrants attention, and therefore no warning needs to be issued. Such similarity of data can be determined by several methods, including determining whether the real-time current glucose trace has characteristic signatures that are similar to previously determined characteristic signatures, e.g., duration, rise time, width, FWHM, etc. Conversely, if a physiological response is abnormal for the user, the quantitative probability that the user has such cognitive awareness decreases accordingly. In this case, a smart alert may be generated based on the data of the reduced quantitative probability, resulting in the rendering of a display of a attention-worthy diabetic condition on the screen or display, where it should be understood that such rendering results in a change to the user interface depicted on such a screen or display. For example, a physiological response may include a series of measured glucose values ​​over time. If the series of measured glucose values ​​are similar to, for example, a previous series of measured glucose values ​​encountered over the same or similar period, and the quantified similarity is greater than a given threshold criterion, such similarity increases the probability that the user has recognized those attention-worthy diabetic conditions.

[0088] In certain implementations, it may be determined whether a physiological response is part of a user's established pattern (step 26). Here, the term “pattern” is used, for example, to associate a repeating data sequence identified in the data received in glucose monitoring with the occurrence of “nocturnal hypoglycemia” that commonly occurs in that user. If a physiological response is part of a pattern the user has previously encountered, then, conversely, the estimate or prediction of the likelihood of user recognition may be high, or, more quantitatively and / or granularly, elevated or increased. The degree of elevation or increase may be based at least in part on the frequency or number of times the user has previously experienced that pattern. Identifying an established pattern may generally involve the following steps relating to a series of measured glucose values ​​over time: Identification may include quantifying similarities in data received over two or more time periods, and, if the quantified similarity is greater than a given threshold criterion, identifying the similarity as an established pattern. Typical identified patterns may include nocturnal hypoglycemia, postprandial hyperglycemia, postprandial hypoglycemia, hyperglycemia at a specific time, hypoglycemia at a specific time, weekend vs. weekday hyperglycemia / hypoglycemia, post-event hyperglycemia / hypoglycemia, and best-day patterns. Since patients are likely to be cognitively aware of the extent to which these identified patterns occur in a given patient, the smart alert function may be configured not to issue alerts to the patient. It should be further noted that in many cases, events occur before physiological responses, and such events can be detected and identified as common to and / or occurring before the repeating data sequences constituting the detected pattern, for example, appearing in two or more data sequences, appearing in half of the data sequences, appearing in 75% of the data sequences. In this sense, the term “common” is used to refer to appearance in two or more data sequences constituting the pattern, and is generally not necessarily common to the user. The occurrence rate of an event may be measured by referring to a predetermined percentage ratio, such as appearing in at least 25%, 50%, 75%, 90%, 95%, 99%, etc., of the data sequences constituting the pattern.To the extent that a warning is expected regarding the occurrence of an event, and to the extent that a warning includes an enumeration of events as the cause, the smart warning function may be further configured to stop or not warn for certain events, since it can be presumed or predicted that the user is cognitively aware of the event.

[0089] It should be noted that in certain implementations, past systems anticipated the issuance of a warning based on exceeding a glucose warning threshold before an alert was issued when the user went outside the range. Predictive algorithms were used to develop data predicted using predictive algorithms, and this data was then compared to a threshold to preemptively warn the user when they went outside the range. However, in both cases, the system would not issue a warning until some degree of current or expected unspecified fluctuation in glucose occurred.

[0090] However, in systems and methods following this principle, historical data and current real-time data corresponding to glucose responses to events such as exercise or diet can be used by machine learning to identify typical responses for the user. When a user exhibits a typical response, the system may suppress the issuance of a warning, or the system may not generate a warning at all.

[0091] However, if the system or method identifies that the current glucose trace is not typical compared to previous glucose traces, i.e., that the user is having an abnormal response, the user will be warned to take appropriate action. For example, a user may be determined to have an abnormal glucose response at lunchtime, with a rise of 2 mg / dL within an hour, resulting in hyperglycemia of 160-220 mg / dL. If the smart warning function indicates an abnormal response, for example, that the glucose trace has risen by 3 mg / dL within 30 minutes or has reached a range exceeding 160 mg / dL, the system may base the smart warning on the abnormal trace and render or display a smart warning on the screen to warn 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 on the fact that the glucose response is abnormal or anomalous, meaning that the glucose level is likely to have risen uniquely after this particular lunch. Thus, the smart warning function operates in a unique and very different way from previous systems.

[0092] The unique benefit of this implementation is not simply that it does not notify the user that their glucose is out of range or will soon be out of range, but rather that it notifies the user of additional information, namely that their glucose response is not typical for them. Specifically, based on the determined or acquired data, a unique and customized smart alert notification is displayed on the user interface rendered on the display or screen, showing types of data that have not been displayed before, and even calculated before. Such notifications allow the user to take additional precautions to manage and treat this more unique scenario, which would not have been possible using the technology of previous systems.

[0093] Referring to the flowchart 250 in Figure 5, the smart alert function 28, which can be executed in an appropriate subroutine or module and can operate in parallel with or provide functionality within a monitoring application, accepts various types of input data 30 and generates smart alerts 32 in response to the input data. In this process, the smart alert function or module may perform relative continuous evaluation. That is, generally, the application does not simply delay the provision of alerts by a predetermined time in order to render alerts more convenient for the user. Rather, the application continuously evaluates the data input 30 and, based on that data or other data, determines when to generate an alert, or whether to generate an alert at all. For example, if the system and method have learned that a particular user usually recovers from "postprandial hyperglycemia" 45 minutes after a meal, it will not generate an alert as long as the actually observed glucose trace indicating hyperglycemia matches the pattern or typical user response. If a physiological response deviates from a pattern or typical user response, for example, if the measured and calibrated glucose data trace from a glucose sensor differs substantially from a typical glucose data trace, e.g., by more than a given threshold, and thus makes the response abnormal, the system estimates or predicts that the user is not cognitively aware, and a smart alert is generated and a display is rendered on the screen or display. Personalized user information / data is typically used to determine whether (or when) to generate a smart alert, in particular, once this information / data has been transformed into data that is normally usable for estimating or predicting the user's cognitive awareness. Subsequently, the data for estimating and predicting cognitive awareness may be used to determine the timing of the alert, the method of providing the alert, the content of the alert, the format of the alert, etc. Generally, the generation of smart alerts, and / or the content or other features of the alert, are personalized or dynamically adapted or adjusted for the user.

[0094] Individual inputs are described below, and these inputs may include data received as measured by signals, calibrated data, and data from the user interface of monitoring devices (including dedicated devices and smartphones / watches), such as data on keystrokes, taps, frequency of interaction, and apps used. Note that the mechanism for estimating or predicting cognitive awareness, i.e., how smart alerts function, may typically involve comparison with a criterion (step 34). For example, the criterion may include known patterns and glucose traces, and in determining whether a physiological response is typical, a physiological response corresponding to a diabetic condition worthy of attention may be compared with a known pattern (criterion). For example, similarity in shape, upward slope / time, duration, time of day, day of the week, etc., may be evaluated.

[0095] input Analyte concentration Various metrics may be used to construct appropriate algorithms for operating such smart alerting functions, and such metrics, individually or in combination, may be used to derive estimates or predictions of cognitive awareness of noteworthy diabetic conditions. In some cases, such metrics are converted into estimated or predictive data, and in other cases, algorithms are used to derive estimated or predictive data. Such metrics may include rate of change, time to glucose level threshold (e.g., how quickly the first 20 mg / dL changes), residual insulin amount, etc. The primary drivers of smart alerting functions are real-time analyte concentration values, e.g., glucose values ​​measured by a glucose sensor, and the rate of glucose change derived from the glucose values ​​measured by the sensor. However, other physiological quantities may also be used. In some cases, data reception / data calibration / data display is performed by a single physical device, while in other cases, multiple devices may be used, in which case data may be transmitted from one device to another as needed and according to an appropriate data transmission protocol.

[0096] Other quantities that may be used in addition to quantities measured or derived from glucose sensor data are the glucose urgency index described in U.S. Patent Application Publication No. 2015 / 0289821, filed March 16, 2015, titled "GLYCEMIC URGENCY ASSESSMENT AND ALERTS INTERFACE," owned by the assignee of this application and incorporated herein by reference in its entirety.

[0097] User input or behavior User inputs or behaviors collected through data input into a system following this principle can also be used to estimate or predict cognitive awareness. For example, user behavior may indicate cognitive awareness if it coincides with self-treatment by a user with a noteworthy diabetic condition.

[0098] In one particular example, machine learning combined with system data on user interface usage could be used to learn that the user responds to the first warning but never to subsequent warnings. Therefore, in this embodiment, the first warning can be made more clearly recognizable because it is known that future warnings will be ignored.

[0099] User "clicks" or icon "activations," determined from user interface usage data, can be further used to determine cognitive awareness. For example, if glucose trace data indicates that a user has entered an alert worthy of a diabetic state, but the user immediately checks their monitoring application, e.g., begins calculating a bolus dose or rescue carbohydrate amount, such activity strongly suggests that the user is cognitively aware of their diabetic state, and thus tends to increase the likelihood of cognitive awareness in quantitative estimation or prediction. 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 estimation or prediction algorithms. For example, if a user has a diabetic condition that warrants attention due to hypoglycemia, but the user inputs current meal data, the user input data indicates that the user is cognitively aware of the hypoglycemic condition and therefore suppresses or prevents the smart alert from being generated. In some cases that were "closer to a critical 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, for example. Data input (by the user) for bolus dose calculation may further indicate the user's cognitive awareness, such as setting parameters in the user interface, for example, by manipulating or adjusting slider bars. The values ​​of the parameters themselves, such as low aggression, medium aggression, and high aggression, may be used as separate inputs to the smart alert function. Therefore, in these implementations, the relevant data includes (1) data inputs to health and diabetes management applications, along with (2) the values ​​of the data itself.

[0101] The input of meal data can trigger other changes in processing, which can further affect the generation or suppression of smart alerts. In some implementations, these aspects serve as an incentive for recording 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 "suppresses the sensitivity" of the hyperglycemia alert level to postprandial meal spikes. In other words, instead of relying on alerts based on cognitive awareness of a diabetic state worthy of attention, this aspect modifies the system definition of a diabetic state worthy of attention. In some implementations, the amount of the alert level increase may be set from 0 to 200 mg / dL, for example, with a default level of 100 mg / dL and an increase of 25 mg / dL. If the level increase is 0, such an application essentially turns off its function. The duration may be set from 30 minutes to 3 hours, for example, with a default duration of 2 hours and an increase of 30 minutes to 3 hours in 15-minute increments. The carbohydrate threshold level at which the sensitivity suppression subroutine initiates may vary, but this level could be, for example, two or three carbohydrate units. It should be understood that such a level typically depends on the insulin / carbohydrate ratio. Parameters such as residual insulin and residual carbohydrate levels, if known, may be considered in the sensitivity suppression subroutine. The advantages of such a sensitivity suppression subroutine are numerous, including the fact that only one configuration screen is added and initial setup is not 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, the setup is automatic and no additional data input is required. Systems or machine learning can further be advantageously used in the implementation of this functionality, and machine learning may be used to determine when the dietary data is actually consumed, for example, after carbohydrate consumption, before carbohydrate consumption, etc., in relation to when the user typically inputs the dietary data.Such records can be analyzed in conjunction with glucose data indicating potential hypoglycemic conditions and may be used to suppress the generation of smart alerts that might be unnecessarily issued for expected postprandial elevations.

[0102] Other relevant data may include user-entered data, which can be entered via or using multiple-choice radio buttons. For example, a user may be asked to directly comment on the usefulness of a given warning. A user may be prompted to acknowledge receipt of a warning by pressing a button selected from a convenient and easily understandable user interface. Buttons such as "Thank you" or "Disappear" may be provided. Such responses allow users to quickly acknowledge receipt of warnings and can be converted into data that is extremely useful for future calculations in the smart warning function. For example, if a warning was given 2 hours after a meal, but the user indicated that it was not useful, the next repetition may alert the user 2.5 hours after the meal (and other warning criteria are met). As another example, if a warning is explicitly indicated as not useful, the warning will not be repeated (i.e., defining the criteria for future smart warning determinations). If a warning is ignored, the warning may be determined to have been intentionally ignored, and the warning may not be repeated, if other data can be used to indicate that the user is aware of their diabetic condition. If it is unclear whether the ignoring was intentional, the warning may be repeated. The system and method can also determine the data based on machine learning, either from intentional ignoring or from the user activating the “ignore” button. For example, the system and method may warn the user multiple times at 180 mg / dL (and when it is rising) if there is no response or the “ignore” button is not activated. In such a situation, a monitoring app using the smart warning feature may ask the user whether they do not want this level of warning, for example, whether they do not want to be warned again in a similar situation. Such data may then lead to changes in how such smart warnings are delivered, i.e., to additional adjustments or personalization for 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) and other non-physiological and physiological data. Such algorithms can operate on smartphone-type devices and other devices, such as smartwatches.

[0103] For example, if a user is about to perform or participate in an event that could affect their glucose levels, other relevant user input data may include event data. For instance, if a user is about to perform exercise that they know will cause their glucose levels to fall outside their normal range, such as a long workout, they can activate a setting on the monitor (for example, by clicking a button on their smartphone to activate a special "training" warning schedule). Such a training warning schedule may provide the duration of the event and different warning values. Other such events that may have special warning schedules include meals and sleep.

[0104] Data regarding user feedback can be received through the user interface at various times while addressing a noteworthy diabetic condition, for example, during an event, considerably after an event, etc.

[0105] Prompts or other questions requesting user responses may be provided at various times to directly learn about the user's cognitive awareness or about "markers" indicating the user's cognitive awareness. More specifically, prompts or other requests, particularly regarding data input, may be provided to collect specific required data, i.e., dated data that is deemed particularly useful in determining user awareness. Such data may be specific to a user or a group of users, e.g., a cohort of users or a larger group. 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 deemed particularly useful. Such received or transmitted data is related not only to the existence of an interaction with the user, but also to the actual content and value of that interaction.

[0106] In addition to using directly entered user information, inferred user information can also be used in smart warning functions. For example, a lack of action by the user may be used. For instance, if a user has a blood alcohol level of 40 mg / dL and no action has been taken after one hour, the warning may be more extensive. This situation can be detected by a firmware or software routine with keystroke or tap data from the user interface as additional input, configured to measure the amount of time the user is in a dangerous or undesirable range. As another example, if a user begins to check their display device with a high degree of interaction, the system may learn that the user is in a mode that requires a significant amount of interaction and information at that time, and the warning may become more active, interactive, or proactive. Similarly, data from the user interface may be used to measure how much "significant" interaction with the user is relative to a "normal" or "typical" amount. For example, a normal or typical amount may be determined by user input data over time, for example, by the average number of times an application is opened or tapped per minute or hour. The number of taps 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, an increase in interaction between the device and the user can have a similar effect to the user moving a slider bar of a setting parameter to a more active state. Such automatic setting of parameters may depend to some extent on the extent to which the interaction with the user indicates the user's cognitive awareness. Interaction with the user may not be related to a diabetic condition of note, such as when the user is responding to emails or watching videos. Thus, user interaction can be distinguished in that only interactions related to analyte monitoring, such as CGM or bolus dose calculation, are taken into consideration. Unplanned and hasty interactions in such applications may indicate the user's cognitive awareness and desire for interaction. In some implementations, the measurement of unplanned and hasty interactions may take into account accelerometer data, for example, when the device is being handled hastily.In this case, a smart alert would be generated. On the other hand, an interaction in which the user is focused, such as the intentional and "typical" execution of bolus dosage calculation within a range considered "acceptable," "normal," or "typical," particularly at a frequency of keystrokes or taps that is normal for that user, would indicate the user's cognitive awareness and therefore would not cause the generation of a smart alert. A complete absence of accelerometer signal fluctuations may indicate that the user has fallen or lost consciousness. In this case, if the alert has not been received 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 divisible or measurable in real time from the user interface of a device on which a health-related application runs, especially when used in conjunction with real-time glucose data, can be used, for example, to determine when and / or whether to use the application to change the user interface in order to give an alert, and such user interactions are defined as not only the behaviors taken by the user on the user interface, but also the behaviors not taken by the user.

[0107] Previous or past user responses (either physiologically or through the user interface) may be used to develop, generate, or improve future smart alert features, for example, to eliminate or reduce user "back and forth" responses. More specifically, such previous or past user responses are typically incorporated into some form of data file, and the retrieval, e.g., transmission and analysis, of such stored data may be used to generate and improve smart alert features to determine which smart alerts in the past produced desirable physiological responses (and conversely, which types of smart alerts in the past produced undesirable physiological responses). Such analysis may include the analysis of glucose trace data (and accompanying event data, if applicable) to determine the characteristics of desirable and undesirable responses, followed by the analysis of current physiological data to determine the presence of a current diabetic state worthy of attention. If a smart alert is determined to be appropriate for generation, the smart alert feature may select the type of smart alert that produced a desirable physiological response in the past.

[0108] Pattern detection and use Patterns in glucose can be useful in helping patients understand and manage their own diabetes and in physicians how they manage their patients. Efforts have been made to identify patterns that require user attention or highlight areas that require attention.

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

[0110] As mentioned above, if a user exhibits a specific pattern of physiological responses, it can be inferred that if such a physiological response occurs again, the user will recognize the pattern and take appropriate action. Therefore, pattern data can be used to determine a user's awareness of a diabetic state. In other words, it can be inferred that a user will recognize previously experienced patterns, increasing the estimation or prediction of the user's cognitive awareness. Furthermore, as mentioned above, pattern recurrence can be determined by remembering and analyzing previous data, particularly data identified as patterns (but not necessarily patterns), and comparing this data with the currently measured (occurring) glucose trace to determine whether the currently occurring glucose trace has curves or signature characteristics similar to previously identified traces.

[0111] One method for determining such patterns, or for detecting the occurrence of glucose events that do not follow a pattern, is to "bin" certain events defined by specific characteristics. That is, a portion of the glucose trace that meets predetermined criteria indicating a particular diabetic issue, such as rebound hypoglycemia, may be detected, and then the pattern may be searched for among these appropriately "binned" events (or it may be determined that it is not among such binned patterns).

[0112] More specifically, and referring to flowchart 300 in Figure 6, a “signature” or “fingerprint” in glucose sensor data can be identified or distinguished within an individual patient based on several predetermined criteria (step 36). Such criteria may include time-based criteria and / or specific events detected within certain constraints. In this system, according to this principle, bins can be distinguished by different criteria. A monitored learning algorithm may be used to enable more bins to be learned for individual specific patterns. For example, bins may be based on insulin data, the rate of change (or acceleration / deceleration) of glucose data, previously identified data patterns used to characterize the data, e.g., events occurring before a small meal, the individual’s correspondence to the individual’s glucose information, etc.

[0113] The next step is to characterize events based on, for example, decay curves or waveform signatures (step 38). Exemplary events may include, for example, meal bolus administration indicators based on insulin data, which may be classified into small, medium, and large meal bins. Such events may correlate with insulin data. Different meal types may also be characterized, which may then be sub-binned into different meal compositions. These may correlate with the rate of change of acceleration / deceleration. Events may also be characterized based on the correlation between the event and pre-meal events, such events corresponding to the data patterns described above. Events may also be based on behavioral patterns, for example, how often the user reviews their glucose data or responds to alarms, such events may correlate with the response data described above. It will be understood that other bins may also be used. Thus, not only data about events but also user response data may be patterned, which may provide further useful data for algorithms to estimate or predict user cognitive awareness when such events and / or user responses occur again.

[0114] Next, the characterized events can be placed in bins (step 40). Then, the bins can be adjusted with respect to the physiological function of a particular patient by synchronizing each event. Next, the bins can be normalized, i.e., a normal distribution of events within the bins can be defined (step 42).

[0115] Next, the normalized bin information can be actively used as data input to the smart alert function, for example, in estimating or predicting user awareness (step 44). Using binning techniques, it may be determined, based on behavioral input, when a patient pays attention to their own data, which can then enable inference, estimation, or prediction of user cognitive awareness.

[0116] Another application of such binning techniques is to identify good or successful warning signatures, e.g., warning signatures representing diabetic conditions and types of warnings to which the patient responded well, from poor or failed warning signatures, i.e., warning signatures representing diabetic conditions and types of warnings that the patient ignored (step 45) (step 43). A smart warning can then be provided based on this information, i.e., the smart warning can determine when and how to issue a warning by comparing it with the good warning signatures (if the diabetic condition is in a predetermined vicinity of the good warning signature (in the glucose trace), this may trigger a smart warning). In this case, the use of the good warning signature does not rely on estimation or prediction of the user's cognitive awareness, although the signature may be used in combination with such estimation or prediction.

[0117] Patterns can also be identified by recognizing that a condition or event occurs repeatedly over the course of CGM wear. To find these recurring occurrences, the algorithm may synchronize CGM data stored in, for example, a buffer memory or data file for each epoch (day, week, or month) and calculate the mean or distribution of CGM values ​​as a function of time. Synchronization may be performed down to 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 necessarily eat or take insulin at the same time, and therefore patterns may not be obvious. Thus, in systems and methods following this principle, patterns corresponding to the timing of food intake or insulin administration can be identified. Such patterns can be identified using the techniques described above. For example, a sudden change in glucose within a given duration in the morning can 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 administration may be sent to a monitoring device such as a smartphone and used as an indicator of food intake. Other such indicators include, for example, data from GPS apps that determine likely glucose changes related to food intake that may occur at a regular restaurant, and changes in exercise determined by accelerometer data regarding the exercise-related effects on CGM. In this way, patterns can be (machine) learned about responses that are closest in "temporal proximity" to meals or nighttime, or responses that are closest in "geographical proximity," for example, how far the user is from home or the food source.

[0118] Once specific time periods of synchronization are selected, the data corresponding to the CGM traces in each of these epochs can be superimposed on each other to generate statistics. For example, the mean of the traces can be used to distinguish between random occurrences and true effects. Any true glucose effects attributable to recurring patient physiological functions are likely to be emphasized, while other random effects are likely to be removed or averaged.

[0119] Data corresponding to the distribution of CGM over time provide the most likely glucose values ​​after a synchronization event, as well as associated minimum and maximum values. Therefore, these can be used to create a typical glucose fluctuation in a given individual due to a synchronization event. For example, if glucose is synchronized based on food intake at lunchtime, the glucose change after lunchtime will capture a typical change for that individual. Any glucose change exceeding a predetermined threshold may have an expected underlying cause, such as an inappropriate or missed bolus dose or the effects of insulin accumulation.

[0120] Trends in glucose patterns (average, high, or low) may also indicate gradual changes in behavior that can be detected and warned about. 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 the ratio of carbohydrates to insulin, or insulin sensitivity. Adjustment of these parameters using machine learning algorithms may also be done using these patterns if different parameters are required for different times, weeks, or months. For example, if the system determines that such a trend is occurring without corresponding changes in user behavior, determined by dietary data, exercise data, or data entered on the user interface, the algorithm may use such data to estimate or predict whether the user is cognitively unaware of the change, and if it is estimated or predicted that the user is unaware, a smart alert may be generated and displayed. For example, if the estimate or prediction indicates a possibility of cognitive awareness higher than a threshold level (this generally applies to all estimates or predictions described herein).

[0121] These analyses can be performed in the background by algorithmic routines while the user is enjoying other functions of their smartphone, and such routines learn from the data over time, either in a monitored or unmonitored manner, using individual patient data. Thus, over time, pattern recognition can be performed, enabling and allowing smart alerts to become more effective.

[0122] As described above, implementing smart alerts requires going beyond simply shifting or delaying the alert to make it more convenient for the user. However, the measure of time 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 deciding when and how to provide smart alerts. For example, a computing environment may identify an alert condition, such as a diabetes condition that warrants attention, but may also decide when to provide a smart alert based on other input variables, including behavioral and contextual data, which are often variables that participate in the decision-making process for the smart alert function. Even if smart alerts are delayed by this criterion, the determination of the delay is still at least partially based on real-time data, as described above.

[0123] Behavior and context input Various types of behavioral and contextual information can also be used as input to smart alert functions to determine, predict, or estimate user cognitive awareness.

[0124] Contextual and behavioral information generally corresponds to how a patient uses their mobile device / monitoring app and therefore provides context to certain data determined by the device. Behavioral input information can be obtained through the system and includes interaction volume, glucose warning / alarm status, sensor data, number of screen taps, alarm analysis, events (e.g., characteristics related to user response, time to response, blood glucose control related to response, user feedback related to alarm, confirmation of receipt of warning or alarm, failure to confirm receipt of warning or alarm within X minutes, time to confirmation of receipt of warning / alarm, duration of warning state, etc.), diabetes management data (e.g., CGM data, insulin pump data, insulin sensitivity, patterns, activity data, calorie data), fatty acid data, heart rate during exercise, IgG anti-gliaridin, stress levels from skin patch sensors (sweating / perspiration), free amino acids, troponin, ketones, adiponectin, sweat, body temperature, user feedback, etc. Inputs can be provided by sensors that communicate data with the monitoring device. In some implementations, information can be obtained through intermediates such as remote data storage devices. The user data mentioned above, related to user interaction, is an example of behavioral data.

[0125] Contextual information may include, for example, the user's location determined by GPS, WiFi, or the locations of sharers and followers. Contextual information may relate to a person's behavior, location, perception of their surroundings (e.g., light, sound), and environmental data (e.g., weather, temperature, humidity, atmospheric pressure). These inputs may be received via peer-to-peer or network communication between machines. Contextual information may include daily routine information from a calendar application (which may vary between weekdays and weekends). Contextual information may include how often the monitoring device was touched or grasped, even without interaction, based on, for example, the device's sensed movement from an accelerometer and / or application within the device.

[0126] Photographs from a user's smartphone can be converted into contextual data using image recognition algorithms. For example, contextual information may be provided using one or more photographs of glucose meter readings, insulin pens or pump IOBs, locations (e.g., gym, park, home, Italian restaurant), or meals. Photographs may be processed using image recognition algorithms, for example, to identify the calorie intake of the meal shown in the photograph. The type of insulin used, which can be determined by a barcode imaged by the smartphone camera, may also be provided to the monitoring system as a useful input for estimating or predicting cognitive awareness. In fact, the reception of such insulin type data, in particular, combined with other data about the user's cognitive awareness, may 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, such as Bluetooth®. Transmission may occur periodically on a push or pull basis, or on another basis.

[0127] Behavioral / contextual data can indicate a user's awareness of their own diabetic condition, and therefore can be used to predict or estimate whether the user is cognitively aware. In one extreme example, contextual GPS data might indicate that the user is in a clinic, suggesting that the user is highly cognitively aware. In another extreme example, behavioral data might indicate sleep, as indicated by accelerometer data, and therefore highly cognitively unaware. Inactivity, warnings, and alerts during such times can be appropriately modified, e.g., automatically enabled or disabled. For example, if sleep is detected, the warning / alert system might enter a “night mode” or “sleep mode” that is more restrained with respect to glucose and more aggressive for minor alerts. The warning / alert system can then adjust the system's behavior, including warnings / alerts, and dynamically further adjust the target range to significantly improve user convenience. For example, in such a night mode, the target range could be adapted so that the alert for hypoglycemia is more aggressive, e.g., somewhat higher than in “daytime mode.” When these modes are triggered or initiated, the monitoring device may be programmed to operate in a different manner than before, improving the efficiency of the computing device.

[0128] Other inputs to the estimation or prediction of the cognitive awareness algorithm that constitutes contextual / behavioral data may include exercise information from a fitness bike, or glucose sensor information from a blood glucose sensor (BG) meter or CGM, or insulin delivery amount from an insulin delivery device, the result of calculation of residual insulin amount for said device, and certain data types that are referenced elsewhere, such as information provided or calculated by other devices. Other contextual / behavioral data inputs may include hydration level, heart rate, target heart rate, internal temperature, external temperature, external humidity, internal analytes, hydration input, power output (cycling), sweat rate, gait, and adrenaline level, stress, disease / illness, metabolic / calorie burning rate, lipolysis rate, current weight, BMI, desired weight, target (consumption) calories per day, target (expansion) calories per day, location, preferred foods, and physical activity level.

[0129] For example, the system might determine that high external temperatures, low stress levels, and high calorie intake coincide with the user being on vacation, which could indicate that some individuals may become less attentive to their diabetic condition. In this case, the system might determine that the user is likely unaware of a diabetic condition that warrants attention, and therefore decide that a smart alert should be generated.

[0130] In this regard, it should be noted that high external temperatures may trigger a smart warning from the user, ensuring that the user's diabetes supplies are kept in a refrigerated container and not exposed to high ambient temperatures.

[0131] For either of the referenced behaviors or contextual inputs described above, the system may be configured to receive and / or generate analytical metrics based on the input. For example, a composite value may be generated based on glucose levels, temperature, and time for a data generation index for the user. The composite value may then be taken into consideration in the estimation or prediction of cognitive awareness.

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

[0133] As mentioned, the alert can be affected by the proximity of the sharer and follower. For example, if the sharer is very close to the follower, 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, which can be annoying. 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®, and scan the sharer's mobile device (or dedicated receiver or pump). If the app detects the sharer's device within, for example, 30 feet (for Bluetooth® detection), the app can check the RSSI (Received Signal Strength Index) to determine how close (e.g., very close, close, far) the app is to the sharer's device. If the follower's device is detected as being near or very near the sharer, the follower's application may delay the warning by one or two minutes to give the sharer a chance to respond. Alternatively, the follower's app may suppress the warning. In either case, if the sharer responds within a given time frame, for example, one or two minutes, the warning may be suppressed on the follower's device.For example, U.S. Patent No. 8,844,007, granted on September 23, 2014, titled "SYSTEMS AND METHODS FOR PROCESSING AND TRANSMITTING SENSOR DATA," U.S. Patent Application Publication No. 2013 / 0078912, filed on September 21, 2012, titled "SYSTEMS AND METHODS FOR PROCESSING AND TRANSMITTING SENSOR DATA," U.S. Patent Application Publication No. 2014 / 0273821, filed on March 14, 2013, titled "SYSTEMS AND METHODS FOR PROCESSING AND TRANSMITTING SENSOR DATA," and U.S. Patent Application Publication No. 2015 / 0123810, filed on November 5, 2014, titled "SYSTEMS AND METHODS FOR A CONTINUOUS MONITORING OF ANALYTE The beacon technologies disclosed in “VALUES”, U.S. Patent Application No. 15 / 001,756, filed January 20, 2016, titled “CONTINUOUS GLUCOSE MONITOR COMMUNICATION WITH MULTIPLE DISPLAY DEVICES”, and U.S. Patent Application No. 62 / 271,880, filed December 28, 2015, titled “INTELLIGENT WIRELESS COMMUNICATION FOR CONTINUOUS ANLAYTE MONITORING”, may also be used for this purpose, all of which are owned by the assignee of this application and are incorporated herein by reference in their entirety.

[0134] In some cases, certain unexpected spikes in glucose, as determined by glucose trace analysis, may temporarily disable the sharing feature to avoid user embarrassment 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 on unexpected spikes is compared to this threshold level to determine whether the sharing feature should be used to share data about the spikes.

[0135] Heart rate data measured by a heart rate sensor may be used to estimate or predict 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 smart alerting capabilities via an appropriate transmission protocol. In another implementation, the sensor electronics or transmitter (see Figures 45 / 46 below) may include a strong light and optical sensor (not shown) for detecting heart rate. Such heart rate data may be used on its own to estimate or predict the user's cognitive awareness, or the data may be used to indirectly infer when the user is exercising, under stress, sleeping, etc. (the data may then be used for estimation or prediction). In such direct use, the user may have a diabetic condition that warrants attention. The accelerometer of the smart device may be used to determine that the device has just been operated and that the operation involved browsing the glucose monitoring app user interface. If the heart rate appears to have suddenly increased, it may be inferred that the user has a diabetic condition that warrants attention and that smart alerts do not need to be given.

[0136] Furthermore, context and behavior can also be determined by using available social networking information about the user, and social networking feeds related to the user are configured to provide a data source for the smart alert function. User recognition data can, in some cases, be determined by analyzing such data in social networking feeds, for example, a user's post "My blood sugar is low right now," or posts with similar content to those posted when the user's blood sugar was previously low. Techniques such as natural language processing can be used to determine the meaning of posts, thus enabling a quantifiable measurement of similarity to previous posts. Thus, posts can be used not only directly in relation to their content ("My blood sugar is low right now"), but also to infer that the user is in a similar state to when they previously posted a similar comment.

[0137] By using such systems and methods that adhere to this principle, problems faced by previous monitoring devices that did not take such contextual / behavioral aspects into consideration can be effectively addressed. In particular, if available data from sensors and other sources, including contextual / behavioral aspects, allows for estimation or prediction of whether the user is cognitively aware of a diabetic condition worth attention, the monitoring device can be greatly improved by using cognitive awareness as a means of suppressing warnings when warnings are not necessary, which provides a significant technological advantage over monitoring devices that base warnings solely on thresholds (or even predictions in addition to thresholds). Thus, the monitoring device provides a significant technological advantage over previous monitoring devices that did not consider such cognitive awareness at all. Further details regarding contextual and behavioral information can be found in U.S. Patent Application Publication No. 2015 / 0119655, filed October 28, 2014, titled "ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES," which is owned by the assignee of this application and is incorporated herein by reference in its entirety, specifically in Figure 4 and the accompanying text.

[0138] Behavior and contextual input may also be used to provide other useful warning functions. For example, if there are multiple CGM receivers in a home, it is important that the user can identify each one individually. To identify them individually, there is currently no visual aid other than different colors used to help distinguish different units from one another. Therefore, systems and methods following this principle may, as part of the setup procedure for a new receiver or a receiver used by a new user, require the user to select a uniquely identifiable mark, such as initials, screen background, color theme, 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 the corner of the screen or in the 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 or backgrounds. Animations may be displayed within various selectable areas of the screen. This allows a CGM receiver or CGM smartphone application to display the user's characteristics 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] Furthermore, as part of the setup procedure, thresholds may also be set, and the user may specify different types of warnings or alerts they wish to receive, for example, wanting to receive a warning after a meal instead of before a meal. The smart alert function or smart alert app may then be configured to query the user periodically or from time to time after setup to determine, for example, whether the user is satisfied with their setting choices or whether the user wants to change their choices, for example, whether they want to choose to receive a warning before a meal. The function or app may prompt the user to change the warning thresholds to better suit the user's lifestyle, or the user may be able to change them.

[0140] Other inputs Other data sources besides the glucose data, including user input, derived data such as rate of change and pattern data, as well as the behavior / context data source, may also be used.

[0141] For example, derived data relating to signal trends (other than patterns) may also be used in the smart warning function. For instance, smart warnings may be based on proximity and duration to or near a warningable zone, also known as "loitering." That is, in many cases, a user should be warned if they are near a danger zone for an extended period, even if they are not actually in the danger zone. The smart warning function can be used to provide a warning in this situation. In other words, a smart warning is generated when, in a loitering situation, the user is typically unaware of being close to a danger zone. In this case, the data indicating loitering is determined by an analysis of measurement data, duration data, and threshold location. If the user is close to the zone threshold, for example, within + / - 10% of a given duration, and other data described above or below indicates that the user is unaware of the loitering situation, the smart warning function generates a smart warning, where the smart warning indicates the presence of a loitering situation.

[0142] In another signaling scenario, when a dangerous or undesirable range is no longer a problem, a notification may be provided, thus potentially reducing user stress and informing the user that they are once again within the target area. This is similar to a home automation aspect of a dimmer switch. Specifically, when the 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 to begin turning the light off, and finally the light sends a command when the light is off. Similarly, in the case of a garage door, the garage is open, then the home automation system sends a command to close the garage, then the garage sends a command to begin closing the garage, and finally the garage sends a command when the garage is closed.

[0143] Regarding garages, this feature is important because it is crucial that the user is aware (through the home automation system) that the garage door is not closed if something interferes with the sensor and prevents the door from closing. In this case, such a notification may occur because the user did not receive the last command. In this example, if the patient is hypoglycemic or hyperglycemic and attempts to improve this situation by taking medical action, the sensor electronics may send a notification indicating that glucose is fluctuating and beginning to rise (or fall). The sensor electronics may then send a notification that the user is no longer hypoglycemic (or hyperglycemic). A more proactive approach may be taken to push a notification informing that the patient is no longer in an undesirable range, rather than waiting for periodic (e.g., every 5 minutes) measurements to determine whether the patient is outside the undesirable range. Thus, in this case, the smart alert may be based on whether the second notification was received. In particular, if the system strictly waits for a determination of a “removed from danger” state to occur, and 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 pays attention This is especially true when corrective measures are taken with the intention of treating a diabetic condition of concern. In the latter case, the user may wait to get out of the dangerous situation without further consideration. If this does not occur, smart alerts can become even more important. It will be understood that this function can be achieved in numerous ways. For example, a "danger removed" notification may take the form of a flag set after a bend point is detected. Where known, the location at the time of the corrective measure may also be used in calculating, determining, and subsequently setting the "danger removed" flag. If the user does not get out of the dangerous situation within a predetermined duration (which can be determined from user history and patterns) after the corrective measure, a smart alert may be generated again.

[0144] Other inputs may include the user's life goals. Specifically, diabetes management goals, such as reducing the risk of hypoglycemia, reducing out-of-range time, reducing warnings / alerts, postprandial optimization, and reducing rebound, can be used as inputs for predicting and estimating cognitive awareness. The user may set a goal, or even multiple different goals for different times, and the system may change or modify the settings so that the user can more easily achieve their desired goals. For example, one person may use a goal of reducing the risk of hypoglycemia at night, and the system may use predictive hypoglycemia warnings with a higher threshold setting. For these settings, for example, if the value is used at night, the user is presumed to be normally cognitively unaware because they are likely to be asleep. As another example, such a user may also have a postprandial optimization setting that provides a reminder to take a bolus dose about 30 minutes before their typical lunch time, or to include protein in their meals, if the user is presumed or predicted to be cognitively unaware.

[0145] Other inputs include data and signals from an insulin sensor or other data sources related to insulin. For example, insulin sensor data can be used to detect insulin delivery, which then provides a method for estimating cognitive awareness of a noteworthy diabetic condition based on an estimate of when insulin was injected. More specifically, if a noteworthy hyperglycemic diabetic condition has occurred, but the smart alert app has used data from the insulin sensor to detect the presence of some residual insulin, the smart alert function may suppress the alert until it is determined that the current insulin is no longer able to control hyperglycemia and the user is not cognitively aware that they need more insulin. Insulin sensor data can also be included for other uses. For example, in addition to residual insulin levels, information on the timing of bolus administration may be used to modify the smart alert behavior for both hypoglycemia and hyperglycemia. For example, if a user has recently administered a bolus of insulin, a threshold warning may be delayed or a predictive warning may temporarily suspend or raise its own target threshold based on the user's awareness of likely cognitive awareness and / or the reduction in the user's risk from the situation, e.g., the reduced risk of a “diabetic condition requiring attention.” In a specific example, if prediction is used at 200 mg / dL, knowledge of a bolus administration may set the warning at 250 mg / dL after one hour. Similarly, with respect to low glucose warnings, knowledge of insulin may increase or decrease the sensitivity of the warning if calculations suggest that the amount of insulin indicates a more conservative or aggressive glucose lowering.

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

[0147] As another example, if information or data regarding residual insulin levels is known or subsequently entered by the patient, or simultaneously, this information or data may be used in determining when to provide smart alerts. Such information regarding residual insulin levels may be entered by the patient or received from a drug delivery device, e.g., a pump or pen. In one implementation, the user may input how much insulin they have taken, and a calculation may then be performed regarding how much insulin will remain in the user's organ system over the next few hours. The value of the residual insulin level may then be used to notify the patient of when to alert them, e.g., to issue a warning or alarm. In one implementation, if the patient typically wishes to be alerted when their level exceeds 200 mg / dL, and the system detects that the user has exceeded that value, or predicts that the user will exceed that value, the system may determine or receive data regarding the residual insulin level. If the user has a large amount of insulin in their organ system, e.g., 5 units, the system may determine that the patient does not need an immediate alert because that insulin will treat a potential hyperglycemic state. Similar steps may be taken as an approach to the patient's hypoglycemia. For example, if a patient desires to be notified when their blood glucose level falls below 80 mg / dL, and the system detects that the user is above this value but still has a significant level of insulin in their organ system, the system may be prompted to warn the user earlier that they are heading towards hypoglycemia, i.e., using a smart alert function.

[0148] Other potential inputs include the type of diabetes and the specific manifestations of diabetes in a given user. Cognitive awareness in a type 1 patient may differ from that of a type 2 patient. Therefore, the generation of smart alerts may differ between these two, as may the timing of the alerts. In one implementation, the difference between these two situations is limited to a threshold level at which 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, with the result leading to the generation (or non-generation) of a smart alert.

[0149] Other different and individualized physiological effects and patterns may be observed. For example, a patient may typically 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, abnormal responses can be detected and, if detected, warned against by determining the glucose concentration value and including the rate of change of this glucose concentration value in the estimation or prediction.

[0150] Systems and methods following this principle, which incorporate cognitive awareness in determining whether or not to warn a user, are customized and / or two-fold, for each individual user, and the customization / adjustment occurs, for example, through machine learning using the data and sources described above. Other important sources of customization or individualization include changing the operation of smart alert functions based on the patient's physiological function, age, accurate diagnosis, etc. Therefore, the implementation of systems and methods following this principle provides significant benefits in reducing the burden on users or clinicians, for example, in setting alarm and warning thresholds that may not even be known because they fluctuate daily. In other words, in many cases, without the systems and methods and subsequent technological advancements in predicting or estimating cognitive awareness, there is no simple method for users to come up with to customize their warnings.

[0151] In other variations, the system and method may create multiple profiles for a single patient depending on activity, illness, pregnancy, menstruation, and other cycles.

[0152] Further data sources may include telemetry and metabolic rate. Other potential data and data sources may include correlation data (such as the user's perception of daytime versus nighttime), pain data, heart rate variability, stroke volume, cardiovascular health, insulin distribution capacity, body temperature (which affects insulin absorption rate), insulin type (based on insulin sensitivity measurements, profile, peak, and time between peaks), atmospheric pressure (which affects CGM and insulin absorption), insulin sensitivity, determination of which factor has the greatest impact on a given user, e.g., exercise versus diet, health or physiological conditions known to affect certain parameters, diseases, whether the smart device is in a specific 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 performing smart alert functions is in training mode, clinician-set parameters, response elicitation data, etc. Thus, user perception may relate not only to whether the user is aware of hyperglycemia or hypoglycemia, but also to whether the user is encountering a situation involving highly complex responses that the user may not simply perceptually recognize due to the inherent complexity of the situation.

[0153] For any given input, ambiguous logic may be used in determining the input value. In some cases, ambiguous processing and ambiguous output may also be used. More specifically, warnings, including smart warnings and alerts, or alerts, may be triggered in a manner that does not depend entirely on the glucose value exceeding a threshold. In one implementation, an algorithm may be used that triggers a warning when, for a given predetermined duration, the user's glucose value hovers slightly below the hyperglycemia warning threshold or slightly above the hypoglycemia warning threshold, even if the threshold has not been exceeded. 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 sequential glucose values ​​may be 178 mg / dL, 175 mg / dL, 177 mg / dL, and 178 mg / dL. The user's glucose value did not reach 180 mg / dL, but the algorithm recognizes that the glucose value is close to the threshold and provides the user with a smart warning after 20 minutes (or after any other duration that may be configurable by the user). Such an implementation is useful because it can prompt the user to take corrective action, such as administering a small bolus or exercising, when the user might not have paid attention to their glucose levels otherwise. In another implementation, an algorithm may be used to weaken the warning / alert if the user's glucose level fluctuates above the warning threshold but the rate of change is slow. For example, the user's hyperglycemia warning threshold may be set at 180 mg / dL, and the user's sequential glucose levels may be 170 mg / dL, 178 mg / dL, 182 mg / dL, 179 mg / dL, 181 mg / dL, 178 mg / dL, and 182 mg / dL. The alarm is triggered by the transition from 178 mg / dL to 182 mg / dL, but if the user acknowledges or rejects the alarm, the alarm is not triggered for the subsequent transition from 179 mg / dL to 181 mg / dL. Such an implementation can be particularly useful because it helps avoid annoying situations that users face when they are aware of their borderline glucose levels and do not want, desire, or need repeated warnings.In some implementations, this technique can be used more safely at the hyperglycemia warning threshold, and then at the hypoglycemia warning threshold.

[0154] Other variations may include variations in the frequency with which input data is received or output data is displayed. In particular, systems and methods following this principle may be configured to receive additional data when a dynamic risk is imminent, for example, by updating more frequently, e.g., every minute instead of every five minutes. For example, if an imminent hypoglycemia is predicted based on the current glucose level and the rate of glucose change, the display may be updated every minute instead of every five minutes. In such implementations, more advanced information may also be displayed, such as an indication of whether the trend of rising or falling glucose is accelerating. More advanced visual aids may also be used to indicate this reasoning, calculation, estimation, or prediction. In this way, the user is provided with better and more frequent information when the user needs it most. Also, for example, if a dangerous situation heals itself, the system may be able to further suppress warnings by using the most accurate information. In this way, the user is further prevented from becoming frustrated by unnecessary warnings.

[0155] As another example of input to estimating or predicting cognitive awareness, signal metadata may be used. For example, inflection points that, once determined, cause a concentration in inflection regions may be used. In a specific 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 user-useful parameters, such as parameters that have determinative power or are useful in determining whether the user is aware of a diabetic condition worth paying attention to. Their benefits are as described above. In this regard, it should be noted that sampling more frequently at such points can reduce sampling at different points, and reducing sampling at different points can be particularly useful in saving battery life, reducing power requirements, and extending the lifespan of sensors and monitors. Subsequent transmission of data for more frequent sampling and rendering may also be used in situations where the user is approaching or is experiencing hypoglycemia or hyperglycemia. In other words, zones, etc., may be used as the inflection points described above.

[0156] In some implementations, input may be received from wearable sensors. In one implementation, data available from a smartwatch may be used either alone or in conjunction with other data. In certain examples, sensors and signals collected by smartwatches such as Apple Watch and Microsoft Band may be used to enhance hypoglycemia detection. Such signals may include signals from heart rate sensors, sympathetic / parasympathetic balance (which may be inferred from heart rate), sweat / emotion / stress from conductance sensors, and motion data from accelerometers. Such signals may be used in addition to CGM signals. Algorithms used to process these auxiliary signals may be trained with the patient's own data, using CGM to aid in training. These algorithms may be optimized offline, for example, in the cloud. Detection criteria may then be sent to the patient's smartphone and / or smartwatch. While CGM may not always be able to detect hypoglycemia, when augmented with auxiliary signals indicating possible hypoglycemia, the patient may be alerted to suspected hypoglycemia, thereby enabling them to avoid its effects. Alternatively, after the algorithm used to process the auxiliary signal has been trained, the smartwatch signal may be able to detect hypoglycemia without using a continuous glucose monitor (CGM). In this use case, adjustment of the algorithm may be necessary to optimize its sensitivity or specificity.

[0157] In other implementations, smartwatch sensors and machine learning can be used to detect and quantify sleep. For example, if motion data from an accelerometer determines that a user is asleep, it can be inferred that the user is not cognitively aware of a diabetic condition worth paying attention to, or even any diabetic condition at all. Therefore, the alarm changes can be configured so that no smart warnings are suppressed if the system estimates or predicts that the user is asleep. Other sleep sensors can also be used in estimating or predicting 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 observe the time spent sleeping relative to the time spent awake. In its implementation, a temperature sensor attached to the skin, which may be a separate temperature sensor or a sensor implemented in an adhesive patch attached to the patient, can effectively utilize the strong correlation between temperature data and the time spent sleeping.

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

[0160] output The output of a smart warning function is generally the displayed output, but the algorithm itself may have an "output" in the sense of user recognition calculation, estimation, or prediction, and therefore suppressing a warning (for example, when it is estimated or predicted that the user is cognitively aware of a diabetic condition worth paying attention to) or simply preventing the warning generation step from occurring can also be considered an "output" in this sense.

[0161] The output of the smart alert function can take several forms, such as visual displays, audible displays, and tactile displays. 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 diabetes status, while audible or tactile displays 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 diabetes status (e.g., values ​​and trace graphs), while another visual display, for example, superimposed on the first one, 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 whether the user is aware of an imminent, attention-worthy diabetes status, or it may be more subtle or implicit, requesting less information but providing the data necessary for estimating or predicting cognitive awareness. Such implicit or subtle prompts or questions may be more appropriate for younger or less experienced users, or more sophisticated users, or users with less experience of the biological symptoms of diabetic conditions. Therefore, systems and methods following this principle may use user profile information in determining or calculating what kinds 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 strongly tied to a calculated estimation or prediction of the user's cognitive awareness. If the user is estimated or predicted to be cognitively aware of a diabetic condition worth paying attention to, the user interface typically does not display smart alerts. Conversely, if the user is estimated or predicted to be cognitively unaware, smart alerts are typically displayed, usually accompanied by a change in the user interface. Such outputs are generally considered far more effective and efficient for the user, and therefore, for the reasons given above, for example, smart alerts result in fewer re-warnings and lower alert fatigue, etc., and are therefore changed based solely on thresholds. This allows for further significant savings in battery power and computing cycles.

[0163] In a given rendered output, smart warnings may be further displayed along with an expression of reliability or uncertainty. The level of reliability or uncertainty may be calculated by systems and methods following these principles, based on error bars calculated with respect to the data, known or determined calibration ranges or errors, known or determined sensor errors, etc. Reliability or uncertainty may be expressed to foster trust between the user and the system. This trust is increased when the system has performed additional machine learning steps and obtained enough data to make accurate and highly personalized suggestions and recommendations to the user. In such cases, systems and methods following these principles may reduce the display of the expression of uncertainty in the smart warning output, as the display of such expression is no longer applicable. As a specific example, hypoglycemia warnings occurring during possible artifacts (e.g., “decline and recovery” failures) may be expressed in terms of uncertainty. Insulin dose recommendations may be made to explain the uncertainty in glucose estimation. Such recommendations may occur, for example, on day 1 of a CGM session. Since users understand that the system "guesses" or predicts rather than makes clear recommendations, this recommendation expresses this uncertainty to the user in a way that then builds trust in the monitoring app and smart alerting features. In this way, smart alerts engage the user and cultivate trust in the system. Later, after the fault no longer exists, the monitoring app and smart alerting features can express data with some degree of uncertainty or reduced uncertainty, increasing the reliability of the monitoring app not only in its accuracy but also in its error detection and handling.

[0164] Smart alerts may be generated and displayed, configured on the user interface to be minimally intrusive to the user, for example, by highlighting trend information achieved by rendering various arrows or zones on the display or screen, while the rendering of the glucose value itself is less emphasized. This may be achieved by a control setting adjusted by a physician or the user, which adjusts the rendering of the display to focus on the trend or trend arrow while the glucose number is less visible.

[0165] The assertiveness of the smart alert function can be adjusted by a user-configurable setting, such as a slider bar. The slider bar can affect both inputs and outputs; that is, it can be used to influence the operation of the smart alert function on both the input and output sides. Users who desire a higher assertiveness setting will typically receive more smart alerts than users who desire a lower assertiveness level. In other words, if the user interface setting is set to a high assertiveness level, the system can automatically control the cognitive awareness threshold level (on which smart alerts are based) to be higher. Since a higher cognitive awareness threshold level is more difficult to achieve, a higher threshold level generates more smart alerts. Thus, the system becomes more assertive. Conversely, if the user controls the user interface setting to a lower assertiveness level, the cognitive awareness threshold level decreases, potentially resulting in fewer smart alerts.

[0166] Dynamic risk can influence how quickly input data is accumulated. Dynamic risk can also influence how often data is updated, providing a more granular and accurate method for users to receive notifications of their risk assessment. This risk can be measured by a suitable calculation based on glucose values ​​and rate of change, and may include more advanced calculations, such as the blood glucose emergency index described in the patent application incorporated by reference above. That is, based on a dynamic risk calculation that may include glucose values, glucose rate of change, and other complex derived values ​​(usually involving one or more of these real-time values), the system may 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] Smart alerts are generated and rendered on the display, more specifically on a user interface rendered on the display, and smart alerts can take several forms, including having varying levels of prediction. For example, referring to Figure 7, a smart alert may indicate a diabetic condition that warrants attention and may further provide details such as the current glucose value, expected glucose value within a particular time frame, for example, within 20 minutes. The smart alert shown in Figure 7 may be overlaid on a trace graph, which is shown in Figure 8. As can be seen, the smart alert in Figure 7 provides a detailed warning to a user who is unaware of their diabetic condition that warrants attention, in this case an impending hypoglycemia (indicated by the local minimum in Figure 8).

[0168] Figures 9-29 illustrate exemplary user interfaces and smart warnings built on consideration of interface usability and other factors. For example, the use of displayed arrows is sometimes helpful to the user, but the meaning of the arrows is sometimes unclear. For example, arrows tend to convey urgency or the need to take action, but users may be confused as to whether the arrows point to a prediction or trend. Therefore, in one implementation, it was found useful to display the following on the user interface: the current glucose level, threshold warning level (e.g., the most relevant threshold warning or alert level considering the current glucose level, e.g., "55"), a symbol, and a color (e.g., yellow or red in the case of a diabetic condition that warrants attention but the user is not consciously aware of, with the specific color depending on the urgency of the condition).

[0169] The symbols may be as shown in Figures 9-14, for example, a dotted line starting with a thick dot and ending at a threshold (Figure 9), a dotted line with a direction arrow (Figure 10), a dotted line indicating direction when read from left to right (Figure 11), or a line segment with a direction arrowhead (Figure 12). In some cases, for example, sophisticated users may only need an alarm, which is shown in Figure 13. An alarm with a trend arrow and color indicator is shown as an alternative user interface in Figure 14. All of these elements, and combinations thereof, are useful in providing context for smart alerts. Symbols can be particularly useful when used with children because they are immediately recognizable and easy to interact with parents.

[0170] As can be seen in Figures 9-14, smart alerts are typically provided as an overlay on another user interface, usually associated with the CGM monitoring application. Therefore, the overlay often lies on a trend graph, which may or may not include predictive elements, sometimes indicated by arrows or dotted lines. Generally, the appearance of two different arrows on the screen can confuse the user; therefore, if a trend arrow appears in a smart alert, the trend arrow should either not appear at all or should be suppressed from the underlying glucose trace chart.

[0171] It has also been found beneficial to indicate the endpoint of the trend, which is shown in Figures 15-17. This endpoint can be expressed as time (quantitative, such as "within 20 minutes," or qualitative, such as "immediately"), value, or both. In Figures 15-17, the time portion of the endpoint is indicated by a segment on a clock showing 20 minutes, and qualitatively or quantitatively within the text alert itself. The value portion of the endpoint is, in this case, indicated by the hypoglycemia warning threshold, e.g., 55 mg / dL. The current value is also shown in Figures 15-17, along with the trend arrow and color indicator. The color indicator is usually 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 overlaid on the chart (Figure 18), and similarly, Figures 20 and 21 show a glucose trace chart (Figure 21) and a smart alert overlaid on the chart (Figure 20). These figures show a smart alert that has been found to be beneficial, which includes the text alert "Urgent hypoglycemia imminent," the current glucose value, i.e., 93 mg / dL, a trend arrow, the relevant threshold, i.e., a display of 55, and a time display indicated by a clock segment. Figures 20 and 21 further include the display of the time end point within the text portion of the smart alert.

[0173] In many cases, it has been found that displaying quantitative, time-based alerts is more beneficial than qualitative alerts, as illustrated by Figures 22–29. Figures 22–29 illustrate a time sequence of smart alerts showing the progression over a 15-minute period. Figures 23, 25, 27, and 29 show the underlying glucose trace graphs, and their respective smart alerts are shown by Figures 22, 24, 26, and 28. The first time point is shown by Figures 22 and 23, and the time point 5 minutes later is shown by Figures 24 / 25. The time point 10 minutes later is shown by Figures 26 / 27, and the time point from the very beginning at 15 minutes is shown by Figures 28 / 29.

[0174] As described above, the use of red has been found to be beneficial in providing smart warnings. However, the use of red may be modified based on the urgency of the smart warning. For less urgent smart warnings, for example, a brighter shade of red may be used.

[0175] In alternative implementations, smart alerts may be provided on the smartphone's lock screen. Figures 30–41 illustrate such implementations, all of which are generally within the context of low glucose alerts. As can be seen, when a user sees a notification on their smartphone (Figures 30, 34, and 38), they may unlock their phone and see a “popover” notification of the alert (Figures 31, 35, and 39). An “OK” button may be shown, and upon activation, a trend 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 reinforces the importance of the alert. The user can close the banner alert by tapping the X button and continue using the application. Alternatively, the banner disappears once the user corrects their glucose levels to raise them to a healthy level. In alternative implementations, the alert banner may be repositioned below the navigation pane, allowing the user to use navigation functions even when the alert is displayed. This can be configured based on the urgency of the warning.

[0176] In the displayed user interface implementation, or in any other implementation, tapping an appropriate icon displayed on the screen, such as a magnifying glass, may trigger the display of additional information or invoke other functions. For example, tapping an appropriate icon may display various levels of forecasts, such as forecasts for the next 10 or 15 minutes. Such forecasts may be provided by text indicators, dotted lines on a glucose trace graph, arrows, and endpoints indicating time and glucose.

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

[0178] A default volume setting that is sufficiently higher than the estimated ambient noise level may be provided. If the measured noise level is higher than the noise level estimated by the default, or the noise level detected or estimated during customization, the volume of the warning / alarm may be automatically increased gradually or abruptly to a level in which 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 with the ambient noise level, for example, to achieve the predetermined signal-to-noise ratio described above. In such an implementation, the noise level can be advantageously measured immediately before the warning / alarm is issued.

[0179] In other implementations of the output, when a user experiences an unpleasant event, such as hypoglycemia, hyperglycemia, or uncontrolled glucose, systems and methods following this principle may automatically generate a post-event smart alert that provides some degree of forensic analysis, informs the user about how the event occurred, and offers advice to help prevent such events in the future. Such automatic generation of forensic information may be provided particularly when the system can individually identify the cause of the unpleasant event thanks to the determination or detection of signal characteristics or other diagnostic information. By providing such forensic analysis, the user gains a better understanding that the smart alert function is configured to track, detect, and warn about such unpleasant events, thereby increasing the user's trust and confidence in the system. In addition, data on 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 be further configured to display notes or other modifiers related to smart alerts. For example, the system may provide a message such as, "[A known 'working' therapeutic aspect, e.g., insulin or food or exercise] is waiting for it to take effect, so we are waiting an hour before issuing an alert. However, please note that you may be warned or alerted in the near future regarding this condition." Such a message 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 equally, where the level of estimate or prediction is not sufficient to establish without doubt whether the user is cognitively aware or not. In certain implementation forms, 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 understood that the content of the string changes will vary depending on the type and content of the smart alert.

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

[0182] In further implementations, it should be noted that CGM and low glucose warning thresholds can help users identify imminent hypoglycemia, enabling them to take measures to avoid or minimize the onset of hypoglycemic symptoms. Such features are particularly useful when patients have difficulty identifying low glucose based on physiological symptoms such as shivering and sweating, which apply to users with reduced hypoglycemia awareness. Hypoglycemia awareness can vary depending on the onset of symptoms and has been shown to be influenced by recent hypoglycemic events. In particular, recent hypoglycemic events reduce the user's awareness of subsequent symptom onset.

[0183] Therefore, in further implementations of systems and methods following this principle, the characteristics of the warning may be modified as a function of the recent history of hypoglycemic symptom occurrences, so that in situations where the patient is unlikely to notice their hypoglycemia as a result of their symptoms, the warning is likely to be provided earlier or more prominently. Typical warning characteristics to be modified include, for example, threshold, intensity, and visual display. Such implementations minimize the number and / or discomfort of nuisance warnings (warnings provided when the patient is already aware of hypoglycemia or more frequently than desired) when the warning is less helpful, and maximize the sensitivity and / or prominence of the warning when the patient cannot rely so much on their symptoms. In other words, the user's cognitive awareness may be further based on the recent history of hypoglycemic symptom occurrences, since it has been shown that the occurrence of hypoglycemic symptoms dulls the user's awareness of subsequent symptom occurrences. In the implementation, a recent history of hypoglycemia symptom occurrences may be collected from past or historical data to provide useful data output for estimating or predicting user cognitive awareness, and may be used in combination with real-time data, such as glucose data, rate of glucose change, and in particular real-time data indicating potential hypoglycemia. The useful data output for estimating or predicting user cognitive awareness may be used, for example, to raise or lower the threshold at which the user is estimated or predicted to become cognitively aware. If a recent history of hypoglycemia symptom occurrences exists, the threshold may be raised, thus resulting in additional smart alerts. Conversely, if user data indicates, for example, that the frequency of hypoglycemia symptom occurrences has decreased due to better diabetes management by the user, the threshold may be raised, and the number of smart alerts may be reduced.

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

[0185] Use with pumps and other delivery devices Smart alerts may be usefully used in combination with data from injection pumps and other such delivery devices. To some extent, the use of smart alerts depends on the use of the delivery device, whether it is 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 worth paying attention to, smart alerts may be used as described above, for example, to provide alerts regarding bolus administration information. For example, in the case of a meal bolus, machine learning may be used to determine the user's meal patterns, and if a glucose trace is encountered after a meal that is not part of a typical meal pattern, smart alerts may be generated based on such data to suggest a bolus administration. In addition to determining when a bolus should be administered, machine learning and smart alerts may preferably be further used to determine a timing that is neither too late nor too early. Such learning typically involves analyzing historical data to learn at what point during a “meal event” the bolus should be delivered. In this case, the historical meal event data is used in combination with real-time data indicating, for example, whether the user is about to eat or is approaching a typical meal time (which can be determined by clock data or event data, etc.). Similarly, machine learning may be used to determine that the user often administers an over-bolus, for example, or a so-called “rebound” or “frenzy” bolus. This may particularly relate to smart alert apps or features receiving data from a pump or pen. If the system can determine that a user has a tendency or pattern toward such over-bolus administration, this tendency or pattern information may be used to provide smart alerts to remind the user not to over-bolus. More generally, this information may be used to give a general warning to a smart alert feature. Such use may be particularly important because users are especially susceptible to the effects of over-bolus administration when they are, for example, prone to hyperglycemia.

[0187] Another example of the use of smart alerts in the context of delivery devices is when a user changes infusion sets, there is a higher-than-usual risk of taking an infusion site or cannula that does not have proper insulin absorption or is blocked. While blockage alarms exist, these alarms are usually not useful in detecting problems related to the infusion site, especially if the cannula is not completely blocked. Standard care instructs users to check their blood glucose levels two hours after changing their infusion sets to ensure they are receiving proper insulin delivery. Undetected cannula problems can lead to hyperglycemia and even life-threatening ketoacidosis, constituting a major risk for multiple daily injections when using pump therapy.

[0188] Systems and methods following this principle can detect problems with infusion sets at an early stage before a patient develops ketones, and, using smart alerts, can provide warnings about such attention-grabbing diabetic conditions to users who are not fully aware of the presence of such problems in such situations. For example, knowing when a patient changed their infusion set can be used to determine the probability of a faulty infusion site, and such data can be further used to distinguish between other increases in blood glucose and problems with the infusion set. In particular, the system can use data on cannula filling, reservoir changes, and pump induction to determine when 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 estimating or predicting the user's cognitive awareness, and fluid pressure data is useful for learning personalized alerts for possible infusion set problems and can be used similarly. While CGM data and pump data used separately are usually insufficient for detecting infusion set problems, when these data are combined, they provide more specific alerts that can prevent dangerous events, especially hyperglycemia events. Specifically, this can be used to determine and warn about problems with the infusion set, and to alert the user to address the problem before medical problems, including ketoacidosis, occur.

[0189] Specifically, referring to system 350 in Figure 42, the system in Figure 1 is illustrated to also receive data from pump 52 (or 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 those related to problems that prevent the pump from functioning properly, the CGM app can detect problems with the cannula / infusion set and provide smart alerts accordingly. Such problems are particularly difficult and notoriously difficult for users to detect and therefore deserve attention in predicting or estimating the user's cognitive awareness of diabetic conditions. Thus, and referring to flowchart 400 in Figure 43 (based on flowchart 101 in Figure 2), a method for providing smart alerts may include a step of receiving pump data (step 54), which can be used to calculate an estimate or prediction of the user's cognitive awareness.

[0190] The pump data received in step 54 may include data relating to bolus administration information, pump stop data, pump alarms, pump rewind (time), pump injection (time), cannula filling (timing and volume), fluid pressure, or other data used to generate occlusion warnings. In one implementation, an API that enables access to such data may be used by the monitoring application. Conversely, the smart warning function may also be provided in the context of an application that operates and controls the delivery device, in which case data from the CGM application or other monitoring application may be used by the smart warning function running on the delivery device via an appropriate API.

[0191] Therefore, if the user is not consciously aware of pump problems such as blockage, smart alerts are provided to inform the user of a diabetic condition that warrants attention, thus providing a more effective warning to the user than conventional alerts.

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

[0193] When implemented in an open-loop system, the smart warning function may provide smart warnings that prompt the user to take various actions based on the user's cognitive awareness. In a closed-loop or semi-closed-loop system, both user cognitive awareness and machine cognitive awareness may be considered, where the latter relates to whether the machine is aware of a diabetic condition worth paying attention to. This implementation is illustrated by flowchart 450 in Figure 44. Similarly, in flowchart 450 based on flowchart 101 in Figure 2, a step (step 21) may be used to determine whether the system is cognitively aware of a diabetic condition worth paying attention to, after the step (step 17) of determining user cognitive awareness. If the machine is cognitively aware of the condition, again, there is no need for a smart warning, and the smart warning may be suppressed or not generated (step 11). If the machine is not cognitively aware of the condition, a smart warning may be provided (step 19). While the estimation or prediction of the user's cognitive awareness is itself a task performed by the machine, it should be noted that this differs from the machine's cognitive awareness in step 19, which is because the latter concerns whether the delivery device is connected and is treating or preparing to treat a diabetic condition. For example, if the system determines, for instance, based on glucose levels and rate of change, that the user may be experiencing hypoglycemia, the machine's cognitive awareness may stop the pump. This is distinct from the determination in step 17, which involves the user becoming aware of the imminent potential for hypoglycemia and taking the step of treating the hypoglycemia, for example, which is part of a typical pattern in which the user treats it by consuming carbohydrates.

[0194] As additional steps are provided before smart alerts are generated, smart alerts are generated in closed-loop systems less frequently than in open-loop or semi-closed-loop systems, and only when the system itself is normally unable to treat a diabetic condition worth paying attention to.

[0195] A specific implementation is described in the context of a user approaching a hypoglycemic situation. Instead of simply using a threshold, the insulin pump may automatically stop when the low glucose threshold is exceeded. If the estimation or prediction of the user's cognitive awareness, made by the smart alert function, results in an estimation or prediction that the user is cognitively aware of a diabetic condition worth paying attention to, the pump may stop earlier than if the user were unaware, in order to avoid a dangerous hypoglycemic situation. A typical situation in which the user is unaware is at night when the user is asleep.

[0196] This document describes a system and method for providing users with smart alerts that can warn them of a diabetic condition requiring attention using a more effective method than conventional methods.

[0197] Variations will be understood. For example, the system and method may be used to interact with other applications and provide warnings. For example, if the system estimates or predicts that the user is not cognitively aware of a diabetic condition worthy of attention, such as an imminent hypoglycemia, but data from the GPS app on the user's smart device indicates that the user is near a food source, such as a gas station or grocery store, a warning about the imminent condition and a place where corrective action can be taken may appear on the GPS app. Generally, the data from the GPS app is data that provides information about the location of food sources, but data from other apps, such as a meal tracking app that can similarly provide information about the location of restaurants, may also be utilized. Such warnings generally use appropriate APIs between the GPS app and the CGM app, and APIs between other apps used. In some cases, data from the GPS app indicates that the user is moving in the direction of a commonly accessed food source, such as a restaurant the user frequently visits. In particular, the determination may be clearly made, for example, that there are no other places the user frequently visits in that direction, and then, in the event of a potential mild hypoglycemia, such GPS data may be used to suppress the generation of a smart warning, at least temporarily. Generally speaking, the GPS data used in this method can be advantageously utilized in estimating or predicting user cognitive awareness.

[0198] Implementation of systems and methods following this principle to enable smart warnings / functions. Smart warning functions following this principle may be implemented using various systems. For example, in one implementation, a mobile computer device dedicated to health and diabetes management, such as a smart device, such as a smartphone, may be used. The mobile computer device may be a device dedicated to health / diabetes management, or a more general device specifically adapted for health and diabetes management. The device may be configurable by the user to suit their lifestyle and preferences. The mobile device may be based on an Android or iOS (or other) operating system and may utilize a touchscreen interface. In some cases, the operating system may be customized or controlled with respect to management services, for example, providing data to the cloud and optimizing / controlling 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 (or "connected to") a wearable computing device such as a smartwatch. The watch may function usefully even without being directly connected to (or connected to) a mobile device. Such a watch or other such wearable may include sensors such as a heart rate monitor, and data from such monitors may also be used to inform the smart alert function. For example, such monitors may be used (perhaps in combination with accelerometer data) to determine whether the user is exercising, and if so, whether the user would like more or fewer warnings / alerts.

[0200] Such wearable devices may also allow for the possibility of configuring smart alerting functions to render a visual display, providing greater privacy and discretion in social settings and usefulness, for example, in sleep. The smart alerting function may be configured to first alert the wearable if a wearable with a haptic display is detected, and then alert other devices, such as a smartphone, if the wearable's warning or alert is ignored.

[0201] Users may choose from a curated ecosystem of apps. This selection may include, for example, apps from Databases (meal memory), TrainingPeaks (activity / fitness), Tidepool, MyFitnessPal, Nike+, and Withings. Other apps may include retrospective insight / pattern recognition apps aimed at optimizing therapy and determining whether the user is cognitively aware of their current attention-worthy diabetic condition. The ecosystem may further include apps that provide basic diabetes management instructions for newly diagnosed type I diabetes users (or their parents). Different sets of instructions may be included for newly diagnosed type I diabetes users.

[0202] Mobile computers enable data connectivity between users (patients) and clinicians via EMR (e.g., Epic). Mobile computer platforms facilitate and enable user / provider dialogue.

[0203] In other specific implementations, the mobile computer may be configured not to include features unrelated to health management.

[0204] Safety settings are generally implemented. For example, the smart alert feature may be disabled 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, or one month's worth of data may be required. As mentioned above, the initial setup or training may be done without data, or using data from a conventional user's device (related to the target user). Subsequent optimizations may be performed after this, specifically, the smart alert feature may execute a data analysis subroutine or diagnostic subroutine to determine whether the functions related to smart alerts have collected enough data to enable, for example, prediction or estimation of the user's cognitive awareness, or may warn the user or HCP to do so. Alternatively, the smart alert feature may be performed automatically but may require confirmation from the user or HCP.

[0205] As mentioned earlier, users are often frustrated by receiving multiple warning or alert notifications, but smart alerting features that adhere to this principle can help minimize the source of such frustration. However, if multiple notifications are requested and provided, smart alerting features may also be configured to allow subsequent notifications to include additional information so that the user receives the entire set of actual or potential warnings. For example, if the first notification indicates that the user is heading towards hypoglycemia, the system may understand that it will not warn the user again via smart alerting features or will suppress the warning / alert until another warning threshold is reached, and then subsequent notifications may include a different essential message, such as "Your blood sugar has been low for the last 20 minutes."

[0206] Systems and methods following this principle can be further used to detect missed opportunities or actions. Specifically, machine learning can be used to learn when users typically take action, especially actions that lead to favorable results. If a similar situation arises but the user does not act in the right direction, for example, if the user is away from a smart device and is unaware of the opportunity, a smart alert may then be provided regarding the missed opportunity.

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

[0208] Sensor system Figure 45 shows an exemplary system 100 according to several exemplary implementations. System 100 includes a continuous analyte sensor system 8, which includes a sensor electronic device 12 and a continuous analyte sensor 10. System 100 may also 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 electronic device 12, integrated with the continuous analyte sensor 10 (e.g., mounted in a non-removable manner), or removable. The sensor electronic device 12, the drug delivery pump 2, and / or the 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, System 100 may include a cloud-based analyte processor 490 configured to analyze analyte data (and / or other patient-related data) provided via a network 406 (e.g., via wired, wireless, or a combination thereof) from other devices such as sensor systems 8 and display devices 14-20 associated with a host (also referred to as user or patient), and to generate a report providing high-level information such as statistical data on the analyte measured over a specific time frame. A full consideration of using a cloud-based analyte processing system can be found in U.S. Patent Application No. 13 / 788,375, titled “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 a factory calibration algorithm may be performed in the cloud.

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

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

[0212] The sensor electronic device 12 may be connected (for example, wirelessly) to one or more devices such as display devices 14, 16, 18, and / or 20, as described. The display devices 14, 16, 18, and / or 20 may be configured to display (and / or issue alarms) information such as sensor information transmitted by the sensor electronic device 12 for display on the 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., a smartphone, tablet, etc.), a computer 20, and / or any other user device, all configured to display at least information (e.g., smart alerts, drug delivery information, separate self-monitoring glucose readings, heart rate monitors, calorie intake monitors, etc.). In some cases, the display device may be, for example, the user's car, if the car communicates with the user's smartphone via signals. For example, the car may communicate with the smartphone via Bluetooth or be paired via Bluetooth. Other display devices may include a television, a smart refrigerator, and the like.

[0214] In one implementation, the factory calibration algorithm can be performed, at least partially, by the display device.

[0215] In some exemplary implementations, the relatively small key fob-type display device 14 may include a wristwatch, belt, necklace, pendant, jewelry, adhesive patch, pager, key fob, plastic card (e.g., credit card), identification (ID) card, and / or similar. This 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 warnings, such as numbers, arrows, or color codes.

[0216] In some exemplary implementations, the relatively large handheld display device 16 may include a handheld receiver device, a palmtop computer, and / or similar. 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 alarms, such as a graph display 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 device, subcutaneous device, transcutaneous device, and / or intravascular device. In some exemplary implementations, the continuous analyte sensor 10 may analyze multiple intermittent blood samples, but 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 enzyme, chemical, physical, electrochemical, spectrophotometric, polarization, calorimetry, iontophoresis, radiation, or immunochemistry. In implementations where the continuous analyte sensor 10 includes a glucose sensor, the glucose sensor may include any device capable of measuring glucose concentration and may provide data such as a data stream indicating glucose concentration within the host using a variety of techniques for measuring glucose, including invasive, minimally invasive, or non-invasive detection techniques (e.g., fluorescence monitoring). The data stream may be sensor data (raw and / or filtered), which may be converted into a calibrated data stream used to provide glucose values ​​to the host, such as a user, patient, or caregiver (e.g., a parent, relative, guardian, teacher, doctor, nurse, or any other individual concerned with the host's health). Furthermore, 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 or outside host blood vessels, subcutaneous sensors, replaceable subcutaneous sensors, intravascular sensors.

[0219] In some exemplary implementations, when a user's diabetes supplies are running low, smart alerts may be provided to warn 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 that the sensor has two days' worth of life left. In this case, the system may provide smart alert information to let the user know that it is time to order new supplies.

[0220] Where user acknowledgment is used, the acknowledgment may be performed on a receiver, mobile device, or other such device. In some cases, warnings or alarms may be acknowledged directly at the transmitter. In some cases, fingerprint recognition may be used in acknowledgment to prevent a person other than the user from performing a harmful acknowledgment of the user's warnings or alarms, thereby potentially preventing the user from receiving such warnings or alarms.

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

[0222] Figure 46 shows one embodiment of the sensor electronic device 12 according to several exemplary implementation configurations. The sensor electronic device 12 may include sensor electronic devices configured to process sensor information such as sensor data and generate, for example, converted sensor data and displayable sensor information via a processor module. For example, the processor module may convert 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, location information, alarm / warning information, calibration information which can be determined by, for example, 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, though not all, portion, of the data processing. The processor module 214 may be integrated with the sensor electronics 12 and / or remotely located, 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 several smaller subcomponents or submodules. For example, the processor module 214 may include an alert module (not shown), or a predictive module (not shown), or any other suitable module that can be used to efficiently process data. If the processor module 214 consists of several submodules, the submodules may be located within the processor module 214, including within the sensor electronics 12 or other related 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 analytics processor 490, or in another location within the network 406.

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

[0225] In some exemplary 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., a processor module 214 and a data storage device 220). Figure 46 shows the ASIC 205, but other types of circuitry may also be used, including a field-programmable gate array (FPGA), one or more microprocessors, analog circuits, digital circuits, or a combination thereof, configured to provide (not all) of the processing performed by the sensor electronics 12.

[0226] In the example shown in Figure 46, the potentiostat 210 is connected to a continuous analyte sensor 10, such as a glucose sensor, through a first input port 211 for sensor data, in order to generate sensor data from the analyte. The potentiostat 210 may also provide a voltage to the continuous analyte sensor 10 via a data line 212 to bias the sensor for measurement of a value indicating the concentration of the analyte in the host (e.g., a current value) (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] In some exemplary implementations, the potentiostat 210 may include a resistor that converts current values ​​from the sensor 10 into voltage values, while in some exemplary implementations, a current / frequency converter (not shown) may also be configured to continuously incorporate measured current values ​​from the sensor 10, for example, using a charge counting device. In some exemplary implementations, an analog / digital converter (not shown) may digitize the analog signal from the sensor 10 into a so-called "count" to enable processing by the processor module 214. The resulting count may directly relate to the current measured by the potentiostat 210, which may directly relate to analyte levels, such as glucose levels in the host.

[0228] The telemetry module 232 may be operably connected to the processor module 214 and may provide hardware, firmware, and / or software that enables wireless communication between the sensor electronics 12 and one or more other devices such as a display device, a processor, or a network access device. 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 wireless 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 similar. In some exemplary implementations, the telemetry module 232 includes a Bluetooth® chip, but Bluetooth® technology may also be implemented in combination with the telemetry module 232 and the processor module 214.

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

[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. This 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 the sampling rate). In some exemplary implementations, such as when the potentiostat 210 is configured to measure an analyte (e.g., glucose and / or similar) at separate 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 / frequency converter. In these current / frequency converter implementations, the processor module 214 may be programmed to request digital values ​​from the integrator of the current / frequency converter at predetermined time intervals (acquisition time). These digital values ​​obtained by the processor module 214 from the integrator may be averaged over the acquisition time due to the continuity of the current measurement. Therefore, 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 display devices 14, 16, 18, and / or 20. Furthermore, the processor module 214 may generate data packets for transmission to these external sources via the telemetry module 232. In some exemplary 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 sensor 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 connected to a communication interface such as a communication port 238 and a power source such as a battery 234. Furthermore, the battery 234 may be further connected to a battery charger and / or regulator 236 to supply 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 for the connected sensors 10 (e.g., sensor identifiers (IDs)) 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 constitute the processor module 214 such as processing and filtering data streams or counts, performing calibration methods, and performing fail-safe checks.

[0234] Memory 218 may also be used to store information. For example, a processor module 214 containing memory 218 may be used as system cache memory, and temporary storage is provided for recent sensor data received from the sensor. In some exemplary implementations, 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), rewritable ROM, and flash memory.

[0235] The data storage device 220 may be connected to the processor module 214 and may be configured to store various sensor information. In some exemplary implementations, the data storage device 220 stores continuous analyte sensor data for one day or more. For example, the data storage device 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 value and / or previous calibration information from, for example, 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., a speaker) 230, a backlight (not shown), and / or the like. The component including the user interface 222 may provide controls for interacting with a user (e.g., a host). One or more buttons 224 may enable, for example, toggles, menu selections, option selections, state selections, yes / no responses to on-screen questions, a "turn off" function (e.g., for alarms), a "received acknowledgment" function (e.g., for alarms), a reset, and / or the like. The LCD 226 may provide the user with, for example, visual data output. The audio transducer 230 (e.g., a speaker) may provide an audible signal in response to triggers for certain warnings, such as current and / or predicted hyperglycemia and hypoglycemia conditions. In some exemplary implementations, an audible signal may be distinguished by timbre, volume, duty cycle, pattern, duration, and / or similar characteristics. In some exemplary implementations, an audible signal may be muted (e.g., acknowledged or turned off) by pressing one or more buttons 224 on the sensor electronic device 12 and / or by sending a signal to the sensor electronic device 12 using a button or selection on a display device (e.g., a key fob, mobile phone, and / or similar). In some cases, an audible warning may be muted while a visual warning remains rendered. In a particular example, the user may still be able to view glucose traces and / or threshold lines, while an audible warning may be muted. In this way, the user is still informed that they are high or low, but can avoid the source of the audible warning's irritation.

[0237] Audible and vibration alarms are described with respect to Figure 46, and other alarm mechanisms may also be used. For example, in some exemplary implementations, tactile alarms are provided, which include a poking mechanism configured to “poke” or physically contact the patient in response to one or more alarm conditions.

[0238] In one exemplary implementation, a default method of warning, such as an on-screen display, may be used. However, if a warning or alarm using the default mode is not acknowledged within a specified period, the warning and alarm may be progressively amplified with subsequent reminder warnings or alarms, often using alternative means of notification, including the use of connected devices such as drug delivery devices. For example, if the original or initial warning and alarm is not acknowledged, a subsequent or reminder warning or alarm, which may occur, for example, five minutes later, may be triggered by a mobile device and / or connected drug device, which may emit an auxiliary or incidental warning, such as an audible warning, such as a mobile phone. If this warning or alarm is also not acknowledged, and the pump or pen is connected to a mobile device (for example, as shown in Figure 45, if the drug delivery pump 2 is connected to a device that performs its respective processing, such as a mobile device 18 or processor 490, or even possibly a sensor electronic device 12), the drug delivery device (pump or pen) may emit an audible, tactile, or visual warning or alarm having, for example, a moderate amplitude and, for example, a moderate volume, for a predetermined period, for example, 20 seconds. Similarly, if these warnings or alarms are also not acknowledged, and the pump or pen is again connected to a device that performs its respective processing, it may emit an audible, tactile, or visual warning or alarm having, for example, a high amplitude and, for example, a loud volume, for a predetermined period, for example, 20 seconds.

[0239] Other means may also be used to render warnings or alarms. For example, dogs are increasingly used as diabetes warning dogs or companion animals. In either case, the system components may be configured with an ultrasonic transmitter such that an ultrasonic transducer is triggered to render an ultrasonic pulse when the user's glucose concentration value approaches a dangerous level. Diabetes warning dogs generally detect an imminent hypoglycemic or hyperglycemic situation, but if the dog fails to detect it, the ultrasonic pulse may provide a reminder. Similarly, a companion animal not trained as a diabetes warning dog may be trained to recognize the pulse as a reason to warn its owner. Even if such a dog is not specifically trained, the ultrasonic pulse may produce some degree of agitation that provides the user with an alarm that something is wrong. The ultrasonic transmitter may be signal-coupled to various parts of the system, e.g., a transmitter, a smartphone, a 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 to the change.

[0240] In another example, the user may be informed of their glucose warnings, alerts, and notifications without looking at their monitoring device by using distinctive force sensations or vibration patterns that can be rendered on a smart device or watch. The force sensation / vibration pattern may be rendered and constructed according to relative urgency or safety concerns using similar principles to those of auditory or visual alerts and alert prioritization. For example, higher priority alerts may use a higher vibration rate, a narrower interval between vibrations, and a longer duration, while lower priority alerts may be the opposite. The user may be able to conform to a specific vibration profile or curve according to the user's own instructions and design. In this way, the user may be informed of an alert or warning without the need to look at a display screen or hear the alert (the latter may also be annoying as it may disrupt others near the user), and may receive information about the type and / or urgency of the warning.

[0241] The battery 234 may be functionally connected to the processor module 214 (and optionally 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, although any appropriately sized and powered battery may be used (e.g., AAA, nickel cadmium, zinc carbon, alkaline, lithium, nickel metal hydride, lithium ion, air zinc, zinc mercury oxide, silver zinc, or sealed form). 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 regulator 236 may be configured to receive energy from an internal and / or external charger. In some exemplary implementations, the battery regulator (or balancer) 236 adjusts the recharge process by bleeding off excess charge current to allow all cells or batteries within the sensor electronics 12 to be fully charged without overcharging other cells or batteries. In some exemplary implementations, the battery 234(s) may be configured to be charged via an inductive and / or wireless charging pad, although any other charging and / or power mechanism may equally be used.

[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 a system that is separate from or integral with the sensor electronics 12. For example, the communication port may include a serial (e.g., Universal Serial Bus or “USB”) communication port and may enable communication with another computer system (e.g., a PC, a Personal Digital Assistant or “PDA”, a server, etc.). In some exemplary implementations, the sensor electronics 12 may be capable of transmitting historical data to a PC or other computer device for retrospective analysis by a patient and / or HCP. As another example of data transmission, factory information may also be transmitted from the sensor or from a cloud data source to an algorithm.

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

[0245] Exemplary Embodiments Non-temporary computer-readable medium 1: A non-temporary computer-readable medium comprising instructions causing a computing environment to perform a method of dynamically adjusting or adjusting user alerts based on a determination of cognitive awareness, thereby providing data relating to the treatment of a diabetic condition of concern, the method comprising the steps of identifying a current or future diabetic condition of concern, wherein the identification is at least partially based on a glucose concentration value; estimating or predicting the user's cognitive awareness of the identified current or future diabetic condition of concern; and warning the user using a user prompt on the user interface of a monitoring device if the result of the estimation or prediction is that the user is not cognitively aware of the identified current or future diabetic condition of concern, wherein the user is warned of a diabetic condition of concern, provided that the user is not aware of the diabetic condition of concern and the notification is effective for the user, and only at these times the user is warned of the diabetic condition of concern.

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

[0247] Non-temporary computer-readable medium 3: An embodiment of non-temporary 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-temporary computer-readable media 4: An embodiment of any one of non-temporary computer-readable media 1 to 3, wherein excessive prompting, repetitive prompting, or unwanted prompting is minimized or avoided.

[0249] Non-temporary computer-readable medium 5: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 4, wherein the user can build trust in the system and the system only warns of notifications that are optimized for the user or are valid.

[0250] Non-temporary computer-readable medium 6: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 5, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the identified current or future diabetic condition worthy of attention includes an abnormal glucose trace.

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

[0252] Non-temporary computer-readable medium 8: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 7, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the user has previously treated a similar identified attention-worthy diabetic condition by taking action without user prompting.

[0253] Non-temporary computer-readable medium 9: The measure is the administration of a drug, as described in the embodiment of non-temporary computer-readable medium 8.

[0254] Non-temporary computer-readable medium 10: The measure is to eat, according to the embodiment described in non-temporary computer-readable medium 8.

[0255] Non-temporary computer-readable medium 11: The measure is motion, as described in the embodiment of the non-temporary computer-readable medium 8.

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

[0257] Non-temporary computer-readable medium 13: An embodiment of non-temporary computer-readable medium according to any one of items 1 to 12, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the user's behavior is consistent with the cognitive awareness.

[0258] Non-temporary computer-readable medium 14: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 13, wherein the estimation or prediction of 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-temporary computer-readable medium 15: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 14, wherein the estimation or prediction of the user's cognitive awareness includes analyzing historical data of the user's glucose values ​​over time.

[0260] Non-temporary computer-readable medium 16: An embodiment of any one of non-temporary computer-readable mediums 1 to 15, wherein the identifying step and the estimation or prediction step are repeated until it is estimated or predicted that the user will cognitively become aware of the identified attention-worthy diabetic condition, and then the user is warned using a user prompt.

[0261] Non-temporary computer-readable media 17: An embodiment of non-temporary computer-readable media according to any one of paragraphs 1 to 16, which includes estimating or predicting user cognitive awareness by receiving data from an application or website via an appropriate API.

[0262] Non - transient computer - readable medium 18: The estimation or prediction is an embodiment according to any one of embodiments 1 to 17 of the non - transient computer - readable medium, at least partially based on location data, i.e., GPS data.

[0263] Non - transient computer - readable medium 19: The location data is the user's location data, which is an embodiment according to non - transient computer - readable medium 18.

[0264] Non - transient computer - readable medium 20: The location data is the location data of the user's followers, which is an embodiment according to non - transient computer - readable medium 18.

[0265] Non - transient computer - readable medium 21: The estimation or prediction of the user's cognitive awareness is an embodiment according to any one of embodiments 1 to 20 of the non - transient computer - readable medium, at least partially based on one or more of population data, data related to behavior or context information, data related to the user's life goals, data related to user privacy settings, or a combination thereof.

[0266] Non - transient computer - readable medium 22: The estimation or prediction of the user's cognitive awareness is at least partially based on real - time data, and the real - time data includes data related to the GPS application of the monitoring device, data related to the accelerometer of the monitoring device, data related to behavior or context 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 blood glucose urgency index, heart rate data, sweat content data, data related to the user's wearable sensor, insulin data, or one or more of a combination thereof. It is an embodiment according to any one of embodiments 1 to 21 of the non - transient computer - readable medium.

[0267] Non - transient computer - readable medium 23: The estimation or prediction of the user's cognitive awareness includes recognizing one or more individualized patterns related to the user, which is an embodiment according to any one of embodiments 1 to 22 of the non - transient computer - readable medium.

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

[0269] Non-temporary computer-readable medium 25: An embodiment of non-temporary computer-readable medium 24, wherein the event relates to eating, exercise, or sleep.

[0270] Non-temporary computer-readable medium 26: The determination is whether the user is not consciously aware whether the current signal trace is outside the envelope of the characteristic analyte concentration signal trace, according to the embodiment of the non-temporary computer-readable medium 25.

[0271] Non-temporary computer-readable medium 27: An embodiment of the non-temporary computer-readable medium according to any one of the non-temporary computer-readable media 1 to 26, further comprising indicating confidence related to a user prompt.

[0272] Non-temporary computer-readable medium 28: The embodiment according to any one of non-temporary computer-readable mediums 1 to 27, where the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition worth paying attention to.

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

[0274] Non-temporary computer-readable medium 30: If the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition of note, the user is warned using a user prompt after a certain time delay, the duration of which is based on at least the identified diabetic condition of note, as well as the glucose concentration value and / or the rate of change of the glucose concentration value, according to any one embodiment of non-temporary computer-readable medium 1 to 29.

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

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

[0277] Non-temporary computer-readable medium 33: An embodiment of any one of non-temporary computer-readable mediums 1 to 32, wherein if it is determined from data from a user interface or data from an accelerometer associated with a monitoring device that the user is ignoring a user prompt, and the user prompt does not address a dangerous condition, the medium stores information that the user is ignoring the user prompt under the aforementioned conditions, and uses the stored information as part of a subsequent estimation or prediction step.

[0278] Non-temporary computer-readable medium 34: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 33, wherein the identification of a current or future diabetic condition worthy of attention includes determining clinical values ​​of glucose concentration and / or the rate of change of glucose and / or the blood glucose emergency index value.

[0279] Non-temporary computer-readable medium 35: An embodiment of non-temporary computer-readable medium according to any one of the non-temporary computer-readable mediums 1 to 34, comprising: measuring a glucose signal signature; comparing the measured signature with a plurality of binned signatures; and, based on the comparison, classifying the diabetic condition of concern into one of the plurality of bins.

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

[0281] Non-temporary computer-readable medium 37: An embodiment of the non-temporary computer-readable medium 36, wherein the trend corresponds to the glucose concentration value remaining within a certain range, or rising or falling, and the fluctuation 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.

[0282] Non-temporary computer-readable medium 38: An embodiment of non-temporary computer-readable medium 37, wherein ambiguous boundaries are used to define the range.

[0283] Non-transient computer-readable medium 39: An embodiment of any one of non-transient computer-readable mediums 1 to 28, further comprising transmitting instructions for a diabetic condition worth noting to a drug pump.

[0284] Non-temporary computer-readable medium 40: An embodiment of the non-temporary computer-readable medium 39, further comprising activating a drug pump to cause a drug bolus delivery if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition worth paying attention to.

[0285] Non-temporary computer-readable medium 41: The embodiment described in non-temporary computer-readable medium 40, wherein the drug bolus administration is a meal bolus of insulin.

[0286] Non-temporary computer-readable medium 42: An embodiment of the non-temporary computer-readable medium 42, further comprising activating a drug pump and changing the baseline rate if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition worth paying attention to.

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

[0288] Non-temporary computer-readable medium 44: An embodiment of the non-temporary computer-readable medium 39, further comprising determining whether the drug pump can treat a diabetic condition worth attention, all or in part, and if it determines that it can treat the condition, not warning the user or changing the user prompt, compared to the case where the drug pump cannot treat the diabetic condition.

[0289] Non-temporary computer-readable medium 45: An embodiment of non-temporary computer-readable medium according to any one of items 1 to 44, wherein if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition worth paying attention to, a user prompt is used to determine when to warn the user.

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

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

[0292] Non-temporary computer-readable medium 48: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 47, wherein the user prompt, if displayed, includes an audible indicator, the volume of which is automatically adjusted to ambient noise measured by a monitoring device or a device that signals to the monitoring device, and the adjustment to ambient noise includes increasing the volume of which is which to ambient noise until a threshold level of signal-to-noise ratio is reached.

[0293] Non-temporary computer-readable medium 49: An embodiment of non-temporary computer-readable medium according to any one of paragraphs 1 to 48, wherein the user prompt is associated with a diabetic condition requiring attention that occurs during a period in which the user has a hypoglycemic emergency index.

[0294] Non-temporary computer-readable medium 50: An embodiment of any one of non-temporary computer-readable mediums 1 to 49, which, if the result of an estimation or prediction is that the user is not cognitively aware of a diabetic condition of concern, warns the user after a certain delay using a user prompt, based on the identified diabetic condition of concern, as well as the glucose concentration value and / or the rate of change in the glucose concentration value, rather than on the duration.

[0295] Non-temporary computer-readable medium 51: An embodiment of any one of the non-temporary computer-readable mediums 1 to 50, wherein if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition worth attention, the medium alerts the user after a certain delay using a user prompt, based on an individualized pattern learned by the monitoring device rather than on duration.

[0296] Non-temporary computer-readable medium 52: An embodiment of any one of the non-temporary computer-readable mediums 1 to 51, wherein identified diabetic conditions requiring attention correspond to abnormal glucose responses or abnormal patterns, and the abnormal responses or abnormal patterns are learned by a monitoring device and not by user input.

[0297] Non-temporary computer-readable medium 53: An embodiment of non-temporary computer-readable medium according to any one of items 1 to 52, wherein the user prompt is displayed at dynamic timing on a pre-designed user interface rather than on a adapted user interface.

[0298] Non-temporary computer-readable medium 54: An embodiment of any one of non-temporary computer-readable mediums 1 to 53, which immediately alerts the user using a user prompt, regardless of instructions received from another monitoring device application 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 a diabetic condition worth attention.

[0299] Non-temporary computer-readable medium 55: An embodiment of any one of non-temporary computer-readable mediums 1 to 54, which immediately warns the user using a user prompt, regardless of instructions not to warn the user with a user prompt based on data or settings entered by another user, if the result of the estimation or prediction is that the user is not cognitively aware of a diabetic condition worth paying attention to.

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

[0301] Non-temporary computer-readable medium 57: An embodiment of non-temporary computer-readable medium according to any one of items 1 to 56, wherein a warning to the user using a user prompt on the user interface of a monitoring device includes rendering an ultrasonic pulse.

[0302] Non-temporary computer-readable medium 58: An embodiment of non-temporary computer-readable medium according to any one of items 1 to 57, wherein a warning to the user using a user prompt on the user interface of the monitoring device causes a prompt to appear on the second user interface of the monitoring device if the user ignores a first warning.

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

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

[0305] Non-temporary computer-readable medium 61: Embodiments of non-temporary computer-readable medium 58, wherein the monitoring device is a mobile cellular device and the second user interface includes a vibratory, force-feedback, or haptic rendering system.

[0306] Non-temporary computer-readable medium 62: The embodiment of non-temporary computer-readable medium 61, wherein the prompt is a vibratory prompt and is reproduced through a vibratory, force-feedback, or haptic rendering system.

[0307] Non-temporary computer-readable medium 63: The embodiment of non-temporary computer-readable medium 62, wherein the monitoring device is a mobile cellular device, the second user interface includes an audio channel, the prompts are audible prompts played through the audio channel, and if the audible prompt is not perceived by the user, the rendering of a vibratory prompt is triggered.

[0308] Non-temporary computer-readable medium 64: An embodiment of a non-temporary computer-readable medium according to any one of the non-temporary computer-readable mediums 1 to 63, wherein a warning to the user using a user prompt on the user interface of a monitoring device causes a prompt on the second user interface of a second device if the user ignores a first warning.

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

[0310] Non-temporary computer-readable medium 66: An embodiment of non-temporary computer-readable medium according to any one of claims 1 to 65, wherein a warning to the user using a user prompt on the user interface of a monitoring device includes rendering force-sensitive or vibrational signals.

[0311] Non-temporary computer-readable medium 67: Rendering is performed on a monitoring device, according to the embodiment of non-temporary computer-readable medium 66.

[0312] Non-temporary computer-readable medium 68: The embodiment of non-temporary computer-readable medium 66, wherein rendering is performed on a device that signals to a monitoring device.

[0313] Non-temporary computer-readable medium 69: An embodiment of non-temporary computer-readable medium 68, wherein the monitoring device is a smartphone, and the device communicating with the monitoring device is a smartwatch.

[0314] Non-temporary computer-readable medium 70: Rendering comprises rendering a user prompt in a pattern, the pattern corresponding to a diabetic condition of note, as described in the embodiment of the non-temporary computer-readable medium 66.

[0315] System 71: A system for providing smart alerts in response to a user's attention-worthy diabetic condition, comprising: a CGM application running on a mobile device, configured to receive data from a sensor at least periodically or occasionally, 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 with the CGM application, receiving data from the CGM application, and configured to perform the method contained in the non-temporary computer-readable medium 1.

[0316] Non-temporary computer-readable medium 72: A non-temporary computer-readable medium comprising instructions for causing a computing environment to perform a method for safely reducing warnings to a user of a diabetic condition requiring attention, the method comprising the steps of identifying a current or future diabetic condition requiring attention, the identification being at least partially based on a glucose concentration value; determining whether the identified diabetic condition requiring attention is abnormal to the user; and, if the determination is that the identified diabetic condition is abnormal to the user, warning the user using a user prompt on the interface of a user monitoring device, the user prompt indicating a diabetic condition requiring attention, the method thereby ensuring that the user is notified of a diabetic condition requiring attention only if the identified diabetic condition is abnormal to the user.

[0317] Non-temporary computer-readable medium 73: An embodiment of the non-temporary computer-readable medium 72 in which the determination of whether an identified diabetic condition worthy of attention is abnormal to the user includes determining whether the identified diabetic condition includes glucose traces that follow a pattern that does not exhibit other pattern features related to the user.

[0318] Non-temporary computer-readable medium 74: The embodiment of the non-temporary computer-readable medium 72 or 73, wherein the determination of whether an identified diabetic condition warranting attention is abnormal for the user includes determining whether the identified diabetic condition includes a glucose trace that follows a tendency not to exhibit other tendency features relevant to the user.

[0319] Non-temporary computer-readable medium 75: A non-temporary computer-readable medium comprising instructions for causing a computing environment to perform a method of prompting a user about a diabetic condition of concern, wherein the computing environment communicates with a drug delivery device, and the user prompts are optimized for effectiveness to the user by at least partially reducing their number, and the user prompts provide data relating to the treatment of a diabetic condition of concern, the method comprising the steps of identifying a current or future diabetic condition of concern, the identification being at least partially based on a glucose concentration value, the first estimation or prediction of the user's cognitive awareness of the identified current or future diabetic condition of concern, and the result of the first estimation or prediction being used by the user If the result is that the drug delivery device is not cognitively aware of a current or future diabetes condition of concern, the step of making a second estimation or prediction of the drug delivery device's computer awareness of the identified current or future diabetes condition of concern, and if the result of the second estimation or prediction is that the drug delivery device is not aware of the identified current or future diabetes condition of concern, the step of warning the user using a user prompt on the monitoring device's user interface, the user prompt indicating a diabetes condition of concern, thereby, if both the user and the drug delivery device are unaware of the diabetes condition of concern and the notification is effective for the user, and only at these times the user will be notified of the diabetes condition of concern.

[0320] Non-temporary computer-readable medium 76: An embodiment of the non-temporary computer-readable medium 75, further comprising the steps of: determining whether a drug delivery device can treat an identified current or future diabetic condition worthy of attention; and, if the determination is that the drug delivery device cannot treat the identified diabetic condition, warning the user using a user prompt.

[0321] Non-temporary computer-readable media 77: Embodiments of non-temporary computer-readable media 75 or 76, wherein the current or future diabetic condition includes hypoglycemia, the drug delivery device is an insulin delivery device, and further comprises stopping or reducing the activity of the insulin delivery device based on the diabetic condition of hypoglycemia.

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

[0323] Non-transient computer-readable medium 79: The embodiment of any one of the non-transient computer-readable mediums 75 to 78, wherein the first estimation or prediction is based at least in part on user interaction with a 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 data, calibrated data, 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 a processor module 214) may be implemented to perform predictive algorithms used to generate converted sensor data and / or displayable sensor information, including, for example, algorithms that evaluate the clinical acceptability of reference and / or sensor data, evaluate calibration data for best calibration based on inclusion criteria, evaluate the quality of calibration, compare predicted analyte values ​​with corresponding estimated analyte values ​​over time, analyze fluctuations in estimated analyte values, evaluate the stability of the sensor and / or sensor data, detect signal artifacts (noise), replace signal artifacts, determine the rate and / or trend of change in 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 user cognitive awareness.

[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 the data processing and storage requirements of the sensor electronic device 12.

[0326] In one preferred embodiment, the analyte sensor is an implantable glucose sensor, such as the one described with reference to U.S. Patent No. 6,001,067 and U.S. Patent Application Publication No. 2005 / 0027463-A1. In another preferred embodiment, the analyte sensor is a transdermal glucose sensor, such as the one described with reference to U.S. Patent Application Publication No. 2006 / 0020187-A1. In yet another embodiment, the sensor is configured to be implanted intravascularly or extracorporeally in a host blood vessel, as described in U.S. Patent Application Publication No. 2007 / 0027385-A1, concurrently pending U.S. Patent Application No. 11 / 543,396 filed October 4, 2006, concurrently pending U.S. Patent Application No. 11 / 691,426 filed March 26, 2007, and concurrently pending U.S. Patent Application No. 11 / 675,063 filed February 14, 2007. In one alternative embodiment, the continuous glucose sensor includes a transdermal sensor, for example, as described in U.S. Patent No. 6,565,509 by Say et al. In another alternative embodiment, the continuous glucose sensor includes a subcutaneous sensor, for example, as described with reference to U.S. Patent No. 6,579,690 by Bonnecaze et al. and U.S. Patent No. 6,484,046 by Say et al. In yet another alternative embodiment, the continuous glucose sensor includes a replaceable subcutaneous sensor, for example, as described with reference to U.S. Patent No. 6,512,939 by Colvin et al. In yet another alternative embodiment, the continuous glucose sensor includes an intravascular sensor, for example, as described with reference to U.S. Patent No. 6,477,395 by Schulman et al. In yet another alternative embodiment, the continuous glucose sensor includes an intravascular sensor, as described with reference to U.S. Patent No. 6,424,847 by Mastrototaro et al.

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

[0328] The various operations of the above method may be performed by any suitable means capable of performing the operations, such as various hardware and / or software components, circuits, and / or modules. In general, any operations shown in the drawings may be performed by corresponding functional means capable of performing the operations.

[0329] Various exemplary logic blocks, modules, and circuits described in connection with this disclosure The blocks (such as those in Figure 46) may be implemented or carried out 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), separate gate or transistor logic, separate hardware components, or any combination thereof, designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternative ways, the processor may be a commercially available processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computer devices, for example, a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other combination of such configurations.

[0330] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored or transmitted as one or more instructions or codes on a computer-readable medium. The computer-readable medium includes both computer storage media and communication media, including any media that facilitate the transfer of computer programs from one place to another. The storage media may be any available media that can be accessed by a computer. Such computer-readable media may include, but are not limited to, various types of RAM, ROM, CD-ROM, or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, or any other media 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. Any connection may also be appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, WiFi, Bluetooth®, RFID, NFC, and microwave are included in the definition of medium. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital multipurpose disc (DVD), floppy disk, and Blu-ray® disc, where a disk typically reproduces data magnetically, while a disc reproduces data optically using a laser. Therefore, in some embodiments, computer-readable medium may include non-temporary computer-readable medium (e.g., tangible representation medium). In addition, in some embodiments, computer-readable medium may include temporary computer-readable medium (e.g., signals).The above combinations 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 interchangeable with one another without departing from the claims. In other words, unless a specific order of steps or actions is specified, the order and use of any particular steps and / or actions may be modified without departing from the claims.

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

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

[0334] Furthermore, it should be understood that modules and / or other suitable means for carrying out the methods and techniques described herein may be downloaded and / or otherwise obtained by user terminals and / or base stations, where applicable. For example, such devices may be connected to a server to facilitate the transfer of means for carrying out the methods described herein. Alternatively, since the various methods described herein may be provided via storage means (e.g., physical storage media such as RAM, ROM, compact disks (CDs), or floppy disks), user terminals and / or base stations may obtain the various methods by connecting or providing storage means to the devices. Furthermore, any other suitable techniques for providing the methods and techniques described herein to devices may be utilized.

[0335] It should be understood that the claims are not limited to the exact configurations and components exemplified above. Various modifications, changes, and alterations may be made to the arrangement, operation, and details of the above-described methods and apparatus without departing from the claims.

[0336] Unless otherwise explicitly defined, all terms (including technical and scientific terms) have their ordinary and customary meanings as indicated to those skilled in the art, and are not limited to any special or customized meanings unless expressly defined herein. It should be noted that the use of a particular term when describing a particular feature or aspect of the Disclosure should not be construed as implying that the term is being redefined herein if it is limited to including any particular characteristic of the feature or aspect of the Disclosure to which it relates. In particular, in the appended claims, terms and phrases used in this application and their variations should be construed as non-restrictive, as opposed to restrictive, unless otherwise explicitly stated. In the examples above, the term “including” should be interpreted as meaning “including without limitation,” “listed but not limited to,” etc.; the term “equipped with,” when used herein, is synonymous with “including,” “containing,” or “characterizing,” and is comprehensive or non-restrictive, without excluding additional unlisted elements or method steps; the term “having” should be interpreted as “having at least”; the term “including” should be interpreted as “listed but not limited to”; the term “examples” is used to provide illustrative examples of matters in consideration, rather than a comprehensive or restrictive list of such matters; and “known,” “usual.” Adjectives such as "standard," "ordinary," and similar terms should not be interpreted as limiting the matters described to those available during a given period or at a given point in time, but rather as encompassing known, ordinary, or standard techniques that may be available or known now or at any future time. The use of terms such as "preferred," "desirable," "desired," or "coveted," and similar terms should not be understood as implying that certain features are critical, essential, or even important to the structure or function of the invention, but rather should simply be intended to highlight alternative or additional features that may or may not be utilized in particular embodiments of the invention.Similarly, a group of items connected by the conjunction "and" should not be interpreted as requiring each item to exist within the group; rather, unless otherwise specified, it should be interpreted as "and / or." Likewise, a group of items connected by the conjunction "or" should not be interpreted as requiring mutual exclusivity between the items; rather, unless otherwise specified, it should be interpreted as "and / or."

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

[0338] With respect to substantially any plural and / or singular terms herein, a person skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context and / or use. Various singular / plural substitutions may be explicitly stated herein for clarity. The indefinite articles “a” or “an” do not exclude the plural. A single processor or other unit may accomplish the functions of several matters described in the claims. The mere fact that certain criteria are described in separate claims that differ from each other does not imply that combinations of these criteria cannot be used for benefit. Reference numerals in the claims should not be construed as limiting the scope.

[0339] If a particular number is intended in the description of an introduced claim, such intention is clearly stated in the claim, and if no such statement is present, such intention is not present, as will be further understood by those skilled in the art. For example, to aid understanding, the following appended claims may include the use of the introductory phrases “at least one” and “one or more” to introduce the description of a claim. However, the use of such phrases should not be interpreted as implying that the introduction of the description of a claim by the indefinite article “a” or “an” implies that any particular claim containing such introduced description is limited to embodiments containing only one such description (for example, “a” and / or “an” should typically be interpreted as meaning “at least one” or “one or more”), and the same applies to the use of definite articles used to introduce the description of a claim. In addition, even when a specific number of descriptions in an introduced claim is explicitly stated, a person skilled in the art will recognize that such a statement should typically be interpreted as meaning at least that number (for example, the mere statement “two descriptions” without other modifiers typically means at least two descriptions, or two or more descriptions). 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 enumerated items, for example, a single member, in the sense that a person skilled in the art will understand the conventional expression (for example, “a system having at least one of A, B, and C” includes, but is not limited to, A alone, B alone, C alone, A and B, A and C, B and C, and / or a system having A, B, and C, etc.).Where a conventional expression similar to “at least one of A, B, or C, etc.” is used, such a structure is generally intended to mean that a person skilled in the art will understand the conventional expression (for example, “a system having at least one of A, B, or C” includes, but is not limited to, A alone, B alone, C alone, A and B, A and C, B and C, and / or a system having A, B, and C, etc.). A person skilled in the art will further understand that substantially any disjunct word and / or phrase indicating two or more alternative terms should be understood as construing the possibility of including one of the terms, either of the terms, or both of the terms, whether in a description, claim, or drawing. For example, the phrase “A or B” is understood to include the possibilities of “A” or “B” or “A and B”.

[0340] All numbers representing quantities of components, reaction conditions, etc., used herein are understood to be modified in any case by the term “approximately.” Therefore, unless otherwise indicated, numerical parameters described herein are approximations that may vary depending on the desired properties to be obtained. Each numerical parameter should be interpreted, at a minimum, and not as an attempt to limit the application of the equivalence principle of any claim scope in any application claiming priority to this application, taking into account a significant number of digits and ordinary rounding methods.

[0341] All references listed herein are incorporated herein in their entirety by reference. This specification is intended to supersede and / or take precedence over any publications and patents or patent applications incorporated by reference to the extent that they conflict with the disclosures contained herein.

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

[0343] Furthermore, although the above has been described in some detail as examples and embodiments for the purpose of clarity and understanding, it will be apparent to those skilled in the art that certain changes and modifications may be made. Therefore, 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 encompassing all modifications and substitutes that fall within the true scope and spirit of the invention.

[0344] The system and method can be fully executed on any number of computing devices. Typically, instructions are placed on a computer-readable medium that is generally non-temporary, and these instructions are sufficient for the processor of the computing device to execute the method of the aspects and embodiments. The computer-readable medium may be a hard drive or solid-state storage device having instructions that, when executed, are read into 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, touchscreen, joystick, trackpad, other pointing device, or any other such computer input device for inputting data related to calculations. Data may also be input by means of an insertable memory chip, hard drive, flash drive, flash memory, optical medium, magnetic medium, or any other type of file storage medium. Output may be delivered to the user by means of a video graphics card or integrated graphics chipset connected to a display that the user can see. Alternatively, a printer may be used to output a hard copy of the results. In consideration of this teaching, it is understood that any number of other tangible outputs are also contemplated. For example, the output may be stored in a memory chip, hard drive, flash drive, flash memory, optical media, magnetic media, or any other type of output. It should also be noted that the embodiments and models can be run 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, and tablet computers, and on devices specifically designed for these purposes. In one implementation, a user of a smartphone or a 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 the payment to the seller. The application may be downloaded via a mobile connection or via Wi-Fi or other wireless network connection. The application may then be run by the user. Such a networked system may provide a computing environment suitable for execution in which multiple users provide separate inputs to the system and method. In the following systems in which smart alerts are intended, multiple inputs may allow multiple users to enter relevant data simultaneously. [Explanation of symbols]

[0345] 2. Drug delivery pump 4. Glucose meter 8. Continuous Analytical Sensor System 10 Sensors (Continuous Analytical Sensors) 12 Sensor Electronic Devices 14. Key fob type display devices 16. Handheld display device (dedicated receiver) 18. Mobile phones (smart devices) 20 Computers 25 Smart Warning Applications 50 Systems 52. Source of pump or pump data 100 Systems 102 patients 114 Follower Devices 115 Servers 117 Healthcare Professional (HCP) Devices 205 Application-Specific Integrated Circuits (ASICs) 210 potentiostat 214 Processor Modules 216 Program Memory 218 memory 220 data storage memory 222 User Interface 224 User Buttons 226 LCD displays 228 Vibrator Motor 230 Audio Converters 232 Telemetry Modules 234 Batteries 236 Battery Charger / Regulator 238 communication ports 350 System 406 Network 490 Cloud-based Analytical Processors

Claims

1. A non-temporary computer-readable medium comprising instructions for causing a computing environment to perform a method of dynamically adjusting or adjusting user alerts based on a determination of cognitive awareness, thereby providing data relating to the treatment of a diabetic condition worth attention, the method being: A step of identifying a current or future diabetic condition that warrants attention, wherein the identification is at least partially based on glucose concentration values. A step of estimating or predicting whether the user is cognitively aware of the identified current or future diabetic condition that warrants attention, including estimating that the user is cognitively aware of the diabetic condition based on established patterns of the user's behavior; If the result of the estimation or prediction is that the user is not consciously aware of the identified current or future diabetes condition requiring attention, the step of warning the user using a user prompt on the user interface of the monitoring device, wherein the user prompt is a warning indicating the diabetes condition requiring attention, Therefore, if the user is unaware of the diabetic condition requiring attention, and the warning is effective for the user, and only at these times the user is warned about the diabetic condition requiring attention, the medium.

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

3. The medium according to claim 2, wherein the abnormal glucose trace includes an abnormal pattern or an abnormal glucose reaction.

4. The medium according to any one of claims 1 to 3, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the user has previously treated a similar identified attention-worthy diabetic condition by taking action without user prompting.

5. The medium according to claim 4, wherein the measure is the administration of a drug, eating, or exercising.

6. The medium according to any one of claims 1 to 5, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the user has entered meal or bolus dose data, or has requested a bolus dose calculation.

7. The medium according to any one of claims 1 to 6, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the user's behavior is consistent with the cognitive awareness.

8. The medium according to any one of claims 1 to 7, wherein the estimation or prediction of the user's cognitive awareness includes receiving user input and basing the estimation or prediction at least in part on the received input.

9. The medium according to any one of claims 1 to 8, wherein the estimation or prediction of the user's cognitive awareness includes estimating that the user is cognitively aware of the diabetic condition based on historical data showing a decrease in the frequency of the user's hypoglycemic symptoms.

10. The medium according to any one of claims 1 to 9, wherein the estimation or prediction of the user's cognitive awareness includes estimating that the user is not cognitively aware of the diabetic condition when data is received from an application or website via an appropriate API and a problem with the infusion set is detected.

11. The medium according to any one of claims 1 to 10, wherein the estimation or prediction includes estimating, at least in part, based on location data, i.e., GPS data, that the user is cognitively aware of the diabetic condition when changes in glucose related to food intake are predicted.

12. The medium according to claim 11, wherein the location data is the location data of the user or the location data of the user's followers.

13. The media according to any one of claims 1 to 12, 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 includes one or more of the following: data related to the GPS application of the monitoring device, data related to the accelerometer of the monitoring device, data related to behavior 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 blood glucose urgency index, heart rate data, sweat content data, data related to the user’s wearable sensor, insulin data, or a combination thereof.

14. The medium according to any one of claims 1 to 13, wherein the individualized pattern corresponds to the envelope of a characteristic analyte concentration signal trace occurring before or after the event.

15. The medium according to claim 14, wherein the event is related to eating, exercise, or sleep.

16. The medium according to claim 15, wherein the determination is whether the user is not consciously aware whether the current signal trace is outside the envelope of the characteristic analyte concentration signal trace.

17. The medium according to any one of claims 1 to 16, wherein the estimation or prediction is further based on the user's location information, the location information includes estimating that the user is cognitively aware of the diabetic condition when the user is within a predetermined threshold of a grocery store or restaurant.

18. A system for providing smart alerts to address diabetic conditions that warrant user attention, A CGM application running on a mobile device, configured to receive data from a sensor at least periodically or occasionally, and to calibrate and display glucose concentration data in clinical units; A system comprising: a smart warning application which is executed on the mobile device as a subroutine within the CGM application or as a parallel process with the CGM application, and which receives data from the CGM application, and which is configured to perform the method contained in the medium according to any one of claims 1 to 17.

Images