System and method for providing user-optimized alerts

Abstract

Systems and methods are disclosed that provide intelligent alerts to a user, for example, alerts to a user about a diabetes state, that are provided only when it is meaningful for them to be provided, for example, when the system can predict or estimate that the user has not yet recognized their current condition, for example, particularly if the current condition is a diabetes state that requires attention. In this way, the alerts or alarms are personalized and particularly effective for the user. Such systems and methods still alert the user when action is necessary, for example, a dose or temporary basal rate change, or provide a response to a missed dose or correction need, but do not issue an alert when action is not necessary, for example, if the user has been estimated or predicted to recognize the diabetes state that requires attention, or if a corrective action has been taken.

Description

[0001] This application is a divisional application of patent application filed on April 28, 2017, with application number 201780027050.0 and entitled "System and method for providing user-optimized alarms". Technical Field

[0002] Any and all priority claims identified in the application data sheet, or any corrections thereof, are incorporated herein by reference in accordance with 37 CFR 1.57. This application claims the benefit of U.S. Provisional Application No. 62 / 330,729, filed May 2, 2016. The foregoing application is incorporated herein by reference in its entirety and is expressly constituted a part of this specification.

[0003] It provides user alerts, especially in the medical field where physiological parameters are monitored. Background Technology

[0004] Diabetes is a condition in which the pancreas cannot produce enough insulin (type 1 or insulin-dependent) and / or insulin is ineffective (type 2 or non-insulin-dependent). In a diabetic state, patients have high blood sugar, which can lead to a range of physiological disorders associated with the deterioration of small blood vessels (e.g., kidney failure, skin ulcers, or vitreous hemorrhage in the eye).

[0005] Traditionally, people with diabetes carry self-monitoring blood glucose (SMBG) monitors, which typically require an uncomfortable finger prick to obtain a blood sample for measurement. Due to the lack of comfort and convenience associated with finger pricking, people with diabetes usually only measure their blood glucose levels two to four times a day. Unfortunately, the time intervals between measurements can be so long that people with diabetes may discover symptoms of high or low blood glucose too late, sometimes causing dangerous side effects. Not only is it impossible for people with diabetes to obtain timely SMBG values, but based on traditional methods, they are also unlikely to know whether their blood glucose level is rising (increased) or falling (decreased). Therefore, people with diabetes may be prevented from making informed decisions about insulin treatment.

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

[0007] If the analyte is blood glucose, and in the case of continuous glucose monitoring (CGM), some CGMs provide various alarms or alerts when a user's blood glucose level enters a dangerous or unwanted range. For example, many CGMs will issue an alarm if a user's blood glucose level deviates into the range of mild hypoglycemia or hyperglycemia, and will issue an alert if the situation becomes more serious. In some cases, such alarms / alerts use predictive algorithms to determine whether the user is approaching a dangerous state, and therefore determine whether an alarm or alert should be activated.

[0008] While useful, these alerts and alarms are not without their problems. For example, users can quickly become accustomed to them and begin to "turn them off" or otherwise ignore them. In some cases, users are unnecessarily alerted again for situations they are already aware of. In many of these cases, "alert fatigue" may lead users to ignore or turn off alerts without fully considering the reasons or the steps that need to be taken.

[0009] Now let's describe other issues. We'll begin with an example in the "high" blood glucose alert category. Users are often annoyed by receiving high-value alerts after meals or after administering insulin. These high-value alerts can even occasionally lead to "backlog" or insulin administration when insulin is already "on the plate." In these situations, users receive alerts that they don't need to take action on, or that might lead them to take unnecessary actions. In many cases, responses to these unnecessary post-meal alerts include users starting to ignore them, setting higher alert thresholds (and thus preventing them from using appropriate thresholds as boundaries for their target range), or in some cases, even disabling their high-value alerts. This corrective approach may cause users to miss unexpected high blood glucose levels in the future.

[0010] Unnecessary repeat alerts are another example of the high-value alert problem. In this case, users are annoyed by receiving multiple high-value alerts for the same hyperglycemic event. This is usually caused by fluctuations in blood sugar levels above or below their high threshold. In some cases, users can activate a "snap timer," for example, for some degree of effectiveness. However, as with post-meal alerts, users do not want to be alerted again for the same high-value event before their set snooze timer. The solutions for these situations are similar to those described above, including ignoring the alert or disabling their high-value alerts, thus missing out on unexpected future hyperglycemic levels.

[0011] Another issue with "high-value alarms" involves missed doses. For example, if a user forgets to administer a meal, they will typically receive a high-value alarm. High-value alarms remind the user to administer the medication, but they are usually too late and cannot prevent further increases. Correction methods for missed doses include having the user set a lower high-value alarm threshold or setting an increase rate alarm. However, these correction methods may result in additional false alarms for the user. Furthermore, high-value alarms and increase rate alarms are sometimes ineffective or inaccurate enough to fail to deliver a missed dose.

[0012] Another issue with "high-value alerts" is that some users, such as those aiming for stricter blood sugar control, want to be alerted when their blood sugar levels are close to but below their high threshold for extended periods. These users may use their high-value alert threshold as the boundary of their target area, and in this case, the user may not know how to accurately set or change their high-value alert threshold.

[0013] Other high-value alarm issues include users not knowing how to respond to their initial alarm settings. Other high-value alarm issues will also be addressed.

[0014] Other issues exist with the use of "low-value alarms." For example, alarm fatigue, as mentioned above, can lead to distrust of the system. For instance, users might set higher low-value alarm thresholds to give themselves more time to prevent severe hypoglycemia events. However, this could result in more frequent alarms and the associated annoyance. For example, these users might receive numerous low-glycemia level alarms that don't actually lead to severe low values. While users might prefer more alerts for severe low values, frequent low-value alarms at higher thresholds can lead to distrust of the system.

[0015] Relatedly, false alarms caused by malfunctions such as squeezing can also lead to distrust of the system. In response to alarm fatigue, users sometimes set lower alarm thresholds, but therefore they have less time to prevent acute low values. As another corrective measure, users can disable low-value alarms and use rate-of-decline alarms or acute low-value alarms as alternatives. For example, a rate-of-decline alarm could be set to -2 or -3 mg / dL. Alternatively, users can disable their low-value alarms and rely on acute low-value alarms as a substitute. In many of these cases, the user's response does not prevent hypoglycemia.

[0016] Another issue, "low-value alerts," is similar to high-value alerts and essentially involves unwanted repeat alerts. That is, users are annoyed by receiving multiple low-value alerts for the same hypoglycemic event. In many cases, these unwanted repeat alerts are caused by their blood sugar levels fluctuating just around their low threshold. This can also occur when a user's blood sugar level is above 55 but still below their low threshold. Responding to unwanted repeat alerts, users sometimes begin to ignore the alerts, or may turn off their low-value alerts, or may over-treat their condition, for example, by accumulating carbohydrates (which is often a particular problem at night). However, this corrective approach can cause users to miss unexpected future hypoglycemic levels.

[0017] Other low-value alarm issues include users potentially setting their low-value alarm thresholds to the bottom boundary of their target range. Other low-value alarm issues will also be understood.

[0018] The prior art in this field addresses certain alarm issues in the following ways.

[0019] In one manner, as disclosed in U.S. Patent Publication No. US-2015 / 0289821, entitled "Glycemic Urgency Assessment and Alert Interface," filed March 16, 2015, an operable alert is provided based on a glycemic urgency index, which is a value that is more representative of a user's diabetes status than blood glucose values. Another disclosure, U.S. Patent Publication No. US-2014 / 0118138, entitled "Systems and Methods for Providing Sensitive and Special Alarms," ​​granted September 1, 2015, under U.S. Patent No. US9119528, discusses the occurrence of alarms that can be annoying to users, but involves corrective methods such as waiting for a specific period of time or delays in usage time. In another application, U.S. Patent Publication No. US-2015 / 0119655, filed October 28, 2014, entitled "Adaptive Interface for Continuous Monitoring Devices," the user interface is adapted based on certain inputs (e.g., target, population data, etc.). However, the adaptation of the alarm itself is not disclosed. In yet another application, U.S. Patent Publication No. US-2014 / 0012510, filed March 13, 2013, entitled "Systems and Methods for Leveraging Smartphone Features in Continuous Glucose Monitoring," disclosure is provided such that, for example, if the user is in a meeting, the alarm can be muted. This reference discloses the timing of changing the alarm, but only as part of a global setting, not based on real-time. In yet another application, USSN62 / 289825, filed on February 1, 2016, entitled “System and Method for Decision Support Using Lifestyle Factors,” feedback was provided to users for decision support purposes, such as informing users of things that would be helpful to them and their treatment.

[0020] All of the applications cited above are the property of the assignee of this application, and their entire contents are incorporated herein by reference.

[0021] This background information is provided to provide a brief overview of the invention and specific embodiments described below. This background information is not intended to help define the scope of the claimed subject matter, nor is it intended to be construed as limiting the claimed subject matter to embodiments that address any or all of the aforementioned drawbacks or problems. Summary of the Invention

[0022] Systems and methods based on this principle satisfy the aforementioned needs in several ways. Specifically, systems and methods based on this principle alert the user only when it is meaningful to do so, for example, when the system can predict or estimate that the user is unaware of their current condition, such as, in particular, a diabetic state requiring attention. Thus, the alert or alarm is personalized and particularly effective for that user. Such systems and methods still alert the user when action is necessary, such as a change in dosage or temporary basal rate, or to provide a response to a missed dose or the need for correction, but do not issue an alert when action is unnecessary, such as if it has been estimated or predicted that the user has become aware of a diabetic state requiring attention, or if corrective action has already been taken.

[0023] In a first aspect, a non-transitory computer-readable medium is provided, comprising instructions for causing a computing environment to perform a method of dynamically adjusting or regulating user alerts based on cognitive awareness determination, thereby providing data related to the treatment of a diabetes state requiring attention, the method comprising the steps of: (a) identifying a current or future diabetes state requiring attention, the identification being at least in part based on a blood glucose concentration value; (b) estimating or predicting a user's cognitive awareness of the identified current or future diabetes state requiring attention; (c) if the estimation or prediction results in the user not being aware of the identified current or future diabetes state requiring attention, alerting the user with a user prompt on a user interface of a monitoring device, the user prompt indicating a diabetes state requiring attention; and (d) thereby alerting the user to a diabetes state requiring attention only if the user is not aware of the diabetes state requiring attention and the notification is effective for the user.

[0024] The implementation of these aspects and embodiments may include one or more of the following. The alarm may be optimized for the patient's cognitive awareness, resulting in fewer alarms compared to alarms provided without considering the user's cognitive awareness. The monitoring device may be a smartphone, smartwatch, dedicated monitoring device, or tablet. In systems and methods according to this principle, excessive, repetitive, or harassing prompts are minimized or avoided. In systems and methods according to this principle, the user is able to develop trust that the system will only issue alarms when the notification is optimized or effective for the user. Estimating or predicting the user's cognitive awareness may include determining whether the identified current or future diabetes state requiring attention includes atypical blood glucose trajectories. Atypical blood glucose trajectories may include atypical patterns or atypical blood glucose responses.

[0025] The estimation or prediction of the user's cognitive awareness may include determining whether the user has previously treated a similar identified diabetes condition requiring attention by taking actions without user prompting. These actions may include medication administration, meals, or exercise. The estimation or prediction of the user's cognitive awareness may include determining whether the user has entered meal or dosage data, or whether a dosage calculation has been requested. The estimation or prediction of the user's cognitive awareness may include determining whether the user's behavior is consistent with their cognitive awareness. The estimation or prediction of the user's cognitive awareness may include receiving user input and making the estimation or prediction at least in part based on the received input. The estimation or prediction of the user's cognitive awareness may include analyzing historical data of the user's blood glucose levels relative to time.

[0026] The steps of identifying and estimating or predicting are repeated until it is estimated or predicted that the user is unaware of the identified diabetes state requiring attention, and then the step of alerting the user with a user prompt is performed. The estimation or prediction of the user's awareness may include receiving data from the application or website via an appropriate API. The estimation or prediction may be based at least in part on location data, i.e., GPS data. The location data may be the user's location data or the location data of the user's followers.

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

[0028] The estimation or prediction of the user's cognitive awareness may include identifying one or more individualized patterns associated with the user. These individualized patterns may correspond to the envelope of an analyte concentration signal trajectory that occurs before or after an event. The event may be associated with eating, exercise, or sleep. The determination may involve the user being unaware of whether the current signal trajectory falls outside the envelope of the analyte concentration signal trajectory.

[0029] The method may further include indicating a confidence level associated with the user prompt. If the estimation or prediction results in the user not recognizing a diabetic state requiring attention, the method may further include immediately displaying the user prompt. The estimation or prediction may further be based on the user's location information, wherein the location information indicates that the user is within a predetermined threshold range of a food store or restaurant. If the estimation or prediction results in the user not recognizing a diabetic state requiring attention, the method may further include alerting the user with a user prompt after a time delay, the duration of which is based on at least the identified diabetic state requiring attention and the blood glucose concentration value and / or rate of change of blood glucose concentration value.

[0030] The user prompt may include an inquiry about user-input data. The inquiry may request data from the user regarding medication, meals, or exercise. If the user ignores the user prompt determined by data from the user interface or from an accelerometer associated with the monitoring device, and if the user prompt does not correspond to a dangerous situation, the method may further include storing information about the user ignoring the user prompt in a previous situation and using the stored information as part of subsequent estimation or prediction steps.

[0031] Identifying current or future diabetes states requiring attention may include determining clinical values ​​of blood glucose concentration and / or rates of change of blood glucose and / or glycemic urgency index values. Identifying current or future diabetes states requiring attention may include measuring a blood glucose signal signature and comparing the measured signature with signatures in multiple bins, and classifying the diabetes state requiring attention into one of the bins based on the comparison. Identifying current or future diabetes states requiring attention may include determining one or more time-based trends in blood glucose concentration values ​​and basing the identified state on the determined trend. The trend may correspond to whether the blood glucose concentration value fluctuates within a range or is rising or falling, where fluctuation corresponds to remaining within a predetermined range for a period of more than 5 minutes, 10 minutes, 15 minutes, or 30 minutes. Fuzzy boundaries may be used to define the range.

[0032] The method may further include transmitting an indication of a diabetic state requiring attention to a medication pump. If the estimation or prediction results in the user not recognizing the diabetic state requiring attention, the method may further include activating the medication pump to deliver a medication dose. The medication dose may be a mealtime dose of insulin. If the estimation or prediction results in the user not recognizing the diabetic state requiring attention, the method may further include activating the medication pump to change the basal rate. The medication may be insulin. The method may further include determining whether the medication pump can fully or partially treat the diabetic state requiring attention, and, compared to a case where the medication pump cannot treat the diabetic state, either not alerting the user or changing the user prompt, respectively. If the estimation or prediction results in the user not recognizing the diabetic state requiring attention, the method may further include determining when to alert the user with a user prompt. If displayed, the user prompt may include a color or arrow in place of or as a supplement to the blood glucose concentration value. If displayed, the user prompt may include a prediction of the blood glucose concentration value. If displayed, the user prompt may include an audible indicator, wherein the volume of the audible indicator is automatically adjusted relative to ambient noise measured by a monitoring device or a device communicating with the monitoring device. This adjustment relative to ambient noise may include increasing the volume of the audible indicator relative to the ambient noise until a signal-to-noise ratio threshold level is reached. The user prompt may relate to a diabetic condition requiring attention that occurs during a period when the user's glycemic urgency index is low.

[0033] If the estimation or prediction results in the user not recognizing the diabetic state requiring attention, the method may further include alerting the user with a user prompt after a delay, the delay being based not on duration but on the identified diabetic state requiring attention and blood glucose concentration values ​​and / or rates of change in blood glucose concentration values. If the estimation or prediction results in the user not recognizing the diabetic state requiring attention, the method may further include alerting the user with a user prompt after a delay, the delay being based not on duration but on individualized patterns learned by the monitoring device.

[0034] The identified diabetes status requiring attention may correspond to atypical blood glucose responses or atypical patterns, wherein the atypical response or atypical pattern is learned by the monitoring device rather than through user input. User prompts may be displayed dynamically in a pre-designed user interface, rather than on an adaptive user interface. If the estimation or prediction results in the user not recognizing the diabetes status requiring attention, the method may further include immediately alerting the user with a user prompt, regardless of any indication to alert the user without using user prompts received from other monitoring device applications. The estimation or prediction of whether the user recognizes the diabetes status requiring attention may be based at least in part on real-time data and not entirely on retrospective data.

[0035] In a second aspect, a system is provided for providing intelligent alerts corresponding to diabetic states requiring user attention, comprising: a CGM application running on a mobile device, the CGM application being configured to receive data from sensors at least periodically or occasionally and to calibrate and display blood glucose concentration data in clinical units; and an intelligent alert application running as a subroutine within the CGM application or as a parallel process of the CGM application on the mobile device and receiving data from the CGM application, the intelligent alert application being configured to perform a method contained in the media according to claim 1.

[0036] In a third aspect, a non-transitory computer-readable medium is provided, comprising instructions for enabling a computing environment to perform a method of safely reducing alerts to a user regarding a diabetes condition requiring attention, the method comprising the steps of: (a) identifying a current or future diabetes condition requiring attention, the identification being at least in part based on a blood glucose concentration value; (b) determining whether the identified diabetes condition requiring attention is atypical for the user; (c) if the determination results in the identified diabetes condition being atypical for the user, alerting the user with a user prompt on a user interface of a monitoring device, the user prompt indicating the diabetes condition requiring attention; and (d) thereby notifying the user of a diabetes condition requiring attention only when the identified diabetes condition is atypical for the user.

[0037] The implementation of these aspects and embodiments may include one or more of the following. Determining whether the identified diabetes state requiring attention is atypical for the user may include determining whether the identified diabetes state includes a blood glucose trajectory that follows a typical pattern not associated with the user.

[0038] In a fourth aspect, a non-transitory computer-readable medium is provided, comprising instructions for causing a computing environment to execute a method of prompting a user about a diabetes state requiring attention, the computing environment being in signal communication with a drug delivery device, the user prompt being optimized for user effectiveness at least in part by reducing its quantity, the user prompt providing data related to the treatment of the diabetes state requiring attention, the method comprising the steps of: (a) identifying a current or future diabetes state requiring attention, the identification being at least in part based on a blood glucose concentration value; (b) performing a first estimation or prediction of the user's awareness of the identified current or future diabetes state requiring attention; (c) if the... If the result of the first estimation or prediction is that the user is unaware of the identified current or future diabetes status requiring attention, then a second estimation or prediction is performed on the computer awareness of the drug delivery device regarding the identified current or future diabetes status requiring attention; (d) if the result of the second estimation or prediction is that the drug delivery device is unaware of the identified current or future diabetes status requiring attention, then an alert is given to the user on the user interface of the monitoring device using a user prompt indicating the diabetes status requiring attention; (e) thus, the user is notified of the diabetes status requiring attention only if neither the user nor the drug delivery device is aware of the diabetes status requiring attention and the notification is effective for the user.

[0039] Implementation of these aspects and embodiments may include one or more of the following. The method may further include the step of determining whether the drug delivery device is capable of treating the identified current or future diabetes state requiring attention, and if the determination results in the drug delivery device being unable to treat the identified diabetes state, alerting the user with a user prompt. The current or future diabetes state may include hypoglycemia, the drug delivery device may be an insulin delivery device, and the method may further include shutting down or reducing the activity of the insulin delivery device based on the diabetes state of hypoglycemia. The shutting down or reducing activity may occur earlier if the user is unaware of the hypoglycemia. The execution of the first estimation or prediction may be based at least in part on user interaction with the drug delivery device.

[0040] In other aspects and embodiments, the above-described method features of each aspect are described in relation to the system in each aspect. Any feature of an embodiment of any aspect (including, but not limited to, any embodiment of any of the first to fourth aspects mentioned above) applies to all other aspects and embodiments identified herein, including, but not limited to, any embodiment of any of the first to fourth aspects mentioned above. Furthermore, any feature of an embodiment of each aspect (including, but not limited to, any embodiment of any of the first to fourth aspects mentioned above) may be combined independently, in part or in whole, with other embodiments described herein in any manner; for example, one, two, or three or more embodiments may be combined in whole or in part. Furthermore, any feature of an embodiment of each aspect (including, but not limited to, any embodiment of any of the first to fourth aspects mentioned above) may be optional for other aspects or embodiments. Any aspect or embodiment of the method may be performed by a system or apparatus of another aspect or embodiment, and any aspect or embodiment of the system or apparatus may be configured to perform the method of another aspect or embodiment, including, but not limited to, any embodiment of any of the first to fourth aspects mentioned above.

[0041] People with diabetes face numerous challenges in controlling their blood sugar due to the complex interactions between food, insulin, exercise, stress, activity, and other physiological and environmental conditions. Established blood sugar management principles are sometimes insufficient because different conditions affect different individuals in vastly different ways, and what actions might be effective for them can vary significantly. Furthermore, as mentioned above, even providing alerts or warnings is problematic because different situations require different actions from individual to individual. Therefore, providing users with customized alerts and warnings, as well as anticipating situations that users may not be aware of, is both beneficial and highly necessary.

[0042] Accordingly, systems and methods based on this principle provide techniques for alerting and / or issuing warnings to users related to diabetic conditions or states that require their attention, typically only when the system can determine (e.g., estimate or predict) that the user has not yet recognized the condition. Therefore, such systems and methods based on this principle reduce the uncertainty commonly associated with diabetes and improve quality of life.

[0043] In some aspects or embodiments, advantages may include one or more of the following: Providing “smart alerts” to advantageously notify the user of a diabetic state requiring attention, particularly when the user is unaware of their diabetic state. Therefore, such smart alerts do not annoy the user because they only occur when needed and do not occur when unnecessary; for example, the smart alert function will not alert the user if they administer the appropriate amount of insulin at the appropriate time relative to a meal. Such smart alerts are more effective at alerting the user to danger or emergency situations than prior art alerts, providing greater reassurance and certainty. Such “smart” alerts further avoid the problem of alert fatigue. In particular, threshold-based alerting algorithms often cause alert fatigue because CGM applications running on smartphones previously could not quantify the user's cognitive state. The embodiments described herein infer cognitive state data by converting physiological and non-physiological data into estimates or predictions of the user's cognitive state, thereby providing smarter alerts and reduced alert fatigue. Other advantages will be understood from the following description, including the accompanying drawings and claims.

[0044] This synopsis aims to present some concepts in a simplified form. These concepts will be further described in the Detailed Description section. Elements or steps other than those described in this synopsis are possible and not necessarily required. This synopsis is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to embodiments that address any or all of the shortcomings mentioned in any part of this disclosure. Attached Figure Description

[0045] This embodiment will now be discussed in detail by emphasizing its advantageous features. These embodiments depict novel and non-obvious systems and methods according to this principle, as illustrated in the accompanying drawings, which are for illustrative purposes only. These drawings include the following figures, in which the same numerals denote the same parts:

[0046] Figure 1 This is a schematic diagram of a system based on this principle.

[0047] Figure 2 This is a flowchart of the first method based on this principle.

[0048] Figure 3This illustration shows the scenarios in which a smart alarm application based on this principle can be run or instantiated.

[0049] Figure 4 This is a flowchart of the second method based on this principle.

[0050] Figure 5 It is a logic diagram of the inputs to intelligent alarm functions or applications and the resulting intelligent alarm outputs.

[0051] Figure 6 This is a flowchart of the third method based on this principle.

[0052] Figure 7 and Figure 8 Intelligent alarms are displayed. Figure 7 The blood glucose trajectory and intelligent alarms appear on it.

[0053] Figures 9 to 14 Other implementations of intelligent alarm output on the user interface based on this principle are shown.

[0054] Figures 15 to 17 Other embodiments of intelligent alarm output on the user interface based on this principle are shown.

[0055] Figures 18 to 21 Other implementations of the smart alarm are shown, along with the corresponding blood glucose trajectory map overlaid on the smart alarm.

[0056] Figures 22 to 29 The time progression of intelligent alarms based on this principle is shown.

[0057] Figures 30 to 41 An implementation of a smart alarm as part of the lock screen on a smartphone is shown.

[0058] Figure 42 This is a schematic diagram of a system incorporating data from a delivery device based on this principle.

[0059] Figure 43 This is a flowchart of the fourth method based on this principle.

[0060] Figure 44 This is a flowchart of the fifth method based on this principle.

[0061] Figure 45 This is a schematic diagram of a system based on this principle.

[0062] Figure 46 This is a more detailed schematic diagram of the sensor electronics module.

[0063] The same reference numerals always refer to the same elements. Unless otherwise stated, the elements are not to scale. Detailed Implementation

[0064] definition

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

[0066] As used herein, the term "analyte" generally refers to, but is not limited to, a substance or chemical component in a biological fluid (e.g., blood, interstitial fluid, cerebrospinal fluid, lymph, or urine) that can be analyzed. Analytes can include naturally occurring substances, artificial substances, metabolites, and / or reaction products. In some embodiments, the analyte measured by the sensor head, device, and method is glucose. However, other analytes are also contemplated, including but not limited to, non-carboxylated prothrombin; acylcarnitine; adenine phosphoribosyltransferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid components (arginine (Kreis cycle), histidine / uric acid, homocysteine, phenylalanine / tyrosine, tryptophan); androstenedione; antipyrine; arabinitol enantiomers; arginase; benzoyl stigmine (cocaine); biotinylate; biopterin; C-reactive protein; carnitine; carnosine; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-β Hydroxycholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporine A; d-penicillamine; deethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylation 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 hereditary Optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, sexual differentiation, 21-deoxycortisol; debutylhalogenated pantyltransferase; dihydropteridine reductase; diphtheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acid / acylglycine; free β-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free triiodothyronine (FT3); fumarate acetylacetase; galactose / gal-1-phosphate; galactose-1-phosphate uridine transferase; gentamicin; analyte 6-phosphate dehydrogenase; glutathione Glutathione; glutathione peroxidase; glycocholic acid; glycated hemoglobin; halogenated pantyltransferase; hemoglobin variants; aminohexosidase A; human erythrocyte carbonic anhydrase I; 17-α-hydroxyprogesterone; hypoxanthine phosphoribosyltransferase; immunoreactive trypsin; lactate; lead; lipoproteins ((a), B / A-1, β); lysozyme; mefloquine; netilmicin; phenobarbital; phenytoin; phytanoic acid / norphytanoic acid; progesterone; prolactin; proline peptidase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sisomicin; somatostatin C;Specific antibodies (adenovirus, antinuclear antibody, anti-ζ antibody, arbovirus, Oyezidzi virus, dengue virus, Draconis mesenae, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia lamblia, Helicobacter pylori, hepatitis B virus, herpes simplex virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, Leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, myoglobin, Onchocerciasis, parainfluenza virus, Plasmodium falciparum, poliovirus, Pseudomonas aeruginosa) Bacteria, respiratory syncytial virus, rickettsiae (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Trypanosoma japonicum / Ranger's trypanosome, vesicular stomatitis virus, Wucet's nematode, yellow fever virus); specific antigen (hepatitis B virus, HIV-1); succinylacetone; sulfadoxine; theophylline; thyroid-stimulating hormone (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; leukocytes; and zinc protoporphyrin. In some embodiments, naturally occurring salts, sugars, proteins, fats, vitamins, and hormones in blood or interstitial fluid may also be used as analytes. Analytes can be naturally present in biological fluids, such as metabolites, hormones, antigens, antibodies, etc. Alternatively, the analyte can be introduced into the body, such as contrast agents for imaging, radioactive isotopes, chemical reagents, synthetic blood or drugs or pharmaceutical compositions based on fluorocarbons, including but not limited to insulin; ethanol; cannabis products (cannabis, tetrahydrocannabinol, cannabinoid resin); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorinated hydrocarbons, hydrocarbons); cocaine (pyracocaine); stimulants (amphetamine, methamphetamine, methylphenidate, serod, benzylmethoxyphenamine, prestate, o-chlorophenoxyphenamine, terzolid). andrex); benzodiazepine; sedatives (barbiturates, methaqualone, tranquilizers such as diazepam, chlordiazepoxide, methaqualone, sedatives, dimethoprim, dichlorvos); hallucinogens (phencyclidine, lysergic acid, mescaline, peotene, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, oxycodone hydrochloride, compound oxycodone, hydrocodone antitussive, fentanyl, dalfool, analgesic, antidiarrheal); compound hallucinogens (fentanyl, meperidine, amphetamine, methamphetamine and analogues of phencyclidine, such as ecstasy); anabolic steroids; and nicotine. Metabolites of drugs and drug combinations are also expected analytes. It can also analyze analytes generated in the body (such as neurochemicals and other chemicals), such as ascorbic acid, uric acid, dopamine, norepinephrine, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), serotonin (5HT), and 5-hydroxyindoleacetic acid (FHIAA).

[0067] As used herein, the term "calibration" generally refers to, but is not limited to, the process of determining the relationship between sensor data and corresponding reference data, which can be used to convert sensor data into meaningful values ​​that are substantially equivalent to the reference data, whether or not the reference data is used in real time. In some embodiments, namely in continuous analyte sensors, calibration may be updated or recalibrated over time (in-plant, in real time and / or retrospectively) when the relationship between sensor data and reference data changes, for example due to changes in sensitivity, baseline, transport, metabolism, etc.

[0068] As used herein, the terms “calibration data” and “calibration data stream” generally refer to, but are not limited to, data that is transformed from its original state (e.g., digital or analog) to another state using functions (e.g., transformation functions) to provide meaningful values ​​to the user.

[0069] As used herein, the term "algorithm" generally refers to, but is not limited to, computational processes (e.g., programs) involved in transforming information from one state to another through computer processing. In the embodiments described herein, the algorithm may implement a decision support application / function that takes input from sensors, computer applications, or user input and converts it into output presented to a user on a user interface or to other devices.

[0070] As used in this article, the term "sensor" generally refers to, but is not limited to, a component or area of ​​a device that can quantify an analyte.

[0071] The term "glucose sensor" generally refers without limitation to any mechanism (e.g., enzymatic or non-enzymatic) that can quantify blood glucose. For example, some embodiments utilize membranes containing glucose oxidase, which catalyzes the conversion of oxygen and glucose into hydrogen peroxide and gluconate, as shown in the following chemical reaction:

[0072] Glucose + O2 → Gluconate + H2O2

[0073] Because for each glucose molecule metabolized, the co-reactant O2 and the product H2O2 change proportionally, electrodes can be used to monitor changes in current in the co-reactants or products to determine blood glucose concentration.

[0074] As used herein, the terms “operably connected” and “operably linked” generally refer to, but are not limited to, one or more components linked to another component(s) in a manner that allows signal transmission between the components. For example, one or more electrodes may be used to detect the amount of blood glucose in a sample and convert that information into a signal, such as an electrical or electromagnetic signal; said signal may then be transmitted to electronic circuitry. In this case, the electrodes are “operably linked” to the electronic circuitry. These terms are broad enough to include wireless connectivity.

[0075] As used herein, the term "variation" generally refers to, but is not limited to, changes or amounts of change starting from a data point, data line, or dataset. In one embodiment, for example based on a known physiological pattern, the estimated analyte value may have variations beyond values ​​representing multiple possibilities to include multiple estimated analyte values.

[0076] As used herein, the terms “physiological parameter” and “physiological boundary” generally refer to, but are not limited to, parameters obtained from consecutive studies of physiological data in humans and / or animals. Examples include, for instance, a maximum sustained rate of change of human blood glucose of approximately 4 to 5 mg / dL / min and approximately 0.1 to 0.2 mg / dL / min. 2 The maximum rate of change acceleration is considered a physiologically feasible limit; values ​​outside these limits are considered non-physiological. As another example, the rate of change in blood glucose is lowest at the maximum and minimum values ​​within the daily glucose range, which represent the areas of greatest risk to patients during treatment; therefore, a physiologically feasible rate of change can be set at the maximum and minimum values ​​based on continuous studies of glucose data. As a further example, it has been observed that the optimal solution for the shape of the curve along any point in the glucose signal data stream within a specific time period (e.g., approximately 20 to 30 minutes) is a straight line, which can be used to set physiological limits. These terms are broad enough to encompass physiological parameters of any analyte.

[0077] As used herein, the term "measured analyte value" generally refers to, but is not limited to, analyte values ​​or sets of analyte values ​​over a period of time during which analyte data has been measured by an 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.

[0078] As used in this paper, the term “estimated analytical value” generally refers to, but is not limited to, analytical values ​​or sets of analytical values ​​that have been derived from measured analytical values ​​using algorithms.

[0079] As used herein, the following abbreviations apply: Eq and Eqs (equivalent); mEq (milliequivalent); M (molar); mM (millimole); μM (micromolar); N (normal); mol (molar); mmol (millimole); μmol (micromolar); nmol (nanomolar); g (gram); mg (milligram); μg (microgram); Kg (kilogram); L (liter); mL (milliliters); dL (deciliters); μL (microliters); cm (centimeter); mm (millimeter); μm (micrometer); nm (nanometer); h and hr (hour); min. (minute); s and sec. (second); ℃ (degree Celsius).

[0080] As used herein, the phrase "continuous glucose sensor" generally refers to, but is not limited to, a device that continuously or persistently measures the concentration of blood glucose in bodily fluids (e.g., blood, plasma, interstitial fluid, etc.) at time intervals ranging from fractions of a second to, for example, 1, 2, or 5 minutes or longer.

[0081] As used herein, the phrase "continuous glucose sensing" or "continuous glucose monitoring" generally refers to, but is not limited to, the continuous or sustained monitoring of glucose concentrations in a host body fluid (e.g., blood, serum, plasma, extracellular fluid, tears, etc.) at time intervals ranging from fractions of a second to, for example, 1, 2, or 5 minutes or longer. In one exemplary embodiment, the glucose concentration in the host extracellular fluid is measured every 1, 2, 5, 10, 20, 30, 40, 50, or 60 seconds.

[0082] As used herein, the term “substantially” generally refers to, but is not limited to, generally but not necessarily all, quantities that may include more than 50%, more than 60%, more than 70%, more than 80%, more than 90%, or more.

[0083] As used herein, the terms “processor” and “processor module” generally refer to, but are not limited to, computer systems, state machines, processors, etc., which are designed to use logic circuitry to perform arithmetic or logical operations in response to and process the basic instructions that drive the computer. In some embodiments, these terms may include ROM and / or associated RAM.

[0084] As used herein, the terms “decision support application” and “decision support application / function” generally refer to, but are not limited to, algorithms that use sensor data and / or other data (e.g., user input data, exported data, or data from other applications or sensors) to provide user prompts on a display and / or to give commands to mechanical devices.

[0085] The term "dissimilar" as used herein generally refers to, but is not limited to, parameters and / or variables that are independent and do not depend on other parameters and / or variables. Conversely, the term "correlated" as used herein generally refers to, but is not limited to, parameters and / or variables that are dependent on each other in some way or can be derived from each other. 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 would be considered dissimilar. However, it is noted here that multiple parameters used in decision support applications / functions may relate to a single action or event, for example, the timing and duration of a movement. The term "independent" is used in the same way as "dissimilar," and similarly, "dependent" is used in the same way as "correlated," although "independent" can also refer to a variable used in a function where the function's output is a "dependent" variable whose dependence is based on the underlying independent variables.

[0086] As used in this article, the term "insulin sensitivity" generally refers to, but is not limited to, the relationship between how much insulin is needed to deposit a given amount of glucose. This is a physiological measure that everyone possesses and is not limited to diabetes. It can vary throughout a person's day, for example, and may be determined by hormones, activity, and diet. It can also change further throughout a person's life and may be determined by factors such as disease, weight, obesity, etc. It is a general measure, similar to measures like weight, blood pressure, heart rate, etc. There are healthy and unhealthy ranges for insulin sensitivity. In diabetes management, users should generally be aware of their insulin sensitivity factor (ISF) when making dosage decisions. The term ISF is sometimes used interchangeably with "correction factor" (CF). For example, a typical calculation a user might need to perform could be something like, "If my blood sugar is too high (100 mg / dL higher), how many units of insulin do I need to correct the high value and lower my blood sugar by that 100 mg / dL?" Many users use the default CF of 1:50, which means that one unit of insulin will lower blood sugar by 50 mg / dL. The determination of insulin sensitivity, as well as other types of sensitivity, is discussed in more detail below. However, it will be noted here that an understanding of insulin sensitivity can be based on, for example, real-time analysis of data from CGM, activity monitors, and insulin pumps, as well as data from retrospective analyses of these sensors and data from, for example, electronic health records. Other factors that may affect insulin sensitivity or ISF may include correlation with time of day, pain, and / or exercise; heart rate variability, stroke volume, and other cardiovascular health issues related to metabolic problems; the ability to dispense insulin; temperature; insulin type, based on insulin sensitivity measurements, distribution maps, peak values, and time between peak values; atmospheric pressure (therefore, "flight mode" may be an input); any activity that has the greatest impact on the patient or user; and so on.

[0087] As used in this article, the term "insulin resistance" generally refers to, but is not limited to, a medical condition in which cells in the body are unable to properly utilize insulin for the normal process of transporting glucose or other metabolites from the bloodstream. Insulin resistance reduces insulin sensitivity. While everyone has insulin sensitivity, only some people suffer from insulin resistance.

[0088] The term "lifestyle factor" generally refers to, but is not limited to, quantitative or qualitative (but somehow quantifiable) parameters that are not typically measured directly by physiological sensors but are relevant to disease management. In some cases, it relates to trends or recurrences, however small, which, according to the systems and methods of this principle, can be identified and used to provide treatment cues or changes to treatment cues given to the user. However, trend information does not necessarily need to correspond to a pattern, although some patterns will be equivalent to trend information. In some implementations, lifestyle factors may be equivalent to relevant parameters discussed elsewhere. Lifestyle factors (also known as "lifestyle background") may relate to certain physiological quantities, such as insulin sensitivity, but may also relate to more external parameters, such as sleep sensitivity, meal sensitivity, exercise sensitivity, and so on. In other words, lifestyle factors can generally be determined quantitatively, but in most cases are not directly measured by sensors.

[0089] The terms "state" and "state model" generally refer to, but are not limited to, data structures used to model patients for purposes such as decision support or intelligent alerting. Typically, a patient's state model envisions the patient as having one of multiple states, dependent on various lifestyle and clinical factors. As a concrete example, a patient's state might correspond to their current insulin sensitivity distribution. Multiple states or state models can then be combined with real-time inputs (e.g., time, schedule, CGM blood glucose levels, rate of change, etc.) to provide treatment cues to the user in support of treatment decisions. In one implementation, multiple diabetes decision states are defined by one or more highly relevant parameters, which can be lifestyle parameters and can be selected by the user through a user interface or learned over time via machine learning and / or cloud analytics.

[0090] The term "diabetic state requiring attention" generally refers to a biological state in a diabetic patient that requires action. For example, symptoms of hypoglycemia or hyperglycemia are examples of a diabetic state requiring attention. A user is also considered to be in a diabetic state requiring attention when such a state is about to occur or is likely to occur but has not yet occurred. Diabetic states requiring attention may vary in urgency, but generally refer to user conditions where action is estimable or determinable and beneficial to the user, typically leading the user towards a normal blood glucose level or towards the center of the target range for blood glucose values, such as the target range corresponding to normal blood glucose.

[0091] The exemplary embodiments disclosed herein relate to the use of a blood glucose sensor for measuring blood glucose or indicating the concentration of another analyte or the concentration of a substance present. In some embodiments, the blood glucose sensor is a continuous device, such as a subcutaneous, transdermal, percutaneous, non-invasive, intraocular, and / or intravascular (e.g., intravenous) device. In some embodiments, the device can analyze multiple intermittent blood samples. The blood glucose sensor can use any blood glucose measurement method, including enzymatic, chemical, physical, electrochemical, optical, photochemical, fluorescence-based, spectrophotometric, spectroscopic (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), optical rotation, calorimetry, iontophoresis, radiometric methods, etc.

[0092] Blood glucose sensors can use any known detection method, including invasive, minimally invasive, and non-invasive sensing technologies, to provide a data stream indicating the concentration of the analyte in the body. 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.

[0093] While most of the description and examples are directed to glucose sensors capable of measuring blood glucose concentration in a body, the systems and methods of the embodiments can be applied to any measurable analyte. Some exemplary embodiments described below use implantable glucose sensors. However, it should be understood that the apparatus and methods described herein can be applied to any device capable of detecting analyte concentration and providing an output signal representing the analyte concentration.

[0094] In some embodiments, the analyte sensor is an implantable glucose sensor, as described with reference to U.S. Patent 6,001,067 and U.S. Patent Publication US-2011 / 0027127. In some embodiments, the analyte sensor is a transcutaneous glucose sensor, as described with reference to U.S. Patent Publication US-2006-0020187-A1. In other embodiments, the analyte sensor is a dual-electrode analyte sensor, as described with reference to U.S. Patent Publication US-2009 / 0137887-A1. In still other embodiments, the sensor is configured to be implanted in a host blood vessel or externally, as described in U.S. Patent Publication US-2007 / 0027385-A1. The entire contents of these patents and disclosures are incorporated herein by reference.

[0095] The following description and examples illustrate this embodiment with reference to the accompanying drawings. In the drawings, reference numerals indicate elements of this embodiment. These reference numerals will be reproduced below in conjunction with a discussion of the corresponding features of the drawings.

[0096] The systems and methods based on this principle provide ways to integrate "intelligent alerts" into analyte monitoring systems, particularly into continuous glucose monitoring systems. In one implementation, the intelligent alert can be provided by its own application or algorithm, which typically operates in conjunction with the CGM application. In another implementation, the intelligent alert can be implemented through additional programming / instructions added to an existing application (e.g., the CGM application). Therefore, in this specification, the provided intelligent alert is generally referred to as an intelligent alert application / function.

[0097] Figure 1 Some exemplary aspects are illustrated in the figure. In this figure, system 50 is shown, in which patient 102 wears sensor 10, and the sensor uses sensor electronics 12 to transmit measurement results. The sensor electronics can transmit data corresponding to analyte measurement results 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 computer, insulin delivery device, or other computing environment). Current measurement data, historical data, analyses, etc., can be transmitted to server 115 and / or follower device 114'. This data can also be transmitted to healthcare professional (HCP) device 117. More detailed aspects of the sensor itself and the sensor electronics are described below. Figure 45 and Figure 46 Describe it.

[0098] Reference Figure 2Flowchart 101 illustrates a method according to this principle for implementing a smart alarm function within an analyte monitoring system (e.g., within a continuous glucose monitor). The first step is to determine whether the user is in a desired or needing-to-be-monitored diabetic state (step 13). In most embodiments, this step is typically performed such that if the diabetic state does not require attention, a smart alarm is not issued (step 11). However, as mentioned above, even if the user is in a diabetic state requiring attention, an alarm is not always issued.

[0099] Specifically, the system estimates or predicts whether the user is aware of a diabetic state requiring attention using various data, which may be past and / or real-time data, and may come from sensors and / or other measuring devices (step 17). If the estimation or prediction indicates that the user is aware of the condition, it is determined again that no alarm will be issued (step 11). However, if the estimation or prediction indicates that the user is not aware of the condition, an intelligent alarm may be provided (step 19).

[0100] Typically, estimations or predictions will be performed automatically and will be based on stored data or currently received or determined data. While various types of input data will be described below, it is noted here that such data can involve data with pattern signatures (if the user has experienced the pattern multiple times before, it can be assumed they are aware of it), behavioral data, historical data (including the use of retrospective analysis in some implementations), and so on. The result of the estimation or prediction can be a binary yes / no condition, but in many other cases it will have the nature of a quantitative estimation or prediction, such as having a percentage probability that the user is aware of. Of course, this can be translated into a yes / no response by comparing the percentage to a single threshold. However, in various other cases, especially those involving multiple thresholds, a variety of different responses may arise depending on the value of the percentage probability.

[0101] Other alternative implementations may include the use of user input. For example, users may influence the operation of the smart alert function by using sliders, radio buttons, or other user interface mechanisms. Users may also influence the sensitivity of the function, depending on their needs for alerts and notifications. Users can further influence the content of alerts by selecting which information they wish to see when one or more types of alerts / events occur. Through appropriate selections, users can influence the operation, timing, and display of smart alerts.

[0102] Now, let's describe the details of the above functions.

[0103] Reference Figure 3The intelligent alarm function can operate as an auxiliary application 25, running alongside the primary analyte monitoring application (e.g., the primary CGM application) on the intelligent device 18, or it can be provided as a function within the CGM application (or another application) running on the intelligent device 18. In either case, other functions can be implemented as part of such an auxiliary application or function. As an auxiliary application implementation running alongside the primary monitoring application, additional or subsequent updates can be tested without affecting the functionality of the primary CGM application. Typically, the intelligent alarm function provides technical improvements to the operation of the monitoring application because fewer alarms are usually required, resulting in lower computational costs, battery savings, etc. Additionally, the device itself possesses technical capabilities related to data lacking in existing systems (e.g., data on the user's awareness of their diabetes status).

[0104] Next, refer to Figure 4 Figure 200 provides further details for step 17, which involves the system using machine learning and stored and / or real-time data to determine whether the user is aware of a diabetes state requiring attention. As described above, in some implementations, this step can potentially be considered equivalent to the machine or system learning to predict or estimate the user's awareness of a diabetes state requiring attention (step 22). That is, the system determines the metrics used in machine learning and also uses the metrics in real time to obtain or determine data that is compared in some way with other data (e.g., with a threshold) to provide a prediction or estimate of the user's awareness, which is then used to determine to provide intelligent alerts.

[0105] One way the system can determine such a metric that allows prediction or estimation of a user's awareness of this diabetic state is by determining whether the data regarding the diabetic state (or, in other words, the physiological blood glucose response experienced) is typical of data the user has previously seen and / or experienced (step 24). If machine learning has learned typical data about the user, and if the acquired or determined metric indicates that the current real-time data is similar to such typical data, then in many cases an alert is not required because the system determines that the user is likely already aware of it, i.e., the estimate or prediction is highly likely to make the user aware of the diabetic state that requires attention. This similarity in the data can be determined in a variety of ways, including determining whether the current real-time blood glucose trajectory has a feature signature similar to a previously determined feature signature, such as duration, rise time, width, FWHM, etc. Conversely, if the physiological response is atypical for the user, the quantitative probability that the user has such awareness is correspondingly reduced, and in this case, a smart alert can be generated based on the reduced quantitative probability of the data. The smart alert results in the presentation of an indication of the diabetic state requiring attention on a screen or display, where it should be understood that this presentation 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 blood glucose measurements over time. If the series of blood glucose measurements is similar to, for example, a previous series of blood glucose measurements encountered within the same or similar time period, such that the quantitative similarity is greater than a predetermined threshold, this similarity increases the likelihood that the user will become aware of a diabetic state that requires attention.

[0106] In one particular implementation, it can be determined whether the physiological response is part of a user's established pattern (step 26). Here, the term "pattern" is used to refer to a recurring data arrangement identified in received data, such as the occurrence of an "overnight low" that a user typically experiences in blood glucose monitoring. If the physiological response is part of a pattern previously encountered by the user, the estimate or prediction of the likelihood of the user's perception may be higher again, or may be elevated or increased in more precise quantification and / or more granular calculations. 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 the pattern. Identification of an established pattern may include the following steps, which typically involve a series of measured blood glucose values ​​over time. The identification may include: quantifying the similarity in received data over two or more time periods, and identifying the similarity as an established pattern if the quantified similarity is greater than a predetermined threshold criterion. Typical identified patterns may include overnight low, postprandial high, postprandial low, time-period high, time-period low, weekend / weekday high / low, post-event high / low, and best day. If these identified patterns occur in a given patient, the intelligent alerting function may be configured not to alert the patient because the likelihood of cognitive awareness is high. It should be further noted that in many cases, the event precedes the physiological response, and such events can be detected and identified as shared with and / or preceding recurring data arrangements corresponding to the detected pattern, e.g., already present in two or more data arrangements, in half of the data arrangements, in 75% of the data arrangements, etc. In this sense, the term "shared with" is used to indicate that the corresponding pattern is present in more than one data arrangement and is not necessarily shared with the user. The incidence of the event can be measured by reference to a predetermined rate or percentage, e.g., appearing in at least 25%, 50%, 75%, 90%, 95%, 99%, etc., of the corresponding pattern data arrangements. If the alert is based on the occurrence of the event, and if the alert includes the event description as a cause, the intelligent alerting function can be further configured to suppress or not suppress alerts for a particular event, as it may be possible to estimate or predict again that the user is aware of the event.

[0107] In one specific implementation, it should be noted that past systems predicted alarms based on the passing of a threshold blood glucose alarm before the alarm sounded when the user was out of range. Predictive algorithms have been used to develop predictive data, which is then compared to a threshold to provide users with an early warning that they are out of range. However, in both cases, the system issues an alarm until some degree of current or anticipated blood glucose deviation occurs.

[0108] However, in systems and methods based on this principle, past data, as well as current real-time data corresponding to blood glucose responses to events such as exercise or meals, can be utilized via machine learning to identify typical user responses. When a user exhibits a typical response, the system may suppress alarm issuance, or the system may never generate an alarm.

[0109] However, when the system or method identifies that the current blood glucose trajectory is not typical compared to previous blood glucose trajectories, i.e., when the user has an atypical response, it alerts the user to take appropriate action. For example, it might be determined that the user had an atypical response at lunchtime, i.e., a high value of 160 to 220 mg / dL within 1 hour, rising by 2 mg / dL. If the smart alarm function identifies an atypical response, for example, showing a blood glucose trajectory that rises by 3 mg / dL or reaches a range above 160 mg / dL within 30 minutes, the system can make the smart alarm based on the atypical trajectory, resulting in an indication of a smart alarm being presented on the screen or display, alerting the user to the potential hyperglycemia. Importantly, this notification is not only based on a blood glucose trajectory through thresholds or predicted blood glucose values ​​as in existing systems, but also on the fact that the blood glucose response is atypical or abnormal and therefore likely to lead to a unique hyperglycemia level after that particular lunch. In this way, the smart alarm function operates in a unique and very different way compared to existing systems.

[0110] A particular benefit of this implementation is that users are not merely notified that their blood sugar levels are out of range or will soon be out of range, but are also informed that their blood sugar response is atypical for them. In other words, based on determined or obtained data, unique and customized intelligent alert notifications are displayed on the user interface shown on a display or screen, displaying types of data that have not been previously displayed or even calculated. This notification allows users to take additional precautions (unknown using the technology of existing systems) to manage and handle this more unique situation.

[0111] Next, refer to Figure 5In flowchart 250, the intelligent alarm function 28 can be implemented by appropriate subroutines or modules and can operate with or be provided within the monitoring application, accepting various types of input data 30 and generating intelligent alarms 32 in response to the input data. In doing so, the intelligent alarm function or module can perform relatively continuous estimation. That is, the application typically does not simply delay the provision of alarms by a predetermined time to make them more convenient for the user. Instead, the application continuously estimates the data input 30 and determines when and whether to generate an alarm based on said data or other data. For example, if the system and method know that a particular user typically experiences a "post-lunch hyperglycemia" (postprandial hyperglycemia) 45 minutes after a meal, then no alarm will be generated as long as the actually observed blood glucose trajectory (indicating hyperglycemia) matches this pattern or typical user response. If a physiological response becomes inconsistent with a pattern or typical user response—for example, if the measurement and calibration data trajectory from a blood glucose sensor differs significantly from typical blood glucose data trajectories, such as exceeding a predetermined threshold—thus making the response atypical, the system will estimate or predict that the user is unaware of it and will generate a smart alarm, displaying an indication on the screen or monitor. In determining whether (or when) to generate a smart alarm, individualized or personalized user information / data is typically used, particularly when it is transformed into data that can be used to estimate or predict user awareness. This data can then be used to determine the timing, manner, content, format, etc., of the alarm. Typically, the generation of smart alarms and / or their content or other characteristics are personalized or dynamically adapted or adjusted for the user.

[0112] The various inputs are described below, and they may include received signals such as those measured by signal measurement, calibration data, data from the user interface of the monitoring device (including dedicated devices and smartphones / watches), such as data on keystrokes, taps, interaction frequency, applications used, etc. It should be noted here that the mechanism for estimating or predicting cognitive awareness, i.e., how to execute intelligent alert functions, can typically include a comparison with a standard (step 34). For example, the standard may include known patterns, and when determining whether a physiological response is typical, a blood glucose trajectory (e.g., a physiological response corresponding to a diabetic state requiring attention) can be compared with a known pattern (standard). Similarity can be measured, for example, by shape, rate of ascent / time, duration, time of day, number of days in a week, etc.

[0113] enter

[0114] Analyte concentration

[0115] Various metrics can be employed in the development of suitable algorithms to operate this intelligent alerting function. These metrics, individually or in combination, indicate the derived estimates or predictions of cognitive awareness of diabetic states requiring attention. In some cases, these metrics are transformed into estimated or predicted data, and in others, algorithms are used to derive these estimates or predictions. These metrics include rates of change, time to reach threshold blood glucose levels (e.g., how quickly blood glucose changes in the first 20 mg / dL), platelet insulin, and so on. The primary driver in intelligent alerting is real-time analyte concentration values, such as blood glucose values ​​measured by a blood glucose sensor, and the rate of change of blood glucose derived from those sensor measurements. However, other physiological quantities can also be used. In some cases, data reception / calibration / display is performed by a single physical device, while in others, multiple devices can be used, and in such cases, data can be transferred from one device to another as needed according to an appropriate data transmission protocol.

[0116] In addition to the measured quantity or the quantity derived from blood glucose sensor data, another quantity that can be used is the Glycemic Urgency Index, as described in U.S. Patent Publication No. US-2014 / 0289821, filed March 16, 2015, entitled “Glycemic Urgency Assessment and Alert Interface,” the entire contents of which are the property of the assignee of this application and are incorporated herein by reference.

[0117] User input or behavior

[0118] User input or behavior collected from data inputs of systems based on this principle can also be used to estimate or predict cognitive awareness. For example, user behavior can indicate cognitive awareness because certain user behaviors are consistent with a user's self-management of a diabetic state that requires attention.

[0119] In one specific instance, machine learning, combined with system data used by the user interface, can be used to determine if a user responds to the first alert but rarely or never responds to subsequent alerts. Therefore, in this instance, the first alert can be made more prominent because future alerts are known to be ignored.

[0120] As determined by user interface usage data, user "clicks" or icon "activations" can be further used to determine cognitive awareness. For example, if blood glucose trajectory data indicates that a user has entered a diabetic state requiring attention, but if the user immediately begins to check their monitoring app, such as calculating dosages or rescuing carbohydrate amounts, this activity strongly indicates that the user is aware of their diabetic state—that is, a tendency to increase cognitive awareness in quantitative estimations or predictions. In this case, smart alerts may be suppressed or never generated.

[0121] Similarly, certain types of input data can be used in estimation or prediction algorithms. For example, if a user has a diabetic condition requiring attention (hypoglycemia), but the user inputs current meal data, the user-input data indicates awareness of the hypoglycemic state and thus suppresses or prevents the generation of smart alerts. In some cases, if it is a “closer call,” such calculations may involve converting the user-input data into carbohydrate data to determine whether the user intends to treat the low value or is simply eating without such awareness. This is applicable to inputting dosage data in response to hyperglycemia, etc. The (user-input) data used for dosage calculations can further indicate the user’s awareness, such as (user-input) data setting parameters of the user interface, such as manipulating or adjusting sliders. The value of the parameter itself (e.g., low aggression, moderate aggression, high aggression) can itself be used as a single input for smart alert functionality. Therefore, in these implementations, the relevant data includes: (1) data input into applications related to health and diabetes management, and (2) the value of the data itself.

[0122] The input of meal data can lead to other variations in processing, which may further affect the generation or suppression of intelligent alerts. In some implementations, these aspects serve as motivations for recording insulin and carbohydrates. For example, if a user records a significant amount of carbohydrates, the monitoring application can automatically increase the alert threshold level by a predetermined amount over a predetermined duration, such as automatically increasing the high alert level by 100 mg / dL over 2 hours. This "desensitizes" the high alert level during the postprandial peak. In other words, instead of making the alert based on a conscious awareness of a diabetic state requiring attention, this aspect modifies the system definition of a diabetic state requiring attention. In implementations, the amount by which the alert level increases can be configurable, for example from 0 to 200 mg / dL in 25 mg / dL increments, with a default level of 100 mg / dL. When the level increases to 0, this essentially disables the feature. The duration can be configurable, for example from 30 minutes to 3 hours in 15-minute increments, with a default time period of two hours. The threshold level for carbohydrates to begin this desensitization subroutine may vary, but it could be, for example, 2 or 3 carbohydrate units. It should be understood that this typically depends on the insulin / carbohydrate ratio. Parameters such as on-plate insulin and on-plate carbohydrates can be considered in the desensitization subroutine if known. The benefits of this desensitization subroutine include adding only one setup screen and eliminating the need for initial setup if default values ​​apply. If the user has a connected pump and insulin / carbohydrate ratio data is transmitted from the pump's dose calculator using an appropriate transmission protocol, the setup is automatic and requires no additional data input. Systems or machine learning can still be advantageously used for implementing this feature, as machine learning can be performed to determine when the user typically inputs meal data (relative to when the meal data is actually consumed), such as after carbohydrate consumption, before carbohydrate consumption, etc. This recording can be analyzed and used to suppress the generation of smart alarms, which may be unnecessary given the anticipated postprandial rise, when combined with blood glucose data indicating potential hypoglycemia.

[0123] Other relevant data may include user input, which could be data entered on a form or using multiple-choice or radio button input. For example, users might be asked to directly comment on the usefulness of a particular alert. Users can be prompted to confirm an alert by pressing a button selected from a convenient and easy-to-understand user interface. Buttons such as "Thank you" or "Go Away" can be provided. Such responses allow users to quickly confirm alerts but can still be transformed into very useful data for future calculations in smart alert functionality. For example, if an alert is provided two hours after a meal, but the user indicates that the alert is not helpful, the next iteration might alert the user 2.5 hours after the meal (and if other alert criteria are met). As another example, if it is explicitly stated that an alert is not helpful, it will not be repeated (i.e., defining the criteria for future smart alert determination). In cases where an alert is ignored, it may not be repeated if other data can be used to indicate the user's awareness of their diabetes status; in such cases, the alert may be determined to be intentionally ignored. If it is unclear whether the ignore was intentional, an alert may be repeated. The system and method can also determine data based on machine learning from intentional ignoring or user activation of an "ignore" button. For example, in the absence of a response or activation of the "ignore" button, the system and method may alert the user multiple times at 180 mg / dL (and rising). In this case, a monitoring application employing smart alert functionality can ask the user if they do not want this level of alerting, for example, if they do not want to be alerted again in similar situations. This data may then lead to a change in the way the smart alert is output, resulting in additional adjustments or personalization for the user. In other words, this data can then be incorporated into an algorithm that optimizes the generation of smart alerts by considering user interaction data (determined by user interface interaction) or other non-physiological data, as well as physiological data. This algorithm can operate on smartphone-type devices and other devices, such as smartwatches.

[0124] Other relevant user input data may include event data, such as if the user is about to perform or participate in an event that may affect their blood sugar levels. For example, if a user is planning to exercise, such as a long workout, and knows their blood sugar will be above the normal range, they can activate a setting on their monitor, for example, by clicking a button on their smartphone, to activate a special "workout" alert schedule. This workout alert schedule can provide different alert values ​​for the duration of the event. Other such events that may have special alert schedules could include meals, sleep, etc.

[0125] During the management of diabetes conditions requiring attention, such as during an event, after an event, etc., data related to user feedback can be received from the user interface at various times.

[0126] Prompts or other questions requesting user responses can be provided at various times to directly learn user cognitive awareness or learn "markers" indicating user cognitive awareness. More specifically, prompts or other requests for user interaction, particularly regarding input data, can be provided to collect specific, desired data—data identified as particularly useful in determining user cognition. This data can be specific to a single user or a group of users, such as a user base or a larger group. In other words, a system using machine learning can prompt users to input specific types of data so that the system receives data identified as particularly useful. This received or transmitted data pertains not only to the presence of user interaction but also to the actual content and value of that interaction.

[0127] In addition to using directly input user information, inferred user information can also be used for intelligent alarm functions. For example, it can be leveraged for user inaction. For instance, if a user is at 40 mg / dL and has not performed any action for an hour, alarms may become more frequent. This can be detected by firmware or software routines configured to measure the amount of time a user is within a dangerous or undesirable range and have keystroke or tap data from the user interface as additional input. As another example, if a user begins to view their display device with high interactivity, alarms can become more active, interactive, or aggressive because the system can know that at that point in time, the user is in a mode where they expect a significant amount of interaction and information. Similarly, data from the user interface can be used to measure a “significant” amount of user interaction relative to a “normal” or “typical” amount. For example, normal or typical amounts can be determined by user input data over time, such as the average number of times an application is opened per minute or hour, or the average number of taps. This number can be used as the basis for a threshold, and once more such taps are measured or detected, a “high-interaction” user mode can be defined and used. In other words, increased user interaction with the device can have a similar effect to a user moving a slider in the settings parameters to a more aggressive state. This automatic parameter setting may depend in part on the degree to which the user interaction indicates their level of awareness. User interaction may be unrelated to a diabetic state requiring attention, for example, if the user is replying to an email or watching a video. Therefore, user interactions can be differentiated, considering only those related to analyte monitoring, such as CGM, dose calculation, etc. Random, panicked interactions in this application may indicate a lack of awareness and a desire to interact. In some implementations, measurements of random, panicked interactions may consider accelerometer data, for example, during frantic device operation. A smart alarm will be generated in this case. On the other hand, user-focused interactions within what are considered "acceptable," "normal," or "typical" ranges, such as the careful and "typical" execution of dose calculations (particularly through a frequency of keystrokes or taps familiar to the user), indicate user awareness and therefore will not indicate the generation of a smart alarm. The complete absence of accelerometer signal changes may indicate that the user has fallen or fainted. In this scenario, if the alarm is not acknowledged or the inactivity continues, the smart alarm function can be configured to send an alarm to the attendant or other caregivers associated with the user. Typically, any user interaction that is determinable or measurable in real time from the user interface of a device running a health-related application can be used to determine when and / or whether the application is used to change the user interface, for example, to provide an alarm, particularly when used in conjunction with real-time blood glucose data. Such user interaction is defined not only as actions taken by the user on the user interface but also as actions not taken by the user.

[0128] Future smart alert features can be developed, generated, or refined using previous or historical user responses (physiological or via the user interface), such as to eliminate or reduce a user's "yo-yo" response. More specifically, these previous or historical user responses are typically represented in the form of some kind of data file, and the retrieval (e.g., transfer) and analysis of this stored data can be used to generate and refine smart alert features to determine which smart alerts in the past led to the desired physiological response (and conversely, what types of smart alerts led to the undesired physiological response). This analysis may include analyzing blood glucose trajectory data (and accompanying event data, if necessary) to determine the characteristics of desired and undesired responses, and then analyzing current physiological data to determine the presence of a current diabetic state requiring attention. If smart alerts are determined to be suitable for generation, the smart alert feature can enable the selection of smart alerts based on the types of smart alerts that have led to the desired physiological response in the past.

[0129] Pattern detection and use

[0130] Blood glucose patterns can be used to understand and help patients manage their diabetes, as well as how physicians manage their patients. Efforts have been made to identify patterns that highlight areas where users want or need to pay attention.

[0131] U.S. Patent Application No. 14 / 874188, filed October 2, 2015 (unpublished), entitled "Systems and methods for data analysis and visualization," and U.S. Patent Publication No. US-2013 / 0035575, filed August 3, 2012, entitled "Systems and methods for detecting glucose level data patterns," are the property of the assignee of this application, and their entire contents are incorporated herein by reference.

[0132] As mentioned above, pattern data can be used to determine a user's perception of their diabetes status because if a user exhibits a pattern of physiological response, it can be inferred that the user will recognize this pattern and take appropriate action when that physiological response recurs. In other words, a user can be considered to be able to recognize previously experienced patterns, thereby improving the estimation or prediction of the user's cognitive awareness. Furthermore, as mentioned above, the recurrence of a pattern can be determined by storing and analyzing previous data, particularly those identified as patterns (but not necessarily patterns), and comparing them with currently measured (occurring) blood glucose trajectories to determine whether the currently occurring blood glucose trajectory has similar curves or signature features to those previously identified.

[0133] One way to identify this pattern, or to detect blood glucose events that do not occur in a pattern, is by “binding” certain events defined by specific characteristics. That is, portions of a blood glucose trajectory that meet predefined criteria indicating certain diabetic problems (e.g., rebound hypoglycemia) can be detected, and patterns can then be looked for (or identified as not occurring in these binned patterns) within these already “binded” events.

[0134] To be more detailed, and refer to Figure 6 Flowchart 300 can identify or differentiate signatures or "fingerprints" in blood glucose sensor data within an individual patient based on some predefined criteria (step 36). Such criteria may include time-based criteria and / or may include specific incidental events detected within specific constraints. In this system, bins can be differentiated using different criteria, based on this principle. Supervised learning algorithms can be employed, which allow for the learning of more bins for individual specific patterns. For example, bins can be based on insulin data, the rate of change (or acceleration / deceleration) of blood glucose data, previously identified data patterns used to characterize the data (e.g., events occurring before a small meal), individual responses to their blood glucose information, and so on.

[0135] The next step is to characterize incidental events, for example, based on decay curves, waveform signatures, etc. (step 38). Exemplary incidental events based on insulin data could include meal dosage indicators, which could be categorized into small, medium, and large meal bins. This may be related to insulin data. Different meal types can also be characterized, and then sub-binned to fit into different meal compositions. These may be related to rates of change / acceleration / deceleration. Incidental events can also be characterized based on their correlation with pre-meal events, and these correspond to the data patterns described above. Incidental events can be further based on behavioral patterns, such as the frequency with which a user checks their blood glucose data or responds to alerts, and this can be related to the responsiveness data mentioned above. It should be understood that other binning methods can also be used. Therefore, data on incidental events and user response data can be patterned to further provide useful data in algorithms for estimating or predicting user cognitive awareness when such incidental events and / or user responses recur.

[0136] The characterized incidental events can then be placed into bins (step 40). Through incidental event synchronization, the bins can be adjusted for specific patient physiological functions. The bins can then be normalized, that is, the normal distribution of incidental events within the bins can be defined (step 42).

[0137] Then, for example, in the estimation or prediction of user cognition, normalized binning information can be proactively used as data input for intelligent alerting functions (step 44). Binning techniques can be employed to determine when a patient is more attuned to their data based on behavioral input, which can then allow for inferences, estimations, or predictions about user cognitive awareness.

[0138] Another use of this binning technique is to identify good or successful alarm signatures (step 43), such as alarm signatures indicating a patient's successful response to a diabetes state and alarm type, to distinguish them from bad or unsuccessful alarm signatures (step 45), i.e., alarm signatures indicating a patient's ignored diabetes state and alarm type. Smart alarms can then be provided based on this information; that is, smart alarms can determine when and how to alarm by comparing with good alarm signatures (this can provide a trigger for a smart alarm if the diabetes state is within a predetermined proximity (in the blood glucose trajectory) of a good alarm signature). In this case, the use of good alarm signatures does not depend on an estimate or prediction of the user's cognitive awareness, although it can be used in conjunction with such an estimate or prediction.

[0139] Patterns can also be identified by recognizing recurring conditions or events during CGM wear. To identify these recurrences, the algorithm can synchronize CGM data (e.g., CGM data stored in a buffer or data file) over each period (day, week, or month) and calculate the average or distribution of CGM values ​​over time. Synchronization can be done using absolute time to identify, for example, nighttime lows or morning / afternoon high / low values. One problem with this method is that users may not always eat or administer insulin at the same time, so patterns may not be obvious. Therefore, in systems and methods based on this principle, patterns corresponding to the timing of food intake or insulin administration can be identified. The techniques described above can be used to identify such patterns. For example, a sudden change in blood glucose within a predefined duration in the morning can be identified as “breakfast.” By utilizing a smartphone and data communication between the pump and the monitoring application, data corresponding to pre-meal dose delivery from the pump can be transmitted to the monitoring device (such as a smartphone) and used as an indicator of food intake. Other such metrics could include data from GPS applications, such as determining potential food-related blood glucose fluctuations at frequently visited restaurants, activity variations determined by accelerometer data (for the effects of exercise on CGM), and so on. In this way, the model can (machine) learn about responses that are closest to the meal or to the night in terms of "temporal proximity," or closest to the location in terms of "geographical proximity," such as how far the user is from their home or food source.

[0140] Once a specific synchronization time is selected, data corresponding to the CGM trajectories in each of these periods can be overlaid to generate statistics. For example, the average of the trajectories can be used to distinguish between true effects and random events. Any true glycemic effects caused by repetition of patient physiological functions may be amplified, while other random effects may be eliminated or averaged.

[0141] Data corresponding to the distribution of CGM over time will provide the most likely blood glucose values ​​and associated minimum and maximum values ​​after the synchronization event. Therefore, these can be used to generate typical blood glucose changes in an individual due to the synchronization event. For example, if blood glucose is synchronized based on lunchtime food intake, the post-lunch blood glucose change will be typical for that individual. Any blood glucose change exceeding a predefined threshold may have an underlying cause, such as inadequate or missed doses, insulin buildup, etc.

[0142] Trends in blood glucose patterns (average, high, or low) can also indicate slow changes in behaviors that can also be detected and alerted. For example, slow trends in average, minimum, or maximum blood glucose, determined through machine learning, can indicate changes in physiological parameters associated with insulin administration (e.g., the insulin-to-carbohydrate ratio or insulin sensitivity). These patterns can also be used to adjust parameters using machine learning algorithms when different parameters are needed at different times of day, week, or month. If the system determines that such a trend will occur without corresponding changes in user behavior, such as from meal data, exercise data, data entered on the user interface, etc., the algorithm can use this data to estimate or predict that the user is unaware of it, and in the event of such estimation or prediction, a smart alert can be generated and displayed. For example, if the estimation or prediction indicates a likelihood of conscious awareness exceeding a threshold standard level (and for all the estimations or predictions described herein, this is generally true).

[0143] While users are enjoying other features of their smartphones, these analyses can be run by background algorithmic routines that learn from individual patient data over time, either in a supervised or unsupervised manner. Thus, over time, pattern recognition can be performed, and intelligent alerts can be enabled, allowing for more effective alerting.

[0144] As mentioned above, implementing smart alarms involves more than simply replacing or delaying alarms in time to make them more convenient for the user. However, the time measure determined by timing circuitry or algorithms can be used in conjunction with other information, such as behavioral or background information in the prediction or estimation of the user's cognitive awareness and in determining when and how to provide a smart alarm. For example, the computing environment can identify alarm states, such as a diabetic condition requiring attention, but the timing of providing a smart alarm can be determined based on other input variables, including behavioral and background data (i.e., variables used in many cases in determining the smart alarm function). Even if the smart alarm is delayed on this basis, the determination of the delay will still be based at least in part on the real-time data described above.

[0145] Behavioral and background input

[0146] Various types of behavior and background information can also be used as input for intelligent alarm functions to determine, predict, or estimate user cognitive awareness.

[0147] Background and behavioral information is data that typically corresponds to how a patient uses their mobile device / monitoring application and thus provides context for certain data determined by the device. Behavioral input information can be obtained via the system and may include a number of interactions, blood glucose alarm / alarm statuses, sensor data, screen clicks, alarm analysis, events (e.g., characteristics related to user responses, response time, blood glucose control related to responses, user feedback related to alarms, alarm or alert confirmation, unconfirmed alarm / alarm within X minutes, alarm / alarm confirmation time, alarm status duration, etc.), diabetes management data (e.g., CGM data, insulin pump data, insulin sensitivity, patterns, activity data, calorie data), data on fatty acids, heart rate during exercise, IgG anti-gliadin, pressure levels (sweat / perspiration) from skin patch sensors, free amino acids, troponin, ketones, adiponectin, sweat, body temperature, user feedback, etc. Input can be provided by sensors that communicate data with the monitoring device. In some embodiments, information can be obtained via an intermediary device such as a remote data storage device. The user data described above along with user interactions is an example of behavioral data.

[0148] Background information may include the user's location, determined by GPS, WiFi, or the location of the sharer and follower. It may involve a person's biological functions, location, sensed environment (e.g., light, sound levels), and environmental data (e.g., weather, temperature, humidity, atmospheric pressure). Input may be received via machine-to-machine communication through a peer-to-peer or mesh network. Background information may include daily information from a calendar application (which may change, especially from weekday to weekend). Background information may include the frequency of touching or grasping the monitoring device, even without interaction with the device, based on sensed movement of the device (e.g., from an accelerometer within the device and / or an application).

[0149] Image recognition algorithms can be used to convert photos from a user's smartphone into background data. For example, one or more of the following photos can be used to provide background information: blood glucose meter readings, insulin pen or pump IOBs, location (e.g., gym, park, room, Italian restaurant), or meals. Image recognition algorithms can be used to process photos to identify, for example, the calorie intake of a meal shown in the photo. The type of insulin used (which can be determined by a barcode, etc., captured by the smartphone's camera) can also be provided as useful input to the monitoring system for estimating or predicting cognitive awareness. In fact, the reception of this insulin type data itself can indicate the user's cognitive awareness, especially when combined with other data about it. Background can also be provided by a baseline or dosage setting provided to or determined by the monitoring device. This setting can use known data transmission methods and protocols (e.g., ...). The data is transmitted to the monitoring device. Transmission can be performed via push or pull, periodically, or in other ways.

[0150] Behavioral / background data can be used by the system to predict or estimate a user's cognitive awareness, as it can indicate the user's awareness of their diabetes status. As one extreme, background GPS data might indicate the user is in their doctor's office, thus implying significant user awareness. At another extreme, behavioral data, such as accelerometer data, might indicate sleep, thus indicating significant lack of awareness. In this case, alarms and alerts can be appropriately modified, for example, by automatically enabling or disabling them. For instance, if sleep is determined, the alarm / alarm system can enter a "night mode" or "sleep mode" that is more conservative with blood glucose and more aggressive with low-value alarms. This can then adjust system behavior, including alarms / alarms, and can further dynamically adjust the target range, significantly enhancing user convenience. For example, in such a night mode, the target range could be adjusted to be slightly higher, such as slightly more aggressive, for low blood glucose alarms compared to "day mode." Initiating or deactivating these modes can be programmed to transform the monitoring device, causing it to process data differently than before, thereby improving the efficiency of the computing device.

[0151] Other inputs equivalent to background / behavioral data used for estimation or prediction in cognitive awareness algorithms may include certain data types referenced elsewhere, such as exercise information from a stationary bike, blood glucose sensor information from a blood glucose (BG) meter or CGM, insulin delivery volume from an insulin delivery device, on-board insulin calculations from the device, and information provided or calculated by other devices. Other background / behavioral data inputs may include: hydration level, heart rate, target heart rate, internal temperature, external temperature, external humidity, in vivo analytes, hydration input, power output (cycle), perspiration rate, pace, and adrenaline levels, stress, symptoms / diseases, metabolic / calorie burning rate, fat breakdown rate, current weight, BMI, desired weight, daily target calories (expenditure), daily target calories (expanded), location, favorite foods, and activity level.

[0152] For example, high external temperatures combined with low stress and high calorie intake can be determined by the system to be consistent with a user being on vacation, which in some individuals may indicate reduced attention to their diabetic state. In this case, the system can determine that the user may not be aware of a diabetic state that requires attention, and therefore should generate a smart alert.

[0153] In this regard, it should be further noted that high external temperatures may cause intelligent alerts to be presented to users regarding ensuring that their diabetes products are kept in refrigerated containers and not exposed to high ambient temperatures.

[0154] For any of the above-mentioned behavioral or background inputs, the system can be configured to receive and / or generate analytical measures based on the input. For example, a composite value can be generated based on the user's blood glucose level, temperature, and the time when the data generates the index value. The composite value can then be considered in the estimation or prediction of cognitive awareness.

[0155] This information can be collected from various sensors, both internal and external to the device (e.g., accelerometers, GPS, camera data, etc.) and third-party tracking applications (including sleep cycle applications), and can also be used to influence the output. For example, GPS can be used to determine the rate of movement in order to suppress smart alarms on mobile devices in the case of a moving car. However, in this context, smart alarms can be transmitted for presentation on a smartwatch. Therefore, real-time measured sensor (blood glucose) data is used to determine a diabetic state requiring attention, and other data, which can be real-time or non-real-time (or a combination thereof), is used to determine whether a smart alarm should be generated. If a smart alarm should be generated, other real-time data (GPS data in the above example) can be used to further determine the form of the smart alarm, particularly the device to which the data is transmitted and presented.

[0156] As mentioned above, alarms can be affected by the proximity of the sharer and follower. For example, alarms can become annoying when the sharer is near the follower because they may be activated in two locations, such as on the sharer's pump, receiver, or smart device, and on the follower's smart device. In one implementation, the follower application can detect this situation and delay or suppress the alarm on the follower's device. For example, when the follower application receives an alarm, it can initiate an RF (e.g., Bluetooth(R)) scan for the sharer's mobile device (or dedicated receiver or pump). If it detects the sharer's device, for example, within 30 feet (for Bluetooth(R) detection), it can check the RSSI (Received Signal Strength) to determine its proximity to the sharer's device (e.g., very close, close, far). If the follower device determines that it is close or very close to the sharer, the follower application can delay the alarm for a minute or two to give the sharer a chance to respond. Alternatively, the follower application can suppress the alarm. In any case, if the sharer responds within a predetermined time frame (e.g., 1 to 2 minutes), the alarm can be suppressed on the follower's device.Beacon technology can also be used for this purpose, as exemplified by, for example, U.S. Patent No. 8,844,007, entitled "Systems and Methods for Processing and Transmitting Sensor Data," filed September 23, 2014; U.S. Patent Publication No. US-2013 / 0078912, filed September 21, 2012, entitled "Systems and Methods for Processing and Transmitting Sensor Data"; U.S. Patent Publication No. US-2014 / 0273821, filed March 14, 2013, entitled "Systems and Methods for Processing and Transmitting Sensor Data"; and U.S. Patent Publication No. US-2014 / 0273821, filed November 5, 2014, entitled "Systems and Methods for Continuous Monitoring and Analysis of Analytical Values." U.S. Patent Publication No. US-2015 / 0123810 entitled "Methods for a continuous monitoring of analytical values"; U.S. Patent Application No. 15 / 001756 entitled "Continuous Glucose Monitor Communication with Multiple Display Devices" filed January 20, 2016; and U.S. Patent Application No. 62 / 271880 entitled "Intelligent Wireless Communication for Continuous Analyte Monitoring" filed December 28, 2015, all of which are the property of the assignee of this application, and the entire contents thereof are incorporated herein by reference.

[0157] In some cases, unexpected blood glucose spikes identified through analysis of blood glucose trajectories may temporarily disable the sharer feature to avoid user embarrassment and to meet user privacy goals and considerations. Such unexpected spikes may include certain health or stressful events. In one implementation, a threshold level for unexpected spikes is predetermined, and data on unexpected spikes is compared to the threshold level to determine whether the sharer feature should be used to share data about the spikes.

[0158] Heart rate data measured by a heart rate sensor can be used to estimate or predict a user's cognitive state. For example, an off-the-shelf heart rate sensor, along with measurement results transmitted via a suitable transmission protocol, can be used in monitoring devices or other devices that provide intelligent alarm functionality. In another embodiment, the sensor electronics or transmitter (see below) Figure 45 / 46) may be equipped with a bright light and an optical sensor (not shown) to detect heart rate. This heart rate data can itself be used to estimate or predict the user's cognitive state, or it can be used indirectly to infer when the user is exercising, under stress, sleeping, etc. (which can then be used for estimation or prediction). In such a direct use, the user may be in a diabetic state requiring attention. The accelerometer in the smart device can be used to determine when the device has just been operated, and said operation includes viewing the blood glucose monitoring application user interface. If the heart rate suddenly appears to rise, it can be inferred that the user has been notified of a diabetic state requiring attention, and a smart alarm does not need to be issued.

[0159] Furthermore, context and behavior can be determined by using information about the user's available social networks, where social network feeds associated with the user are set up to provide a data source for intelligent alerting functions. By analyzing this data in social network feeds, user cognitive data can be determined in some cases, such as when a user posts "I am currently in a low value." or posts content similar to what the user previously posted when they were in a low value. Techniques such as natural language processing can be used to determine the meaning of the post and thus allow for a quantitative measurement of similarity to previous posts. Therefore, a post can not only be used directly for its content ("I am currently in a low value.") but also to infer that the user is in a similar state to when the user previously posted similar comments.

[0160] Using this system and method based on this principle, the problems encountered by existing monitoring devices that lack consideration of such context / behavioral aspects can be effectively addressed. In particular, if available data from sensors and other sources (including context / behavioral aspects) allows for the estimation or prediction of a user's cognitive awareness of a diabetic state requiring attention, the monitoring device can be significantly improved by using cognitive awareness as a means of suppressing alarms (when they are not needed), offering a significant technical advantage over monitoring devices that base such alarms solely on thresholds (or even thresholds plus predictions). Therefore, this offers a significant technical advantage over existing monitoring devices that never consider such cognitive awareness. Further details regarding context and behavioral information can be found in U.S. Patent Publication No. 2015 / 0119655, filed October 28, 2014, entitled "Adaptive Interface for Continuous Monitoring Devices," which is the property of the assignee of this application, and the entire contents of which are incorporated herein by reference, particularly... Figure 4 And the accompanying text.

[0161] Behavioral and background inputs can also be used to provide other useful alarm functions. For example, if there are multiple CGM receivers in a home, it becomes important that the user can uniquely identify each CGM receiver. To do this, currently there are no visual aids to help distinguish different units except for different colored casings. Therefore, in systems and methods based on this principle, as part of the setup process for a new receiver, or for a receiver that a new user is using, the user can be asked to select a unique identifiable marker, such as an initial, screen background, color theme, screen saver, animation, etc., or a combination thereof, which will be displayed in a screen area when CGM information is displayed. For example, an initial might be displayed in a corner of the screen or in the status bar. When the screen does not display CGM information, a screen saver can be applied. It can be applied to entities such as fonts, backgrounds, etc. Animations can be displayed in various selectable areas of the screen. In this way, when the user's CGM data is displayed, the CGM receiver or CGM smartphone application can display the marker belonging to the user, thereby avoiding confusion when multiple data sources (e.g., hosts with sensors) are transmitting data in a common location at approximately the same time.

[0162] Also as part of the setup process, thresholds can be set, allowing users to indicate the various types of alarms or alerts they wish to receive, such as wanting to receive alarms before or after meals. The smart alarm feature or app can then be configured to periodically or regularly prompt the user for their settings, for example, to determine if the user is satisfied with their settings choices or if they wish to modify them, such as choosing to receive alarms before meals. This can also prompt and allow users to modify alarm thresholds to better suit their lifestyle, i.e., perform alarm optimization.

[0163] Other inputs

[0164] Other data sources besides user input, blood glucose data including exported data (such as rate of change and pattern data), and behavioral / background data sources can also be used.

[0165] For example, data derived from signal trends (in addition to patterns) can also be used for smart alarm functionality. For instance, smart alarms can be based on proximity and duration, such as being in or near an alarmable area, also known as "fluctuation." That is, in many cases, even if a user is not in a danger zone, they would want to be alerted if they approached one over a prolonged period. Smart alarm functionality can be used to provide an alert in this situation. In other words, in the case of fluctuation, a smart alarm is generated when a user is not typically aware of their approach to a danger zone. In this case, the data indicating fluctuation can be determined by analyzing measurement data, duration data, and the location of a threshold. If a user approaches an area threshold (e.g., + / - 10%) within a predetermined duration, and if other data discussed above or below indicates that the user is unaware of the fluctuation, the smart alarm functionality may result in the generation of a smart alarm indicating the presence of fluctuation.

[0166] In another signaling trend, notifications can be provided when a dangerous or undesirable area is no longer a problem, potentially reducing stress on users and informing them that they are back to their target. This is similar to the home automation aspect of a dimmer switch. Specifically, when the dimmer switch is turned off, the steps involve: the light is on, then the home automation system issues a command to turn off the light, then the light issues a command indicating it is beginning to turn off, and finally the light issues a command when it is off. Similarly, in the case of a garage door: the garage is open, then the home automation system issues a command to close the garage, then the garage issues a command indicating it is beginning to close, and finally the garage issues a command when it is closed.

[0167] This functionality is important for garages because if something blocks the sensor and prevents the door from closing, it's crucial that the user (through the home automation system) recognizes the garage is not closed. In this scenario, a notification might occur because the user never received the final command. In the current situation, if a patient is in a state of hypoglycemia or hyperglycemia and attempts to correct the situation by taking medical action, the sensor electronics can send a notification indicating that blood sugar has reached an inflection point and begun to rise (or fall). It can then send a notification that the user is no longer in the hypoglycemic (or hyperglycemic) range. A more proactive approach could be adopted, pushing notifications to announce that the patient is no longer in the undesirable range, rather than waiting for periodic (e.g., every 5 minutes) measurements to determine if the patient has exceeded the undesirable range. Therefore, in this case, a smart alarm could be based on whether a second notification was never received. Specifically, when the system correctly anticipates a "out of danger" situation that will be determined (which never occurs), the system can infer that the user is still in a dangerous situation and therefore should generate a smart alarm. This is particularly true when the user has taken corrective actions aimed at treating a diabetic state requiring attention. In the latter scenario, users may want to escape a dangerous situation without needing further thought. If this doesn't occur, intelligent alerts may be more important. It should be understood that this functionality can be achieved in several ways. For example, an "out of danger" notification could take the form of a flag set after an inflection point is detected. The timing and location of corrective actions (if known) can also be used to calculate, determine, and subsequently set the "out of danger" flag. If the user does not escape the dangerous situation within a predetermined duration after the corrective action (which can be determined from user history and patterns), an intelligent alert can be generated again.

[0168] Another input can include the user's life goals. Specifically, diabetes management goals (e.g., reduced risk of hypoglycemia, reduced time spent out of range, reduced alerts / alarms, post-meal optimization, reduced rebound, etc.) can be used as input for cognitive awareness prediction and estimation. Users can set a single goal, or even different goals for different times of day, and the system will change or modify the settings to make it easier for the user to achieve their desired goal. For example, a person might use a reduced risk of hypoglycemia goal at night, with the system using predicted low-value alerts and higher threshold settings. For these settings, for example, in the case of using values ​​at night, it is assumed that the user is typically unconscious, as if they are likely asleep. As another example, such a user could also have post-meal optimization settings that remind the user to take a bolus approximately 30 minutes before their typical lunch time, or provide a reminder that their meal should include protein if the user is estimated or predicted to be unconscious.

[0169] Other inputs include data and signals from insulin sensors, or from other sources of data about insulin. For example, insulin sensor data can be used to detect insulin delivery, which in turn provides an estimate of the level of awareness of a diabetic state requiring attention based on when insulin should be injected. More specifically, if a diabetic state requiring attention occurs, but the smart alert application detects a certain level of on-board insulin using data from the insulin sensor, the smart alert can suppress the alert until it is determined that the current insulin is no longer sufficient to control the hyperglycemia and the user does not recognize the need for more insulin. Insulin sensor data can also be used for other purposes. For example, in addition to on-board insulin, information about the timing of injections can be used to modify the behavior of smart alerts for hypoglycemia and hyperglycemia. For example, if a user has recently administered a dose of insulin, a threshold alert may be delayed, or the alert may be predicted to temporarily suspend or increase its target threshold, based on the identification of possible user awareness and / or reduced user risk associated with the situation (e.g., reduced risk of a “diabetic state requiring attention”). As a specific example, if prediction is used at 200 mg / dL, the knowledge of the dose can set the alarm at 250 mg / dL for one hour. Similarly, for hypoglycemia alarms, the knowledge of insulin can increase or decrease the sensitivity of the alarm if calculations indicate that the insulin dose suggests a more moderate or more aggressive reduction in blood glucose.

[0170] Typically, using insulin sensor data in this context requires a certain level of machine learning, especially because each user has different insulin sensitivity, and this sensitivity can change over time. Therefore, understanding current insulin sensitivity may be a prerequisite for using insulin sensor data, particularly where high accuracy is required.

[0171] As another example, if information or data about the insulin on the plate is known, or entered subsequently or simultaneously by the patient, it can be used to determine when to provide a smart alarm. This information about the insulin on the plate can be entered by the patient or received from a drug delivery device (e.g., a pump or pen). In one implementation, the user can enter how much insulin they have already administered, and then the system can calculate how much insulin remains in their system over the next few hours. The insulin value on the plate can then be used to notify the patient when they are notified (e.g., when given an alarm or alert). In one implementation, if the patient typically expects to be alerted when their insulin level exceeds 200 mg / dL, and the system detects that they are above that value or predicts they will exceed it, the system can subsequently determine or receive data about the insulin on the plate. If they have a large amount of insulin in their system, such as five units, the system may determine that the patient does not need to be alerted immediately because the insulin will handle potential hyperglycemia symptoms. Similar steps can be taken when the patient is approaching hypoglycemia. For example, if a patient wants to be notified when their insulin level drops below 80 mg / dL, and the system detects that they have a significant level of insulin in their system but above that value, the system, with the help of a smart alarm function, may alert the user in advance that their level is approaching a low value.

[0172] Another potential input includes a given user's type of diabetes and specific manifestations of diabetes. A type I patient's cognitive awareness may differ from that of a type II patient. Therefore, the generation of smart alerts may differ between the two, and the timing of the alerts may also differ. In one implementation, the difference between the two cases is limited to estimating or predicting a threshold level that determines cognitive awareness. In other words, the threshold level varies between the two types of diabetes; the threshold level is a level compared to the estimated or predicted cognitive awareness, and the result leads to the generation (or non-generation) of a smart alert.

[0173] Other different and individualized physiological functions and patterns of effect can be observed. For example, fluctuations around 70 mg / dL may be common in patients, but a sudden deceleration after the same patient passes 60 mg / dL may be very rare. In this example, atypical responses can be detected and alerted by determining the blood glucose concentration value and including its rate of change in the estimate or prediction.

[0174] Systems and methods based on this principle that incorporate cognitive awareness into the determination of whether to alert a user are customized and / or two-fold and tailored to each individual user, and are customized / adjusted, for example, using data and sources as described above through machine learning. Other significant sources of customization or personalization include altering the operation of intelligent alert functionality based on physiological function, patient age, accurate diagnosis, etc. Therefore, implementations of systems and methods based on this principle offer significant advantages in reducing the burden on users or clinicians (e.g., setting alarms and alert thresholds), which in some cases are even unknowable due to daily changes. That is, in many cases, users simply have no way of figuring out how to customize their alerts without the technological advancements of current systems and methods and their subsequent predictions or estimates of cognitive awareness.

[0175] In other variants, depending on activity, disease, pregnancy, menstruation, other cycles, etc., systems and methods can create multiple distribution maps for patients.

[0176] Other data sources can include telemetry data, metabolic rate, etc. Other potential data and data sources can include relevant data (such as user perception at night and during the day), pain data, heart rate variability, stroke volume, cardiovascular health, insulin distribution capacity, body temperature (which affects insulin absorption), insulin type (based on insulin sensitivity measurements, distribution maps, peak values, and time between peak values), atmospheric pressure (which affects CGM and insulin absorption), insulin sensitivity, determination of which factors most affect a given user (e.g., exercise and meals), known health or physiological conditions that affect certain parameters, diseases, whether smart devices are in a specific mode (e.g., flight mode), anomaly management (e.g., identifying what is normal for a particular patient and implementing anomaly management rules), whether smart devices running smart alarm functions are in training mode, clinician settings, response trigger data, etc. Therefore, user perception can involve not only whether a user is aware of high or low values, but also whether the user encounters situations with highly complex responses that the user cannot recognize due to their inherent complexity.

[0177] For any given input, fuzzy logic can be used to determine the value of the input. In some cases, fuzzy processing and fuzzy output can also be employed. More specifically, alarms or alerts (including smart alarms and alerts) can be triggered in a way that does not solely rely on blood glucose levels exceeding a numerical threshold. In one implementation, an algorithm can be employed that triggers an alarm when a user's blood glucose level fluctuates just below a high alarm threshold or just above a low alarm threshold for a given predetermined duration (even if the threshold is not exceeded). This implementation is similar to the fluctuation implementation described above. For example, the user's high alarm threshold can be set to 180 mg / dL, and the user's consecutive blood glucose levels can be 178 mg / dL, 175 mg / dL, 177 mg / dL, and 178 mg / dL. Although the user's blood glucose level never reaches 180 mg / dL, the algorithm identifies the proximity of the blood glucose level to the threshold and provides a smart alarm to the user after 20 minutes (or after another duration configurable by the user). This implementation is useful because it can prompt the user to take corrective action, such as a small insulin dose or exercise, when the user is not paying attention to their blood glucose level. In another implementation, an algorithm to decay alarms / alarms can be used when a user's blood glucose level alternates around an alarm threshold but at a small rate of change. As an example, the user's high alarm threshold can be set to 180 mg / dL, and the user's consecutive blood glucose levels can be 170 mg / dL, 178 mg / dL, 182 mg / dL, 179 mg / dL, 181 mg / dL, 178 mg / dL, and 182 mg / dL. An alarm is triggered when the blood glucose level changes from 178 mg / dL to 182 mg / dL, but if the user acknowledges or clears the alarm, it will not be triggered again when the blood glucose level subsequently changes from 179 mg / dL to 181 mg / dL. This implementation can be particularly useful because it helps avoid the annoying situation a user faces when aware of borderline blood glucose levels and does not want, expect, or need repeated alarms. In some implementations, this technique can be used more safely at a high alarm threshold followed by a low alarm threshold.

[0178] Other variations may include changes in the frequency of receiving input data or displaying output data. In particular, systems and methods based on this principle can be configured to receive additional data, such as updating every minute instead of every 5 minutes, when a dynamic risk is imminent. For example, if an impending low value is predicted based on the current blood glucose level and rate of change, the display may update every minute instead of every 5 minutes. In this implementation, more advanced information, such as indications of whether an upward or downward trend in blood glucose is accelerating, can also be displayed. More advanced visualizations can also be used to indicate this derivation, calculation, estimation, or prediction. This allows users to obtain better and more frequent information when most needed. Furthermore, by using the most accurate information, the system can even further suppress alarms, for example, when a dangerous situation is self-correcting. This further avoids user annoyance regarding unnecessary alarms.

[0179] As another example of input for estimating or predicting cognitive awareness, signal metadata can be employed. For instance, inflection points, once identified, draw attention to the inflection point region. As a specific example, the system can sample more frequently at inflection points than at non-inflection points. Such inflection points can include points where blood glucose signals are turning or other such points where fine-tuning or other data can be used to determine parameters helpful to the user, including parameters that are decisive or useful in determining the user's awareness of a diabetic state requiring attention. The benefits are as described above. It should be noted in this regard that more sampling at such points allows for less sampling at different points, and less sampling at different points can be particularly useful in terms of saving battery life, reducing power requirements, and extending sensor and monitor lifespan. More frequent sampling and subsequent data transmission for presentation can also be employed when the user is approaching or experiencing hypoglycemia or hyperglycemia. In other words, regions, such as those described above, can be used as inflection points.

[0180] In some implementations, input can be received from wearable sensors. In one implementation, data obtained from a smartwatch can be used either independently or to supplement other data. In a particular instance, sensors and signals collected by a smartwatch (e.g., Apple Watch and Microsoft Band) can be used to enhance the detection of hypoglycemia. Such signals may include signals from a heart rate sensor, sympathetic / parasympathetic balance (which can be inferred from heart rate), sweating / mood / stress data from a conductivity sensor, and motion data from an accelerometer. These signals can be used in addition to CGM signals. Algorithms for processing these auxiliary signals can be trained based on the patient's own data (using CGM-assisted training). These algorithms can be optimized offline, for example, in the cloud. Detection criteria can then be sent to the patient's smartphone and / or smartwatch. It is possible that when the CGM does not detect hypoglycemia, but when supplemented with auxiliary signals indicating possible hypoglycemia, the patient can be alerted to suspected hypoglycemia, thus preventing consequences. Alternatively, after the algorithm for processing auxiliary signals has been trained, smartwatch signals can detect hypoglycemia without using the CGM. In this usage scenario, adjusting the algorithm may be necessary to optimize sensitivity or specificity.

[0181] In other implementations, smartwatch sensors and machine learning can be used to detect and quantify sleep. For example, if a user is asleep, as determined by motion data from an accelerometer, it can be inferred that the user is unaware of a diabetic condition requiring attention, or is actually unaware of any diabetic condition. Therefore, if the system estimates or predicts that the user is sleeping, alarm changes can be configured not to suppress any smart alerts. Other sleep sensors can also be used for estimating or predicting cognitive awareness.

[0182] As an example of an alternative type of sleep sensor, temperature can be used as a mechanism to determine whether a patient is sleeping. For example, such a sleep sensor can be used to observe the relationship between wakefulness and sleep time. In implementations, a temperature sensor mounted on the skin (which can be a standalone temperature sensor or a temperature sensor implemented within an adhesive patch attached to the patient) can utilize the strong correlation between temperature data and sleep time.

[0183] Other inputs will be understood as disclosed in U.S. Patent Application No. 62 / 289825, filed February 1, 2016, entitled “System and Method for Decision Support Using Lifestyle Factors,” which is the property of the assignee of this application and whose entire contents are incorporated herein by reference.

[0184] Output

[0185] The output of a smart alarm function is usually the displayed output, but the algorithm itself can have "output" in terms of calculations, estimations, or predictions in the user's perception, and thus cause the alarm to be suppressed or simply prevent the alarm step from occurring (e.g., if the estimation or prediction makes the user aware of a diabetes state that needs attention) is also considered "output" in this sense.

[0186] The output of the smart alert function can also take many forms, such as visual displays, audible indicators, tactile indicators, and so on. These can be combined in various ways to support the smart alert function. For example, a visual display can be used to provide an indication of the diabetes state, but audible or tactile indicators can be provided depending on the cognitive awareness-based smart alert function. Alternatively, a visual display can be used to provide an indication of the diabetes state (e.g., values ​​and trajectory graphs), but a smart alert can be provided, for example, by another visual display overlaid on a first visual display. In another implementation, a cue on the display can be adopted and used to test the user's cognitive awareness, and a smart alert can be generated if the user is not cognitively aware of such an indication. The way the cue and its response indicate cognitive awareness can vary. A cue on the display may be explicit, asking the user if they are aware of an impending diabetes state requiring attention, or it may be more subtle or implicit, requesting less information, but this will provide the data necessary to estimate or predict cognitive awareness. These implicit or subtle cuees or questions may be more suitable for younger users or less experienced or less sophisticated users, or users with less experience with the biological symptoms of the diabetes state. Therefore, systems and methods based on this principle can use user distribution map information when determining or calculating what type of prompts or questions are presented on the user interface.

[0187] The user interface presented in the output of the intelligent alert function is closely related to the calculated estimate or prediction of the user's cognitive awareness. If it is predicted or estimated that the user is aware of a diabetic state requiring attention, the user interface will typically not display an intelligent alert. Conversely, if it is estimated or predicted that the user is not aware, an intelligent alert will be displayed, and this will usually involve changes to the user interface. For the reasons given above, such as because intelligent alerts result in fewer repeat alerts and less alert fatigue, this output is generally considered more effective and efficient for users who subsequently only alert based on thresholds, further significantly saving battery power and computation cycles.

[0188] In a given presentation output, smart alerts can be further displayed along with expressions of confidence or doubt levels. Confidence or doubt levels can be calculated by systems and methods based on this principle, based on error bars calculated for the data, known or determined calibration ranges or errors, known or determined sensor errors, etc. Confidence or doubt can be expressed to foster trust between the user and the system. This trust is enhanced when the system has performed further machine learning steps and has acquired sufficient data to provide accurate, highly personalized opinions and recommendations to the user. At this point, systems and methods based on this principle can reduce the display of doubt expressions in the smart alert output because they are no longer or less relevant. As a specific example, low-value alerts occurring during possible human events (e.g., "immersion and recovery" failures) can be expressed with a degree of doubt. Insulin administration recommendations can be given to explain uncertainties in blood glucose estimation. This might occur, for example, during the first day of a CGM communication period, where the recommendation somehow expresses this uncertainty to the user, which in turn fosters trust in the monitoring application and smart alert functionality because the user realizes the system is making "guesses" or predictions rather than providing explicit recommendations. In this way, intelligent alerts will attract user attention and foster trust in the system. Subsequently, once the fault has been resolved, the monitoring application and intelligent alerting function can present data with unquestionable confidence, or with reduced skepticism, thereby increasing confidence in the monitoring application not only in its accuracy but also in its error awareness and handling.

[0189] When generating and displaying intelligent alerts, the user interface can be configured to minimize user intrusion, and the presentation of blood glucose values ​​themselves can be de-emphasized, instead highlighting trend information, for example, by displaying various arrows or areas on the monitor or screen. This can be implemented through control settings adjusted by the doctor or the user, which adjusts the display presentation to focus on the trend or trend arrows, while the blood glucose number is less prominent.

[0190] The aggressiveness of the smart alert function can be adjusted through user-configurable settings (e.g., a slider). The slider affects not only the input but also the output. That is, the slider can be used to influence the operation of the smart alert function on both the input and output sides. Users who expect a high level of aggressiveness will typically receive more smart alerts than users who expect a lower level of aggressiveness. In other words, if the user interface setting is set to a high level of aggressiveness, the system can automatically control the threshold level of cognitive awareness (on which smart alerts are based), making it higher. A higher threshold will generate more smart alerts because it is harder to reach. Thus, the system becomes more aggressive. Conversely, if the user interface setting is set to a lower level of aggressiveness, the threshold level of cognitive awareness may decrease, resulting in fewer smart alerts.

[0191] Dynamic risk may play a role in the rate at which input data accumulates. It may also play a role in the frequency of data updates, providing users with a more granular and accurate way to receive notifications and assessments of their risks. This risk can be measured through appropriate calculations based on blood glucose levels and rates of change, or may include more advanced calculations, such as the blood glucose urgency index described in the patent application incorporated above by reference. That is, based on dynamic risk calculations that may include blood glucose levels, rates of change in blood glucose, and other more complex derived values ​​(typically involving one or more of these real-time values), the system can automatically adjust data transmission settings, such as frequency, whether push or retrieved data is used, screen refresh rate, data update and recalculation rate, calibration frequency, and so on.

[0192] When intelligent alerts are generated and presented on a display, and more specifically on a user interface displayed on the display, they can take many forms, including having various predictive levels. For example, refer to Figure 7 Intelligent alerts can indicate diabetic conditions requiring attention and can further provide details such as current blood glucose levels and expected blood glucose levels (e.g., expected within a certain time range, such as 20 minutes). Figure 7 The intelligent alarms shown can be overlaid on top of the trajectory graph, as shown in the trajectory graph. Figure 8 As shown. It can be seen that, Figure 7 Intelligent alarms in this impending low value (by Figure 8 In the case of a local minimum (represented by the local minimum), a detailed alert is provided to users who are unaware of their diabetes condition and need to pay attention to it.

[0193] Figures 9 to 29Exemplary user interfaces and smart alerts have been constructed based on interface usability and other factors. For example, while using displayed arrows can sometimes be helpful to users, their meaning can sometimes be ambiguous. For instance, arrows tend to express urgency or the need for action, but users may be confused as to whether an arrow indicates a prediction or a trend. Therefore, in one implementation, it has been found helpful to display the current blood glucose level, a threshold alert level (e.g., the most relevant threshold alert or alarm level given the current blood glucose level (e.g., '55'), a symbol, and a color (e.g., yellow or red, with the specific color depending on the urgency of the diabetic state in cases where the user is unaware of the need for attention).

[0194] Symbols can be like Figures 9 to 14 As shown, for example, a dashed line that starts at a thick point and ends at a threshold ( Figure 9 ), dashed lines with arrows indicating direction ( Figure 10 ), dashed lines indicating direction (if read from left to right) Figure 11 ), line segments with directional arrows ( Figure 12 In some cases, such as for experienced users, only a warning is needed, such as... Figure 13 As shown. Warnings with trend arrows and color indicators are displayed in... Figure 14 The text is displayed as an alternative user interface. All these elements and their combinations are useful in providing context for smart alarms. Symbols may be particularly helpful for children, as they are easier to identify and communicate with parents.

[0195] from Figures 9 to 14 As can be seen, smart alerts are typically provided as an overlay on top of another user interface, usually associated with CGM monitoring applications. Therefore, the overlay is usually located above the trend graph, and may or may not contain predictive elements, sometimes indicated by arrows or dotted lines. It has generally been found that having two different arrows on the screen can confuse users, and therefore, if a trend arrow appears in a smart alert, it should not appear in the underlying blood glucose trajectory graph or should be suppressed.

[0196] It has also been found that indicating the end of a trend is helpful, and this is in Figures 15 to 17 The endpoint is indicated. This endpoint can indicate time (quantitative, such as "within 20 minutes" or qualitative, such as "soon"), value, or both. Figures 15 to 17 In this context, the time portion of the endpoint is represented by a sector on a clock indicating 20 minutes, as well as a qualitative or quantitative indication within the text warning itself. In this case, the value portion of the endpoint is indicated by a low alarm threshold, such as 55 mg / dL. Figures 15 to 17It also displays the current value, along with trend arrows and color indicators. The color indicators are typically based on the urgency level of the smart alert, determined by the current blood glucose level, its rate of change, and other factors.

[0197] Figure 18 and Figure 19 Indicates blood glucose trajectory ( Figure 19 ) and intelligent alarms overlaid on it ( Figure 18 And similarly, Figure 20 and Figure 21 Indicates blood glucose trajectory ( Figure 21 ) and intelligent alarms overlaid on it ( Figure 20 These diagrams illustrate intelligent alerts that have been found to be helpful, including a text warning “Urgent low value soon”, the current blood glucose value (i.e., 93 mg / dL), a trend arrow, an indication of the relevant threshold (i.e., 55), and a time indication indicated by a clock sector. Figure 20 and Figure 21 This further includes indications of the time endpoint within the text portion of the intelligent alert warning.

[0198] In many cases, such as Figures 22 to 29 As shown, it has been found that providing quantitative, time-based warnings, rather than qualitative ones, is advantageous. Figures 22 to 29 The time sequence of the smart alarms is shown, displaying the time progress over a 15-minute time span. Figure 23 , Figure 25 , Figure 27 and Figure 29 The following is a blood glucose trajectory graph, and its corresponding intelligent alarm is displayed by... Figure 22 , Figure 24 , Figure 26 and Figure 28 As shown. The initial time point is determined by... Figures 22 to 23 Instructions, including the time point 5 minutes later, such as Figure 24 As shown in / 25. The time point 10 minutes later is as follows. Figure 26 As shown in / 27, and the time point 15 minutes after the first time point is as follows Figure 28 As shown in / 29.

[0199] As mentioned above, the use of red has been found to be beneficial in providing intelligent alerts. However, it can be modified based on the urgency of the intelligent alert. For example, a lighter red can be used for less urgent intelligent alerts.

[0200] In another implementation, a smart alert can be provided on the lock screen of a smartphone. Figures 30 to 41 This implementation method is indicated under normal circumstances as well as in the event of a low blood sugar alarm. It can be seen that when the user sees the notification on their smartphone ( Figure 30 , Figure 34 and Figure 38 They might unlock their phones and see an alert "pop-up" notification. Figure 31 , Figure 35 and Figure 39 The "OK" button will be displayed; once activated, the trend screen will be shown. Figure 32 , Figure 36 and Figure 40 In these images, the banner obscures other navigation buttons within the app, further underscoring the importance of the alert. Users can close the banner alert and continue using the app by tapping the X button. Alternatively, the banner will disappear once the user corrects their blood sugar levels to a satisfactory level. In an alternative implementation, the alert banner can be repositioned below the navigation pane, allowing users to access navigation even when the alert is displayed. This can be configured based on the urgency of the alert.

[0201] In the shown user interface implementation or in any other implementation, tapping an appropriate icon displayed on the screen (e.g., a magnifying glass) can cause the display of additional information or invoke other functions. For example, tapping an appropriate icon can result in the display of various predicted levels, such as indicating the expected level for the next 10 or 15 minutes. This prediction can be provided by text indicators, dashed lines on a blood glucose trajectory graph, arrows, time indicators, and endpoints of blood glucose levels.

[0202] In another embodiment, a smart alarm function can be implemented such that the alarm or alert volume is automatically adjusted to an appropriate level based on the detected ambient noise level. In other words, the alarm or alert volume can be adjusted according to the detected ambient noise level so that the signal-to-noise ratio is sufficient for the user to hear the alarm or alert. This volume can also be user-customizable. The detection of the ambient noise level can be implemented by detecting and measuring it using a microphone or other sensors. In a smartphone implementation, a telephone microphone can be used. In other words, the system measures or detects the ambient noise level and automatically adjusts the alarm or alert volume to achieve a desired predetermined signal-to-noise ratio or optional SINR.

[0203] A default volume setting sufficiently higher than the assumed ambient noise level can be provided. When the measured noise level exceeds the noise level assumed by this default setting, or when a noise level is detected or assumed during the customization process, the alarm / alarm volume may automatically, gradually or abruptly increase to a level at which the user can hear the alarm or alarm. For example, the decibel level of the alarm / alarm can be set to have a predetermined relationship with the ambient noise level, for example, to achieve the predetermined signal-to-noise ratio described above. The noise level in this implementation can advantageously be measured only before issuing the alarm / alarm.

[0204] In other implementations where the user has experienced an unpleasant event (e.g., hypoglycemia, hyperglycemia, uncontrolled blood sugar, etc.), the system and method based on this principle can automatically generate a post-event intelligent alert indicating a certain degree of evidence, informing the user how the event occurred and providing helpful tips to prevent future such events. This automatic generation of evidence information can be particularly provided where the system can uniquely identify the cause of the unpleasant event by determining or detecting signal characteristics or other diagnostic information. By providing this evidence, the intelligent alert function is configured to track, detect, and be programmed to alert the user to such unpleasant events, thereby increasing the user's confidence and trust in the system. Furthermore, data about such events can be advantageously used to refine the operation of the intelligent alert application / function through the use of machine learning algorithms.

[0205] The system can be further configured to indicate warnings or other modifiers associated with the smart alarm. For example, the system could provide an indication such as, “I will wait one hour before issuing the alarm because I am waiting for [a known ‘onboard’ treatment, such as insulin or food or exercise] to take effect. But please note that there may be an alarm or alert regarding this impending situation.” This indication provides a middle ground where the system may have some confidence in its estimate or prediction of the user’s cognitive awareness, but the confidence is not explicit; equivalently, the level of the estimate or prediction is insufficient to definitively prove whether the user is cognitively aware or not. In a particular implementation, such a warning or modifier can be configured to appear with the smart alarm (via various string manipulation subroutines) whenever the estimate or prediction of cognitive awareness is within 5% of a threshold level. It is understood that the content of the string modifier will vary depending on the type and content of the smart alarm.

[0206] Even during the sensor warm-up period, certain intelligent alerting features can be utilized. More specifically, when a new sensor is installed, there is often a period of time when no information is available, such as two hours. During this period, blood glucose values ​​cannot be guaranteed to be accurate. However, trend values ​​can still be obtained, and their display is beneficial to the user. Accurate blood glucose values ​​can be obtained by finger-prick testing during this warm-up period, and in some cases, system analysis of the trend obtained during the warm-up period can be used as a trigger to obtain such finger-prick values. In one implementation, if the blood glucose monitoring algorithm uses the last known reading from the removed sensor, the algorithm can automatically generate an instruction or user prompt instructing the user to perform finger-prick testing as a safety warning. For example, if the last known blood glucose value from the removed sensor is 76 and has a decreasing trend, the reduced ion count during the warm-up period can indicate a tendency towards a hypoglycemic event. Since actual blood glucose data is unavailable during the warm-up period, the user's awareness or prediction of a diabetic state requiring attention will be correspondingly reduced. In this case, an intelligent alert may be generated that the user should perform finger-prick testing. In another example, if the last known blood glucose value from the removed sensor was 76 and relatively stable, but a real-time decrease in ion count is measured during warm-up, this could again indicate that the user was unaware of a potential hypoglycemia, especially if the user did not benefit from the downward trend indicated during the previous sensor communication period. In summary, the smart alert function can use data from previous sensor communication periods as well as real-time trend information in the generation of smart alerts, where generation is based on the user's level of awareness, typically compared to a threshold criterion, and may itself depend on one or more data inputs.

[0207] In another implementation, it is important to note that CGM and hypoglycemia alarm thresholds help users identify impending hypoglycemia, enabling them to take action to avoid or minimize a hypoglycemic episode. This feature is particularly useful when patients have difficulty identifying hypoglycemia based on physiological symptoms (such as trembling, sweating, etc.), and these correspond to users with impaired hypoglycemic awareness. Hypoglycemic awareness varies from episode to episode and has been shown to be influenced by recent hypoglycemic events. Notably, recent hypoglycemic events reduce a user's awareness of subsequent episodes.

[0208] Therefore, in another embodiment of the system and method according to this principle, alarm features can be modified based on a recent history of hypoglycemic episodes, making alarms more likely to be provided earlier or more prominently when the patient is least likely to be aware of their hypoglycemia due to their symptoms. Typical alarm features to be modified include, for example, thresholds, intensity, visual display, etc. This implementation minimizes the number and / or annoyance of bothersome alarms (alarms provided when the patient is already aware of hypoglycemia, or alarms provided more frequently than expected) when alarms are less valuable, and maximizes the sensitivity and / or prominence of alarms when the patient cannot rely on symptoms. In other words, user awareness may be further based on a recent history of hypoglycemic episodes, as this has been shown to reduce user awareness of subsequent episodes. In one embodiment, a recent history of hypoglycemic episodes can be collected from past or historical data and used in conjunction with real-time data, such as blood glucose data, rates of change in blood glucose, etc., particularly real-time data indicating potential hypoglycemia, resulting in data output useful for estimating or predicting user awareness. Data output useful for estimating or predicting user awareness can be used, for example, to raise or lower the threshold for estimating or predicting user awareness. In cases with a recent history of hypoglycemia, the threshold may be increased, leading to additional smart alerts. Conversely, if user data indicates a decrease in the frequency of hypoglycemia episodes, such as due to better diabetes management, the threshold may be increased, thus reducing the number of smart alerts.

[0209] In an alternative implementation, the smart alert displayed on the user interface may be incorporated into or have an output in the form described below: U.S. Patent Publication No. US-2015 / 0289821 entitled “GLYCEMIC URGENCY ASSESSMENT ANDALERT INTEFFACE”, which is the property of the assignee of this application and whose entire contents are incorporated herein by reference.

[0210] Used with pumps and other delivery devices

[0211] Intelligent alarms can be advantageously combined with data from infusion pumps and other such delivery devices. Whether in an open-loop, closed-loop, or semi-closed-loop system, the use of intelligent alarms will be partly determined by the delivery device being used.

[0212] In open-loop systems, smart alerts can be used as described above to provide warnings about, for example, dosage information when a user is unaware of a diabetic condition requiring attention. For instance, in the case of meal dosages, machine learning can be used to determine a user's meal patterns, and if a blood glucose trajectory is encountered after a meal that is not part of a typical meal pattern, a smart alert can be generated based on this data to prompt a dosage. Beyond determining the appropriate dose, machine learning and smart alerts can be further employed to determine timing, e.g., preferably not too late or too early. This learning typically involves analyzing past data to understand the timing within the "meal window" when the dose should be delivered. In this case, past data, meal window data, and real-time data are combined, e.g., to indicate that 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 can be used to identify users who frequently overdose, e.g., or cause so-called "rebound" or "rage" doses. This can be particularly relevant when smart alert applications or functions receive data from a pump or pen. If the system can determine that a user has a tendency or pattern toward overdosing, this trend or pattern information can be used to provide intelligent alerts to warn the user against doing so. More generally, this information can often be used to notify intelligent alert functions. This can be particularly important during periods when the user is on an upward trend (e.g., toward hyperglycemia), as overdosing is especially likely to occur at such times.

[0213] As another example of the use of smart alarms in the context of delivery devices, there is a higher risk when a user changes in the infusion kit than the general risk of infusion site or cannula not receiving adequate insulin absorption or being blocked. While blockage alarms exist, they are often useless in detecting problems at the infusion site, especially if the cannula is not completely blocked. Standards of care instruct users to check their blood glucose levels two hours after changing the infusion kit to ensure they are receiving adequate insulin delivery. Undetected cannula problems can lead to hyperglycemia or even ketoacidosis, which can be life-threatening and constitute a major risk associated with pump therapy compared to multiple daily infusions.

[0214] Systems and methods based on this principle can detect infusion kit problems early in the course of a patient's ketoacidosis and can employ intelligent alerts to alert users to this critical diabetic condition, in which the user is often completely unaware of the problem. For example, knowing when a patient has changed their infusion kit can be used to determine the likelihood of an adverse infusion site, and this data can be further used to differentiate other elevations in blood glucose from infusion kit problems. In particular, the system can use data on cannula filling, reservoir replacement, and pump injection to determine if a user has replaced all or part of their infusion kit, and this data can be used in combination with CGM data as part of an estimate or prediction of the user's awareness; fluid pressure data is useful in learning individualized alerts for potential infusion kit problems and can be used similarly. While CGM data and pump data alone are often insufficient to detect infusion kit problems, together they provide more specific alerts that can prevent dangerous events, particularly hyperglycemic events. This can be particularly used to identify and alert users to infusion kit problems, prompting them to address the issue before medical problems, including ketoacidosis, occur.

[0215] Specifically, refer to Figure 42 System 350, Figure 1 The system is shown to also receive data from pump 52 (or the pump data source). By analyzing the pump data, for example by comparing the received pump data with patterns or signatures of known pump data (especially those associated with problems preventing the pump from operating properly), the CGM application can detect cannula / infusion kit problems and provide intelligent alerts about them. Such problems are particularly difficult for users to detect and therefore can be of great importance in predicting or estimating the user's awareness of a diabetic state requiring attention. Therefore, referencing... Figure 43 Flowchart 400 (based on) Figure 2 The flowchart 101) shows that the method for providing intelligent alarms may include the step of receiving pump data (step 54), and it may be used in the calculation of estimation or prediction of user cognitive awareness.

[0216] The pump data received in step 54 may include data related to dosage information, pump shutdown data, pump alarms, pump rewind (time), pump injection (time), cannula filling (timing and volume), fluid pressure, or other data used to generate a blockage alarm. In one embodiment, the API that allows access to such data can be used for a monitoring application. Conversely, intelligent alarm functionality can also be provided in the context of applications that operate and control the delivery device, and in this case, data from CGM applications or other monitoring applications can be used via an appropriate API for intelligent alarm functionality running on the delivery device.

[0217] Therefore, intelligent alerts can be provided to notify users of diabetic conditions that require attention, even when users are unaware of pump problems such as blockages, thus offering more effective alerts to users than existing ones.

[0218] In other embodiments of smart alarms in the context of pumps / pens or other delivery devices, the user interface of such a delivery device can be used to confirm the smart alarm, and conversely, the user interface of a monitoring device can be used to confirm alarms initiated by the delivery device. In other words, data regarding a smart alarm generated by one device can be transmitted to another device using an appropriate transmission protocol, and presented on that device and, in some cases, confirmed. If confirmed, the confirmation can be sent back to the generating device using an appropriate transmission protocol.

[0219] For example, intelligent alerting functions implemented in open-loop systems can provide intelligent alerts prompting users to take various actions based on user awareness. In closed-loop or semi-closed-loop systems, both user awareness and machine awareness can be considered, where the latter involves the machine's awareness of diabetic states requiring attention. This implementation method is... Figure 44 Flowchart 450 is shown. Based on the same... Figure 2 In flowchart 450 of flowchart 101, after the step of determining user awareness (step 17), a step of determining whether the system recognizes a diabetic state requiring attention can be taken (step 21). If the machine recognizes the state, then again, a smart alarm is not needed and can be suppressed or never generated (step 11). If the machine does not recognize the state, a smart alarm can be provided (step 19). It should be noted that the estimation or prediction of user awareness is itself a task performed by the machine, but this differs from the machine awareness in step 19, as the latter involves whether the delivery device is connected and is treating or preparing to treat the diabetic state. For example, if the system determines, for example, based on blood glucose levels and rates of change, that the user may become hypoglycemic, machine awareness might lead to pump shutdown. This differs from the determination in step 17, where the user is aware of the impending hypoglycemic potential and is taking steps to treat it, for example, as part of a typical pattern of treatment by the user consuming carbohydrates.

[0220] Because of the additional steps provided before generating smart alarms, smart alarms can be generated less frequently in closed-loop systems than in open-loop or semi-closed-loop systems, and typically only when the system itself cannot treat a diabetic condition that requires attention.

[0221] A specific implementation is described in the context of a user approaching a hypoglycemic situation. Instead of using only a threshold, where the insulin pump would automatically shut off when the hypoglycemic threshold is crossed, if the estimation or prediction of the user's cognitive awareness performed by the intelligent alert function estimates or predicts that the user or the predicted user is aware of a diabetic state requiring attention, the pump can shut off faster than if the user is unaware, thus avoiding a dangerous hypoglycemic situation. A typical situation where the user is unaware is during the night when the user is sleeping.

[0222] Systems and methods for providing intelligent alerts to users have been described, enabling users to be alerted to diabetes conditions requiring attention in a more effective manner than existing efforts.

[0223] Changes can be understood. For example, systems and methods can interact with other applications and be used to provide alerts. For instance, if the system estimates or predicts that a user is unaware of an impending hypoglycemic diabetic state requiring attention, but data from a GPS application on the user's smart device indicates proximity to a food source (e.g., a gas station or grocery store), an alert might appear on the GPS application regarding the impending situation and the location where corrective action can be taken. Typically, the data from the GPS application will provide information about the location of the food source, but data from other applications, such as meal tracking applications, can also be utilized, which may also provide information about the restaurant's location. Such alerts typically use appropriate APIs between the GPS application and the CGM application, as well as APIs between other employed applications. In some cases, data from the GPS application will indicate that the user is heading in the direction of a commonly visited food source, such as a restaurant the user frequents. In particular, if it can be clearly determined, for example, that there are no other frequently visited locations in that direction, such GPS data can be used to at least temporarily suppress the generation of smart alerts in the event of a potential mild hypoglycemic event. Generally, GPS data used in this way can be advantageously used for estimating or predicting user awareness.

[0224] Implementation of systems and methods based on this principle to achieve intelligent alarm / function

[0225] Various systems can be used to implement the intelligent alarm function based on this principle. For example, in one implementation, a mobile computing device dedicated to health and diabetes management, such as a smart device or smartphone, can be used. The mobile computing device can be a device dedicated to health / diabetes management, or it can be a more general device specifically designed for health and diabetes management. The device can be configured by the user to suit the user's lifestyle and preferences. The mobile device can be based on an Android or iOS (or other) operating system and utilize a touchscreen interface. In some cases, the operating system can be customized or controlled for managing services, for example, for providing data to the cloud and optimizing / controlling elements of the user experience. The device may include one or more public radio communication links, such as Bluetooth Low Energy (BLE). It may also include WiFi or other data connectivity technologies for remote monitoring, data transfer, and software updates.

[0226] Mobile computers can be used in conjunction with (“tethered”) wearable computing devices (e.g., smartphones). Watches may also be useful when not directly connected (not tethered) to a mobile device. Such watches or other such wearable devices may include sensors such as heart rate monitors, and data from these monitors may be used to notify smart alert functions. For example, such a monitor may be used to determine if the user is exercising (possibly in conjunction with accelerometer data), and if so, the user may expect more or fewer alerts / alarms.

[0227] This wearable device can also allow for the configuration of smart alarm functions to present the possibility of a tactile display, thereby providing significant privacy and autonomy in social situations and usefulness, such as during sleep. The smart alarm function can be configured to first provide an alarm on the wearable device if a wearable device with a tactile display is detected, and then, if the alarm or alert on the wearable device is ignored, subsequently provide an alarm on other devices (e.g., smartphones).

[0228] Users can choose from a curated ecosystem of apps. This selection may include apps from, for example, Databetes (meal memory), TrainingPeaks (activity / fitness), Tidepool, MyFitnessPal, Nike+, Withings, and others. Other apps may be included for retrospective insights / pattern recognition to optimize treatment and for determining a user's awareness of their current diabetes status and areas requiring attention. The ecosystem may further include an app that provides basic diabetes management instructions for newly diagnosed users with T1D (or their parents). A different set of instructions may be included for newly diagnosed users with T2D.

[0229] Mobile computing enables data connectivity between users (patients) and clinicians via EMR (e.g., Epic). Mobile computing platforms support and facilitate user / vendor dialogue.

[0230] In another particular implementation, the mobile computer can be configured to exclude functions unrelated to health management.

[0231] Security settings are typically implemented. For example, the smart alert function might be disabled until CGM data is collected. Thus, the setup can be data-driven and data-validated. For example, it might require one week's worth of data, two weeks' worth, one month's worth, and so on. As mentioned above, initial setup or training can be performed without data or using data from existing user devices (associated with the subject user). This can then be further optimized, and in particular, the smart alert function can execute data analysis or diagnostic subroutines to determine if sufficient data has been collected to allow functions related to smart alerts, such as allowing prediction or estimation of user cognitive awareness, or alerting the user or HCP to perform the same action. Alternatively, the smart alert function can be implemented automatically, but requires confirmation from the user or HCP.

[0232] As mentioned earlier, users are often annoyed by receiving multiple alarms or alerts, and the Smart Alarm feature, based on this principle, can be used to minimize this annoyance. However, when multiple notifications are invoked and provided, the Smart Alarm feature can also be configured to allow subsequent notifications to include additional information so that the user receives a summary of all actual or potential alarms. For example, if the first notification provides the user with an indication that the value may be low, and the system subsequently knows via the Smart Alarm feature to stop alerting the user or suppress alarms / alarms until another alarm threshold is reached, then a subsequent notification might contain a different, substantive message, such as, "You have now been in a low-value state for 20 minutes."

[0233] Systems and methods based on this principle can be further used to detect missed opportunities or windows of opportunity. In particular, machine learning can be used to understand when users typically take action, especially actions with positive outcomes. If a similar situation arises, but the user does not act proactively—for example, they are far from their smart device and unaware of the opportunity—a smart alert regarding the missed opportunity can then be provided.

[0234] Systems and methods for implementing intelligent alerts have been described, particularly in the context of estimated or anticipated user awareness of a diabetic state requiring attention. Given this description, many of the variations described above will be understood.

[0235] Sensor system

[0236] Figure 45 An exemplary system 100 according to some exemplary embodiments is depicted. System 100 includes a continuous analyte sensor system 8, which includes sensor electronics 12 and a continuous analyte sensor 10. System 100 may include other devices and / or sensors, such as a drug delivery pump 2 and a blood glucose meter 4. The continuous analyte sensor 10 may be physically connected to the sensor electronics 12 and may be integral with (e.g., non-releasably attached) or releasably attached to the continuous analyte sensor 10. The sensor electronics 12, the drug delivery pump 2, and / or the blood glucose meter 4 may be coupled to one or more devices (e.g., display devices 14, 16, 18, and / or 20).

[0237] In some exemplary embodiments, system 100 may include a cloud-based analyte processor 490 configured to analyze analyte data (and / or other patient-related data) provided via network 406 (e.g., via wired, wireless, or a combination thereof) from sensor system 8 and other devices associated with the subject (also referred to as user or patient) (e.g., display devices 14-20, etc.) and generate reports providing advanced information (e.g., statistics) about the measured analytes within a specific time frame. A full discussion of the use of cloud-based analyte processing systems can be found in U.S. Patent Application No. 13 / 788375, filed March 7, 2013, entitled "CALCULATION ENGINE BASED ON HISTOGRAMS," the entire contents of which are incorporated herein by reference. In some embodiments, one or more steps of a factory calibration algorithm may be performed in the cloud.

[0238] In some exemplary embodiments, sensor electronics 12 may include electronic circuitry associated with measuring and processing data generated by the continuous analyte sensor 10. The 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. Sensor electronics 12 may include hardware, firmware, software, or a combination thereof to provide measurements of analyte levels via a continuous analyte sensor (e.g., a continuous glucose sensor). Reference is made below. Figure 46 An exemplary embodiment of the sensor electronics 12 is further described.

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

[0240] As described above, sensor electronics 12 can be coupled (e.g., wirelessly, etc.) to one or more devices (e.g., display devices 14, 16, 18, and / or 20). Display devices 14, 16, 18, and / or 20 can be configured to present information (and / or alarms), such as sensor information transmitted by sensor electronics 12 for display on display devices 14, 16, 18, and / or 20.

[0241] The display device may include a relatively small keychain-like display device 14, a relatively large handheld display device 16, a cellular phone 18 (e.g., a smartphone, tablet, etc.), a computer 20, and / or any other user device configured to at least present information (e.g., smart alarms, medication delivery information, discrete self-monitoring blood glucose readings, heart rate monitors, calorie intake monitors, etc.). In some cases, if the vehicle is signaling to, for example, a user's smartphone, the display device may be, for example, the user's vehicle. For example, the vehicle may communicate with or pair with the smartphone via Bluetooth. Other display devices may include a television, a smart refrigerator, etc.

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

[0243] In some exemplary embodiments, the relatively small keychain-like display device 14 may include a watch, belt, necklace, pendant, jewelry, adhesive patch, pager, keychain, plastic card (e.g., credit card), identity (ID) card, etc. 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 alarms, such as numerical values ​​and arrows or color codes).

[0244] In some exemplary embodiments, the relatively large handheld display device 16 may include a handheld receiver device, a handheld computer, or the like. This large display device may include a relatively large display (e.g., larger than the small display device 14) and may be configured to display information (including intelligent alarms, such as a graphical representation of continuous sensor data, which includes current and historical sensor data output by the sensor system 8).

[0245] In some exemplary embodiments, the continuous analyte sensor 10 includes a sensor for detecting and / or measuring an analyte, and the continuous analyte sensor 10 can be configured as a non-invasive device, subcutaneous device, transdermal device, and / or intravascular device for continuously detecting and / or measuring analytes. In some exemplary embodiments, the continuous analyte sensor 10 can analyze multiple intermittent blood samples, but other analytes may also be used.

[0246] In some exemplary embodiments, the continuous analyte sensor 10 may include a blood glucose sensor configured to measure blood glucose in blood or interstitial fluid using one or more measurement techniques, such as enzymatic, chemical, physical, electrochemical, spectrophotometric, optical rotation, calorimetric, iontophoresis, radiometric, and immunochemical methods. In embodiments where the continuous analyte sensor 10 includes a blood glucose sensor, the blood glucose sensor may include any device capable of measuring blood glucose concentration and may use various techniques to measure blood glucose, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring), to provide data indicating blood glucose concentration in the subject, such as a data stream. The data stream may be sensor data (raw and / or filtered data) that can be converted into a calibration data stream to provide blood glucose values ​​to a subject such as a user, patient, or caregiver (e.g., a parent, relative, guardian, teacher, doctor, nurse, or any other individual interested in the subject's health). In addition, the continuous analyte sensor 10 can be implanted as at least one of the following types of sensors: implantable blood glucose sensor, percutaneous blood glucose sensor implanted in a main blood vessel or outside the body, subcutaneous sensor, refillable subcutaneous sensor, and intravascular sensor.

[0247] In some exemplary implementations, a smart alert can be provided to notify the user when diabetes supplies are running low, and then automatically reorder or prompt the user to reorder. For example, in some cases, the system may know that the user typically orders two days in advance, and the system may be aware that the sensor has two days of life remaining. In this case, the system can provide a smart alert to notify the user that it is now time to order new diabetes supplies.

[0248] When user confirmation is required, it can be confirmed on a receiver, mobile device, or other such device. In some cases, alarms or alerts may be confirmed directly on the transmitter. In some cases, fingerprint recognition can be used for confirmation so that non-users cannot harmfully confirm user alarms or alerts that might result in the user not receiving such alarms or alerts.

[0249] While this disclosure relates to some embodiments including a continuous analyte sensor 10 containing a blood glucose sensor, the continuous analyte sensor 10 may also include other types of analyte sensors. Furthermore, although some embodiments consider the blood glucose sensor to be an implantable blood glucose sensor, other types of devices capable of detecting blood glucose concentration and providing an output signal representing the blood glucose concentration may also be used. Additionally, although the description herein considers blood glucose as an analyte to be measured, processed, etc., other analytes may also be used, including, for example, ketone bodies (e.g., acetone, acetoacetic acid, β-hydroxybutyrate, lactate, etc.), glucagon, acetyl-CoA, triglycerides, fatty acids, intermediates in the citric acid cycle, choline, insulin, cortisol, testosterone, etc.

[0250] Figure 46 Examples of sensor electronics 12 according to some exemplary embodiments are depicted. Sensor electronics 12 may include sensor electronics configured to process sensor information (e.g., sensor data) and generate, for example, transformed sensor data and displayable sensor information via a processor module. For example, the processor module may transform 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 rate information, sensor diagnostic information, location information, alarm / alarm information, calibration information (e.g., which may be determined by calibration algorithms, sensor data smoothing and / or filtering algorithms, etc.).

[0251] In some embodiments, processor module 214 is configured to perform most (if not all) of the data processing, including data processing related to factory calibration. Processor module 214 may be integrated into sensor electronics 12 and / or may be remotely located, for example, in one or more of devices 14, 16, 18 and / or 20 and / or cloud 490. In some embodiments, processor module 214 may include multiple smaller sub-components or sub-modules. For example, processor module 214 may include an alarm module (not shown) or a prediction module (not shown), or any other suitable module that can be used to efficiently process data. When processor module 214 comprises multiple sub-modules, the sub-modules may be located within processor module 214, including within sensor electronics 12 or other associated devices (e.g., 14, 16, 18, 20 and / or 490). For example, in some embodiments, processor module 214 may be at least partially located within cloud-based analytics processor 490 or elsewhere in network 406.

[0252] In some exemplary embodiments, processor module 214 may be configured to calibrate sensor data, and data memory 220 may store calibrated sensor data points as converted sensor data. Furthermore, in some exemplary embodiments, processor module 214 may be configured to wirelessly receive calibration information from a display device (e.g., devices 14, 16, 18, and / or 20) to calibrate sensor data from sensor 12. Additionally, processor module 214 may be configured to perform additional algorithmic processing on sensor data (e.g., calibration and / or filtered data and / or other sensor information), and data memory 220 may be configured to store converted sensor data and / or sensor diagnostic information related to the algorithm. Processor module 214 may be further configured to store and use calibration information determined from calibration.

[0253] In some exemplary embodiments, sensor electronics 12 may include an application-specific integrated circuit (ASIC) 205 coupled to user interface 222. ASIC 205 may further include a potentiometer 210, a telemetry module 232 for transmitting data from sensor electronics 12 to one or more devices (e.g., devices 14, 16, 18, and / or 20), and / or other components for signal processing and data storage (e.g., processor module 214 and data memory 220). Although Figure 46 ASIC 205 is described, but other types of circuitry may also be used, including field-programmable gate arrays (FPGAs), one or more microprocessors configured to provide some (if not all) of the processing performed by sensor electronics 12, analog circuitry, digital circuitry, or combinations thereof.

[0254] exist Figure 46 In the example shown, potentiometer 210 is coupled to continuous analyte sensor 10, such as a blood glucose sensor, via a first input port 211 for sensor data to generate sensor data from the analyte. Potentiometer 210 can also provide a voltage to continuous analyte sensor 10 via data line 212 to bias the sensor for measuring values ​​(e.g., current, etc.) of the analyte concentration in the indicator body (also referred to as the analog portion of the sensor). Depending on the number of working electrodes at continuous analyte sensor 10, potentiometer 210 may have one or more channels.

[0255] In some exemplary embodiments, potentiometer 210 may include a resistor that converts a current value from sensor 10 into a voltage value. In other exemplary embodiments, a current-to-frequency converter (not shown) may be configured to continuously integrate measured current values ​​from sensor 10 using, for example, a charge counting device. In some exemplary embodiments, an analog-to-digital converter (not shown) may digitize the analog signal from sensor 10 into a so-called “count” to allow processing by processor module 214. The resulting count may be directly correlated with the current measured by potentiometer 210, which may be directly correlated with the level of an analyte in the body (e.g., blood glucose level).

[0256] Telemetry module 232 may be operatively connected to processor module 214 and may provide the hardware, firmware, and / or software for enabling wireless communication between sensor electronics 12 and one or more other devices (e.g., display devices, processors, network access devices, etc.). Various wireless radio technologies that may be implemented in telemetry module 232 include Bluetooth(R), Bluetooth Low Energy(R), ANT, ANT+, ZigBee, IEEE 802.11, IEEE 802.16, cellular radio access technologies, radio frequency (RF), inductive (e.g., magnetic), near field communication (NFC), infrared (IR), paging network communication, magnetic induction, satellite data communication, spread spectrum communication, frequency hopping communication, and so on. In some exemplary embodiments, telemetry module 232 includes a Bluetooth(R) chip, but Bluetooth technology may also be implemented in a combination of telemetry module 232 and processor module 214.

[0257] The processor module 214 can control the processing performed by the sensor electronics 12. For example, the processor module 214 can be configured to process data from the sensor (e.g., counting), filter the data, calibrate the data, perform fail-safe checks, etc.

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

[0259] Processor module 214 may further include a data generator (not shown) configured to generate data packets for transmission to devices (e.g., display devices 14, 16, 18, and / or 20). Additionally, processor module 214 may generate data packets for transmission to these external sources via telemetry module 232. In some exemplary embodiments, as described above, the data packets may be customizable for each display device and / or may include any available data, such as timestamps, displayable sensor information, converted sensor data, identification codes of the sensor and / or sensor electronics 12, raw data, filtered data, calibration data, rate of change information, trend information, error detection or correction, etc.

[0260] The processor module 214 may also include program memory 216 and other memory 218. The processor module 214 may be coupled to a communication interface (e.g., communication port 238) and a power source (e.g., battery 234). Furthermore, the battery 234 may be further coupled to a battery charger and / or regulator 236 to provide power to the sensor electronics 12 and / or charge the battery 234.

[0261] Program memory 216 may be implemented as a semi-static memory for storing data and code (also referred to as program code), such as an identifier of coupled sensor 10 (e.g., sensor identifier (ID)), and the code for configuring ASIC 205 to perform one or more operations / functions described herein. For example, the program code may configure processor module 214 to process data streams or counts, perform filtering, execute calibration methods, perform fail-safe checks, etc.

[0262] The memory 218 can also be used to store information. For example, the processor module 214, which includes the memory 218, can be used as a system cache to provide temporary storage for recent sensor data received from the sensor. In some exemplary embodiments, the memory may include storage components such as read-only memory (ROM), random access memory (RAM), dynamic RAM, static RAM, non-static RAM, erasable programmable read-only memory (EEPROM), rewritable ROM, flash memory, etc.

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

[0264] 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), etc. Components including user interface 222 can provide control for interaction with a user (e.g., a subject). One or more buttons 224 may allow, for example, toggling, menu selection, option selection, status selection, yes / no response to on-screen questions, "off" function (e.g., for alarms), "confirm" function (e.g., for alarms), reset, etc. LCD 226 may provide, for example, visual data output to the user. Audio transducer 230 (e.g., a speaker) may provide an audible signal in response to triggering certain alarms (e.g., present and / or predicted symptoms of hyperglycemia and hypoglycemia). In some exemplary embodiments, the audible signal may be distinguished by tone, volume, duty cycle, pattern, duration, etc. In some exemplary embodiments, the audible signal can be configured to mute (e.g., confirm or turn off) the sensor electronics 12 by pressing one or more buttons 224 on the sensor electronics 12 and / or by using a button or selection on a display device (e.g., a key fob, a mobile phone, etc.). In some cases, audible alarms can be muted while visual alarms can still be displayed. As a specific example, audible alarms can be muted while the user can still view the blood glucose trajectory and / or threshold line. In this way, the user is notified that they are still at a high or low level while avoiding the annoyance of audible alarms.

[0265] Although reference Figure 46 Audio and vibration alarms are described, but other alarm mechanisms may also be used. For example, in some exemplary embodiments, tactile alarms are provided, which include a stabbing mechanism configured to respond to one or more alarm conditions, such as "poke" or physical contact with the patient.

[0266] In one exemplary implementation, a default alarm method (e.g., display on a screen) may be used. However, if an alarm or alert using the default mode is not acknowledged within a predetermined time period, the alarm or alert may escalate in a subsequent reminder alarm or alert, and many use alternative notification means, including using connected devices (e.g., medication delivery devices). For example, if the original or initial alarm or alert is not acknowledged, a mobile device and / or a connected medication device may provide supplementary or auxiliary alarms, such as audible alarms, like a phone emitting a sound, in a subsequent or reminder alarm or alert that may occur, for example, five minutes later. If the alarm or alert is still not acknowledged, and if the pump or pen is connected to a mobile device (e.g., refer to...) Figure 45If the drug delivery pump 2 is connected to a device that performs response processing (e.g., mobile device 18 or processor 490, or even sensor electronics 12 in some cases), the drug delivery device (pump or pen) can be made to emit an audible, tactile, or visual alarm or alert, for example, with a moderate amplitude (e.g., moderate volume), lasting for a predetermined period of time (e.g., 20 seconds). Similarly, if these alarms or alerts have not yet been acknowledged, and again if the pump or pen is connected to a device that performs response processing, it can be made to emit an audible, tactile, or visual alarm or alert, for example, with a high amplitude (e.g., high volume), lasting for a predetermined period of time (e.g., 20 seconds).

[0267] Other methods can also be used to present alarms or alerts. For example, dogs are increasingly being used as diabetes alert dogs or companion animals. In either case, components of the system can be configured with an ultrasonic transmitter that causes the ultrasonic transducer to emit an ultrasonic pulse if the user's blood glucose level approaches a dangerous level. Diabetes alert dogs will typically detect impending hypoglycemia or hyperglycemia; however, if they fail to detect it, the ultrasonic pulse may provide an alert. Similarly, companion animals not trained as diabetes alert dogs can be trained to recognize the pulse as a reason to alert their owners (i.e., the diabetic user). Even without specialized training, the ultrasonic pulse may cause a degree of agitation, thus warning the user that something is wrong. The ultrasonic transmitter can be signal-coupled to various parts of the system, such as a transmitter, smartphone, receiver, or other device. As the severity of the danger increases, the ultrasonic tone may change, so the diabetic companion can be trained to respond accordingly.

[0268] In another example, users can be notified of blood glucose alerts, alarms, and notifications without even having to view their monitoring device using unique haptic or vibration patterns that can be presented on a smart device or watch. Haptic / vibration patterns can be presented and constructed using similar prioritization principles for audible or visual alarms and alerts based on relative urgency or security considerations. For example, higher-priority alarms might employ higher vibration speeds, shorter intervals between vibrations, and longer durations, and vice versa for lower-priority alarms. Users can customize these vibration patterns to fit their specific requirements and designs. This allows alarms or alerts to be communicated to the user, and the user can even receive information about the type and / or urgency of the alarm without having to look at the display or listen to the alarm (which can be annoying as it may disturb others nearby).

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

[0270] The battery charger and / or regulator 236 can be configured to receive energy from internal and / or external chargers. In some exemplary embodiments, the battery regulator (or balancer) 236 regulates the recharging process by discharging excess charging current to allow all battery cells or batteries in the sensor electronics 12 to be fully charged without overcharging other battery cells or batteries. In some exemplary embodiments, the battery 234 (or multiple batteries) is configured to be charged via an inductive and / or wireless charging pad, but any other charging and / or power mechanism may also be used.

[0271] One or more communication ports 238 (also referred to as external connectors) may be provided to allow communication with other devices, such as a PC communication (com) port to enable communication with systems independent of or integrated with sensor electronics 12. The communication ports may include, for example, a serial (e.g., Universal Serial Bus or "USB") communication port and allow communication with another computer system (e.g., a PC, a personal digital assistant or "PDA"), a server, etc. In some exemplary embodiments, sensor electronics 12 is capable of transmitting historical data to a PC or other computing device for retrospective analysis by the patient and / or HCP. As another example of data transmission, plant information may also be sent from the sensor or from a cloud data source to the algorithm.

[0272] One or more communication ports 238 may further include a second input port 237 in which calibration data can be received and an output port 239 in which calibration data or data to be calibrated can be sent to a receiver or mobile device. Figure 46 These aspects are illustrated schematically. It should be understood that ports can be physically separated, but in alternative implementations, a single communication port can provide the functionality of a second input port and an output port.

[0273] Exemplary embodiments

[0274] Non-transitory computer-readable medium 1: A non-transitory computer-readable medium comprising instructions for causing a computing environment to perform a method of dynamically adjusting or regulating user alerts based on cognitive awareness determination, thereby providing data related to the treatment of a diabetes state requiring attention, the method comprising the steps of: identifying a current or future diabetes state requiring attention, the identification being at least in part based on a blood glucose concentration value; estimating or predicting the user's cognitive awareness of the identified current or future diabetes state requiring attention; and, if the estimation or prediction results in the user not being aware of the identified current or future diabetes state requiring attention, alerting the user with a user prompt on the user interface of a monitoring device, the user prompt indicating a diabetes state requiring attention, thereby alerting the user to a diabetes state requiring attention only if the user is not aware of the diabetes state requiring attention and the notification is effective for the user.

[0275] Non-transitory computer-readable medium 2: According to an embodiment of non-transitory computer-readable medium 1, wherein the alarm is optimized for the patient's cognitive awareness, resulting in fewer alarms being generated compared to alarms provided without taking the user's cognitive awareness into account.

[0276] Non-transitory computer-readable medium 3: According to an embodiment of any one of the non-transitory computer-readable media 1 to 2, the monitoring device is a smartphone, smartwatch, dedicated monitoring device or tablet computer.

[0277] Non-transitory computer-readable medium 4: According to an embodiment of any one of non-transitory computer-readable media 1 to 3, excessive prompts, repetitive prompts, or harassing prompts are minimized or avoided.

[0278] Non-transitory computer-readable medium 5: According to an embodiment of any one of non-transitory computer-readable media 1 to 4, wherein the user is able to establish trust that the system will issue alerts only when there is a notification that is optimized or effective for the user.

[0279] Non-transitory computer-readable medium 6: According to an embodiment of any one of non-transitory computer-readable media 1 to 5, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the identified current or future diabetes state requiring attention includes atypical blood glucose trajectories.

[0280] Non-transitory computer-readable medium 7: According to an embodiment of non-transitory computer-readable medium 6, the atypical glucose trajectory includes atypical patterns or atypical glucose responses.

[0281] Non-transitory computer-readable medium 8: According to an embodiment of any one of non-transitory computer-readable media 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 diabetic state requiring attention by taking action without user prompting.

[0282] Non-transitory computer-readable medium 9: According to an embodiment of non-transitory computer-readable medium 8, the action is drug administration.

[0283] Non-transitory computer-readable medium 10: According to an embodiment of non-transitory computer-readable medium 8, the action is dining.

[0284] Non-transitory computer-readable medium 11: According to an embodiment of non-transitory computer-readable medium 8, the action is movement.

[0285] Non-transitory computer-readable medium 12: According to an embodiment of any one of non-transitory computer-readable media 1 to 11, wherein the estimation or prediction of the user's cognitive awareness includes determining whether the user has entered meal or dosage data, or whether a dosage calculation has been requested.

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

[0287] Non-transitory computer-readable medium 14: According to an embodiment of any one of non-transitory computer-readable media 1 to 13, wherein the estimation or prediction of the user's cognitive awareness includes receiving user input and making the estimation or prediction at least in part based on the received input.

[0288] Non-transitory computer-readable medium 15: According to an embodiment of any one of non-transitory computer-readable media 1 to 14, wherein the estimation or prediction of the user's cognitive awareness includes analyzing historical data of the user's blood glucose values ​​relative to time.

[0289] Non-transitory computer-readable medium 16: According to an embodiment of any one of non-transitory computer-readable media 1 to 15, the steps of repeatedly identifying and estimating or predicting are performed until it is estimated or predicted that the user is unaware of the identified diabetes state requiring attention, and then the step of alerting the user with the user prompt is performed.

[0290] Non-transitory computer-readable media 17: According to an embodiment of any one of non-transitory computer-readable media 1 to 16, wherein the estimation or prediction of the user's cognitive awareness includes receiving data from an application or website via an appropriate API.

[0291] Non-transitory computer-readable medium 18: According to an embodiment of any of the non-transitory computer-readable media 1 to 17, the estimation or prediction is at least partially based on location data, i.e., GPS data.

[0292] Non-transitory computer-readable medium 19: According to an embodiment of non-transitory computer-readable medium 18, the location data is the location data of the user.

[0293] Non-transitory computer-readable medium 20: According to an embodiment of non-transitory computer-readable medium 18, the location data is the location data of the user's followers.

[0294] Non-transitory computer-readable medium 21: According to an embodiment of any one of non-transitory computer-readable media 1 to 20, wherein the estimation or prediction of the user's cognitive awareness is based at least in part on one or more of the following: group data, data associated with behavior or contextual information, data associated with the user's life goals, data associated with the user's privacy settings, or a combination thereof.

[0295] Non-transitory computer-readable medium 22: According to an embodiment of any one of non-transitory computer-readable media 1 to 21, wherein the estimation or prediction of the user's cognitive awareness is based at least in part on real-time data, and wherein the real-time data includes one or more of the following: data associated with a GPS application in the monitoring device, data associated with an accelerometer in the monitoring device, data associated with behavior or background information, data associated with the location of the user's follower, data associated with the user's metabolic rate, data associated with the user's glycemic urgency index, heart rate data, sweat content data, data associated with the user's wearable sensors, insulin data, or a combination thereof.

[0296] Non-transitory computer-readable medium 23: According to an embodiment of any of the non-transitory computer-readable media 1 to 22, wherein the estimation or prediction of the user's cognitive consciousness includes identifying one or more individualized patterns associated with the user.

[0297] Non-transitory computer-readable medium 24: According to an embodiment of non-transitory computer-readable medium 23, the individualized pattern corresponds to the envelope of the characteristic analyte concentration signal trajectory that occurs before or after the event.

[0298] Non-transitory computer-readable medium 25: According to an embodiment of non-transitory computer-readable medium 24, the event is associated with meals, exercise, or sleep.

[0299] Non-transitory computer-readable medium 26: According to an embodiment of non-transitory computer-readable medium 25, wherein the determination is that the user is unaware whether the current signal trajectory falls outside the envelope of the characteristic analyte concentration signal trajectory.

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

[0301] Non-transitory computer-readable medium 28: According to an embodiment of any of the non-transitory computer-readable media 1 to 27, the user prompt is displayed immediately if the result of the estimation or prediction is that the user does not recognize a diabetic state that requires attention.

[0302] Non-transitory computer-readable medium 29: According to an embodiment of any of the non-transitory computer-readable media 1 to 28, wherein the estimation or prediction is further based on the user's location information, wherein the location information indicates that the user is within a predetermined threshold range of a food store or restaurant.

[0303] Non-transitory computer-readable medium 30: According to an embodiment of any of the non-transitory computer-readable media 1 to 29, if the result of the estimation or prediction is that the user does not recognize a diabetic state that requires attention, the user is alerted with the user prompt after a time delay, the duration of which is based on at least the identified diabetic state requiring attention and the blood glucose concentration value and / or the rate of change of the blood glucose concentration value.

[0304] Non-transitory computer-readable medium 31: According to an embodiment of any one of non-transitory computer-readable media 1 to 30, the user prompt includes an inquiry about user input data.

[0305] Non-transitory computer-readable medium 32: According to an embodiment of non-transitory computer-readable medium 31, the query requests user input of data regarding medication, meals, or exercise.

[0306] Non-transitory computer-readable medium 33: According to an embodiment of any of the non-transitory computer-readable media 1 to 32, if the user ignores a user prompt determined by data from the user interface or data from an accelerometer associated with the monitoring device, and if the user prompt does not correspond to a dangerous situation, information about the user ignoring the user prompt in a previous situation is stored and the stored information is used as part of a subsequent estimation or prediction step.

[0307] Non-transitory computer-readable medium 34: According to an embodiment of any of the non-transitory computer-readable media 1 to 33, wherein the identification of a current or future diabetes state requiring attention includes determining clinical values ​​of blood glucose concentration and / or blood glucose variability rate and / or blood glucose urgency index values.

[0308] Non-transitory computer-readable medium 35: According to an embodiment of any of the non-transitory computer-readable media 1 to 34, identifying a current or future diabetes state requiring attention includes measuring a blood glucose signal signature and comparing the measured signature with a plurality of bin signatures, and classifying the diabetes state requiring attention into one of the plurality of bins based on the comparison.

[0309] Non-transitory computer-readable medium 36: According to an embodiment of any of the non-transitory computer-readable media 1 to 35, wherein identifying a current or future diabetes state requiring attention includes determining one or more time-based trends in blood glucose concentration values ​​and making the identified state based on the determined trend.

[0310] Non-transitory computer-readable medium 37: According to an embodiment of non-transitory computer-readable medium 36, the trend corresponds to whether the blood glucose concentration value fluctuates within a range or increases or decreases, wherein fluctuation is equivalent to remaining within a predetermined range for a period of more than 5 minutes, 10 minutes, 15 minutes, or 30 minutes.

[0311] Non-transitory computer-readable medium 38: According to an embodiment of non-transitory computer-readable medium 37, fuzzy boundaries are used to define the range.

[0312] Non-transitory computer-readable medium 39: According to an embodiment of any one of the non-transitory computer-readable media 1 to 28, it further includes transmitting an indication of a diabetic state requiring attention to a medication pump.

[0313] Non-transitory computer-readable medium 40: According to an embodiment of non-transitory computer-readable medium 39, if the result of the estimation or prediction is that the user does not recognize a diabetic state that requires attention, it further includes activating the drug pump to deliver a drug dose.

[0314] Non-transitory computer-readable medium 41: According to an embodiment of non-transitory computer-readable medium 40, the drug dose is a meal dose of insulin.

[0315] Non-transitory computer-readable medium 42: According to an embodiment of non-transitory computer-readable medium 40, if the result of the estimation or prediction is that the user does not recognize a diabetic state that requires attention, it further includes activating the drug pump to change the basal rate.

[0316] Non-transitory computer-readable medium 43: According to an embodiment of non-transitory computer-readable medium 40, the drug is insulin.

[0317] Non-transitory computer-readable medium 44: According to an embodiment of non-transitory computer-readable medium 39, it further includes determining whether the drug pump can completely or partially treat a diabetic state requiring attention, and if the diabetic state can be completely or partially treated, then the user is not alerted or the user prompt is changed, compared to a case where the drug pump cannot treat the diabetic state.

[0318] Non-transitory computer-readable medium 45: According to an embodiment of any of the non-transitory computer-readable media 1 to 44, if the result of the estimation or prediction is that the user is unaware of a diabetic state that requires attention, then it is determined when to alert the user with the user prompt.

[0319] Non-transitory computer-readable media 46: According to an embodiment of any of the non-transitory computer-readable media 1 to 45, wherein, if displayed, the user prompt includes a color or arrow in place of or as a supplement to the blood glucose concentration value.

[0320] Non-transitory computer-readable media 47: According to an embodiment of any of the non-transitory computer-readable media 1 to 46, wherein, if displayed, the user prompt includes a prediction of a blood glucose concentration value.

[0321] Non-transitory computer-readable media 48: According to an embodiment of any one of non-transitory computer-readable media 1 to 47, wherein, if displayed, the user prompt includes an audible indicator, and wherein the volume of the audible indicator is automatically adjusted for ambient noise measured by the monitoring device or a means of signaling to the monitoring device, wherein the adjustment for ambient noise includes increasing the volume of the audible indicator relative to the ambient noise until a signal-to-noise ratio threshold level is reached.

[0322] Non-transitory computer-readable medium 49: According to an embodiment of any of the non-transitory computer-readable media 1 to 48, the user prompt relates to a diabetic state requiring attention that occurs during a period when the user's glycemic urgency index is low.

[0323] Non-transitory computer-readable medium 50: According to an embodiment of any of the non-transitory computer-readable media 1 to 49, if the result of the estimation or prediction is that the user is not aware of a diabetic state requiring attention, the user is alerted with the user prompt after a delay, the delay being based not on duration but on the identified diabetic state requiring attention and the blood glucose concentration value and / or the rate of change of the blood glucose concentration value.

[0324] Non-transitory computer-readable medium 51: According to an embodiment of any of the non-transitory computer-readable media 1 to 50, wherein if the result of the estimation or prediction is that the user does not recognize a diabetic state that requires attention, the user is alerted with the user prompt after a delay, the delay being based not on duration but on an individualized pattern learned by the monitoring device.

[0325] Non-transitory computer-readable medium 52: According to an embodiment of any one of non-transitory computer-readable media 1 to 51, wherein the identified diabetes state requiring attention corresponds to an atypical blood glucose response or atypical pattern, and wherein the atypical response or atypical pattern is learned by the monitoring device rather than by user input.

[0326] Non-transitory computer-readable medium 53: According to an embodiment of any of the non-transitory computer-readable media 1 to 52, the user prompt is displayed in a dynamic timing sequence on a pre-designed user interface, rather than on an adaptive user interface.

[0327] Non-transitory computer-readable medium 54: According to an embodiment of any of the non-transitory computer-readable media 1 to 53, if the result of the estimation or prediction is that the user is unaware of a diabetic state requiring attention, the user is immediately alerted with the user prompt, regardless of whether there is an instruction to alert the user without using a user prompt received from another monitoring device application.

[0328] Non-transitory computer-readable media 55: According to an embodiment of any of the non-transitory computer-readable media 1 to 54, if the result of the estimation or prediction is that the user is unaware of a diabetic state requiring attention, the user is immediately alerted with the user prompt, regardless of whether there is an instruction to alert the user without using user prompts based on data or settings from other users.

[0329] Non-transitory computer-readable media 56: According to an embodiment of any of the non-transitory computer-readable media 1 to 55, wherein the estimation or prediction of whether the user recognizes a diabetes state requiring attention is based at least in part on real-time data and not entirely on retrospective data.

[0330] Non-transitory computer-readable medium 57: According to an embodiment of any one of the non-transitory computer-readable media 1 to 56, wherein the alarm to the user by user prompting on the user interface of the monitoring device includes presenting an ultrasonic pulse.

[0331] Non-transitory computer-readable medium 58: According to an embodiment of any one of non-transitory computer-readable media 1 to 57, wherein the alarm to the user by user prompting on the user interface of the monitoring device includes: if the user ignores the first alarm, issuing a prompt on the second user interface of the monitoring device.

[0332] Non-transitory computer-readable media 59: According to an embodiment of non-transitory computer-readable media 58, the monitoring device is a mobile cellular device, and the second user interface includes an audio channel.

[0333] Non-transitory computer-readable media 60: According to an embodiment of non-transitory computer-readable media 59, the prompt is an audible prompt and is played through the audio channel.

[0334] Non-transitory computer-readable media 61: According to an embodiment of non-transitory computer-readable media 58, the monitoring device is a mobile cellular device, and the second user interface includes a vibration, haptic, or tactile presentation system.

[0335] Non-transitory computer-readable media 62: According to an embodiment of non-transitory computer-readable media 61, the cues are vibration cues and are played through the vibration, tactile, or tactile presentation system.

[0336] Non-transitory computer-readable media 63: According to an embodiment of non-transitory computer-readable media 62, the monitoring device is a mobile cellular device, and the second user interface includes an audio channel, wherein the prompt is an audible prompt and is played through the audio channel, and wherein the vibration prompt is presented if the user does not acknowledge the audible prompt.

[0337] Non-transitory computer-readable medium 64: According to an embodiment of any one of non-transitory computer-readable media 1 to 63, wherein alerting a user with a user prompt on the user interface of the monitoring device includes: if the user ignores the first alarm, issuing a prompt on a second user interface of the second device.

[0338] Non-transitory computer-readable medium 65: According to an embodiment of non-transitory computer-readable medium 64, the second device is a drug delivery device, and the cues are audible or vibratory.

[0339] Non-transitory computer-readable medium 66: According to an embodiment of any one of non-transitory computer-readable media 1 to 65, wherein the alarm to the user by user prompting on the user interface of the monitoring device includes presenting tactile or vibration signals.

[0340] Non-transitory computer-readable medium 67: According to an embodiment of non-transitory computer-readable medium 66, the latter is presented on the monitoring device.

[0341] Non-transitory computer-readable medium 68: According to an embodiment of non-transitory computer-readable medium 66, the latter is presented on a means of signal communication with the monitoring device.

[0342] Non-transitory computer-readable medium 69: According to an embodiment of non-transitory computer-readable medium 68, the monitoring device is a smartphone, and the device communicating with the monitoring device is a smartwatch.

[0343] Non-transitory computer-readable media 70: According to an embodiment of non-transitory computer-readable media 66, the presentation includes presenting the user prompt in a pattern corresponding to a diabetic state requiring attention.

[0344] System 71: A system for providing intelligent alerts corresponding to diabetic states requiring user attention, comprising: a CGM application running on a mobile device, the CGM application being configured to receive data from sensors at least periodically or occasionally and to calibrate and display blood glucose concentration data in clinical units; and an intelligent alert application running as a subroutine within the CGM application or as a parallel process of the CGM application on the mobile device and receiving data from the CGM application, the intelligent alert application being configured to perform a method contained on the medium according to the non-transitory computer-readable medium 1.

[0345] Non-transitory computer-readable medium 72: A non-transitory computer-readable medium comprising instructions for enabling a computing environment to perform a method of safely reducing alerts to a user regarding a diabetes condition requiring attention, the method comprising the steps of: identifying a current or future diabetes condition requiring attention, the identification being at least in part based on a blood glucose concentration value; determining whether the identified diabetes condition requiring attention is atypical for the user; and if the determination results in the identified diabetes condition being atypical for the user, alerting the user with a user prompt on a user interface of a monitoring device, the user prompt indicating the diabetes condition requiring attention, thereby notifying the user of a diabetes condition requiring attention only when the identified diabetes condition is atypical for the user.

[0346] Non-transitory computer-readable medium 73: According to an embodiment of non-transitory computer-readable medium 72, wherein determining whether the identified diabetes state requiring attention is atypical for the user includes determining whether the identified diabetes state includes a blood glucose trajectory following a typical pattern that is not associated with other patterns of the user.

[0347] Non-transitory computer-readable medium 74: According to an embodiment of any of the non-transitory computer-readable media 72 to 73, wherein determining whether the identified diabetes state requiring attention is atypical for the user includes determining whether the identified diabetes state includes a blood glucose trajectory following a typical trend that is not associated with other trends of the user.

[0348] Non-transitory computer-readable medium 75: A non-transitory computer-readable medium comprising instructions for causing a computing environment to perform a method of prompting a user about a diabetes state requiring attention, the computing environment being in signal communication with a drug delivery device, the user prompt being optimized for user effectiveness at least in part by reducing its quantity, the user prompt providing data related to the treatment of the diabetes state requiring attention, the method comprising the steps of: identifying a current or future diabetes state requiring attention, the identification being at least in part based on a blood glucose concentration value; performing a first estimation or prediction of the user's awareness of the identified current or future diabetes state requiring attention; if the first estimation... If the prediction result is that the user is unaware of the identified current or future diabetes status requiring attention, then a second estimation or prediction is performed on the computer awareness of the drug delivery device regarding the identified current or future diabetes status requiring attention; if the result of the second estimation or prediction is that the drug delivery device is unaware of the identified current or future diabetes status requiring attention, then an alert is issued to the user via a user prompt on the user interface of the monitoring device, the user prompt indicating the diabetes status requiring attention, thereby notifying the user of the diabetes status requiring attention only if neither the user nor the drug delivery device is aware of the diabetes status requiring attention and the notification is effective for the user.

[0349] Non-transitory computer-readable medium 76: According to an embodiment of non-transitory computer-readable medium 75, the method further includes the step of determining whether the drug delivery device is capable of treating the identified current or future diabetes state requiring attention, and if the determination results in the drug delivery device being unable to treat the identified diabetes state, then alerting the user with the user prompt.

[0350] Non-transitory computer-readable medium 77: According to an embodiment of any of the non-transitory computer-readable media 75 to 76, the current or future diabetes state includes hypoglycemia, and the drug delivery device is an insulin delivery device, and further includes the activity of shutting down or reducing the insulin delivery device based on the diabetes state of hypoglycemia.

[0351] Non-transitory computer-readable media 78: According to an embodiment of non-transitory computer-readable media 77, the shutdown or reduction of activity occurs earlier if the user is unaware of the hypoglycemia.

[0352] Non-transitory computer-readable medium 79: According to an embodiment of any of the non-transitory computer-readable media 75 to 78, wherein the performance of the first estimation or prediction is based at least in part on the user’s interaction with the drug delivery device.

[0353] In some continuous analyte sensor systems, the skin portion of the sensor electronics can be simplified to minimize the complexity and / or size of the on-skin electronics, for example, by providing only raw data, calibration data, and / or filtered data to a display device configured to run calibration and other algorithms required to display sensor data. However, the sensor electronics 12 (e.g., via processor module 214) can be implemented to execute predictive algorithms for generating transformed sensor data and / or displayable sensor information, including algorithms such as: algorithms for estimating the clinical acceptability of reference data and / or sensor data; algorithms based on calibration data containing standard estimates for optimal calibration; algorithms for estimating calibration quality; algorithms for comparing estimated analyte values ​​with time-corresponding measured analyte values; algorithms for analyzing changes in estimated analyte values; algorithms for estimating the stability of the sensor and / or sensor data; algorithms for detecting signal artifacts (noise); algorithms for replacing signal artifacts; algorithms for determining the rate of change and / or trend of sensor data; algorithms for performing dynamic and intelligent analyte value estimation; algorithms for performing diagnostics on the sensor and / or sensor data; algorithms for setting operating modes; algorithms for estimating abnormal data; algorithms for estimating or predicting user cognitive awareness, etc.

[0354] Despite Figure 46 Separate data and program memory are shown, but various configurations can also be used. For example, one or more memories can be used to provide storage space to support the data processing and storage requirements at sensor electronics 12.

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

[0356] The connection between the components shown in the figure illustrates an exemplary communication path. Other communication paths, either directly or via intermediary devices, may be included to further facilitate information exchange between the components. The communication path may be a bidirectional communication path that allows the components to exchange information.

[0357] The various operations described above can be performed by any suitable means capable of performing the operations, such as various hardware and / or software components, circuits and / or modules. Typically, any operation shown in the figure can be performed by a corresponding functional means capable of performing the operation.

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

[0359] In one or more aspects, the described functionality can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality can be stored or transmitted thereon as one or more instructions or code on a computer-readable medium. Computer-readable medium includes both computer storage media and communication media, wherein the communication media includes any media that facilitates the transfer of a computer program from one place to another. Storage media can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media can include various types of RAM, ROM, CD-ROM or other optical disc storage, disk storage 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. Furthermore, any connection is appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, optical fiber, twisted pair, digital subscriber line (DSL), or wireless technologies (e.g., infrared, radio, and microwave), then the definition of media includes coaxial cable, optical fiber, twisted pair, DSL, or wireless technologies (e.g., infrared, radio, WiFi, etc.). RFID, NFC, and microwave). The disks and optical discs used in this article include compact discs (CDs), laser discs, optical discs, digital multifunction discs (DVDs), floppy disks, and... Disks, where magnetic disks typically reproduce data magnetically, and optical disks reproduce data optically using lasers. Therefore, in some aspects, computer-readable media can include non-transitory computer-readable media (e.g., tangible media). Additionally, in some aspects, computer-readable media can include transient computer-readable media (e.g., signals). Combinations of the above should also be included within the scope of computer-readable media.

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

[0361] Some aspects may include a computer program product for performing the operations presented herein. For example, such a computer program product may include a computer-readable medium having instructions stored thereon (and / or encoded thereon, which can be executed by one or more processors to perform the operations described herein. In some aspects, the computer program product may include packaging material.

[0362] Software or instructions may also be transmitted via transmission media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, optical fiber, twisted pair, digital subscriber line (DSL), or wireless technology (e.g., infrared, radio, and microwave), then the definition of transmission media includes coaxial cable, optical fiber, twisted pair, DSL, or wireless technology (e.g., infrared, radio, and microwave).

[0363] Furthermore, it should be understood that modules and / or other suitable means for performing the methods and techniques described herein may be downloaded and / or otherwise obtained by the user terminal and / or base station where applicable. For example, such an apparatus may be coupled to a server to facilitate the transmission of means for performing the methods described herein. Alternatively, the various methods described herein may be provided via storage means (e.g., RAM, ROM, physical storage media such as CDs or floppy disks), such that the user terminal and / or base station can obtain the various methods when the storage means are coupled to or provided to the apparatus. Furthermore, any other suitable techniques for providing the methods and techniques described herein to the apparatus may be utilized.

[0364] It should be understood that the claims are not limited to the precise configurations and components shown above. Various modifications, alterations, and variations may be made to the arrangement, operation, and details of the above-described methods and apparatus without departing from the scope of the claims.

[0365] Unless otherwise defined, all terms (including technical and scientific terms) shall be given the meaning common and customary to those skilled in the art, and are not limited to any particular or customary meaning unless expressly defined herein. It should be noted that the use of specific terms in describing certain features or aspects of this disclosure should not be construed as implying that the terms are redefined herein to be limited to include any specific feature of the disclosure associated with that term. Terms and phrases used in this application, and variations thereof, particularly in the appended claims, should be interpreted as open-ended rather than restrictive unless expressly stated otherwise. As an example of the foregoing, the term “including” should be understood to mean “including, without limitation / including but not limited”. The term "comprising" as used herein is synonymous with "including," "containing," or "characterized by," and is inclusive or open-ended, and does not exclude other unlisted elements or method steps; the term "having" should be interpreted as "having at least"; the term "comprising" should be interpreted as "including but not limited to"; the term "example" is used to provide exemplary examples of the items under discussion, and is not an exhaustive or limiting list thereof; adjectives such as "known," "normal," "standard," and similar meanings should not be interpreted as limiting the described items to items available for a given time period or within a given time, but should be interpreted as covering known, normal, or standard techniques that may be available or known now or in the future; and the use of terms such as "preferred," "ideal," "required," or "desired," and words with similar meanings, should not be construed as implying that certain features are critical, necessary, or even important to the structure or function of the invention, but are only intended to highlight alternative or additional features that may be used or not used in a particular embodiment of the invention. Similarly, unless otherwise explicitly stated, a group of items connected by the conjunction "and" should not be understood as requiring each of these items to be present in the group, but should be understood as "and / or". Likewise, unless otherwise explicitly stated, a group of items connected by the conjunction "or" should not be understood as requiring mutual exclusivity within the group, but should be understood as "and / or".

[0366] When a numerical range is provided, it should be understood that the upper and lower limits of the range, as well as each intermediate value between the upper and lower limits, are included in the embodiments.

[0367] Regarding the use of virtually any plural and / or singular terms herein, those skilled in the art may appropriately convert plural to singular and / or singular to plural depending on the context and / or application. For clarity, various singular / plural substitutions may be explicitly stated herein. The indefinite article “a / an” does not exclude plural. A single processor or other unit may perform the functions of several items listed in the claims. The fact that certain measures are listed in mutually different dependent claims does not imply that combinations of these measures cannot be used advantageously. Any reference signs in the claims should not be construed as limiting the scope.

[0368] Those skilled in the art will further understand that if there is an intention to indicate a specific number of claim statements introduced, such intention will be explicitly stated in the claims, and in the absence of statements, such intention will not exist. For example, to aid understanding, the appended claims may include the use of the introductory phrases “at least one” and “one or more” to introduce claim statements. However, the use of these phrases should not be construed as implying that the introduction of a claim statement by the indefinite article “a / an” limits any particular claim containing such an introduced claim statement to an embodiment containing only one such statement, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a / an” (e.g., “a / an” should generally be interpreted as meaning “at least one” or “one or more”); the same applies to the use of definite articles for introducing claim statements. Furthermore, even when a specific number of the introduced claim statements is explicitly stated, those skilled in the art will recognize that such statements should generally be interpreted as meaning at least the number stated (e.g., a simple statement of "two statements" without other modifiers generally means at least two statements, or two or more statements). Additionally, in cases where conventions such as "at least one of A, B, and C" are used, this structure is generally intended to indicate that those skilled in the art will understand the meaning of the convention, such as including any combination of the enumerated items, including single members (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.). In cases where conventions such as "at least one of A, B, or C" are used, this structure is generally intended to indicate that a person skilled in the art will understand the meaning of the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having both A and B, a system having both A and C, a system having both B and C, and / or a system having both A, B, and C, etc.). A person skilled in the art will further understand that, whether in the specification, claims, or drawings, any separate words and / or phrases presenting two or more alternative terms should be understood to account for the possibility of including one of the terms, including either one or both of the terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B".

[0369] All figures used in the specification to indicate the amount of ingredients, reaction conditions, etc., should be understood to be modified by the term "about" in all cases. Therefore, unless otherwise stated, the numerical parameters described herein are approximations that may vary depending on the desired properties sought to be obtained. At least, and without attempt to limit the application of the doctrine of equivalence to the scope of any claim in any application asserting priority to this application, each numerical parameter should be interpreted according to significant digits and ordinary rounding.

[0370] All references cited herein are incorporated herein by reference in their entirety. In the event of any conflict between a publication incorporated herein by reference and a publication of a patent or patent application contained herein, the specification is intended to supersede and / or take precedence over any such conflicting material.

[0371] Headings are included in this document for reference and to help locate the various sections. These headings are not intended to limit the scope of the concepts described therein. These concepts may apply throughout the entire specification.

[0372] Furthermore, although the foregoing has been described in detail by way of illustration and examples for the purpose of clarity and understanding, it will be apparent to those skilled in the art that certain changes and modifications can be practiced. 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 also covering all modifications and alternatives within the true scope and spirit of the invention.

[0373] The systems and methods described can be fully implemented in any number of computing devices. Typically, instructions are arranged on a computer-readable medium, are generally non-transitory, and are sufficient to allow a processor in the computing device to implement the methods of these aspects and embodiments. The computer-readable medium can be a hard disk drive or solid-state memory with instructions loaded into random access memory at runtime. Input to the application, for example, from multiple users or from any one user, can be any number of suitable computer input devices. For example, a user can use a keyboard, mouse, touchscreen, joystick, touchpad, other pointing devices, or any other such computer input device to input computation-related data. Data can also be input via inserted memory chips, hard disk drives, flash drives, flash memory, optical media, magnetic media, or any other type of file storage media. Output can be delivered to the user via a video graphics card or integrated graphics chipset coupled to a display that can be viewed by the user. Alternatively, a hard copy of the results can be output using a printer. In light of this teaching, any number of other tangible outputs will also be understood as expected. For example, output can be stored in memory chips, hard disk drives, flash drives, flash memory, optical media, magnetic media, or any other type of output. It should also be noted that these aspects and embodiments can be implemented on any number of different types of computing devices (e.g., personal computers, laptops, notebooks, netbooks, handheld computers, personal digital assistants, mobile phones, smartphones, tablets, and devices specifically designed for these purposes). In one implementation, a user of a smartphone or Wi-Fi connected device uses a wireless internet connection to download a copy of the application from a server to their device. Appropriate authentication procedures and secure transaction processes can prepare for payment to the seller. The application can be downloaded via a mobile connection or via WiFi or other wireless network connections. The application can then be run by the user. Such a networked system can provide a suitable computing environment for implementations where multiple users provide individual input to the system and method. In the following envisioned intelligent alarm system, multiple inputs can allow multiple users to simultaneously input relevant data.

Claims

1. A non-transitory computer-readable medium comprising instructions for causing a computing environment to perform a method of safely reducing alerts to a user's need for attention regarding a diabetic state, the method comprising: Identify a user's current or future diabetes status that requires attention, the identification being at least in part based on the user's blood glucose concentration value that meets a threshold blood glucose concentration value associated with the user; After identifying the current or future diabetes status requiring attention, the system compares the identified diabetes status requiring attention with previously identified diabetes status requiring attention to determine whether the identified diabetes status requiring attention is atypical for the user. and In response to determining that the identified diabetes condition is atypical for the user, an alert is issued to the user via a user prompt on the monitoring device's user interface, indicating the diabetes condition requiring attention. Specifically, the user is notified of the diabetes condition requiring attention only when the identified diabetes condition is atypical for the user.

2. The media of claim 1, wherein determining whether the identified diabetes state requiring attention is atypical for the user includes determining whether the identified diabetes state includes a blood glucose trajectory following a typical pattern that is not associated with other patterns of the user.

3. The media of claim 1, wherein determining whether the identified diabetes state requiring attention is atypical for the user includes determining whether the identified diabetes state includes a blood glucose trajectory following a typical trend that is not associated with other trends of the user.

4. The media of claim 1, wherein determining whether the identified diabetes state requiring attention is atypical for the user includes determining the similarity between data associated with the identified diabetes state and data typical for the user.

5. A system for providing intelligent alerts corresponding to diabetic states requiring user attention, the system comprising: A continuous glucose monitoring (CGM) application, the CGM application being configured to run on a mobile device, the CGM application also being configured to receive data from a sensor at least periodically or occasionally and to calibrate and display blood glucose concentration data in clinical units; and A smart alarm application, configured to run as a subroutine within the continuous glucose monitoring (CGM) application or as a parallel process of the CGM application on the mobile device and to receive data from the CGM application, the smart alarm application also configured to perform a method included on the media according to claim 1.

Images