Glucose alert prediction range modification

Abstract

Data describing glucose measurements are received from a continuous glucose monitoring (CGM) system worn by a user, and predicted glucose values for the user during a future time period are generated based on the data. It is determined that at least one of the predicted glucose values satisfies a threshold of an alert, the alert being associated with a prediction horizon defining an amount of time before satisfying the threshold for communicating the alert to the user. The alert is caused to be output in response to determining that the at least one predicted glucose value satisfies the threshold of the alert relative to a current time being within the prediction horizon. The prediction horizon is modified based on a user response to the alert. Subsequent instances of the alert are caused to be output based on the modified prediction horizon.

Description

[0001] Related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 074,391, filed September 3, 2020, entitled “Glucose Alert Prediction Horizon Modification,” the entire disclosure of which is incorporated herein by reference. Background Technology

[0003] Diabetes is a metabolic disease affecting hundreds of millions of people. For these individuals, monitoring blood glucose levels and regulating them within acceptable ranges is crucial not only for mitigating long-term problems such as heart disease and vision impairment, but also for avoiding the effects of both high and low blood sugar. Maintaining blood glucose levels within acceptable ranges can be challenging because these levels fluctuate almost constantly over time and in response to daily events such as eating or exercising.

[0004] Advances in medical technology have enabled the development of various systems for monitoring blood glucose, including continuous glucose monitoring (CGM) systems that measure and record glucose concentrations essentially in real time. CGM systems are essential tools for users of these systems to ensure that measured glucose levels are within acceptable ranges. For example, a CGM system can issue an alert when a measured glucose level exceeds a user-specified threshold. In response to receiving the alert, the user can take action to correct for either high or low blood glucose levels.

[0005] While high / low glucose alerts generated by the CGM system are valuable for ensuring users are aware of whether their glucose levels are too high or too low, users may already be experiencing symptoms of either high or low blood glucose levels when they receive a high / low alert. For example, upon receiving a high glucose alert, a user may already be experiencing symptoms of high blood glucose levels such as nausea, fatigue, vomiting, dry mouth, and increased heart rate. Similarly, upon receiving a low glucose alert, a user may already be experiencing symptoms of low blood glucose levels, including anxiety, nausea, fatigue, confusion, and dizziness. Summary of the Invention

[0006] To overcome these problems, a system and technique for modifying the prediction range associated with a blood glucose level alarm are described. Data describing glucose measurement results are received from a user-worn continuous glucose monitoring (CGM) system. Based on this data, predicted glucose values ​​for the user over a future time period are generated. At least one of these predicted glucose values ​​is determined to meet an alarm threshold. The alarm is associated with a prediction range that defines the amount of time before the alarm is delivered to the user before the threshold is met.

[0007] For example, the prediction range defines how far the predicted glucose value is considered to be within the future time period relative to the threshold of the alarm. This results in an alarm being output in response to determining that the at least one predicted glucose value meets the threshold of the alarm within the prediction range relative to the current time. For example, the alarm is output as a notification in the user interface of a computing device. The prediction range is modified based on the user's response to the alarm.

[0008] For example, the prediction range may be modified based on explicit feedback (e.g., user input) to a notification of an alarm output in the user interface of the computing device. Alternatively or additionally, the prediction range may be modified based on the user's monitored glucose level, which indicates the intervention the user may take in response to the notification. Alternatively or additionally, the prediction range may be modified based on additional data other than explicit feedback or monitored glucose levels indicating a response to the notification (e.g., third-party data describing exercise activity, insulin administration, calorie intake, etc.).

[0009] In one example, the prediction range is modified by utilizing the confidence level of predicted glucose values ​​that meet the threshold for the alarm. In this example, multiple prediction ranges are used to predict glucose values ​​that meet the threshold for the alarm. For example, the prediction range is modified until a predicted glucose value that meets the threshold for the alarm is identified, and the confidence level of that predicted glucose value is at least the threshold confidence level. In another example, the prediction range is modified until the longest prediction range is identified as having a predicted glucose value that meets the threshold for the alarm, and the confidence level of that predicted glucose value is at least the threshold confidence level. This results in subsequent instances of the alarm being output based on the modified prediction range.

[0010] One aspect is a method comprising: receiving data describing glucose measurement results from a user-worn continuous glucose monitoring (CGM) system; predicting glucose values ​​for the user during a future time period based on the data; determining a threshold for at least one predicted glucose value to satisfy an alarm, the alarm being associated with a prediction range defining the amount of time required to output the alarm before the threshold is satisfied; causing the alarm to be output in a user interface of a computing device in response to determining that the at least one predicted glucose value satisfies the threshold within the prediction range relative to the current time; modifying the prediction range; and a subsequent instance causing the alarm to be output in the user interface based on the modified prediction range.

[0011] In the methods described above, modifying the prediction range is performed based on the user's historical glucose measurement patterns. In any of the methods described above, predicting the user's glucose value during the future time period is performed based on the user's historical glucose measurement patterns. In any of the methods described above, predicting the user's glucose value during the future time period includes processing the data using at least one machine learning model trained to predict glucose values ​​using training data describing glucose measurement results for a user group. In any of the methods described above, the at least one machine learning model is further trained to predict glucose values ​​using additional data for the user group. Any of the methods described above also includes causing a feedback prompt to be output in the user interface relative to the alert and receiving a response to the prompt, wherein modifying the prediction range is performed based on the response to the prompt.

[0012] In any of the methods described above, the feedback prompt includes at least one of the following: feedback prompt regarding the adequacy of the advance warning time associated with the alarm; feedback prompt regarding whether the alarm is helpful; or feedback prompt regarding the user's response to the alarm. In any of the methods described above, the alarm indicates one of a high glucose level alarm, a low glucose level alarm, or an emergency low glucose level alarm. In any of the methods described above, modifying the prediction range includes adjusting the advance warning time before the threshold is met. In any of the methods described above, modifying the prediction range is performed based on data describing a subset of users with user profile attributes similar to the user.

[0013] In any of the above methods, the modification of the prediction range is performed based on the confidence level of the at least one predicted glucose value. Any of the above methods further includes: determining that the alarm is a hindrance alarm; and modifying the prediction range in response to determining that the alarm is a hindrance alarm. Any of the above methods further includes: receiving additional data describing glucose measurements observed during the future time period; comparing at least one predicted glucose value with at least one of the observed glucose measurements during the future time period; and modifying the prediction range based on the difference between the at least one observed glucose measurement and the at least one predicted glucose value.

[0014] On the other hand, there is a system comprising: at least one processor; and one or more computer-readable storage media executable by the at least one processor to perform operations including: receiving data describing glucose measurement results from a user-worn continuous glucose monitoring (CGM) system; predicting glucose values ​​for the user during a future time period based on the data; determining a threshold for at least one predicted glucose value to satisfy an alarm, the alarm being associated with a prediction range defining the amount of time required to output the alarm before the threshold is satisfied; causing the alarm to be output in a user interface of a computing device in response to determining that the at least one predicted glucose value satisfies the threshold within the prediction range relative to the current time; modifying the prediction range; and subsequent instances causing the alarm to be output in the user interface based on the modified prediction range.

[0015] In the aforementioned systems, modifying the prediction range is performed based on the user's historical glucose measurement patterns. In any of the aforementioned systems, predicting the user's glucose value for the future time period is performed based on the user's historical glucose measurement patterns. In any of the aforementioned systems, predicting the user's glucose value for the future time period includes processing the data using at least one machine learning model trained to predict glucose values ​​using training data describing glucose measurement results for a user group. In any of the aforementioned systems, the at least one machine learning model is further trained to predict glucose values ​​using additional data from the user group. In any of the aforementioned systems, the operation further includes causing a feedback prompt to be output in the user interface relative to the alert and receiving a response to the prompt, wherein modifying the prediction range is performed based on the response to the prompt.

[0016] In any of the aforementioned systems, the feedback prompt includes at least one of the following: feedback prompt regarding the adequacy of the advance warning time associated with the alarm; feedback prompt regarding whether the alarm is helpful; or feedback prompt regarding the user's response to the alarm. In any of the aforementioned systems, the alarm indicates one of a high glucose level alarm, a low glucose level alarm, or an emergency low glucose level alarm. In any of the aforementioned systems, modifying the prediction range includes adjusting the advance warning time before the threshold is met. In any of the aforementioned systems, modifying the prediction range is performed based on data describing a subset of users with user profile attributes similar to the user. In any of the aforementioned systems, modifying the prediction range is performed based on the confidence level of the at least one predicted glucose value.

[0017] In any of the aforementioned systems, the operation further includes: determining that the alarm is a hindrance alarm; and modifying the prediction range in response to determining that the alarm is a hindrance alarm. In any of the aforementioned systems, the operation further includes: receiving additional data describing glucose measurements observed during the future time period; comparing at least one predicted glucose value with at least one of the observed glucose measurements during the future time period; and modifying the prediction range based on the difference between the at least one observed glucose measurement and the at least one predicted glucose value.

[0018] On the other hand, there is one or more computer-readable storage media storing instructions executable by a computing device to perform operations including: receiving data describing glucose measurement results from a user-worn continuous glucose monitoring (CGM) system; predicting the user's glucose values ​​for a future time period based on the data; determining a threshold for at least one predicted glucose value to satisfy an alarm associated with a prediction range that defines the amount of time required to output the alarm before the threshold is satisfied; causing the alarm to be output in a user interface of the computing device in response to determining that the at least one predicted glucose value satisfies the threshold within the prediction range relative to the current time; modifying the prediction range; and subsequent instances causing the alarm to be output in the user interface based on the modified prediction range.

[0019] In any of the aforementioned media, modifying the prediction range is performed based on the user's historical glucose measurement patterns. In any of the aforementioned media, predicting the user's glucose value during the future time period is performed based on the user's historical glucose measurement patterns. In any of the aforementioned media, predicting the user's glucose value during the future time period includes processing the data using at least one machine learning model trained to predict glucose values ​​using training data describing glucose measurement results for a user group. In any of the aforementioned media, the at least one machine learning model is further trained to predict glucose values ​​using additional data from the user group.

[0020] In any of the aforementioned media, the operation further includes causing the output of a feedback prompt in the user interface relative to the alarm and receiving a response to the prompt, wherein the modification of the prediction range is performed based on the response to the prompt. In any of the aforementioned media, the feedback prompt includes at least one of the following: feedback regarding the adequacy of the advance warning time associated with the alarm; feedback regarding whether the alarm is helpful; or feedback regarding the user's response to the alarm.

[0021] In any of the aforementioned media, the alarm indicates one of a high glucose level alarm, a low glucose level alarm, or an emergency low glucose level alarm. In any of the aforementioned media, modifying the prediction range includes adjusting the advance warning time for outputting the alarm before the threshold is met. In any of the aforementioned media, modifying the prediction range is performed based on data describing a subset of users with user profile attributes similar to the user.

[0022] In any of the aforementioned media, the modification of the prediction range is performed based on the confidence level of the at least one predicted glucose value. In any of the aforementioned media, the operation further includes: determining that the alarm is a hindrance alarm; and modifying the prediction range in response to determining that the alarm is a hindrance alarm. In any of the aforementioned media, the operation further includes: receiving additional data describing glucose measurements observed during the future time period; comparing at least one predicted glucose value with at least one of the observed glucose measurements during the future time period; and modifying the prediction range based on the difference between the at least one observed glucose measurement and the at least one predicted glucose value.

[0023] On the other hand, there is a device comprising: a receiving means for receiving data describing glucose measurement results from a user-worn continuous glucose monitoring (CGM) system; a prediction means for predicting glucose values ​​for the user during a future time period based on the data; a determining means for determining that at least one predicted glucose value meets a threshold for an alarm, the alarm being associated with a prediction range that defines the amount of time required to output the alarm before the threshold is met; an alarm means for causing the alarm to be output in a user interface of a computing device in response to determining that the at least one predicted glucose value meets the threshold relative to the current time within the prediction range; a modifying means for modifying the prediction range; and the alarm means being further configured to cause subsequent instances of the alarm to be output in the user interface based on the modified prediction range.

[0024] Another method includes: determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; causing the alarm to be output in a user interface of a computing device in response to the determination; receiving additional data describing the response to the alarm; automatically and without user intervention modifying at least one setting of the CGM system, the at least one setting adjusting the prediction range associated with the alarm based on the additional data; and causing a subsequent instance of the alarm to be output in the user interface according to the modified at least one setting.

[0025] In the above methods, the prediction range defines the advance warning time that causes the alarm to be output before the threshold is met. In any of the above methods, the additional data describing the response to the alarm includes at least one of: data describing food consumed by the user associated with the CGM system; data describing insulin administered to the user associated with the CGM system; or data describing the exercise activity of the user associated with the CGM system. In any of the above methods, the additional data describing the response to the alarm includes information describing the user's interaction with the application associated with the CGM system. In any of the above methods, the at least one glucose value predicted by the CGM system is predicted based on the user's historical glucose measurement patterns within the CGM system.

[0026] In any of the methods described above, the response to the alarm indicates that the alarm is a hindrance alarm, and the method further includes adjusting the prediction range by reducing the prediction range in response to determining that the alarm is the hindrance alarm. Any of the methods described above also includes: receiving data describing one or more glucose measurements observed by the CGM system during a future time period; comparing the at least one glucose value predicted by the CGM system with the one or more glucose measurements observed by the CGM system during the future time period; and adjusting the prediction range based on the difference between the at least one glucose value predicted by the CGM system and the one or more glucose measurements observed by the CGM system during the future time period.

[0027] On the other hand, there is a system comprising: one or more processors; and a computer-readable storage medium storing instructions executable by the one or more processors to perform operations including: determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; causing the alarm to be output in a user interface of a computing device in response to the determination; receiving additional data describing the response to the alarm; automatically and without user intervention modifying at least one setting of the CGM system, the at least one setting adjusting a prediction range associated with the alarm based on the additional data; and causing a subsequent instance of the alarm to be output in the user interface according to the modified at least one setting.

[0028] In the aforementioned systems, the prediction range defines the advance warning time that causes the alarm to be output before the threshold is met. In any of the aforementioned systems, the additional data describing the response to the alarm includes at least one of the following: data describing food consumed by the user associated with the CGM system; data describing insulin administered to the user associated with the CGM system; or data describing the exercise activity of the user associated with the CGM system. In any of the aforementioned systems, the additional data describing the response to the alarm includes information describing the user's interaction with the application associated with the CGM system. In any of the aforementioned systems, the at least one glucose value predicted by the CGM system is predicted based on the user's historical glucose measurement patterns.

[0029] In any of the aforementioned systems, the response to the alarm indicates that the alarm is a hindrance alarm, and the operation further includes adjusting the prediction range by reducing the prediction range in response to determining that the alarm is a hindrance alarm. In any of the aforementioned systems, the operation further includes: receiving data describing one or more glucose measurements observed by the CGM system during a future time period; comparing the at least one glucose value predicted by the CGM system with the one or more glucose measurements observed by the CGM system during the future time period; and adjusting the prediction range based on the difference between the at least one glucose value predicted by the CGM system and the one or more glucose measurements observed by the CGM system during the future time period.

[0030] On the other hand, there is one or more computer-readable media storing instructions executable by a computing device to perform operations including: determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; causing the alarm to be output in a user interface of the computing device in response to the determination; receiving additional data describing the response to the alarm; automatically and without user intervention modifying at least one setting of the CGM system, the at least one setting adjusting the prediction range associated with the alarm based on the additional data; and causing a subsequent instance of the alarm to be output in the user interface according to the modified at least one setting.

[0031] In any of the aforementioned media, the prediction range defines the advance warning time that causes the alarm to be output before the threshold is met. In any of the aforementioned media, the additional data describing the response to the alarm includes at least one of the following: data describing food consumed by the user associated with the CGM system; data describing insulin administered to the user associated with the CGM system; or data describing the exercise activity of the user associated with the CGM system. In any of the aforementioned media, the additional data describing the response to the alarm includes information describing the user's interaction with the application associated with the CGM system. In any of the aforementioned media, the at least one glucose value predicted by the CGM system is predicted based on the user's historical glucose measurement patterns within the CGM system.

[0032] On the other hand, there is an apparatus comprising: a determining means for determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; an alarm means for causing the alarm to be output in a user interface of a computing device in response to the determining means; a communication means for receiving additional data describing the response to the alarm; a modification means for automatically and without user intervention modifying at least one setting of the CGM system, the at least one setting adjusting the prediction range associated with the alarm based on the additional data; and the alarm means being further configured to cause subsequent instances of the alarm to be output in the user interface according to the modified at least one setting.

[0033] Another method includes: determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; causing the alarm to be output in a user interface of a computing device in response to the determination; receiving feedback data describing at least one user input relative to the alarm; modifying at least one setting of the CGM system based on the feedback data; and a subsequent instance causing the alarm to be output in the user interface according to the modified at least one setting.

[0034] The methods described above further include causing a feedback prompt to be output in the user interface, the feedback prompt requesting feedback on whether the alarm is helpful to the user of the CGM system, wherein the at least one user input includes interaction with the feedback prompt. In any of the methods described above, the feedback data describing the at least one user input relative to the alarm includes an advance warning time for a subsequent instance of the alarm being output before the threshold is met, wherein the subsequent instance causing the alarm to be output is executed based on the advance warning time. Any of the methods described above further includes suppressing the output of additional subsequent instances of the alarm based on determining that the subsequent instance of the alarm is an alarm-inhibiting instance. In any of the methods described above, at least one setting of the modification is the end of a prediction range, the prediction range defining the amount of time required before the at least one glucose value predicted by the CGM system meets the threshold of the alarm.

[0035] In any of the methods described above, at least one setting of the modification is a threshold confidence level, which is compared with a confidence level of the at least one glucose value predicted by the CGM system to determine whether to generate the alarm. In any of the methods described above, at least one setting of the modification is an advance of the prediction range relative to the current time, the prediction range defining the amount of time required to output the alarm before the at least one glucose value predicted by the CGM system meets the threshold for the alarm.

[0036] On the other hand, there is a system comprising: one or more processors; and a computer-readable storage medium storing instructions executable by the one or more processors to perform operations including: determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; causing the alarm to be output in a user interface of a computing device in response to the determination; receiving feedback data describing at least one user input relative to the alarm; modifying at least one setting of the CGM system based on the feedback data; and a subsequent instance causing the alarm to be output in the user interface according to the modified at least one setting.

[0037] In the aforementioned systems, the operation further includes causing a feedback prompt to be output in the user interface, the feedback prompt requesting feedback on whether the alarm is helpful to the user of the CGM system, wherein the at least one user input includes interaction with the feedback prompt. In any of the aforementioned systems, the feedback data describing the at least one user input relative to the alarm includes an advance warning time for subsequent instances of the alarm to be output before the threshold is met, wherein the subsequent instance causing the alarm to be output is executed based on the advance warning time. In any of the aforementioned systems, the operation further includes suppressing the output of additional subsequent instances of the alarm based on determining that the subsequent instance of the alarm is an obstructive alarm.

[0038] In any of the aforementioned systems, at least one setting of the modification is the end of a prediction range, which defines the amount of time required to output an alarm before the at least one glucose value predicted by the CGM system meets the threshold for the alarm. In any of the aforementioned systems, at least one setting of the modification is a threshold confidence level, which is compared with a confidence level of the at least one glucose value predicted by the CGM system to determine whether to generate the alarm. In any of the aforementioned systems, at least one setting of the modification is an advance of the prediction range relative to the current time, which defines the amount of time required to output an alarm before the at least one glucose value predicted by the CGM system meets the threshold for the alarm.

[0039] On the other hand, there is one or more computer-readable media storing instructions executable by a computing device to perform operations including: determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; causing the alarm to be output in a user interface of the computing device in response to the determination; receiving feedback data describing at least one user input relative to the alarm; modifying at least one setting of the CGM system based on the feedback data; and a subsequent instance causing the alarm to be output in the user interface according to the modified at least one setting.

[0040] In the aforementioned media, the operation further includes causing a feedback prompt to be output in the user interface, the feedback prompt requesting feedback on whether the alarm is helpful to the user of the CGM system, wherein the at least one user input includes interaction with the feedback prompt. In any of the aforementioned media, the feedback data describing the at least one user input relative to the alarm includes an advance warning time for a subsequent instance of outputting the alarm before the threshold is met, wherein the subsequent instance causing the alarm to be output is executed based on the advance warning time.

[0041] In any of the aforementioned media, at least one setting of the modification is a threshold confidence level, which is compared with a confidence level of the at least one glucose value predicted by the CGM system to determine whether to generate the alarm. In any of the aforementioned media, at least one setting of the modification is an advance of the prediction range relative to the current time, the prediction range defining the amount of time required to output the alarm before the at least one glucose value predicted by the CGM system meets the threshold for the alarm.

[0042] On the other hand, there is an apparatus comprising: a determining means for determining that at least one glucose value predicted by a continuous glucose monitoring (CGM) system meets a threshold for an alarm; an alarm means for causing the alarm to be output in a user interface of a computing device in response to the determining means; a receiving means for receiving feedback data describing at least one user input relative to the alarm; a modifying means for modifying at least one setting of the CGM system based on the feedback data; and the alarm means is further configured to cause a subsequent instance of the alarm to be output in the user interface according to the modified at least one setting.

[0043] This summary presents a simplified version of some concepts, which will be further described in the detailed description below. Therefore, this summary is not intended to identify essential features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter. Attached Figure Description

[0044] Specific implementation methods are described with reference to the accompanying drawings.

[0045] Figure 1 This is an illustration of an exemplary specific implementation of the technology described herein.

[0046] Figure 2 A more detailed description Figure 1 An example of a continuous glucose monitoring (CGM) system.

[0047] Figure 3An exemplary implementation is described in which CGM device data (including glucose measurement results and associated notifications) combined with glucose measurement results and event predictions are directed to different systems.

[0048] Figure 4 It describes in more detail the method used to generate glucose measurement predictions based on glucose measurement results and additional data. Figure 3 An exemplary specific implementation of the prediction system.

[0049] Figure 5 Describing one of the specific implementations Figure 3 An exemplary representation of the prediction system that generates glucose measurement result predictions.

[0050] Figure 6 Depicting by Figure 3 An exemplary representation of the relationship between the glucose measurement predictions generated by the prediction system and the prediction range associated with the alerts for the glucose measurement predictions.

[0051] Figure 7 Depicting by Figure 3 An exemplary representation of the glucose measurement results generated by the prediction system and the corresponding alarms transmitted to the computing device.

[0052] Figure 8 An exemplary embodiment of a user interface for notifying a user based on a glucose measurement result prediction is described, according to one or more specific embodiments.

[0053] Figure 9 An exemplary embodiment of a user interface for prompting user input feedback regarding a glucose measurement result prediction notification is described, according to one or more specific embodiments.

[0054] Figure 10 An exemplary embodiment of a user interface for prompting user input feedback regarding a glucose measurement result prediction notification is described, according to one or more specific embodiments.

[0055] Figure 11 An exemplary embodiment of a user interface for prompting user input feedback regarding a glucose measurement result prediction notification is described, according to one or more specific embodiments.

[0056] Figure 12 The text describes in more detail the training of the machine learning model to adjust the prediction range settings related to glucose measurement alerts. Figure 3 An exemplary specific implementation of the prediction system.

[0057] Figure 13An exemplary implementation of the procedure is described, in which settings for predicting glucose measurement results are modified and an alarm is output based on the modified settings.

[0058] Figure 14 An exemplary implementation of the procedure is described, in which settings for predicting glucose measurement results are modified and an alarm is output based on the modified settings.

[0059] Figure 15 An exemplary system including an exemplary computing device is shown, which represents one or more computing systems and / or devices that can implement the various technologies described herein. Detailed Implementation

[0060] Overview

[0061] Glucose alerts generated by the CGM system ensure that users are informed of whether their current blood glucose level is too high or too low. However, by the time a user receives an alert, they may already be experiencing symptoms of either high or low blood glucose levels. Therefore, it is still necessary to alert users before problematic blood glucose levels occur, with sufficient advance warning time to allow users to intervene and avoid symptoms and other complications associated with problematic blood glucose levels.

[0062] The prediction system receives data describing glucose measurement results from a CGM system worn by the user. Based on this data, the prediction system predicts the user's glucose levels for a future time period. The CGM system determines that at least one predicted glucose level of the user meets an alarm threshold, which indicates a problematic blood glucose level for the user during the future time period. This alarm is associated with a prediction range that defines the amount of time required to issue an alarm before the threshold is met.

[0063] In some implementations, the CGM system causes an alarm to be output in the user interface of a computing device associated with the user in response to determining that at least one predicted glucose value meets a threshold within the predicted range relative to the current time. The CGM system modifies the predicted range of the alarm based on data describing the user's response to the alarm. For example, in some implementations, the CGM system identifies the alarm as an obstructive alarm (e.g., an alarm the user does not want to receive).

[0064] The CGM system is configured to identify alarm notifications as hindrance alarms based on various types of data, such as data describing explicit feedback from users, data describing patterns and relationships between predicted glucose values ​​for users over future time periods, CGM data for user groups, data describing users' glucose measurements after an alarm is issued, data describing user interactions with applications associated with the CGM system, and combinations thereof. In response to identifying an alarm as a hindrance alarm, the CGM system modifies the prediction range to prevent subsequent instances of the alarm from becoming hindrance alarms. For example, the CGM system modifies the prediction range by increasing or decreasing its length to adjust the advance warning time before delivering an alarm to the user before the predicted threshold blood glucose level is met.

[0065] In another example, the CGM system modifies the prediction range based on the confidence level associated with predicted glucose values ​​over a future time period. In this example, the CGM system modifies the prediction range until the predicted glucose value is identified as meeting an alarm threshold and the confidence level of the predicted glucose value is at least the threshold confidence level (e.g., 85%, 90%, 95%, 99%, etc.). In similar examples, the CGM system uses multiple prediction ranges to compare predicted glucose values ​​with alarm thresholds. For example, the CGM system modifies the prediction range based on the longest prediction range among multiple prediction ranges, which includes predicted glucose values ​​that meet the alarm threshold and whose confidence level is at least the threshold confidence level.

[0066] A CGM system causes subsequent instances of alerts to be output based on a modified prediction range, and repeats this process by continuously modifying the prediction range associated with the alert. Continued modification of the prediction range associated with the alert can be performed by adjusting the prediction range according to one or more intervals (e.g., after a fixed time period, after an alert instance with a threshold number of outputs, after each subsequent instance of the alert, until it is determined that a subsequent instance of the alert is not interfering with the alert, combinations thereof, etc.). For example, a CGM system monitors a user's glucose measurement after outputting a subsequent instance of an alert and determines that the user has been intervened to prevent an event associated with a subsequent alert. By continuously modifying the prediction range, the CGM system avoids displaying interfering alerts to the user and outputs alerts at a time when the user is able to intervene and prevent problematic blood glucose levels. Furthermore, by continuously modifying the prediction range of the alert, the CGM system reduces its sensitivity to statistically anomalous or random effects that would otherwise bias the system's interpretation of the user's response to a particular alert.

[0067] In the following description, an exemplary environment configured to employ the techniques described herein is first described. Then, exemplary specific implementation details and procedures that can be executed in the exemplary environment, as well as in other environments, are described. Execution of the exemplary procedures is not limited to the exemplary environment, and the exemplary environment is not limited to the execution of the exemplary procedures.

[0068] Exemplary Environment

[0069] Figure 1 An environment 100 operable in an exemplary specific implementation of the personalized glucose alert setting technology described herein is illustrated. The illustrated environment 100 includes a person 102, depicted as wearing a continuous glucose monitoring (CGM) system 104, an insulin delivery system 106, and a computing device 108. The illustrated environment 100 also includes other users within a user group 110 in the CGM system, CGM platform 112, and Internet of Things 114 (IoT 114). The CGM system 104, insulin delivery system 106, computing device 108, user group 110, CGM platform 112, and IoT 114 are communicatively connected (including via network 116).

[0070] Alternatively or additionally, one or more of the CGM system 104, insulin delivery system 106, or computing device 108 are communicatively connected in other ways, such as using one or more wireless communication protocols and / or technologies. By way of example, the CGM system 104, insulin delivery system 106, and computing device 108 are configured to communicate with each other using one or more of Bluetooth (e.g., Bluetooth Low Energy link), Near Field Communication (NFC), 5G, etc. In some examples, the CGM system 104, insulin delivery system 106, and / or computing device 108 are capable of radio frequency (RF) communication and include an RF transmitter and an RF receiver. In these examples, one or more RFID tags may be used to identify and / or track the CGM system 104, insulin delivery system 106, or computing device 108 within environment 100. For example, the CGM system 104, insulin delivery system 106, and computing device 108 are configured to utilize various types of communication to form a closed-loop system among themselves. In this way, when glucose measurement results are obtained through CGM system 104 and when glucose measurement result prediction is generated, insulin delivery system 106 delivers insulin in real time based on the sequence of glucose measurement results.

[0071] According to the described technique, the CGM system 104 is configured to continuously monitor the glucose levels of a person 102. For example, in some embodiments, the CGM system 104 is equipped with a CGM sensor that continuously detects analytes indicating glucose levels in the person 102 and enables the generation of glucose measurement results. In the illustrated environment 100, these measurement results are represented as glucose measurement results 118. The following section discusses… Figure 2 This section describes in further detail the configuration of the CGM system 104 and other aspects.

[0072] In one or more embodiments, the CGM system 104 transmits glucose measurement results 118 to the computing device 108 via one or more communication protocols described herein (such as via wireless communication). The CGM system 104 is configured to communicate these measurements in real time using CGM sensors (e.g., when glucose measurement results 118 are generated). Alternatively or additionally, the CGM system 104 is configured to communicate glucose measurement results 118 to the computing device 108 at specified intervals (e.g., every 30 seconds, every minute, every five minutes, every hour, every six hours, every day, etc.). In some embodiments, the CGM system 104 is configured to communicate glucose measurement results in response to requests from the computing device 108 (e.g., requests initiated when the computing device 108 generates a glucose measurement result prediction for person 102, requests initiated when a user interface is displayed conveying information about glucose measurement results for person 102, combinations thereof, etc.). Therefore, the computing device 108 is configured to at least temporarily hold the glucose measurement result 118 of the person 102 (e.g., by storing the glucose measurement result 118 in a computer-readable storage medium, as described below). Figure 15 (For further detailed description).

[0073] Although shown as a wearable device (e.g., a smartwatch), computing device 108 can be implemented in a variety of configurations without departing from the spirit or scope of the described technology. By way of example, and not limitation, in some embodiments, computing device 108 is configured as a different type of mobile device (e.g., a mobile phone or a tablet device). In other embodiments, computing device 108 is configured as a dedicated device associated with CGM platform 112 (e.g., a device that supports functions such as obtaining glucose measurement results 118 from CGM system 104, performing various calculations related to glucose measurement results 118, displaying information related to glucose measurement results 118 and CGM platform 112, transmitting glucose measurement results 118 to CGM platform 112, and combinations thereof). Compared to the embodiment where computing device 108 is configured as a mobile phone, computing device 108 excludes functions that would otherwise be available in a mobile phone or wearable configuration when implemented in a dedicated CGM device configuration, such as making calls, capturing images, utilizing social networking applications, etc.

[0074] In some embodiments, computing device 108 represents more than one device. For example, computing device 108 may represent both a wearable device (e.g., a smartwatch) and a mobile phone. In such multi-device embodiments, different devices among the multiple devices are capable of performing at least some of the same operations, such as receiving glucose measurement results 118 from CGM system 104, transmitting glucose measurement results 118 to CGM platform 112 via network 116, displaying information related to glucose measurement results 118, etc. Alternatively or additionally, the different devices in the multi-device embodiment support different capabilities relative to each other, such as capabilities limited by the computing instructions of a particular device.

[0075] In some exemplary embodiments where computing device 108 represents a single device (e.g., a smartwatch and a mobile phone), one device is configured with various sensors and functions to measure various physiological markers (e.g., heart rate, respiration, blood flow rate, etc.) and activities (e.g., steps, altitude change, etc.) of a person 102. Continuing with this exemplary multi-device embodiment, another device is not configured with such sensors or functions, or includes a limited number of such sensors or functions. For example, one of the multiple devices includes capabilities not supported by another of the multiple devices, such as a camera for capturing dietary images that can be used to predict future glucose levels, or the amount of computing resources (e.g., battery life, processing speed, etc.) that enable the device to efficiently perform calculations about the glucose measurement result 118. Even in scenarios where one of the multiple devices (e.g., a smartphone) is capable of performing such calculations, computing instructions may restrict the execution of these calculations to one of the multiple devices to avoid burdening multiple devices with redundant computing and to utilize available resources more efficiently. In this way, computing device 108 represents a variety of different configurations and a different number of devices beyond the specific exemplary embodiments described herein.

[0076] As described above, computing device 108 transmits glucose measurement result 118 to CGM platform 112. In the illustrated environment 100, glucose measurement result 118 is depicted as being stored in storage device 120 of CGM platform 112. Storage device 120 represents one or more types of storage devices (e.g., databases) capable of storing glucose measurement result 118. In this way, storage device 120 is configured to store a variety of other data besides glucose measurement result 118. For example, according to one or more embodiments, person 102 represents a user of at least CGM platform 112 and one or more other services (e.g., services provided by one or more third-party service providers). In this way, person 102 can be associated with personally attributable information (e.g., username) and may at some time be required to provide authentication information (e.g., password, biometric data, telemedicine service information, etc.) to access CGM platform 112 using personally attributable information. Storage device 120 is configured to retain this personal attribution information, authentication information, and other information about person 102 (e.g., demographic information, healthcare provider information, payment information, prescription information, health indicators, user preferences, account information associated with the wearable device, social network account information, other service provider information, etc.).

[0077] Storage device 120 is further configured to maintain data about other users in user group 110. Therefore, the glucose measurement results 118 in storage device 120 represent both glucose measurements from the CGM sensor of CGM system 104 worn by person 102 and glucose measurements from CGM systems worn by other individuals in user group 110. Similarly, the glucose measurement results 118 of these other individuals in user group 110 can be transmitted via network 116 to CGM platform 112 by their respective devices, thus associating them with their corresponding user profiles in CGM platform 112.

[0078] Data analytics platform 122 refers to capabilities such as processing glucose measurement results 118 individually using one or more machine learning models and / or processing them together with other data held in storage device 120 to generate multiple predictions. Based on these predictions, CGM platform 112 is configured to provide prediction-related notifications (e.g., alerts, warnings, suggestions, or other information generated based on the predictions). For example, CGM platform 112 is configured to provide notifications to person 102, healthcare providers associated with person 102, combinations thereof, etc. Although depicted as separate from computing device 108, some or all of data analytics platform 122 is optionally or additionally configured to be implemented at computing device 108. Data analytics platform 122 is further configured to generate predictions using additional data obtained via IoT 114.

[0079] For example, according to one or more specific embodiments, data analytics platform 122 is configured to generate glucose measurement result predictions for person 102 and event predictions for events concerning person 102 based on glucose measurement results 118 and additional information (such as information received from IoT 114). For example, data analytics platform 122 is configured to analyze glucose measurement result predictions relative to glucose level thresholds for person 102 and determine whether person 102 is likely to experience an event that should generate a notification (e.g., low glucose level, high glucose level, emergency low glucose level, etc.). By utilizing both glucose measurement results and additional data (e.g., third-party data), data analytics platform 122 is configured to consider various factors affecting the glucose level of person 102, thereby providing more accurate glucose measurement result predictions compared to conventional methods that only consider glucose measurement results as input.

[0080] To provide some of the additional information beyond the previously measured glucose levels, IoT 114 represents a variety of sources capable of providing data describing human 102 and human 102's activities as those of users of one or more service providers, as well as data related to real-world activities. For example, IoT 114 includes various devices belonging to the user (e.g., cameras, mobile phones, laptops, exercise equipment, etc.). In this way, IoT 114 is configured to provide information about the user's interactions with various devices (e.g., interactions with web-based applications, photographs taken, communications with other users, etc.). Alternatively or additionally, IoT 114 may include various real-world artifacts (e.g., shoes, clothing, sports equipment, appliances, vehicles, etc.) equipped with sensors to provide information describing behavior, such as the number of steps taken, the force of the foot striking the ground, stride length, the user's body temperature (and other physiological measurements), the temperature around the user, the type of food stored in the refrigerator, the type of food removed from the refrigerator, driving habits, etc. Alternatively or additionally, IoT 114 includes third parties to the CGM platform 112, such as medical providers (e.g., the medical provider of person 102) and manufacturers (e.g., the manufacturer of CGM system 104, insulin delivery system 106, or computing device 108) capable of providing medical and manufacturing data respectively, and platforms that track person 102's exercise and nutritional intake, which can be utilized by data analytics platform 122. Therefore, IoT 114 represents devices and sensors capable of providing large amounts of data for glucose prediction using machine learning and glucose measurement results, without departing from the spirit or scope of the described technology. Consider the following description in the context of, for example, continuously measuring glucose and obtaining data describing such measurements. Figure 2 The description.

[0081] Figure 2 A more detailed description Figure 1 An exemplary implementation 200 of the CGM system 104 is shown. Specifically, the illustrated example 200 includes a top view and a corresponding side view of the CGM system 104.

[0082] CGM system 104 is shown to include sensor 202 and sensor module 204. In the illustrated example 200, sensor 202 is depicted in a side view as being inserted subcutaneously into skin 206 (e.g., the skin of person 102). Sensor module 204 is depicted in a top view as a rectangle with a dashed outline. CGM system 104 is also shown to include transmitter 208. The use of the dashed outline representing the rectangle of sensor module 204 indicates that sensor module 204 can be accommodated in transmitter 208 or otherwise implemented within the housing of transmitter. In this example 200, CGM system 104 also includes adhesive pad 210 and attachment mechanism 212.

[0083] In operation, sensor 202, adhesive pad 210, and attachment mechanism 212 can be assembled to form an application assembly, wherein the application assembly is configured to be applied to skin 206 such that sensor 202 is subcutaneously inserted as depicted. In such a scenario, transmitter 208 may be attached to the assembly after it has been applied to skin 206, such as via attachment mechanism 212. Additionally or alternatively, transmitter 208 may be incorporated as part of the application assembly, such that sensor 202, adhesive pad 210, attachment mechanism 212, and transmitter 208 (together with sensor module 204) can all be applied to skin 206 simultaneously. In one or more embodiments, the application assembly is applied to skin 206 using a separate applicator (not shown). This application assembly can also be removed by peeling adhesive pad 210 off skin 206. In this way, CGM system 104 and its application assembly are... Figure 2 The various components shown represent an exemplary shape factor, and the CGM system 104 and its components may have different shape factors without departing from the spirit or scope of the described technology.

[0084] In operation, sensor 202 is communicatively connected to sensor module 204 via at least one communication channel, which can be a “wireless” connection or a “wired” connection. Communication from sensor 202 to sensor module 204, or from sensor module 204 to sensor 202, can be active or passive, and can be continuous (e.g., analog) or discrete (e.g., digital).

[0085] Sensor 202 may be a device, molecule, and / or chemical substance that changes or causes a change in response to an event at least partially independent of sensor 202. Sensor module 204 is implemented to receive indications of changes in sensor 202 or changes caused by sensor 202. For example, sensor 202 may include glucose oxidase that reacts with glucose and oxygen to form hydrogen peroxide, which may be electrochemically detected by electrodes of sensor module 204. In this example, sensor 202 may be configured as or may include a glucose sensor configured to detect an analyte in blood or interstitial fluid indicating glucose levels using one or more measurement techniques.

[0086] In another example, sensor 202 (or an additional, undepicted sensor of CGM system 104) may include a first and a second electrical conductor, and sensor module 204 may electrically detect changes in potential across the first and second electrical conductors of sensor 202. In this example, sensor module 204 and sensor 202 are configured as thermocouples such that changes in potential correspond to changes in temperature. In some examples, sensor module 204 and sensor 202 are configured to detect a single analyte (e.g., glucose). In other examples, sensor module 204 and sensor 202 are configured to detect multiple analytes (e.g., sodium, potassium, carbon dioxide, and glucose). Alternatively or additionally, CGM system 104 includes multiple sensors to detect not only one or more analytes (e.g., sodium, potassium, carbon dioxide, glucose, and insulin) but also one or more environmental conditions (e.g., temperature). Thus, sensor module 204 and sensor 202 (and any additional sensors) may detect the presence of one or more analytes, the absence of one or more analytes, and / or changes in one or more environmental conditions.

[0087] In one or more specific implementations, although Figure 2 Not depicted in the illustrated example, sensor module 204 may include a processor and memory. Utilizing such a processor, sensor module 204 may generate a glucose measurement result 118 based on communication with sensor 202 indicating one or more changes (e.g., analyte changes, environmental condition changes, etc.). Based on the communication with sensor 202, sensor module 204 is further configured to generate CGM device data 214. CGM device data 214 represents a communicable data packet including at least one glucose measurement result 118. Alternatively or additionally, CGM device data 214 includes other data, such as multiple glucose measurements 118, sensor identification 216, sensor status 218, combinations thereof, etc. In one or more embodiments, CGM device data 214 may include other information, such as one or more temperatures corresponding to the glucose measurement result 118 and the measurements of other analytes. In this way, CGM device data 214 may include various data other than at least one glucose measurement result 118 without departing from the spirit or scope of the described technology.

[0088] In operation, transmitter 208 can wirelessly transmit CGM device data 214 as a data stream to computing device 108. Alternatively or additionally, sensor module 204 can buffer CGM device data 214 (e.g., in the memory of sensor module 204) and cause transmitter 208 to transmit the buffered CGM device data 214 at various intervals, such as time intervals (every second, every thirty seconds, every minute, every five minutes, every hour, etc.), storage intervals (when the buffered CGM device data 214 reaches a threshold data amount or the number of instances of CGM device 214), combinations thereof, etc.

[0089] In addition to generating CGM device data 214 and causing it to be transmitted to computing device 108, sensor module 204 is configured to perform additional functions according to one or more specific implementations. These additional functions may include generating predictions of future glucose levels for person 102 and delivering notifications based on those predictions (e.g., notifications of anticipated events, warnings when predictions indicate that person 102's glucose levels may be dangerous, etc.). This computational capability of sensor module 204 is particularly advantageous in situations where connectivity to the service via network 116 is limited or absent. In this way, people can be alerted to dangerous situations without relying on connectivity (e.g., an internet connection). This additional function of sensor module 204 may also include initially or continuously calibrating sensor 202, as well as calibrating any other sensors of CGM system 104.

[0090] Regarding CGM device data 214, sensor identification 216 represents information that uniquely identifies sensor 202 from other sensors (e.g., other sensors in other CGM systems 104, other sensors previously or subsequently implanted in skin 206, etc.). By uniquely identifying sensor 202, sensor identification 216 can also be used to identify other aspects of sensor 202, such as the manufacturing batch of sensor 202, packaging details of sensor 202, shipping details of sensor 202, etc. In this way, various problems detected by sensors manufactured, packaged, and / or shipped in a similar manner to sensor 202 can be identified and used in different ways (e.g., to calibrate glucose measurement results 118, to notify the user to replace or dispose of defective sensors, to notify the manufacturing facility of processing problems, etc.).

[0091] Sensor state 218 represents the state of sensor 202 at a given time (e.g., the state of the sensor at the moment a glucose measurement result in glucose measurement result 118 is generated). To this end, sensor state 218 may include an entry for each glucose measurement result in glucose measurement result 118, such that a one-to-one relationship exists between glucose measurement result 118 and the state captured in the sensor state 218 information. Generally, sensor state 218 describes the operational state of sensor 202. In one or more embodiments, sensor module 204 may identify one of a plurality of predetermined operational states for a given glucose measurement result 118. The identified operational state may be based on communication from sensor 202 and / or the characteristics of such communication.

[0092] By way of example, sensor module 204 may include (e.g., in memory or other storage device) a predetermined number of operating states and a lookup table for selecting a state from another state. For example, the predetermined states may include a "normal" operating state, where the basis for selecting this state may be that communication from sensor 202 falls within a threshold indicating normal operation (e.g., within a threshold of expected time, within a threshold of expected signal strength, within a threshold of when the ambient temperature is within a threshold of appropriate temperature to continue operation as expected, a combination thereof, etc.). The predetermined states may also include operating states indicating that one or more characteristics of sensor 202 communication are outside of normal activity and may cause potential errors in the glucose measurement result 118.

[0093] The basis for these abnormal operating states may include receiving communication from sensor 202 outside of a threshold expected time, detecting the signal strength of sensor 202 outside of a expected signal strength threshold, detecting ambient temperature outside of an appropriate temperature to continue operation as expected, detecting that person 102 has changed orientation relative to CGM system 104 (e.g., turning over in bed), etc. Sensor state 218 may indicate various aspects of sensor 202 and CGM system 104 without departing from the spirit or scope of the technology described herein.

[0094] Having considered the exemplary environment and exemplary CGM system, we now consider a description of some exemplary details of a technique, based on one or more specific implementations, for generating event predictions and glucose measurement result predictions using at least one machine learning model.

[0095] Prediction of glucose measurement results

[0096] Figure 3 An exemplary implementation 300 is described in which CGM device data (including glucose measurement results) combined with glucose measurement result predictions using machine learning are guided to different systems.

[0097] Example 300 shown includes CGM system 104 and about Figure 1 An example of the computing device 108 is described. The illustrated example 300 also includes a data analysis platform 122 and a storage device 120, which stores glucose measurement results 118 as described above. In example 300, the CGM system 104 is depicted as transmitting CGM device data 214 to the computing device 108. (See also: ...) Figure 2 As described, CGM device data 214 includes glucose measurement results 118 and other data. CGM system 104 is configured to transmit CGM device data 214 to computing device 108 in various ways.

[0098] The illustrated example 300 also includes a CGM package 302. The CGM package 302 represents data including CGM device data 214 (e.g., glucose measurement result 118, sensor identification 216, and sensor status 218), supplementary data 304, or portions thereof. In this example 300, the CGM package 302 is depicted as being routed from computing device 108 to storage device 120 of CGM platform 112. Generally, computing device 108 includes the capability to generate supplementary data 304, at least in part, based on CGM device data 214. Computing device 108 also includes the capability to package the supplementary data 304 together with CGM device data 214 to form CGM package 302 and to transmit CGM package 302 to CGM platform 112 for storage in storage device 120 (e.g., via network 116). Therefore, CGM package 302 may include data collected by CGM system 104 (e.g., glucose measurement results 118 sensed by sensor 202) and supplementary data 304 generated by computing device 108 (such as a user's mobile phone or smartwatch) that acts as an intermediary between CGM system 104 and CGM platform 112.

[0099] Regarding supplementary data 304, computing device 108 may generate various supplementary data to complement CGM device data 214 included in CGM package 302. According to the described techniques, supplementary data 304 may describe one or more aspects of the user's context, making it possible to identify the correspondence between the user's context and CGM device data 214 (e.g., glucose measurement result 118). By way of example, supplementary data 304 may describe user interactions with computing device 108 and includes, for example, data extracted from application logs describing interactions with a specific application (e.g., choices made, actions performed). Supplementary data 304 may also include clickstream data describing clicks, taps, and presses performed with respect to the input / output interfaces of computing device 108. As another example, supplementary data 304 may include gaze data describing where the user is looking (e.g., about the display device associated with computing device 108 or when the user takes their gaze away from the device), voice data describing audible commands and other spoken phrases from the user or other users (e.g., including passively listening to the user), device data describing the device (e.g., brand, model, operating system and version, camera type, application running on computing device 108), and combinations thereof.

[0100] Supplementary data 304 may also describe other aspects of the user's context, such as environmental factors, including, for example, the user's location, the temperature at that location (e.g., generally outdoors, using a temperature sensing function near the user), the weather at that location, the user's altitude, atmospheric pressure, and contextual information about the user obtained via IoT 114 (e.g., the food the user is eating, the way the user is using sports equipment, the clothing the user is wearing), etc. Supplementary data 304 may also describe detected health-related aspects of the user, including, for example, steps, heart rate, sweating, and the user's body temperature (e.g., as detected by computing device 108), etc. In respect of computing device 108 including the ability to detect or otherwise measure some of the same aspects as CGM system 104, the accuracy, fault detection, etc., of data from these two sources can be compared. The types of supplementary data 304 described above are merely examples, and supplementary data 304 may include more, fewer, or different types of data without departing from the spirit or scope of the technology described herein.

[0101] Regardless of how robustly the supplementary data 304 describes the user's context, the computing device 108 may transmit CGM packet 302 (e.g., containing CGM device data 214 and supplementary data 304) to the CGM platform 112 for processing at various intervals. In one or more embodiments, the computing device 108 streams CGM packet 302 to the CGM platform 112 substantially in real time (e.g., when the CGM system 104 continuously provides CGM device data 214 to the computing device 108). The computing device 108 may alternatively or additionally transmit one or more CGM packets from CGM packet 302 to the CGM platform 112 at predetermined intervals (e.g., every second, every 30 seconds, every hour, etc.).

[0102] Although not depicted in the illustrated example 300, the CGM platform 112 can process the CGM package 302 and cause at least some of the CGM device data 214 and supplementary data 304 to be stored in the storage device 120. This data can be provided from the storage device 120 to the data analysis platform 122 or otherwise accessed by the data analysis platform, thereby enabling the data analysis platform to generate predictions of glucose measurement results and predictions of impending events, as described in further detail below.

[0103] For example, in a specific implementation where CGM system 104 and / or computing device 108 have limited computing resources, data analytics platform 122 is used to expand the computing resources of CGM system 104 and / or computing device 108. Consider an example where data analytics platform 122 receives CGM device data 214 on a periodic basis (e.g., daily, every other day, weekly, etc.). In this example, data analytics platform 122 uses significantly more computing resources than available to CGM system 104 and / or computing device 108 to process CGM device data 214 on a periodic basis. In one example, data analytics platform 122 performs computationally intensive preprocessing of CGM device data 214 on a periodic basis and transmits the preprocessed CGM device data 214 to computing device 108 for additional processing.

[0104] In another example, data analytics platform 122 performs full processing of CGM device data 214 on a periodic basis and communicates instructions regarding the results of this full processing to computing device 108 and / or CGM system 104. For example, data analytics platform 122 trains models such as machine learning models on a periodic basis, and computing device 108 and / or CGM system 104 utilizes or otherwise accesses the trained models. In this example, training the model is computationally resource-intensive and requires significantly more computational resources than are available to CGM system 104 and / or computing device 108, whereas using the trained model is less computationally intensive.

[0105] In yet another example, computing device 108 may be configured to utilize a model trained on a first training dataset, while data analytics platform 122 is configured to continue training the model using additional training datasets, and after training on each additional training dataset, subsequent instances of the trained model are delivered to computing device 108. In this way, CGM system 104, computing device 108, and data analytics platform 122 are configured to work together in a distributed computing environment to utilize additional computing and network resources compared to those otherwise available to any one of CGM system 104, computing device 108, or data analytics platform 122, as described below regarding... Figure 15 Further detailed description.

[0106] In one or more specific implementations, the data analytics platform 122 is configured to ingest data from a third party 306 (e.g., a third-party service provider) for use in conjunction with predictions of upcoming glucose levels and upcoming events. By way of example, the third party 306 may generate its own additional data, such as through a device manufactured and / or deployed by the third party 306 (e.g., a workout device, a wearable device, etc.). The illustrated example 300 includes third-party data 308, which is shown as being transmitted from the third party 306 to the data analytics platform 122 and represents additional data generated by or otherwise transmitted from the third party 306.

[0107] As described above, third party 306 may manufacture and / or deploy associated devices. Additionally or alternatively, third party 306 may obtain data from other sources, such as corresponding applications. Therefore, this data may include user input data entered via corresponding third-party applications (e.g., social networking applications, lifestyle applications, etc.). In view of this, data generated by third party 306 can be configured in various ways, including as proprietary data structures, text files, images obtained via a user's mobile device, formats indicating text input into exposed fields or dialog boxes, formats indicating option selections, combinations thereof, etc.

[0108] Third-party data 308 may describe aspects relating to one or more services provided by a third party without departing from the spirit or scope of the described technology. Third-party data 308 may include, for example, application interaction data describing a user's use or interaction with a specific application provided by third party 306. Generally, application interaction data enables data analytics platform 122 to determine the usage or volume of a specific application by users of user group 110. For example, such data may include data extracted from application logs describing user interactions with a specific application, clickstream data describing clicks, taps, and presses performed regarding the application's input / output interfaces, etc. In one or more embodiments, data analytics platform 122 is configured to receive third-party data 308 generated by third party 306 or otherwise obtained.

[0109] Data analytics platform 122 is shown to include prediction system 310. According to the described system, prediction system 310 is configured to generate prediction 312 based on glucose measurement results 118. Specifically, prediction system 310 is configured to generate predictions 312 of glucose measurement results and upcoming events to occur in future time intervals based on glucose measurement results 118 obtained during previous time intervals and confidence levels associated with various predictions 312. For example, prediction system 310 is configured to predict the occurrence (or non-occurrence) of an upcoming event in a certain time interval based on glucose measurement results 118 obtained during previous time intervals, historical user information, and combinations thereof. As described further below, prediction 312 may be based on glucose measurement results 118 that have been sorted by timestamps to form time-series glucose measurement results (e.g., glucose traces). In one or more embodiments, for example, additional data used by prediction system 310 to generate prediction 312 may include one or more portions of CGM device data 214, supplementary data 304, third-party data 308, data from IoT 114, combinations thereof, etc. As described below, the prediction system 310 can generate such predictions 312 by using multiple machine learning models arranged in a stacked configuration. These models can be trained using glucose measurements 118 and additional data obtained from the user population 110 or otherwise constructed.

[0110] Based on the generated prediction 312, the data analysis platform 122 may also generate a notification 314. For example, the notification 314 may remind the user of an impending event prediction that may cause the user's glucose level to exceed a high glucose threshold, a low glucose threshold, etc. Alternatively or additionally, the notification 314 may also support decisions on how to mitigate the adverse health effects associated with problematic glucose levels, such as by recommending actions (e.g., consuming specific foods or beverages, downloading the application to the computing device 108, seeking immediate medical attention, reducing insulin dosage, or changing exercise behavior), continuing behaviors (e.g., continuing to eat in a certain way or exercise in a certain way), changing behaviors (e.g., changing eating or exercise habits, changing basal or bolus insulin dosage), or combinations thereof.

[0111] In such scenarios, prediction 312 and / or notification 314 are communicated from data analytics platform 122 and output via computing device 108. In illustrated example 300, prediction 312 and notification 314 are further shown as being communicated to computing device 108. Additionally or alternatively, prediction 312 and / or notification 314 may be directed to decision support platform and / or verification platform before being delivered to computing device 108. Considering the context of generating prediction 312, Figure 4 The following description applies. Prediction 312 and / or notification 314 may be further delivered to a third party 306, such as to a healthcare provider associated with person 102.

[0112] Figure 4 The glucose measurement results, used in conjunction with a machine learning model, are described in more detail. Figure 3 An exemplary embodiment 400 of the prediction system 310. As used herein, the term "machine learning model" refers to a computer representation that can be adjusted (e.g., trained) based on inputs to approximate an unknown function. By way of example, the term "machine learning model" can include a model that uses algorithms to learn from and predict known data by analyzing known data, in order to learn to generate outputs that reflect patterns and properties of the known data. Depending on the specific embodiment, such a machine learning model uses supervised learning, semi-supervised learning, unsupervised learning, reinforcement learning, and / or transfer learning. For example, a machine learning model may include, but is not limited to, clustering, decision trees, support vector machines, linear regression, logistic regression, Bayesian networks, random forest learning, dimensionality reduction algorithms, reinforcement algorithms, artificial neural networks (e.g., fully connected neural networks, deep convolutional neural networks, or recurrent neural networks), deep learning, etc. By way of example, a machine learning model performs a high-level abstraction of data by generating data-driven predictions or decisions based on known input data.

[0113] In the illustrated example 400, the prediction system 310 is configured to receive glucose measurement results 118 (e.g., from storage device 120), timestamp 402, and additional data 404. Depending on one or more embodiments, the glucose measurement results 118 and the additional data 404 may correspond to a person 102. Each glucose measurement result in the glucose measurement results 118 corresponds to a timestamp in the timestamp 402. In this way, a one-to-one relationship may exist between glucose measurement results 118 and timestamp 402, such that for each individual glucose measurement result 118, there is a corresponding timestamp 402. In one or more embodiments, CGM device data 214 may include glucose measurement results 118 and corresponding timestamps 402. Therefore, the corresponding timestamp 402 may be associated with (e.g., in conjunction with) the glucose measurement results 118 at the CGM system level 104. Regardless of how timestamp 402 is associated with glucose measurement result 118 or which device associates timestamp 402 with glucose measurement result 118, each glucose measurement result in glucose measurement result 118 has a corresponding timestamp 402.

[0114] In this example 400, the prediction system 310 is depicted as including a sequence manager 406 and a prediction manager 408, wherein the prediction manager 408 is configured to generate a prediction 312 based on one or more of glucose measurement results 118, timestamps 402, and additional data 404. Although the prediction system 310 is depicted as including only the sequence manager 406 and the prediction manager 408, the prediction system 310 may have more, fewer, and / or different components to generate the prediction 312, examples of which are described in further detail below.

[0115] Sequencing manager 406 represents the function of prediction system 310 in generating time-series glucose measurement results 118 (e.g., time series data) based on glucose measurement results 410 and timestamp 402. While glucose measurement results 118 are generally received sequentially (e.g., received by CGM platform 112 from CGM system 104 and / or computing device 108 as glucose measurement results 118 are generated), in some cases, one or more glucose measurement results in glucose measurement results 118 may not be received in the same order as the order in which they were generated (e.g., packets with glucose measurement results 118 may be transmitted or received out of order). Therefore, the order of reception may not temporally match the order in which CGM system 104 generated glucose measurement results 118. Alternatively or additionally, communication including one or more glucose measurement results in glucose measurement results 118 may be disrupted. In this way, there may be several reasons why glucose measurement results 118 obtained by prediction system 310 may not be exactly in chronological order.

[0116] To generate a time-series glucose measurement result 410, the sequencing manager 406 determines the temporal sequence of the glucose measurement result 118 based on the corresponding timestamp 402. The sequencing manager 406 outputs the temporal sequence of the glucose measurement result 118 as the time-series glucose measurement result 410. The time-series glucose measurement result 410 can be configured independently or otherwise referred to as a "glucose trace".

[0117] According to the techniques described herein, sequencing manager 406 generates time-series glucose measurement results 410 for specific time intervals. In one or more specific embodiments, the time-series glucose measurement results 410 correspond to time intervals corresponding to previous days and are used by machine prediction manager 408 to predict glucose measurement results for the current day or the upcoming day. Therefore, unlike conventional systems that extract features from glucose measurement results to generate predictions, time-series glucose measurement results 410 correspond to a complete set of estimated glucose values ​​for a specific person 102 within any suitable previous time period (e.g., one or more previous days, 12 hours previous, six hours previous, one hour previous, 30 minutes previous, etc.). It is noteworthy that the duration and timing of the time intervals spanned by the time-series glucose measurement results 410 can vary based on a variety of factors without departing from the spirit or scope of the techniques described herein. For example, in some cases, the time interval can be customized to correspond to the activity schedule of person 102 (e.g., using one time interval to correspond to person 102's sleep schedule and using another time interval to correspond to person 102's activity (i.e., wakefulness) schedule). In this way, sequencing manager 406 is configured to generate time-series glucose measurement results 410 for any suitable time interval, which may span multiple days (e.g., the first seven days), or certain hours within multiple days (e.g., 5:00 AM to 10:00 PM for the first 14 days), etc.

[0118] When glucose measurement results and / or user behavior information are provided as input, prediction manager 408 is configured to generate prediction 312. According to one or more specific embodiments, prediction manager 408 is further configured to generate prediction 312 by supplementing the input of glucose measurement result 118 (e.g., in the form of time-series glucose measurement result 410) with additional data 404. Additional data 404 represents information that can be used to describe aspects that may affect the future glucose level of person 102. Additional data 404 may be temporally correlated with glucose measurement result 118 (e.g., based on a timestamp associated with additional data 404). By way of example, and not limitation, such additional data 404 may include application usage data (e.g., click stream data describing the displayed user interface and user interactions with the application via the user interface), accelerometer data from a mobile device or smartwatch (e.g., indicating that a person has viewed the device's user interface and may therefore have seen an alert or message related to a predicted event), explicit feedback to notification prompts requesting input about a user's current or planned activities, data describing insulin administration (e.g., time and insulin dose), data describing food consumption (e.g., time of food consumption, type of food, and / or amount of carbohydrates consumed), activity data from various sensors (e.g., step count data, fitness activities performed, or other data indicating user activity or exercise), glucose level responses to stress, combinations thereof, etc.

[0119] For example, supplementary data 404 includes interaction data describing the interaction between person 102 and computing device 108, including information describing the interaction between person 102 and the application associated with CGM system 104. In some examples, supplementary data 404 describes person 102's response to alarms displayed in the user interface of computing device 108, such as how long person 102 views the displayed alarm and / or whether person 102 clears the displayed alarm. In one example, supplementary data 404 includes the number of times person 102 interacts with computing device 108 to check glucose measurement result 118, the duration of these interactions, the time since the most recent interaction, etc.

[0120] In this way, supplementary data 404 may include information describing the occurrence of actual historical events that could influence predictions of future glucose measurement results. For example, in an exemplary scenario where supplementary data 404 includes information specifying that person 102 exercised on Thursday at 4:00 PM, supplementary data 404 can be used as a basis for generating predictions related to future time intervals, such as the time interval spanning from 12:00 PM to 1:00 PM on the following Saturday. Because changes occurring in the muscles affect person 102's insulin sensitivity several hours after exercise (e.g., 48 hours or longer), information confirming when person 102 previously exercised is crucial for generating accurate predictions 312 related to future insulin administration events. Therefore, by taking into account the supplementary data 404 confirming the occurrence of the exercise event, the subsequently generated prediction 312 can be used to recommend the correct dose and / or type of insulin to be administered in a manner that mitigates potential health consequences, such as delayed post-exercise hypoglycemia.

[0121] Further examples of aspects indicative of a person's future glucose levels may include the person's body temperature, ambient temperature, atmospheric pressure, and the presence or absence of various health conditions (e.g., pregnancy, illness, etc.). Furthermore, aspects indicative of a person's future glucose levels may include data describing aspects of exercise (e.g., frequency, duration, intensity, etc.), sleep (e.g., duration, quality, etc.), and stress (e.g., blood pressure, heart rate, etc.), to name just a few. In this way, additional data 404 may include references above. Figure 3 The supplementary data 304 and / or third-party data 308 are described. In some specific implementations, the supplementary data 404 may represent information output by one or more machine learning models implemented by the prediction manager 408 in the process of generating prediction 312.

[0122] To generate prediction 312, the prediction manager utilizes at least one machine learning model 412. Machine learning model 412 represents a machine learning model trained to process input data, identify patterns in the input data, and generate predictive outputs based on the identified patterns. For example, when provided with additional data 404, glucose measurement results 118, or the outputs of one or more other machine learning models 412 implemented by prediction manager 408, machine learning model 412 may be trained to predict a target based on the glucose measurement results of person 102. In some implementations, machine learning model 412 represents multiple different machine learning models, each trained based on a different predictive target, to individually predict one of insulin administration events, exercise events, meal events, sleep or other recovery events, stress events, etc.

[0123] In addition to being trained on person-specific information 102, machine learning model 412 can be further trained using historical supplementary data from user group 110. In this way, by utilizing glucose measurement results 118 and supplementary data 404, the accuracy and confidence associated with predictions generated by machine learning model 412 are improved.

[0124] In one or more embodiments, supplementary data 404 received as input by the prediction manager 408 is associated with an application of the CGM platform 112. For example, the CGM platform 112 application may execute on a user's computing device (e.g., a smartphone or smartwatch) to display glucose measurement results 118, prediction 312, notifications associated with the prediction, etc., to the user (e.g., in the user interface of the CGM platform application). In this way, the supplementary data 404 may correspond to a screen view or user selection of different controls in the CGM application. Such an application uses the data to enable the prediction manager 408 to receive feedback from the user regarding whether the notification 314 corresponding to prediction 312 is accurate, helpful, or inconvenient, and to receive feedback from the user providing further context for the prediction (e.g., the user's expected response to mitigate the problematic glucose level associated with prediction 312). This feedback can be used to assign a confidence level associated with prediction 312, which the prediction system 310 may further use to selectively refine one or more parameters of the machine learning model 412. Therefore, the machine learning model 412 of the prediction manager 408 can learn patterns associated with various event responses (e.g., changes in glucose levels) to the person 102, and then adjust its subsequent predictions accordingly.

[0125] Glucose measurement result prediction 414 represents the output prediction generated by the machine learning model 412 of the prediction manager 408. This output prediction can then be trained based on one or more training methods and using one or more of the following: historical glucose measurement results 118, supplementary data 404, or output predictions generated by other machine learning models in the stacked machine learning models 412, or the underlying model can be learned. See below. Figure 12 The training of machine learning model 412 is described in more detail.

[0126] Exemplary ways in which the machine learning model 412 can be configured include, for example, neural networks (e.g., recurrent neural networks such as Long Short-Term Memory networks (LSTM), state machines, Markov chains, Monte Carlo methods, and particle filters, to name just a few. Thus, the machine learning model 412 is configured to classify an input stream of observed glucose values ​​118 and contextual data describing the various effects on the observed glucose values ​​in order to generate a glucose measurement prediction.

[0127] For example, consider Figure 5 This depicts an exemplary representation 500 of observed glucose measurements 118 based on one or more specific implementations and a glucose measurement prediction 414 generated by the prediction system 310. As shown, representation 500 includes a current time indication 502 that defines the relationship between a past time period 504 and a future time period 506. The past time period 504 includes multiple glucose measurements 118, which are at least partially utilized to generate multiple glucose measurement predictions 414 included in the future time period 506. In one example, the prediction system 310 receives the glucose measurements 118 of the past time period 504 as input, and the prediction system 310 generates the glucose measurement prediction 414 based on the glucose measurements 118 and / or additional data 404.

[0128] Each glucose measurement result prediction in glucose measurement result prediction 414 is shown as including a predicted glucose value 508 within a range defined by an upper limit value 510 and a lower limit value 512. For example, a specific predicted glucose value 508 represents an estimated or highest probability glucose value at a specific time within a future time period 506. The upper limit value 510 and the lower limit value 512 associated with a specific predicted glucose value 508 represent the upper and lower limits, respectively, of the range of possible glucose values ​​at a specific time based on the defined confidence level of glucose measurement result prediction 414. This range of possible glucose values ​​generally increases as the specific time extends relative to the current time indication 502. For example, as time progresses within the future time period 506, the associated confidence level with respect to each predicted glucose value in the predicted glucose values ​​508 gradually decreases. As the confidence level in the predicted glucose values ​​508 decreases, the range between the upper limit value 510 and the lower limit value 512 of glucose measurement result prediction 414 increases.

[0129] As shown in the figure, 500 includes a low alarm threshold 514 and a high alarm threshold 516. To provide the user of the CGM system 104 with an early warning that the glucose measurement result prediction 414 meets one or more of the low alarm threshold 514 or the high alarm threshold 516, the CGM system 104 compares the glucose measurement result prediction 414 with the low alarm threshold 514 and the high alarm threshold 516. In response to determining that the glucose measurement result prediction 414 meets the low alarm threshold 514 or the high alarm threshold 516, the CGM system 104 generates a corresponding alarm configured to be displayed in the user interface of the computing device 108.

[0130] In some examples, the CGM system 104 uses the confidence level of glucose measurement prediction 414 that meets either a low alarm threshold 514 or a high alarm threshold 516 as part of generating the corresponding alarm. For example, the CGM system 104 only generates an alarm if the confidence level of glucose measurement prediction 414 that meets the alarm threshold is at least the threshold confidence level. The confidence threshold level can be 85%, 90%, 95%, 99%, etc. In some examples, the CGM system 104 avoids generating alarms based on glucose measurement prediction 414 with a confidence level lower than the threshold confidence level.

[0131] In the illustrated example, the low alarm threshold 514 and the high alarm threshold 516 are configured according to default settings (e.g., the default settings of the CGM system 104 determined based on glucose measurement results 118 of user group 110). Alternatively or additionally, the low alarm threshold 514 and / or the high alarm threshold 516 may be adjusted according to their respective default settings (e.g., via user input implemented through interaction with a corresponding application implemented at computing device 108, in response to data received from a healthcare provider associated with person 102, combinations thereof, etc.). In one example, computing device 108 transmits data describing changes in alarm threshold settings to CGM system 104, which processes the data and generates a high glucose / low glucose alarm based on the modified settings. In another example, computing device 108 generates an alarm by processing data received from CGM system 104 indicating whether glucose measurement result prediction 414 meets one or more of the low alarm threshold 514 or the high alarm threshold 516. In some implementations, the amount of time before a threshold for outputting a corresponding alarm (e.g., a low alarm threshold 514 or a high alarm threshold 516) is met is at least partially controlled by the prediction range 518 associated with the alarm. Although described herein with reference to high and low thresholds, thresholds such as “urgent low” thresholds, “critical high” thresholds, etc., can be specified for any number of different alarms for the user of CGM system 104, thereby enabling the customization of alarms associated with CGM system 104 based on the specific needs and / or preferences of person 102.

[0132] like Figure 5As shown, 500 includes a prediction range 518, which is shown as a subset of the future time period 506. Although shown as including only the appropriate subset of the future time period 506, in some examples, the prediction range 518 extends over the entire future time period 506. The prediction range 518 is associated with a specific alarm and generally corresponds to an advance warning time before an alarm is output before it is determined that the associated glucose measurement result prediction 414 meets an alarm threshold (e.g., a low alarm threshold 514 or a high alarm threshold 516). In this way, a “low” alarm associated with a low alarm threshold 514 can be associated with a prediction range 518 that is different from the prediction range of a “high” alarm associated with a high alarm threshold 516. Since the confidence associated with the glucose measurement result prediction 414 is generally inversely proportional to the amount of future time relative to the current time 502, the prediction range 518 limits the advance warning time associated with the alarm to mitigate the amount of false positive warnings that would otherwise be generated by low-confidence future predictions. It should be understood that in some scenarios, such as those where additional data 404 describes future contextual data (e.g., person 102 will eat within two hours), the relationship between the confidence level associated with the glucose measurement result prediction 414 is not necessarily directly or inversely proportional to the amount of future time relative to the current time 502. Therefore, the CGM system 104 monitors the glucose measurement result prediction 414 and causes an alarm to be output in response to determining that the glucose measurement result prediction 414 meets an alarm threshold (e.g., a low alarm threshold 514 or a high alarm threshold 516) within an appropriate prediction range 518 for an alarm.

[0133] In one example, the CGM system 104 determines whether a specific glucose measurement prediction 414 is at or above a corresponding alarm threshold based on a predicted glucose value 508 of that prediction. In this example, the CGM system 104 compares the predicted glucose value 508 with the threshold because the predicted glucose value 508 corresponds to the highest probability value between the upper limit 510 and the lower limit 512 of the specific glucose measurement prediction 414. Therefore, if the CGM system 104 identifies that the predicted glucose value 508 is at or below the corresponding threshold within the prediction range 518 of the alarm, the CGM system 104 determines that the specific glucose measurement prediction 414 is sufficient to generate an alarm.

[0134] In another example, the CGM system 104 uses a lower limit 512 of the glucose measurement result prediction 414 to compare with a threshold to determine whether a particular glucose measurement result prediction 414 guarantees the output of a corresponding alarm. By using the lower limit 512 to determine whether a particular glucose measurement result prediction 414 meets (e.g., is at, above, or below) a threshold, the CGM system 104 changes the probability of determining that a particular glucose measurement result prediction 414 meets the threshold for an alarm. For example, in an implementation where the lower limit 512 is compared with a low measurement alarm (e.g., low alarm, critical low alarm, etc.), using the lower limit 512 of the glucose measurement result prediction 414 increases the likelihood that the glucose measurement result prediction 414 will trigger a low measurement alarm. Conversely, in an implementation where the lower limit 512 is compared with a high measurement alarm (e.g., high alarm, critical high alarm, etc.), using the lower limit 512 of the glucose measurement result prediction 414 decreases the likelihood that the glucose measurement result prediction 414 will trigger a high measurement alarm.

[0135] Alternatively or additionally, the CGM system 104 may use the upper limit value 510 as a threshold for determining whether a particular glucose measurement prediction 414 meets an alarm requirement. For example, in an implementation where the upper limit value 510 is compared with a low measurement alarm, the upper limit value 510 reduces the likelihood that the glucose measurement prediction 414 will trigger a low measurement alarm. Conversely, in an implementation where the upper limit value is compared with a high measurement alarm, the upper limit value 510 increases the likelihood that the glucose measurement prediction 414 will trigger a high measurement alarm.

[0136] Regardless of whether the CGM system 104 uses a specific predicted glucose value 508, a specific upper limit value 510, or a specific lower limit value 512 to determine whether a specific glucose measurement result prediction 414 meets the alarm threshold, the CGM system can use the confidence level of the specific glucose measurement result prediction 414 to determine whether to generate an alarm. For example, the CGM system 104 compares the confidence level of the specific glucose measurement result prediction 414 with a threshold confidence level. If the confidence level of the specific glucose measurement result prediction 414 is greater than or equal to the threshold confidence level, the CGM system 104 can generate an alarm. Conversely, if the confidence level of the specific glucose measurement result prediction is less than the threshold confidence level, the CGM system 104 may not generate an alarm.

[0137] In response to determining that the predicted glucose measurement result 414 meets an alarm threshold within the predicted range 518 of the alarm, the CGM system 104 causes an output alarm (e.g., to be displayed in the user interface of the computing device 108). Therefore, the output of the alarm enables the person 102 to intervene and prevent a future observed glucose measurement result 118 from actually meeting the corresponding threshold of the warning (e.g., low alarm threshold 514, high alarm threshold 516, etc.). Examples of such intervention include consuming dietary supplements configured to increase blood glucose levels, taking glucose tablets, consuming carbohydrates, exercising, disabling the insulin delivery system 106, administering insulin (e.g., via the insulin delivery system 106 or manually), combinations thereof, etc.

[0138] The CGM system 104 provides an early warning to person 102 of the probability of a problematic glucose event by generating an alarm based on an alarm threshold within a prediction range 518 that determines if a glucose measurement result prediction 414 meets the alarm. As described above, the amount of this early warning time for a problematic glucose event is at least partially related to the length of the prediction range 518 (e.g., the duration of the prediction range 518 relative to the current time 502). Generally, increasing the length of the prediction range 518 also increases the amount of early warning time between the alarm output and the occurrence of the prediction that the glucose measurement result prediction 414 meets the threshold. Similarly, decreasing the length of the prediction range 518 generally decreases the amount of early warning time between the alarm output and the occurrence of the prediction that the glucose measurement result prediction 414 meets the threshold.

[0139] CGM system 104 is also capable of modifying prediction range 518 and / or using multiple prediction ranges together with the confidence level of glucose measurement prediction 414 included in the modified prediction range and / or multiple prediction ranges to generate or avoid generating an alarm. Consider an example in which CGM system 104 determines that glucose measurement prediction 414 included in prediction range 518 meets an alarm threshold and CGM system 104 also determines a first confidence level for glucose measurement prediction 414. In this example, CGM system 104 modifies prediction range 518 by increasing or decreasing the length of prediction range 518 to generate a modified prediction range 518. CGM system 104 then determines that glucose measurement prediction 414 included in the modified prediction range 518 meets an alarm threshold and that this glucose measurement prediction 414 has a second confidence level. CGM system 104 compares the first confidence level with the second confidence level.

[0140] In an example where the first confidence level is greater than the second confidence level, the CGM system 104 generates an alarm based on the prediction range 518. In an example where the second confidence level is greater than the first confidence level, the CGM system 104 generates an alarm based on a modified prediction range 518. In another example, the CGM system 104 compares the larger of the first and second confidence levels with a threshold confidence level and avoids generating an alarm if the larger of the first and second confidence levels is less than the threshold confidence level.

[0141] Consider another example where CGM system 104 uses multiple prediction ranges to generate alarms. In this example, the CGM system can use different prediction ranges, starting with a five-minute prediction range and including additional prediction ranges whose durations increase in five-minute increments, such as five-minute prediction ranges, 10-minute prediction ranges, 15-minute prediction ranges, 20-minute prediction ranges, 25-minute prediction ranges, 30-minute prediction ranges, 35-minute prediction ranges, 40-minute prediction ranges, 45-minute prediction ranges, 50-minute prediction ranges, 55-minute prediction ranges, 60-minute prediction ranges, etc.

[0142] In the previous example, multiple prediction ranges can be extended by overlapping, such that glucose measurement prediction 414 included in a five-minute prediction range is also included in a 10-minute prediction range, glucose measurement prediction 414 included in a 10-minute prediction range is also included in a 15-minute prediction range, glucose measurement prediction 414 included in a 15-minute prediction range is also included in a 20-minute prediction range, and so on. However, in other examples, multiple prediction ranges may not be extended by overlapping (e.g., they do not overlap) and may not be temporally consecutive (e.g., one or more gaps in the future time period 506 may separate the end of a prediction range from the beginning of the next prediction range of multiple prediction ranges).

[0143] In some examples, multiple prediction ranges may partially overlap, such that the end of the first prediction range does not occur until the beginning of the second prediction range in a future time period 506. In these examples, the partial overlap between the start of the next prediction range and the end of the previous prediction range can be utilized in several ways. For example, during the partial overlap between the start of the next prediction range and the end of the previous prediction range, the glucose measurement result prediction 414 of the previous prediction range can be compared with the glucose measurement result prediction 414 of the next prediction range to confirm and / or verify the confidence level in the glucose measurement result prediction 414 of the next prediction range. In similar examples, the glucose measurement result prediction 414 of the previous prediction range may have been compared with the glucose measurement result prediction 414 of an additional previous prediction range included in the additional partial overlap between the start of the previous prediction range and the end of an additional previous prediction range, etc.

[0144] In some examples, the CGM system 104 utilizes a combination of multiple prediction ranges and confidence levels of glucose measurement predictions 414 that satisfy alarm thresholds within the multiple prediction ranges to reduce false positive alarms and / or the amount of advance warning time between the predicted occurrence of an alarm and the corresponding glucose event. For example, if multiple glucose measurement predictions 414 satisfy alarm thresholds within one or more of the multiple prediction ranges, the CGM system 104 may identify a specific glucose measurement prediction 414 among the multiple glucose measurement predictions 414 as having the highest confidence level. In this example, the CGM system 104 generates an alarm based on the specific glucose measurement prediction 414, which minimizes false positive alarms. For example, the CGM system 104 may identify the specific glucose measurement prediction 414 as having the highest confidence level, which is also greater than the threshold confidence level.

[0145] Consider an example where the CGM system 104 determines a threshold for an alarm within one or more prediction ranges of a plurality of glucose measurement result predictions 414. In this example, the CGM system 104 identifies a specific glucose measurement result prediction 414 among the plurality of glucose measurement result predictions 414 as meeting the threshold for an alarm within the longest prediction range of one or more prediction ranges of one or more glucose measurement result predictions among the glucose measurement result predictions 414 that meet the threshold. For example, if the specific glucose measurement result prediction 414 is also associated with a confidence level greater than the threshold confidence level, the CGM system generates an alarm based on the specific glucose measurement result prediction 414. In this way, the CGM system 104 extends the amount of advance warning time between the delivery of the alarm and the predicted occurrence of the glucose event corresponding to the delivered alarm.

[0146] Consider a specific example where the CGM system 104 utilizes multiple prediction ranges, including a first prediction range extended by 10 minutes, a second prediction range extended by 20 minutes, and a third prediction range extended by 30 minutes. In this example, each of the three prediction ranges includes a glucose measurement result prediction 414 that meets an alarm threshold. The CGM system 104 determines a confidence level in each of the glucose measurement result predictions 414 that meet the alarm threshold. For example, the confidence level in the first glucose measurement result prediction 414 that meets the alarm threshold in the second prediction range is higher than the confidence level in the second glucose measurement result prediction 414 that meets the alarm threshold in the third prediction range. If both the first and second glucose measurement result predictions 414 are greater than the threshold confidence level, then in one example, the CGM system 104 generates an alarm based on the second glucose measurement result prediction 414 because the third prediction range is longer than the second prediction range. In this example, the CGM system 104 extends the advance warning time between delivering the alarm and the predicted occurrence of the glucose event corresponding to the delivered alarm. In one example where the CGM system 104 reduces false positive alarms, the CGM system 104 generates an alarm based on the association of a first glucose measurement result prediction 414 with a higher confidence level than a second glucose measurement result prediction 414.

[0147] Having considered an example of glucose measurement predictions generated by prediction system 310 relative to a glucose level threshold for alarm notification, we now consider exemplary specific implementations of different prediction ranges for alarm notification.

[0148] Figure 6 Depicting by Figure 3 An exemplary representation 600 shows the relationship between a glucose measurement prediction 414 generated by the prediction system and the prediction range associated with an alarm notification for the glucose measurement prediction 414. Representation 600 includes a current time indication 602 that defines the relationship between a past time period 604 and a future time period 606. (As...) Figure 5 The past time period 604, as depicted in representation 500, includes multiple observed glucose measurements 118, which are at least partially utilized by prediction system 310 to generate multiple glucose measurement predictions 414 expected to occur during the future time period 606.

[0149] The designation 600 includes a low alarm threshold 514 and a high alarm threshold 516, as well as a first prediction range 608, a second prediction range 610, and a third prediction range 612. The first prediction range 608 is shown as extending from the current time, as indicated by crossing from the current time indication 602 to the first future time indication 614. In one example, the first prediction range 608 is the default prediction range for alarms corresponding to the low alarm threshold 514 and / or the high alarm threshold 516, such as the prediction range determined based on CGM device data 214 of user group 110.

[0150] In another example, the first prediction range 608 is greater than or less than the default prediction range of one or more alarms of the CGM system 104. In this example, the modification of the default prediction range can be defined by a person 102 through interaction with an application of the computing device 108, such as the application of the CGM system 104. Therefore, the first prediction range 608 represents any suitable time metric (e.g., 10 minutes, 15 minutes, 20 minutes, 25 minutes, 30 minutes, etc.).

[0151] like Figure 6 As shown, the value of glucose measurement result 118 is indicated to have increased just before the current time indicator 602, where glucose measurement result prediction 414 exceeds a high alarm threshold 516 within a first prediction range 608. In an exemplary embodiment where the high alarm threshold 516 is associated with the first prediction range 608, in response to identifying that at least one of the glucose measurement result predictions 414 meets the high alarm threshold 516 during the first prediction range 608, the CGM system 104 causes the output of a corresponding alarm (e.g., via a display in the user interface of the computing device 108). The output of the high alarm may prompt or otherwise encourage person 102 to intervene and prevent future observed glucose measurement results 118 from actually rising to the value associated with the high alarm threshold 516. Examples of interventions to prevent persistently elevated glucose levels include taking insulin, exercising, avoiding carbohydrate consumption, etc.

[0152] Continuing the example, the value of glucose measurement prediction 414 is shown to decrease after exceeding the high alarm threshold 516 within the first prediction range 608. This decrease in the value of glucose measurement prediction 414 can reflect interventions by human 102, such as interventions taken in response to a high alarm output. Although glucose measurement prediction 414 is shown to decrease after exceeding the high alarm threshold 516, the CGM system 104 will not output a corresponding low alarm if a low alarm is also associated with the first prediction range 608. This is because the first prediction range 608 does not include glucose measurement predictions 414 that meet the low alarm threshold 514 (e.g., a glucose measurement prediction 414 that meets the low alarm threshold 514 is predicted to occur only after the first future time indication 614, which marks the end of the first prediction range 608).

[0153] Compared to the first forecast range, the second forecast range 610 extends further into the future time period 606 than the first forecast range 608, as shown in representation 600. Specifically, the second forecast range 610 extends from the current time to a second future time indicated by the second future time indication 616. In this way, the second forecast range 610 represents any suitable time measure (e.g., 20 minutes, 25 minutes, 30 minutes, 35 minutes, 40 minutes, etc.) that is greater than the amount of time associated with the first forecast range 608.

[0154] Although shown to span from the current time to the second future time indication 616, the second prediction range 610 may alternatively begin at a start time different from the current time. In one example, the second prediction range 610 begins at a time point included in the first prediction range 608, such as at or before the first future time indication 614, and spans up to the second future time indication 616. In this example, the computational resources of the CGM system 104 are conserved by monitoring only a portion of the glucose measurement result prediction 414, which would otherwise be represented as occurring between the current time and the second future time indication 616. Therefore, although shown in representation 600 to span three distinct and overlapping time points, the prediction range 518, as described herein, can span any amount of time and is not limited to starting at the current time.

[0155] By way of example, and regardless of when prediction range 518 begins and / or ends, prediction range 518 can advance as the current time progresses within future time period 506 (e.g., advances substantially in real time). In the previous example, as the current time advances by one time unit, the start and end of prediction range 518 also advance by one future time unit within future time period 506. In other examples, the start and / or end of prediction range 518 may advance faster or slower than the current time, such as advancing by 0.5 or 1.5 future time units based on advancing one time unit from the current time. In one example, the start and / or end of prediction range 518 may not advance as the current time progresses (e.g., prediction range 518 may be static relative to the dynamic current time).

[0156] For example, prediction range 518 may advance within a future time period 506 in time increments corresponding to the frequency at which prediction system 310 generates glucose measurement result prediction 414. In this example, if prediction system 310 generates a glucose measurement result prediction 414 every two time units, prediction range 518 may not advance by one time unit within the future time period 506 in response to the current time. Alternatively, in this example, prediction range 518 may advance by two future time units in response to the current time advancing by two time units, based on the frequency at which prediction system 310 generates glucose measurement result prediction 414.

[0157] In some examples, the advancement of prediction range 518 in future time period 506 may be delayed relative to the advancement of the current time. This delay between the advancement of the current time and the advancement of prediction range 518 may correspond to a time delay equal to a multiple of the frequency at which prediction system 310 generates glucose measurement prediction 414. For example, as the current time advances, CGM system 104 indicates a new glucose measurement 118 in past time period 504. This new glucose measurement 118 corresponds to a specific glucose measurement prediction 414 included in future time period 506 prior to the advancement of the current time. In one example, prediction system 310 compares the value of the new glucose measurement 118 with the value of the specific glucose measurement prediction 414.

[0158] By comparing the new glucose measurement result 118 with the previous glucose measurement result prediction result 414 in this manner, the prediction system 310 improves the accuracy of the predicted glucose value 508 and the confidence level in these predictions. For example, the prediction system 310 may adjust the glucose measurement result prediction 414 based on this comparison. In another example, the prediction system 310 uses this comparison to generate a new glucose measurement result prediction 414. The prediction system 310 may also compare multiple new glucose measurement results 118 with the values ​​of the glucose measurement result prediction results 414 to further improve the confidence level in the predicted glucose value 508.

[0159] like Figure 6 As shown and above regarding Figure 5 The difference between the corresponding upper limit 510 and lower limit 512 of the glucose measurement result prediction 414 generally increases as the glucose measurement result prediction 414 is further generated from the current time in a future time period 606. For example, this increasing difference between the upper and lower limits of the glucose measurement result prediction 414 explains a wider error tolerance relative to the predicted glucose value 508 of the glucose measurement result prediction as the prediction 414 is further generated in the future. Due to this gradually increasing error tolerance regarding the glucose measurement result prediction as the glucose measurement result prediction 414 is further predicted from the current time, the prediction output by the prediction system 310 is generally more reliable in the first prediction range 608 than the prediction included in the second prediction range 610. For example, if the lower limit 512 of the glucose measurement result prediction 414 included in the second prediction range exceeds the low warning threshold 514, while the corresponding predicted glucose value 508 of the same glucose measurement result prediction 414 itself does not meet the indication of the low warning threshold 514, the alarm output for the glucose measurement result prediction 414 included in the second prediction range 610 is more likely to be a false positive alarm, depending on the specific settings of the user of the CGM system 104.

[0160] The third forecast range 612 extends further into the future time period 606 than the first forecast range 608 and the second forecast range 610. As shown in representation 600, the third forecast range 612 extends from the current time to the third future time indicated by the third future time indicator 618. Therefore, the third forecast range 612 represents any suitable duration (e.g., 30 minutes, 35 minutes, 40 minutes, 45 minutes, 50 minutes, etc.) that extends further into the future time period 606 than the first forecast range 608 and the second forecast range 610.

[0161] As shown in the figure, each glucose measurement prediction in the glucose measurement prediction 414 included in the third prediction range 612 (excluding the first prediction range 610 or the second prediction range 608) has a larger difference between its corresponding upper limit 510 and lower limit 512 than the glucose measurement prediction 414 included in the second prediction range 608 and the first prediction range 610. This increased difference between the upper limit 510 and lower limit 512 of the glucose measurement prediction 414 included only in the third prediction range 612 represents a lower confidence level for the predicted glucose value 505 of the glucose measurement prediction 414 included in the third prediction range 612 relative to the predicted glucose value 508 of the glucose measurement prediction 414 included in the first prediction range 608 and the second prediction range 610. In one example, an alarm generated based on the glucose measurement prediction 414 included in the third prediction range 612 is more likely to be a false positive alarm than an alarm generated based on the glucose measurement predictions included in the first prediction range 608 and the second prediction range 610.

[0162] The third prediction range 612 includes two glucose measurement result predictions 414, which have an upper limit value 510 that meets the high warning threshold 516, such as... Figure 6 Positions 620 and 622 are shown in the diagram. The third prediction range 612 also includes five glucose measurement predictions 414, each having a lower limit 512 that satisfies a low alert threshold 514, collectively indicated by brackets 624. In the illustrated example, assuming an alarm corresponding to a high alert threshold 516 is associated with the third prediction range 612, the CGM system 104 generates a first high alert in response to the first upper limit 510 indicated at position 620 satisfying the high threshold 516, causing the high alert to be displayed in the user interface of the computing device 108. The CGM system 104 will further generate a second high alert in response to the second upper limit 510 indicated at position 622 satisfying the high threshold, causing the second high alert to be displayed in the user interface of the computing device 108.

[0163] Continuing the previous example, the lower limits 512 of the five glucose measurement predictions 414 indicated by brackets 624 each meet a low alarm threshold 514 during the third prediction range 612. In a specific implementation where alarms corresponding to the low alarm threshold 514 are also associated with the third prediction range 612, the CGM system 104 is configured to generate five low alarms, generating one low alarm for each of the five lower limits 512 that meet the low alarm threshold 514 during the third prediction range 612. For example, the CGM system 104 causes each of the five low alarms to be displayed in the user interface of the computing device 108.

[0164] Obstruction alarm

[0165] Based on the previous example, at least one of the two high alarms and / or five low alarms can be a hindrance alarm, depending on the specific preferences of the user of CGM system 104. For example, person 102 may prefer to receive only an appropriate subset of the seven alarms that would normally be output due to their association with the third prediction range 612, where any one or more alarms not included in the appropriate subset are defined as hindrance alarms. In one example, CGM system 104 identifies which glucose measurement result prediction 414 corresponds to at least one hindrance alarm and avoids displaying the identified hindrance alarm in the user interface of computing device 108. For example, CGM system 104 may identify hindrance alarms based on feedback data from person 102, historical CGM system 104 data from person 102, contextual analysis of glucose measurement result predictions 414 included in the third prediction range 612, combinations thereof, etc.

[0166] For example, CGM system 104 is configured to compare the trajectory of person 102's glucose measurement result 118 after an alarm is output with one or more similar historical scenarios in which no alarm was output (e.g., similar time of day, similar trajectory of glucose measurement result 118, combinations thereof, etc.). By comparing the trajectory of person 102's glucose measurement result 118 after an alarm is output with the trajectory of person 102's glucose measurement result 118 to similar historical glucose measurement result 118 trajectories of person 102 when no alarm was output, CGM system 104 is configured to determine whether outputting an alarm for a particular glucose trajectory is useful (e.g., whether outputting an alarm has any effect on person 102 taking intervention actions, modifying their behavior, or otherwise responding to the alarm).

[0167] In some scenarios, to obtain data on similar historical glucose measurement trajectory 118 (where no alarm is output for comparison with the glucose measurement trajectory 118 of person 102 after an alarm is output), CGM system 104 is configured to suppress the output of one or more such alarms in order to measure the glucose measurement trajectory 118 of person 102 after the point in time when an alarm would have been output. Suppressing the output of one or more alarms to obtain such comparative data for person 102 can be performed in response to determining that one or more alarms may be detrimental to alarms, as described in further detail below. For example, in some specific implementations, in response to determining that glucose measurement prediction 414 will exceed a high glucose alarm threshold at the same time of day (e.g., after breakfast) on multiple days, CGM system 104 may selectively output a high alarm on some days and suppress the output of a high alarm on other days. By selectively suppressing the output of some alarms associated with similar glucose measurement results 118 and / or glucose measurement prediction 414 trajectories, the CGM system 104 can determine whether a person's 102 response differs from those days when alarms were output and those days when alarms were not output, in order to determine whether the alarms are helpful or detrimental to the person 102.

[0168] Consider an example where the CGM system 104 uses historical glucose measurements 118 of person 102 at specific times (e.g., before meals, after meals, before exercise, after exercise, when person 102 is sleeping, when person 102 is not sleeping, etc.) and the trajectory of these measurements 118 to identify instances of intervention for person 102 without receiving alerts suggesting such interventions. In this example, person 102 may be aware of the glucose measurement trajectory 118 (e.g., based on person 102's knowledge of the glucose measurement trajectory 118 occurring at a specific time). Based on this awareness, person 102 intervenes to level or reverse the glucose measurement trajectory 118 without receiving an alert.

[0169] For example, before predicting to generate an alert at the current time based on glucose measurement results 414, CGM system 104 analyzes the glucose measurement results 118 of person 102 before and after the current time on the previous day or several days prior. By analyzing person 102's historical glucose measurement results 118 in this way, CGM system 104 determines whether person 102 is likely to be aware of the current time's glucose measurement result 118 trajectory, whether person 102 might intervene without receiving an alert, or whether person 102 might intervene after receiving an alert, etc. If CGM system 104 determines based on person 102's historical glucose measurement results 118 that person 102 is likely to be aware of future events associated with the alert, then CGM system 104 avoids generating an alert. For example, if CGM system 104 determines based on person 102's historical glucose measurement results 118 that person 102 might intervene without receiving an alert, then CGM system 104 avoids generating an alert. Similarly, if the CGM system 104 determines, based on a person's historical glucose measurements 118, that the person 102 is unlikely to intervene after receiving an alarm, then the CGM system 104 avoids generating an alarm.

[0170] In another example, CGM system 104 identifies hindrance alarms based on patterns identified in CGM device data 214 of user group 110, based on additional data 404, based on combinations thereof, etc. For example, the CGM system utilizes the interaction between person 102 and computing device 108 to determine whether a particular alarm is likely a hindrance alarm or whether a particular alarm is likely not a hindrance alarm. In this example, before displaying a particular alarm in the user interface of computing device 108, CGM system 104 determines whether person 102 has interacted with computing device 108 within a threshold time period (e.g., 1 minute, 5 minutes, 10 minutes, 15 minutes, etc.) to check person 102's glucose measurement result 118. In one example, CGM system 104 determines that person 102 has interacted with computing device 108 within the threshold time period. In this example, CGM system 104 determines that the particular alarm is likely a hindrance alarm. In another example, CGM system 104 determines that person 102 has not yet interacted with computing device 108 within the threshold time period. In this other example, CGM system 104 determines that a particular alarm may not be a hindrance alarm. Other examples in which CGM system 104 uses human 102's interaction with computing device 108 to determine whether a particular alarm is a hindrance alarm are conceivable, such as using the number of times human 102 interacts with computing device 108 within a specific time period, the average number of interactions between human 102 and computing device 108 based on the historical interactions between human 102 and computing device 108, the amount of time elapsed since human 102 last interacted with computing device 108, etc. In one example, CGM system 104 determines that all alarms within a specific time period following an indication of interaction between user 102 and computing device 108 are hindrance alarms. In this example, CGM system 104 avoids generating alarms within a threshold time period (e.g., 1 minute, 5 minutes, 10 minutes, 15 minutes, etc.) after human 102 interacts with computing device 108 to check human 102's glucose measurement result 118.

[0171] In other examples, the CGM system 104 uses the duration of the interaction between person 102 and computing device 108 to determine whether a particular alarm is an obstructive alarm. In these examples, the CGM system 104 may infer that if the interaction between person 102 and a particular instruction displayed in the user interface of computing device 108 lasts for an amount of time greater than a first threshold, person 102 is aware of and conscious of the particular instruction. In similar examples, the CGM system 104 may infer that if the interaction between person 102 and a particular instruction displayed in the user interface of computing device 108 lasts for an amount of time less than a second threshold, person 102 is not aware of and conscious of the particular instruction. For example, the CGM system 104 compares the duration of a particular interaction between person 102 and computing device 108 to the average duration of interactions based on the historical interactions between person 102 and computing device 108. If the duration of the particular interaction is greater than the average interaction duration, the CGM system 104 may infer that person 102 is more likely to be aware of the topic associated with the particular interaction.

[0172] In some examples, the CGM system 104 determines whether a particular alarm is likely to be a hindrance alarm or not based on the interaction between person 102 and computing device 108. For example, if the CGM system 104 displays a particular alarm in the user interface of computing device 108 and if person 102 clears the particular alarm within a threshold time period, the CGM system 104 may infer that the particular alarm is likely a hindrance alarm. In another example, if the CGM system 104 displays a particular alarm in the user interface of computing device 108 and person 102 does not clear the particular alarm within a threshold time period, the CGM system 104 may also infer that the particular alarm is likely a hindrance alarm. In yet another example, if the CGM system 104 displays a particular alarm in the user interface of computing device 108 and person 102 interacts with an application on computing device 108, indicating that person 102 plans to intervene in response to the alarm, such as through interaction with a food delivery application, the CGM system 104 may infer that the particular alarm is likely not a hindrance alarm.

[0173] Consider an example where CGM system 104 determines, based on a defined confidence level of the predicted glucose value 508 of a specific glucose measurement prediction 414 (e.g., the difference between the upper limit 510 and the lower limit 512 of the specific glucose measurement prediction 414), whether the specific glucose measurement prediction 414 corresponds to an increased and / or decreased likelihood of an alarm being triggered. In this example, CGM system 104 determines to generate a high alarm because the upper limit 510 of the specific glucose measurement prediction 414 meets a high alarm threshold 516 during a third prediction range 612 (e.g., at positions 620 or 622). This may or may not indicate that the corresponding high alarm represents an increased likelihood of an alarm being triggered.

[0174] For example, if CGM system 104 also determines that the predicted glucose value 508 does not meet the high alarm threshold 516, this indicates an increased likelihood that the high alarm is a hindrance alarm. This increased likelihood of it being a hindrance alarm is inferred because the alarm is generated based on a relatively small fraction of the possible glucose values ​​included in the specific glucose measurement prediction 414 that meet the high alarm threshold 516. By generating a corresponding high alarm in response to a relatively small fraction of the possible glucose values ​​that meet the high alarm threshold 516, the probability that the corresponding high alarm is a false positive alarm increases. This is because a relatively large majority of the possible glucose values ​​in the specific glucose measurement prediction 414 fail to meet the high alarm threshold 516. If the high alarm is a false positive alarm (e.g., the glucose level measured by person 102 may meet the high alarm threshold 516 during an upcoming time period but never actually does), this alarm is likely a hindrance alarm, and CGM system 104 avoids displaying the possible hindrance alarm in the user interface of computing device 108.

[0175] Alternatively, if CGM system 104 determines that the predicted glucose value 508 also meets the high alarm threshold 516, this does not necessarily indicate an increased or decreased likelihood that the corresponding high alarm is a hindering alarm. However, if CGM system 104 also determines that the lower limit value 512 of a particular glucose measurement prediction 414 meets the high alarm threshold 516 (e.g., indicating that all possible values ​​of a particular glucose measurement prediction 414 meet the high alarm threshold 516), this may indicate a decreased likelihood that the corresponding high alarm is a hindering alarm. In this example, the probability that the high alarm is a false positive is reduced because all values ​​of the glucose measurement prediction 414 indicate that a future glucose measurement will exceed the high alarm threshold 516. A reduced likelihood that a high alarm is a false positive generally reduces the likelihood that a high alarm is a hindering alarm.

[0176] Consider another example where the CGM system 104 determines the likelihood that a specific glucose measurement prediction 414 corresponds to a hindering alarm based on a defined confidence level of the predicted glucose value 508 of that prediction. In this example, the CGM system 104 determines that a low alarm will be generated because the lower limit 512 of the specific glucose measurement prediction 414 meets the low alarm threshold 514 during the third prediction range 612. As in the previous example, this determination may or may not indicate an increased likelihood that the corresponding low alarm is a hindering alarm.

[0177] Continuing this example, if the CGM system 104 further determines that the predicted glucose value 508 does not meet the low alarm threshold 514, this additional determination increases the likelihood that the corresponding low alarm is an alarm-inhibiting increase. This increased likelihood is because the low alarm is based on a relatively small fraction of the possible glucose values ​​that would meet the low alarm threshold 514, as predicted by the specific glucose measurement result. Therefore, the corresponding low alarm is generally more likely to be a false positive alarm, and thus may be an alarm-inhibiting alarm.

[0178] In an alternative example where CGM system 104 determines that the predicted glucose value 508 of a specific glucose measurement prediction 414 does not meet the low alarm threshold 514, this additional determination may affect the likelihood that the corresponding low alarm is a hindering alarm. In another example, if CGM system 104 determines that the upper limit 510 of a specific glucose measurement prediction 414 meets the low alarm threshold 514, this determination may indicate a reduced likelihood that the corresponding low alarm is a hindering alarm. In this example, since the upper limit 510 of the glucose measurement prediction 414 meets the low alarm threshold 514, all possible glucose values ​​of the specific glucose measurement prediction 414 meet the low alarm threshold 514. This generally corresponds to a reduced probability that the corresponding low alarm is a false positive alarm, and therefore a reduced probability that the low alarm is a hindering alarm.

[0179] Consider which prediction range 608-612 includes a glucose measurement result prediction 414 that meets either a low alarm threshold 514 or a high alarm threshold 516 to determine examples that might prevent an alarm. For example, if a glucose measurement result prediction 414 has resulted in an alarm being generated because the predicted glucose value 508 of the glucose measurement result prediction 414 meets an alarm threshold (e.g., low alarm threshold 516 or high alarm threshold 516) within the first prediction range 608, then the CGM system 104 may determine that the generated alarm is more likely a true positive alarm than a false positive alarm. This is because the relatively small difference between the upper limit 510 and the lower limit 512 of the glucose measurement result prediction 414 within the first prediction range 608 indicates a relatively high confidence level for the predicted glucose value 508 included in the first prediction range 608. Since a true positive alarm is less likely to be a hindrance alarm than a false positive alarm, the CGM system 104 can determine that an alarm generated based on glucose measurement results predicted 414 within the first prediction range 608 is less likely to be a hindrance alarm than an alarm generated based on glucose measurement results predicted 414 outside the first prediction range 608.

[0180] If CGM system 104 determines that glucose measurement prediction 414 has led to the generation of an alarm because the predicted glucose value 508 of glucose measurement prediction 414 meets the alarm threshold within the second prediction range 610, then CGM system 104 may not necessarily infer a change in the likelihood that the alarm will become a hindrance alarm. In this example, if glucose measurement prediction 414 is temporally close to the current time, then CGM system 104 determines that the alarm is more likely to be a true positive alarm than a false positive alarm. Therefore, CGM system 104 determines that the alarm is unlikely to be a hindrance alarm because CGM system 104 has a relatively high confidence in the predicted glucose value 508 that is temporally close to the current time.

[0181] Continuing the example, if glucose measurement prediction 414 is temporally close to a second future time indicated by second future time indication 616, then CGM system 104 determines that the alarm is less likely to be a true positive alarm compared to an alarm generated based on glucose measurement prediction 414 that is temporally close to the current time. This is because CGM system 104 has less confidence in a predicted glucose value 508 that is temporally close to the second future time than in a predicted glucose value 508 that is temporally close to the current time. Therefore, CGM system 104 is configured to consider the temporal position of glucose measurement prediction 414 relative to a specific prediction range in determining whether a corresponding alarm is likely to be a hindrance to the user of CGM system 104, rather than simply making a binary consideration of whether glucose measurement prediction 414 meets an alarm threshold within a specific prediction range. For example, in response to a glucose measurement prediction 414 being close in time to a second future time rather than to a different part of the second prediction range 610 (e.g., close in time to the current time, close to the first future time indicator 614, etc.), the CGM system 104 may determine that an alarm generated because a glucose measurement prediction 414 that meets an alarm threshold within the second prediction range 610 is more likely to be a hindrance alarm.

[0182] If the CGM system 104 determines that the predicted glucose value 508 of the glucose measurement result prediction 414 meets the alarm threshold within the third prediction range 612, then the CGM system 104 determines whether the glucose measurement result prediction 414 is included in the first prediction range 608. In response to determining that the glucose measurement result prediction 414 is included in the first prediction range 608, the CGM system 104 determines that an alarm generated based on the glucose measurement result prediction 414 is more likely to be a true positive alarm than a false positive alarm. Therefore, the CGM system 104 determines that the alarm is unlikely to be a detrimental alarm.

[0183] Continuing the previous example, if CGM system 104 determines that glucose measurement result prediction 414 is not included in the first prediction range 608, then CGM system 104 determines whether glucose measurement result prediction 414 is included in the second prediction range 610. If CGM system 104 determines that glucose measurement result prediction 414 is included in the second prediction range 610, then CGM system 104 determines that an alarm generated based on glucose measurement result prediction 414 is more likely to be a false positive alarm than an alarm generated based on glucose measurement result predictions that meet an alarm threshold in the first prediction range 608. Therefore, CGM system 104 determines that the alarm is more likely to be a hindrance alarm.

[0184] In another example, CGM system 104 determines which alarms are likely to be hindrances based on the relationships between alarms generated from glucose measurement predictions 414 within the prediction range 608-612. For example, the third prediction range 612 includes glucose measurement predictions 414 that meet the high alarm threshold 516 twice and the low alarm threshold 514 five times between the second future time indicator 616 and the third future time indicator 618. The first glucose measurement prediction 414 indicated at position 620 has an upper limit 510 for meeting the high threshold warning 516, which would cause CGM system 104 to generate a high alarm if a high alarm is associated with the third prediction range 608-612.

[0185] The second glucose measurement prediction 414 (e.g., one of the glucose measurement predictions in the prediction 414 marked by brackets 624) includes a lower limit 512 that meets the low alarm threshold 514 during the third prediction range 312. Therefore, if a low alarm is associated with the third prediction range 312, the second glucose measurement prediction 414 will cause the CGM system 104 to generate a low alarm. In this example, the association of both a high alarm and a low alarm within the third prediction range would result in contradictory warnings with closely spaced temporal outputs, which could lead the person 102 to take inappropriate intervention actions when managing their glucose levels. Although true positive high alarms and true positive low alarms may be generated based on different glucose measurement predictions 414 within a single prediction range 608-612, the close temporal proximity between two alarms with opposing indications (e.g., high versus low) causes the CGM system 104 to determine whether one or more of these alarms are hindrance alarms.

[0186] For example, the CGM system 104 determines the amount of time between the first glucose measurement result prediction 414 and the second glucose measurement result prediction 414 within a third prediction range 612. The CGM system 104 then compares this determined amount of time with a glucose change duration threshold to determine whether an alarm corresponding to the first glucose measurement result prediction and the second glucose measurement result prediction 414 is an intrusive alarm. This glucose change duration threshold can be any suitable duration (e.g., 30 minutes, 1 hour, 1.5 hours, 2 hours, 2.5 hours, 3 hours, etc.).

[0187] In one example, the glucose change duration threshold reflects the average amount of time between glucose measurements 118 that meet the corresponding high alarm threshold for users in user group 110 and glucose measurements 118 that meet the corresponding low alarm threshold. In another example, the glucose change duration threshold reflects the average amount of time between glucose measurements 118 that meet the high alarm threshold 516 for person 102 and glucose measurements 118 that meet the low alarm threshold 514. In one example, the glucose change duration threshold may be scaled based on the average values ​​of user group 110 and / or user 102. In this example, if the average amount of time between observed glucose measurements 118 that meet the high alarm threshold 516 and observed glucose measurements 118 that meet the low alarm threshold 514 is 5 hours, then the glucose change duration threshold may be defined as a value not exceeding 5 hours (e.g., 2.5 hours, 2 hours, 1.5 hours, etc.).

[0188] Regardless of how the glucose change duration threshold is determined, the CGM system 104 compares the determined amount of time between the first glucose measurement prediction 414 and the second glucose measurement prediction 414 with the glucose change duration threshold. In one example, if the determined amount of time is greater than the glucose change duration threshold, the CGM system 104 determines that the alarm corresponding to the first glucose measurement prediction and the second glucose measurement prediction 414 is unlikely to be a false positive alarm. This is because the comparison of the determined amount of time between the first glucose measurement prediction and the second glucose measurement prediction 414 with the glucose change duration threshold indicates that a glucose measurement 118 has been observed to meet both the high alarm threshold 516 and the low alarm threshold 514 within the determined amount of time. Specifically, in this example, the CGM system 104 determines that the high and low alarms generated from the glucose measurement prediction 414 occurring within the third prediction range 612 are unlikely to be obstructive alarms.

[0189] In another example, if the amount of time between the determined first glucose measurement result prediction 414 and the second glucose measurement result prediction 414 is less than a glucose change duration threshold, the CGM system 104 determines that at least one of the corresponding alarms may be a false positive alarm and thus inconvenience the user 102. For example, the CGM system 104 may determine that both the high and low alarms generated based on the first and second glucose measurement result predictions 414 are likely false positive alarms. In this example, the CGM system 104 determines that the possible false positive alarms may also be inconvenience alarms, and the CGM system 104 avoids displaying these alarms in the user interface of the computing device 108. To do this, and to ensure that future glucose measurement result predictions 414 do not lead to the generation and / or output of inconvenience alarms, the CGM system 104 is configured to modify the prediction range associated with the alarm such that the modified prediction range does not extend to points in the future time period 606 that would otherwise trigger false positive alarms, as described in further detail below.

[0190] Consider the example where the CGM system 104 uses the value of the first glucose measurement result prediction 414 that meets the high alarm threshold 516 and the value of the second glucose measurement result prediction 414 that meets the low alarm threshold 514 as an example to determine whether one or more of the corresponding high and low alarms are part of an alarm-preventing event. For example, in addition to determining that the first glucose measurement result prediction 414 meets the high alarm threshold 516, the CGM system 104 determines the difference between the value of the first glucose measurement result prediction 414 that meets the high alarm threshold 516 and the high alarm threshold 516. To do this, in one example, the CGM system 104 determines the average value of the value of the first glucose measurement result prediction 414 that meets the high alarm threshold 516. In another example, the CGM system 104 determines the maximum value of the value of the first glucose measurement result prediction 414 that meets the high alarm threshold 516.

[0191] In a similar example, CGM system 104 determines the difference between the value of the second glucose measurement result prediction 414 that satisfies the low alarm threshold 514 and the low alarm threshold 514. For example, CGM system 104 may determine the average value of the second glucose measurement result prediction 414 that satisfies the low alarm threshold 514. In one example, CGM system 104 determines the minimum value of the second glucose measurement result prediction 414 that satisfies the low alarm threshold 514.

[0192] Consider an example where the CGM system 104 compares the value of the first glucose measurement prediction 414 that satisfies the high alarm threshold 516 with an extremely high glucose threshold (e.g., 600 mg / dL, 650 mg / dL, 700 mg / dL, 800 mg / dL, 900 mg / dL, etc.). In one example, if the CGM system 104 determines that the value of the first glucose measurement prediction 414 that satisfies the high alarm threshold 516 is greater than the extremely high glucose threshold, the CGM system 104 may further determine that the corresponding high alarm is likely a true positive alarm. In another example, the extremely high glucose threshold may indicate an inaccurate glucose measurement prediction 414, thereby indicating that the first glucose measurement prediction 414 is higher than the highest reasonable glucose level for person 102. In this example, the CGM system 104 determines that the first glucose measurement prediction 414 may indicate a false positive alarm. In one example, the CGM system 104 also determines that this possible false positive alarm is a hindrance alarm, and the CGM system 104 avoids displaying the high alarm in the user interface of the computing device 108.

[0193] In another example, the CGM system 104 compares the value of the second glucose measurement result prediction 414 that satisfies the low alarm threshold 514 with an extremely low glucose threshold (e.g., 55 mg / dL, 50 mg / dL, 45 mg / dL, 40 mg / dL, 35 mg / dL, etc.). If the CGM system 104 determines that the value of the second glucose measurement result prediction 414 that satisfies the low alarm threshold 514 is less than the extremely low glucose threshold, the CGM system 104 may also determine that the low alarm is a false positive alarm. In this example, the CGM system 104 additionally determines that the low alarm is a hindrance alarm and avoids displaying the low alarm in the user interface of the display device 108.

[0194] Consider an example where the CGM system 104 identifies potential nuisance alarms based on glucose measurement predictions 414 before and / or after a glucose measurement prediction 414 that meets a threshold, leading the CGM system 104 to generate an alarm. For example, the CGM system 104 compares the predicted glucose value 508 of the first glucose measurement prediction 414 with the predicted glucose value 508 of the previous glucose measurement prediction 414. The CGM system 104 also determines the amount of time between the predicted glucose value 508 of the first glucose measurement prediction 414 and the predicted glucose value 508 of the previous glucose measurement prediction 414. The CGM system 104 uses this amount of time and the difference between the predicted glucose values ​​508 to calculate the glucose change rate, which the CGM system 104 compares to a glucose change rate threshold.

[0195] For example, a glucose rate of change threshold corresponds to the time-varying change in glucose levels that indicates a false positive alarm. The glucose rate of change threshold can be any suitable measure, such as 3.0 mg / dL / min, 3.5 mg / dL / min, 4.0 mg / dL / min, 4.5 mg / dL / min, 5.0 mg / dL / min, etc. The CGM system 104 compares the calculated glucose rate of change to the glucose rate of change threshold. If the calculated glucose rate of change is greater than the glucose rate of change threshold, the CGM system 104 determines that the corresponding alarm triggered by one or more analyzed glucose measurement predictions 414 is likely a false positive alarm. Based on this determination, the CGM system 104 also determines that the alarm may be a hindrance alarm, and the CGM system 104 avoids displaying this alarm in the user interface of the computing device 108. In an alternative example where the CGM system 104 determines that the calculated rate of change is less than the rate of change threshold, the CGM system 104 does not necessarily infer any change in the likelihood that the corresponding alarm is a hindrance alarm.

[0196] Continuing the previous example, the CGM system 104 additionally compares the predicted glucose value 508 of the first glucose measurement prediction 414 with the predicted glucose value 508 of the subsequent glucose measurement prediction 414. For example, the CGM system 104 also determines the amount of time between the predicted glucose value 508 of the first glucose measurement prediction 414 and the predicted glucose value 508 of the subsequent glucose measurement prediction 414. Based on this determined amount of time and the difference between the predicted glucose values ​​508, the glucose rate of change is calculated, and the CGM system 104 compares the calculated glucose rate of change with a glucose rate of change threshold.

[0197] In response to determining that the calculated rate of glucose change is greater than a glucose rate of change threshold, the CGM system 104 determines that the corresponding alarm may be a false positive alarm. The CGM system 104 may also determine that such a possible false positive alarm corresponds to a hindrance alarm, which causes the CGM system 104 to avoid displaying the alarm to the user of the computing device 108. In some specific implementations, the CGM system 104 is configured to modify the prediction range associated with the alarm to terminate before the point where the rate of glucose change between the predicted continuous glucose measurements 414 calculated in the future time period 606 exceeds the glucose rate of change threshold.

[0198] In this way, the CGM system 104 is configured to identify potential disruptive alarms based on continuous glucose measurement result predictions 414 and modify the prediction ranges associated with each alarm. For example, a third prediction range 612 includes five continuous glucose measurement result predictions 414, indicated by brackets 624, which have a lower limit 512 that satisfies a low alarm threshold 514. In this example, the CGM system 104 may determine that for the five continuous glucose measurement result predictions 414, only a single low alarm should be displayed in the user interface of the computing device 108. For example, the CGM system 104 may identify continuous glucose measurement result predictions 414 that cause the CGM system to generate a similar alarm as an indication that at least one of the similar alarms that are close in time to continuous output will be interpreted by person 102 as a disruptive alarm. In one example, the CGM system determines that the second alarm of two consecutive similar alarms is a disruptive alarm. In another example, the CGM system determines that the first alarm of two consecutive similar alarms is a disruptive alarm.

[0199] Figure 7 An exemplary representation 700 depicts a glucose measurement result prediction 414 generated by the prediction system 310 and a corresponding alarm notification communicated to the computing device 108. As shown, representation 700 includes a timeline 702 that begins at 8:00 AM and ends at 9:00 PM. Milestones on the timeline 702 represent alarms and glucose measurement result predictions for person 102 during the duration of the timeline. In the example shown, milestone 704 represents a glucose measurement result prediction 414 for person 102 that meets an emergency low threshold at 9:45 AM. In one example, an emergency low alarm associated with the emergency low threshold is associated with a default prediction range (not shown). For example, the CGM system 104 predicts an emergency low event at 9:45 AM in response to determining that a glucose measurement result prediction 414 meeting the emergency low threshold occurred during the default prediction range. In response to this determination, the CGM system 104 causes an emergency low alarm to be output in the user interface of the computing device 108. The output of the emergency low alarm may, for example, be at 9:00 AM, as indicated by milestone 706. In this exemplary scenario, the default prediction range associated with an emergency low alert causes the CGM system 104 to generate and output an emergency low alert 45 minutes before the predicted emergency low event.

[0200] CGM system 104 is configured to display, in the user interface of computing device 108, the glucose measurement result 118 of monitored person 102 following an emergency low alert indicated by mile marker 706 at 9:00 AM, in order to determine whether the default prediction range should continue to be used for the emergency low alert. For example, if during this monitoring period, CGM system 104 does not identify confirmation of the alert indicated by mile marker 706 (e.g., clearing the alert without intervention by person 102 to avoid a hypoglycemic event inferred from the monitored glucose measurement result 118 for person 102), CGM system 104 may determine that the notification is inconvenient for person 102 and that the default prediction range needs to be modified for subsequent outputs of the emergency low alert. CGM system 104 is configured to determine whether person 102 intervened in response to the output alert in any appropriate manner. For example, CGM system 104 is configured to determine whether intervention was taken in response to the alert by representing the monitored glucose measurement result 118 as a polynomial function and solving for the first derivative of the polynomial function at zero to identify local minima and maxima of the polynomial function. Using the local minimum and maximum values ​​of these identified polynomial functions, the CGM system 104 can determine whether the monitored glucose measurement result 118 includes an inflection point of intervention by the person 102, or whether the monitored glucose measurement result 118 does not include an inflection point where the person 102 did not intervene.

[0201] Continuing the previous example, CGM system 104 determines that the 9:00 AM emergency low alert is a disruptive alert based on glucose measurement results 118 monitored after the alert was output. In this example, CGM system 104 determines that the monitored glucose measurement result 118 indicates that person 102 should not intervene because the 9:00 AM emergency low alert was received due to its association with the default prediction range. In this exemplary scenario, according to the CGM system 104 settings specified by person 102, a second instance of an emergency low alert that might have been output without intervention could be deactivated, paused, or otherwise prevented. Assuming that person 102 specifies an exemplary configuration with a 15-minute pause delay between consecutive alert outputs, timeline 702 includes a marker 708 representing another instance of an emergency low alert being output at 9:15 AM, providing person 102 with a 30-minute advance warning of the anticipated emergency low glucose event indicated by marker 704.

[0202] Continuing this exemplary scenario, after the second instance of an emergency low alert output at 9:15 AM, the CGM system 104 continues to monitor the glucose measurement 118 of person 102 to determine whether the second instance of the alert is sufficient to prompt person 102 to take intervention action to avoid an emergency low event indicated by mile marker 704. This monitoring is performed by the CGM system 104 to determine whether the default prediction range of the emergency low alert should be modified to avoid outputting a future emergency low alert that would hinder person 102. For example, during the monitoring of person 102's glucose measurement 118 after the output of the second instance of an emergency low alert as indicated by mile marker 708, the CGM system 104 may determine that person 102 took intervention action in response to the output of the 9:15 AM emergency low alert. In response to this determination, the CGM system 104 is configured to modify the prediction range of the emergency low alert to avoid outputting an emergency low alert 45 minutes before a subsequently predicted emergency low glucose level event.

[0203] Alternatively, in response to determining that person 102 did not take intervention action in response to the output of the 9:15 AM Emergency Low Alert, CGM system 104 infers that the 9:15 AM Emergency Low Alert is a hindrance alert for person 102, and subsequently outputs a third instance of the Emergency Low Alert at 9:30 AM, as indicated by mile marker 710 on timeline 702. After outputting the Emergency Low Alert at 9:30 AM, CGM system 104 continues to monitor person 102's glucose measurement 118 to determine whether person 102 took intervention to avoid the hypoglycemic event.

[0204] As an example, the intervention for person 102 includes taking a glucose tablet, which causes the value of person 102's glucose measurement 118 to increase above the emergency low threshold corresponding to the emergency low alert represented by mile markers 706-710 on timeline 702. CGM system 104 identifies this exemplary intervention by monitoring person 102's glucose measurement 118 and determines the ideal prediction range for emergency low alerts in response to the identified intervention. For example, CGM system 104 determines that person 102 tends not to receive emergency low alerts generated based on the default prediction range because person 102 failed to intervene in response to the output of emergency low alerts at 9:00 AM and 9:15 AM, and only responded to the 9:30 AM emergency low alert, i.e., intervened 15 minutes before the predicted emergency low alert event occurred. In this example, CGM system 104 is configured to modify the prediction range of person 102's emergency low alerts such that subsequent emergency low alerts are output with a 15-minute advance warning time before the predicted emergency low event occurs. Alternatively, the CGM system 104 is configured to modify the alarm's prediction range by monitoring the person 102's glucose measurement 118 and expanding the alarm's prediction range in response to determining the output of an alarm, but not before the person 102's glucose measurement 118 actually meets the corresponding threshold of the alarm. In this exemplary scenario, expanding the alarm's prediction range is appropriate because the CGM system 104 recognizes that the alarm's advance warning time is insufficient to allow the person 102 to take intervention action before meeting the alarm's glucose threshold value.

[0205] Alternatively or additionally, the CGM system 104 may modify the predictive range of the alarm to zero (e.g., in response to determining that all alarms of a particular type are hindrance alarms to person 102, since the person would never take intervention action in response to a particular type of alarm until their glucose measurement 118 meets the corresponding threshold of the alarm). Therefore, the CGM system 104 is configured to modify the predictive range of the alarm by monitoring the glucose measurement 118 of person 102 after the alarm is output, to mitigate the hindrance caused by the alarm to person 102. Using this modification, the CGM system 104 will subsequently cause only one alarm to be output for a subsequently predicted emergency hypoglycemic event, such as an emergency hypoglycemic alarm at 7:45 p.m., as indicated by mile marker 712, 15 minutes before an expected emergency hypoglycemic event predicted to occur at 8:00 p.m. (as indicated by mile marker 714 on timeline 702). In one example, the CGM system 104 uses a machine learning model to process data describing the historical glucose measurement results 118 of person 102. The machine learning model is trained to generate modified prediction ranges that increase or decrease the frequency of alerts displayed in the user interface of the computing device 108.

[0206] By outputting an alarm using a modified prediction range instead of the alarm's default prediction range, the CGM system 104 is able to customize the alarm output so that it is most helpful to person 102 at the time (e.g., when person 102 is aware of an anticipated glucose level event and takes intervention action to prevent problematic glucose levels, while avoiding an alarm that would otherwise hinder the anticipated glucose level event). In addition to modifying the alarm's prediction range based on monitored glucose measurements 118, the CGM system 104 is further configured to modify the alarm's prediction range based on explicit user input received from person 102. Examples of such explicit user feedback are discussed below. Figures 8 to 11 Describe it.

[0207] Figure 8 An exemplary representation 800 of a user interface, according to one or more specific implementations, for notifying a user based on a prediction of glucose measurement results is depicted. Representation 800 includes an emergency low alert 802 and an emergency high alert 804. As shown, the user interface of computing device 108 displays the emergency low alert 802 as an indication that “you may drop below 70 mg / ml within 30 minutes.” The user interface includes a first user interface element 806 and a second user interface element 808. Person 102 interacts with the first user interface element 806 to deactivate the emergency low alert 802. Alternatively, person 102 interacts with the second user interface element 808 to confirm the action regarding the emergency low alert 802.

[0208] In response to interaction with the first user interface element 806, the CGM system 104 stops displaying the Emergency Low Alert 802. This also indicates to the CGM system 104 that the Emergency Low Alert 802 is a hindrance alarm and that the predicted range causing the Emergency Low Alert 802 to be output 30 minutes before the predicted Emergency Low Event should be modified. Alternatively, in response to interaction with the second user interface element 808, the CGM system 104 pauses the Emergency Low Alert 802 and monitors the glucose measurement result 118 of person 102 to confirm whether the intervention action taken by person 102 is reflected in the glucose measurement result 118. The selection of the second user interface element 808 and / or the confirmation that the intervention action is reflected in the glucose measurement result 118 of person 102 indicates that the Emergency Low Alert 802 is not a hindrance alarm and that the predicted range causing the Emergency Low Alert 802 to be output 30 minutes before the predicted Emergency Low Event should not be modified.

[0209] Similarly, the CGM system 104 can use interaction with the user interface of the computing device 108 to determine whether to modify the different prediction range of the Emergency High Alert 804. In the illustrated representation 800, the Emergency High Alert 804 indicates "You may reach 250 mg / dL or higher within 15 minutes" and includes a first user interface element 806 and a second user interface element 808. In response to interaction with the first user interface element 806 presented for the Emergency High Alert 804, the CGM system 104 stops displaying the Emergency High Alert 804 and determines that the Emergency High Alert 804 is a hindrance alarm. In response to determining that the Emergency High Alert 804 is a hindrance alarm, the CGM system 104 is configured to modify the prediction range that causes the Emergency High Alert to be output 15 minutes before the predicted Emergency High Event. Alternatively, in response to interaction with the second user interface element 808 regarding the emergency high alert 804, the CGM system 104 determines that the emergency high alert 804 is not a hindrance alert, monitors the glucose measurement result 118 of the person 102 to confirm that an intervention has been taken to avoid an emergency high event, and maintains the predictability range of the emergency high alert 804.

[0210] Figure 9 An exemplary representation 900 of a user interface is depicted for providing user feedback on a predicted alert regarding glucose measurement results. For example, according to one or more specific embodiments, this user feedback may be used by the CGM system 104 to modify the alert prediction range. Representation 900 includes a prediction range modification notification 902, an emergency low-impact alert identification notification 904, and an emergency low-alarm intervention notification 906. The user interface of computing device 108 displays the prediction range modification notification 902 as indicating "Your current ULS prediction range is: 30 minutes." The user interface also includes a prompt 908 for specifying a different prediction range. In this example, prompt 908 may receive a specified prediction range entered in minutes, which allows manual specification of the prediction range for an emergency low-alarm for person 102.

[0211] The user interface of computing device 108 displays an Emergency Low Disturbance Alarm Identification Notification 904, which prompts person 102 for feedback on a previously output notification by indicating "You received an Emergency Low Alarm at 4:00 PM". The user interface includes a first user interface element 910 and a second user interface element 912. In response to interaction with the first user interface element 910, CGM system 104 determines that the Emergency Low Alarm output at 4:00 PM is not a Disturbance Alarm and maintains the prediction range associated with the Emergency Low Alarm. Alternatively, in response to detecting interaction with the second user interface element 912, CGM system 104 determines that the Emergency Low Alarm output at 4:00 PM is a Disturbance Alarm and continues to modify the prediction range associated with the Emergency Low Alarm.

[0212] As shown in the figure, the user interface displays an Emergency Low Alert Intervention Notification 906 to request specific information about the response actions taken in response to a previously output alarm by conveying the question, "What did you do after the Emergency Low Alert at 4:00 PM?". This user interface includes user interface elements 914-920. In response to interaction with the first user interface element 914, the CGM system 104 determines that the intervention is "food". In response to interaction with the second user interface element 916, the CGM system 104 determines that the intervention is "glucose gel / tablets". If the CGM system 104 recognizes interaction with the third user interface element 918, the CGM system 104 determines that the intervention is "glucagon". Input to user interface elements 914-918 can be used by the CGM system 104 to identify patterns in the glucose measurement results 118 of person 102, which can be used to infer whether a similar intervention should be taken subsequently in response to the output of the alarm notification without the benefit of explicit user feedback, in order to determine whether the predictive range associated with the alarm should be maintained or modified. Alternatively, if the CGM system 104 recognizes an interaction with the fourth user interface element 920, the CGM system 104 determines that the intervention is “irrelevant” and uses this information to classify the glucose measurement results 118 of person 102 monitored after the output of the emergency low alert at 4:00 p.m., and / or determine that the emergency low alert is a hindrance alert and modify its predictive range.

[0213] Figure 10 An exemplary representation 1000 of a user interface, based on one or more specific implementations, is depicted for providing user feedback regarding a glucose measurement result prediction notification, which can be used by the CGM system 104 to modify the alarm prediction range. Representation 1000 includes a prediction range modification notification 1002, an emergency high-interference alarm identification notification 1004, and an emergency high-interference alarm intervention notification 1006. The user interface of computing device 108 displays the prediction range modification notification 1002 as indicating "Your current UHS prediction range is: 20 minutes." The user interface also includes a prompt 1008 for specifying a different prediction range. In this example, prompt 1008 can receive a specified prediction range entered in minutes, which allows for manual specification of the prediction range for an emergency high-interference alarm for person 102.

[0214] The user interface of computing device 108 displays an Emergency High Disturbance Alarm Identification Notification 1004, which prompts person 102 for feedback on a previously output notification by indicating "You received an Emergency High Disturbance Alarm at 11:00 AM". The user interface includes a first user interface element 1010 and a second user interface element 1012. In response to interaction with the first user interface element 1010, CGM system 104 determines that the Emergency High Disturbance Alarm output at 11:00 AM is not a disturbance alarm and maintains the prediction range associated with the Emergency High Disturbance Alarm. Alternatively, in response to detecting interaction with the second user interface element 1012, CGM system 104 determines that the Emergency High Disturbance Alarm output at 11:00 AM is a disturbance alarm and modifies the prediction range associated with the Emergency High Disturbance Alarm.

[0215] As shown in the figure, the user interface displays an Emergency High Alert Intervention Notification 1006 to request specific information about the response actions taken in response to a previously issued alarm by instructing users to “What did you do after the Emergency High Alert at 11:00 AM?” This user interface includes user interface elements 1014-1018. In response to interaction with the first user interface element 1014, the CGM system 104 determines that the intervention was “handled immediately.” In response to interaction with the second user interface element 1016, the CGM system 104 determines that the intervention is at the “wait / observation level.” The first or second input to user interface elements 1014 and 1016 can be used by the CGM system 104 to identify patterns in the glucose measurement results 118 of the person 102, which can be used to infer whether a similar intervention should subsequently be taken in response to the output of the alarm notification without the benefit of explicit user feedback, in order to determine whether the predictive range associated with the alarm should be maintained or modified. Alternatively, if the CGM system 104 recognizes an interaction with the third user interface element 1018, the CGM system 104 determines that the intervention is “irrelevant” and uses this information to classify the glucose measurement results 118 of the person 102 monitored after the output of the 11:00 AM Emergency High Alert, and / or determines that the Emergency High Alert is a hindrance alarm and modifies its predictive range.

[0216] Figure 11An exemplary representation 1100 of a user interface, based on one or more specific implementations, for prompting user input regarding glucose measurement result prediction alarm notifications is depicted. Representation 1100 includes an alarm setting prompt 1102, displayed in the user interface of computing device 108 as “Your current settings are the default settings. Would you like to modify the settings to increase or decrease the alarm frequency?” As shown, the user interface includes user interface elements 1104-1108. In response to interaction with the first user interface element 1104, CGM system 104 determines that more alarms are preferred relative to the number of alarms received based on the default settings. In one example, CGM system 104 modifies the default prediction range of one or more types of alarms to generate more alarms.

[0217] In response to interaction with the second user interface element 1106, the CGM system 104 determines that fewer alarms are preferred relative to the number of alarms received based on default settings. To take this explicit user feedback into account, the CGM system 104 modifies the default prediction range of one or more types of alarms to generate fewer alarms. In response to interaction with the third user interface element 1108, the CGM system 104 determines that the number of alarms received based on default settings is preferred. In this example, the CGM system 104 does not modify the default prediction range of alarms.

[0218] The example shown includes a single user feedback notification; however, additional types of user feedback notifications are also conceivable. These additional types of user feedback notifications may include communications requesting feedback on: person 102's age, the amount of time since person 102 received a diagnosis, the indication of the diagnosis, whether person 102 has difficulty preventing hypoglycemia, whether person 102 has difficulty maintaining glucose levels within a defined range, situations and scenarios that person 102 wishes to avoid, person 102's specific risk tolerance, the frequency with which person 102 checks glucose levels, the adequacy of advance warning time, the accuracy of the number of advance warnings, combinations thereof, etc. Feedback from these additional types of user feedback notifications may be included along with additional data 404 to improve the accuracy of glucose measurement predictions 414 generated by prediction system 310. In one example, feedback from these additional types of user feedback notifications may be used to identify which alarms displayed in the user interface of computing device 108 are hindrance alarms and which are not. In another example, feedback from these additional types of user feedback notifications may be communicated to the manufacturer of CGM system 104, person 102's healthcare provider, etc.

[0219] Figure 12An exemplary specific implementation 1200 of the prediction system 310 is described in more detail, wherein a machine learning model is trained to generate a prediction 312 (e.g., glucose measurement result prediction 414) and a notification 314 (e.g., an alert about glucose measurement result prediction 414) based on a prediction range associated with notification 314 when provided with glucose measurement result 118 and / or additional data 404 as input. Figure 3 As shown, the prediction system 310 is included as part of the data analysis platform 122, although in other scenarios the prediction system 310 may be additionally or alternatively partially or wholly included in other devices (such as computing device 108).

[0220] In Example 1200, the prediction system 310 includes a model manager 1202 that manages one or more machine learning models, such as machine learning model 412, implemented by prediction manager 408. As described above, machine learning model 412 can be configured as a recurrent neural network, a convolutional neural network, etc. Alternatively, without departing from the spirit or scope of the described technique, machine learning model 412 can be configured as other machine learning models or include other types of machine learning models. These different machine learning models can be built or trained (or otherwise learned) using different algorithms at least in part attributable to different architectures. Thus, the functionality of model manager 1202 is applicable to a wide variety of different machine learning model types and configurations. However, for illustrative purposes, the functionality of model manager 1202 will be described generally with respect to training neural networks.

[0221] Generally, model manager 1202 is configured to manage one or more machine learning models implemented by prediction manager 408, including machine learning model 412. This model management includes, for example, building machine learning model 412, training machine learning model 412, updating this model, etc. In one or more specific implementations, updating machine learning model 412 may include transfer learning to personalize machine learning model 412, such that the machine learning model is personalized from a state trained using training data of user group 110 to an updated state trained using additional training data or (updated data) describing one or more aspects of person 102 and / or the description is determined to be one or more aspects of a subset of user group 110 similar to this person.

[0222] Specifically, the model manager 1202 is configured to perform model management using at least part of a large amount of data held in the storage device 120 of the CGM platform 112. As shown, this data includes glucose measurement results 118, timestamps 402, and additional data 404 of user group 110. In other words, the model manager 1202 builds a machine learning model 412, trains the machine learning model 412 (or otherwise learns the underlying model), and updates this model using the glucose measurement results 118, timestamps 402, and additional data 404 of user group 110.

[0223] Unlike conventional systems, CGM platform 112 stores (e.g., in storage device 120) or otherwise accesses glucose measurements 118 obtained by hundreds of thousands (e.g., 500,000 or more) of users 110 using CGM system 104. Furthermore, these measurements 118 are indicated by sensors of CGM system 104 at a continuous rate, e.g., substantially in real time. Therefore, the number of glucose measurements 118 available to model manager 1202 for model building and training is in the millions, or even billions. Utilizing this robust amount of data, model manager 1202 is configured to build and train machine learning model 412 to accurately predict, based on patterns in the observed glucose measurements of person 102, whether a predicted glucose measurement 414 will meet one or more glucose measurement thresholds for that person during an upcoming time interval.

[0224] Because the glucose measurements 118 from the CGM platform 112 lack robustness, conventional systems simply cannot build or train models to properly represent how patterns indicate future glucose levels. Failure to do so may result in inaccurate predictions, leading to outcomes ranging from user annoyance (e.g., providing notifications indicating a predicted hypoglycemic event that does not actually occur) to life-or-death situations (e.g., an unsafe condition resulting from a hypoglycemic event occurring at night, but no such unsafe condition was predicted). Given the importance of generating inaccurate predictions and the untimely notifications associated with these predictions, it is crucial to build a machine learning model 412 using a sufficient amount of glucose measurements 118 that are robust to rare or statistically anomalous events.

[0225] In one or more specific implementations, model manager 1202 constructs machine learning model 412 by generating training data. Initially, generating training data includes forming training glucose measurements from glucose measurements 118 and corresponding timestamps 402 of user group 110. Model manager 1202 may utilize the functionality of sequencing manager 406 to form those training glucose measurements, for example, in a manner similar to the detailed description above regarding the formation of time-series glucose measurements 410. Model manager 1202 may be further implemented to generate training glucose measurements for specific time intervals.

[0226] In one or more specific implementations, model manager 1202 generates training data to include an alarm response profile 1204, which describes historical notifications corresponding to predictions output by prediction system 310 (e.g., a predicted glucose level alarm notification), the time prior to the occurrence of the predicted event corresponding to the notification (e.g., the predicted range of the notification), and user responses to the notification (e.g., confirmation of the notification, dismissal of the notification, or "pausing" without action, specific actions taken in response to the notification such as insulin administration or consumption of a meal or snack, unconfirmed notification, etc.). Alarm response profile 1204 represents a description of responses to notifications (such as...) Figures 8 to 11 The data on one or more user responses to the alarm notifications described herein can be used by one or more machine learning models 412 of the prediction system 310 to more accurately determine the expected response to the upcoming alarm notification and the prediction range for a particular type of alarm, so as to determine when the corresponding notification should be delivered to the user.

[0227] For example, instances of training data may include a labeled portion of glucose measurement results, where the labels identify the type of alarm notification trigger event corresponding to the glucose measurement result (e.g., meeting a threshold glucose level specified for a specific user), synchronized with timestamp 402 to indicate when the event started and ended regarding the glucose measurement result, the user's response to the notification, and the time of the user's response relative to the glucose measurement result. Therefore, the labels of such training data serve as the basis for comparison with the output of machine learning model 412 during training. In this way, for Figures 8 to 11 Feedback from one or more user interface prompts depicted herein can be further used as base-based live training data to refine the alarm response profile 1204 associated with a certain type of alarm and modify the prediction range for the corresponding alarm. For example, for Figures 8 to 11 Feedback from one or more user interface prompts shown can be used to refine the alarm response profile 1204 for various types of notifications that may be specific to person 102 (e.g., based on explicit feedback provided by person 102).

[0228] In one or more specific implementations, model manager 1202 uses such labeled training data to train machine learning model 412 based on alarm response profile 1204 to output notification 314 corresponding to glucose measurement result prediction 414 (e.g., high alarm, low alarm, urgent low alarm, urgent high alarm, etc.). In this case, machine learning model 412 learns to output a notification for a specific person 102 at an ideal time based on one or more of the inputs from glucose measurement result 118 or supplementary data 404 by modifying the prediction range associated with a particular alarm or notification type to avoid outputting an alarm-intrusive signal.

[0229] In a similar manner, the machine learning model learns to generate a prediction 312 (e.g., a glucose measurement result prediction 414) and when to output a corresponding notification 314 based on the input of glucose measurement result 410 and / or additional data 404, wherein the additional data 404 additionally represents the output prediction previously generated by the machine learning model 412.

[0230] The process of feeding instances of training data into machine learning model 412, receiving training predictions from machine learning model 412, comparing the training predictions with (observed) ground truth information corresponding to the generated predictions 312 and notifications 314, and adjusting the internal weights of machine learning model 412 based on these comparisons can be repeated hundreds, thousands, or even millions of times using instances of training data per iteration.

[0231] Model manager 1202 may perform such iterations until machine learning model 412 is able to generate consistent predictions that substantially match the expected output. The ability of a machine learning model to consistently generate predictions that substantially match the expected output can be termed "convergence". With this in mind, it can be said that model manager 1202 trains machine learning model 412 until it "converges" to a solution (e.g., due to training iterations, the model's internal weights have been appropriately adjusted so that the model consistently generates predictions that substantially match the corresponding underlying real data).

[0232] As described above, the management of machine learning model 412 may include using transfer learning to personalize machine learning model 412. In such a scenario, model manager 1202 may initially train machine learning model 412 at a global level, as detailed above in the example of training data generated from data generated from user group 110. In a transfer learning scenario, model manager 1202 may then create instances of this globally trained model for specific users, such that a copy of the globally trained model is generated for person 102, and additional copies of the globally trained model are generated for other users on a per-user basis.

[0233] This globally trained model can then be updated (or further trained) using person-specific data 102. For example, model manager 1202 can create instances of training data using glucose measurement results 118, glucose measurement predictions 414 for person 102, and explicit user feedback received from person 102 relative to alerts output based on glucose measurement predictions 414, and further train a globally trained version of the model in a manner similar to that described herein (e.g., by providing training inputs of person 102's training data to machine learning model 412, receiving training predictions 312, comparing these predictions with corresponding base real-world training data, and adjusting the internal weights of machine learning model 412). Based on this further training, machine learning model 412 is trained at the individual level, creating a personally trained machine learning model 412 configured to generate and output notifications based on user-specific prediction ranges.

[0234] In one or more specific implementations, this personalization can be more granular than on a per-user basis. For example, a globally trained model can be personalized at the user segment level (i.e., a group of similar users within user group 110, less than user group 110 as a whole). In this way, model manager 1202 can create a copy of the globally trained machine learning model 412 on a segment-by-segment basis and train the global version at the segment level, thereby creating a segment-specific machine learning model 412. For example, machine learning model 412 can utilize transfer learning applied to segments in a manner similar to that described above with respect to person 102.

[0235] In one or more specific implementations, model manager 1202 may personalize machine learning model 412 at the server level (e.g., at a server on CGM platform 112). Machine learning model 412 may then be maintained and / or communicated at the server level to computing device 108, i.e., for integration with applications on CGM platform 112 at computing device 108. In this way, larger computing resources than those included in computing device 108 can be used to train machine learning model 412 (e.g., using cloud-based computing resources via implementing prediction system 310 at data analytics platform 122). Alternatively or additionally, at least a portion of model manager 1202 may be implemented at computing device 108 such that a globally trained version of machine learning model 412 is communicated to computing device 108, and transfer learning (i.e., further training to personalize the model as described above) is performed at computing device 108. While transfer learning may be utilized in one or more scenarios, this personalization may not be utilized, and the described techniques may be implemented using a globally trained version of machine learning model 412.

[0236] In some examples, prediction system 310 includes an indication of the version of the machine learning model 412 used by prediction system 310 to generate glucose measurement result prediction 414 (e.g., global version, segment version, user version, whether the version includes transfer learning, etc.). For example, prediction system 310 includes the indication of the version of machine learning model 412 in the metadata associated with glucose measurement result prediction 414. CGM system 104 utilizes the indicated version of machine learning model 412 as part of generating alerts, identifying hindrance alerts, and / or modifying the prediction range associated with a specific alert. In one example, if glucose measurement result prediction 414 is associated with a global version of machine learning model 412 rather than a segment version of machine learning model 412, CGM system 104 is more likely to display an alert in the user interface based on glucose measurement result prediction 414 that meets an alert threshold. In another example, if an alert is generated based on glucose measurement result prediction 414 associated with a version of machine learning model 412 that includes transfer learning rather than a version of machine learning model 412 that does not include transfer learning, CGM system 104 is more likely to display an alert in the user interface of computing device 108. The CGM system 104 may also use the indicated version of the machine learning model 412, such as by displaying a notification in the user interface indicating that the current version of the machine learning model 412 is a global version that suggests different versions of the machine learning model 412 to the user 102, to increase the accuracy of the predicted glucose value 508 and reduce false positive alarms to request user feedback.

[0237] Having described exemplary details of the technique for generating event predictions and glucose measurement result predictions using at least one machine learning model, we now consider some exemplary procedures to illustrate additional aspects of the technique.

[0238] Exemplary program

[0239] This section describes an exemplary procedure for predicting glucose measurement results and setting personalized notifications using one or more machine learning models. Aspects of the procedure may be implemented in hardware, firmware, or software, or a combination thereof. The procedure is shown as a set of blocks specifying operations to be performed by one or more devices and is not necessarily limited to the order shown for the operations to be performed by the individual blocks. In at least some specific embodiments, the procedure is executed by a prediction system, such as prediction system 310 utilizing sequencing manager 406, prediction manager 408, and model manager 1202.

[0240] Figure 13 An exemplary implementation of program 1300 is described, in which a subsequent instance of modifying the prediction range of an alarm notification and outputting an alarm notification based on the modified prediction range is depicted.

[0241] Information describing glucose measurement results is received from a user-worn continuous glucose monitoring (CGM) system (box 1302). For example, prediction manager 408 receives glucose measurement result 118, which is obtained from a CGM system 104 worn by person 102. Specifically, CGM system 104 includes sensor 202, which is subcutaneously inserted into the skin of person 102 and used to measure glucose in the interstitial fluid of person 102.

[0242] Based on this data, a prediction of the user's glucose measurement results for a future time period is generated (box 1304). For example, machine learning model 412 processes glucose measurement results 118 to generate a glucose measurement result prediction 414. In some specific implementations, the machine learning model additionally processes glucose measurement results 118 using additional data 404 to generate the glucose measurement result prediction based on patterns learned during training relative to the person 102 or user group 110 for which it generates the glucose measurement result prediction 414. As mentioned above, user group 110 includes users wearing CGM systems (such as CGM system 104).

[0243] Then, it is determined whether at least one glucose measurement prediction meets an alarm threshold within the prediction range of the alarm (box 1306). For example, prediction system 310 compares one or more values ​​specified by one or more glucose measurement predictions 414 to determine whether the one or more values ​​meet (e.g., meet, exceed, fall below, etc.) the threshold associated with the alarm during the prediction range of the alarm. Prediction system 310 performs this determination by detecting the prediction range (e.g., prediction range 608, 610, or 612) of a specific type of alarm (e.g., low glucose event alarm, high glucose event alarm, etc.) and the threshold of that alarm (e.g., low warning threshold 514, high warning threshold 516, etc.), and determining whether the values ​​of one or more glucose measurement predictions 414 occur during the prediction range and meet the threshold.

[0244] In response to determining that the prediction of at least one glucose measurement result does not meet the alarm threshold within the prediction range of the alarm, the operation returns from box 1306 to box 1304 and continues to predict the user's glucose value during a future time period.

[0245] In response to determining that at least one glucose measurement prediction meets an alarm threshold within the predicted range of the alarm, an alarm is output (box 1306). For example, data analytics platform 122 generates notification 314 based on glucose measurement prediction 414. Notification 314 may, for example, alert a user (or healthcare provider or telemedicine service) to an impending adverse health condition, such as the user potentially administering an incorrect dose of insulin for their predicted glucose levels without mitigating behaviors (e.g., eating, exercising, etc.). Additionally or alternatively, notification 314 may support decisions on how to treat diabetes, such as by recommending the user (or healthcare provider or telemedicine service) to perform actions (e.g., download the app to computing device 108, seek immediate medical attention, administer insulin, take a walk, consume a specific food or beverage), continue behaviors (e.g., continue eating in a certain way or exercising in a certain way), or change behaviors (e.g., change eating or exercise habits), etc. The alarm may also include one or more prompts requesting feedback related to the alarm, such as those mentioned above regarding… Figures 8 to 11 The exemplary feedback prompts described above.

[0246] The prediction scope of the alarm is then modified (box 1310). For example, the prediction system 310 monitors glucose measurement 118 after outputting notification 314 and additional data 404 related to notification 314. The monitored glucose measurement 118 can be used by the prediction system 310 to determine the response of person 102 to notification 314 (e.g., whether person 102 took mitigation actions to intervene and prevent the problematic glucose event from occurring, or whether no intervention action was taken, etc.). The additional data 404 related to notification 314 represents any suitable type of data other than the monitored glucose measurement 118 that describes person 102's response to the output of alarm notification 314. For example, additional data 404 could represent data related to... Figures 8 to 11 The explicit user feedback provided in one of the user interfaces shown and described.

[0247] Based on glucose measurement results 118 and / or additional data 404, model manager 1202 specifically updates the alarm response profile 1204 by modifying the prediction range of the alarm. In some implementations, modifying the prediction range of the alarm includes reducing the amount of time included in the prediction range to mitigate the number of disruptive alarms that would otherwise be associated with the unmodified prediction range. Alternatively, modifying the prediction range of the alarm includes increasing the amount of time included in the prediction range to provide person 102 with additional advance warning time before the predicted problematic glucose level event occurs, allowing for intervention to avoid the problematic glucose level event.

[0248] Model manager 1202 is configured to communicate an alarm response profile 1204 with a modified prediction range for a specified alarm to machine learning model 412, which uses the modified prediction range to cause at least one subsequent instance of the alarm to be output based on the modified prediction range (box 1312). For example, machine learning model 412 may cause at least one subsequent instance of notification 314 to be output based on the modified prediction range for the alarm type of notification 314. Operation then returns from box 1312 to box 1304 and continues to predict the user's glucose value during a future time period.

[0249] Figure 14 An exemplary embodiment of procedure 1400 is described, in which a subsequent instance of modifying at least one prediction range setting of a CGM system and outputting an alarm based on the modified at least one prediction range setting of the CGM system is described.

[0250] A threshold is determined for at least one CGM system glucose measurement prediction to meet an alarm (box 1402). For example, prediction manager 408 receives glucose measurement 118 from a CGM system 104 worn by person 102. Machine learning model 412 processes glucose measurement 118 to generate glucose measurement prediction 414 for future time periods. A subset of glucose measurement prediction 414 is identified as falling within the predicted duration of a specific alarm (e.g., high glucose alarm, low glucose alarm, etc.) and compared to a threshold for that alarm (e.g., low alarm threshold 514, high alarm threshold 516, etc.).

[0251] This results in an alarm being output in response to determining a threshold at which at least one glucose measurement prediction would satisfy an alarm (box 1404). For example, in response to determining a threshold at which one or more glucose measurement predictions in a subset of glucose measurement predictions 414 would satisfy an alarm (e.g., low alarm threshold 514, high alarm threshold 516, etc.), the prediction system 314 causes a notification 314 to be output at the user interface of the computing device 108 of the human 102. Examples of such alarms output at the user interface of the computing device 108 include alarms 802 and 804 and notifications 902, 904, 906, 1002, and 1004.

[0252] Then it is determined whether feedback data describing user input relative to the alarm has been received (box 1406). For example, the prediction system 310 monitors the receipt of supplementary data 404 and determines whether the supplementary data 404 includes information describing user input relative to the output alarm.

[0253] In response to determining that feedback data describing user input relative to an alarm has been received, at least one setting of the CGM system is modified based on the feedback data (box 1408). For example, in response to receiving feedback data describing user input relative to user interface elements 806 and / or 808 in the illustrated representation 800, the setting may be modified based on, as per the information provided... Figure 8 The described considerations are used to modify the prediction range associated with the corresponding alarm (e.g., alarm 802 or 804). Alternatively or additionally, in response to receiving feedback data describing user input relative to user interface elements 908-920, the prediction range may be based on, as per the description of... Figure 9 The described considerations are used to modify the prediction range associated with the corresponding notification (e.g., notifications 902, 904, and / or 906). Alternatively or additionally, in response to receiving feedback data describing user input relative to user interface elements 1008-1018, the prediction range may be based on, as per the description of... Figure 10 The described considerations are used to modify the forecast range associated with the corresponding notifications (e.g., notifications 1002, 1004, and / or 1006).

[0254] In response to determining that no feedback data describing user input relative to the alarm has been received, or optionally after execution box 1408, such as Figure 14 As indicated by the dashed arrow in the diagram, data other than user input describing the response to the alarm is received (box 1410). This data, in addition to user input describing the response to the alarm, may include, for example, glucose measurement results 118 and / or additional data 404. Such additional data 404 describing the response to the alarm, other than user input, may include (by way of example and not limitation) application usage data, accelerometer data from the mobile device or smartwatch (e.g., indicating that the user has viewed the device's user interface and may therefore have seen an alarm or message related to a predicted event), data describing the insulin administered (e.g., time and insulin dose), data describing the food consumed (e.g., time of consumption, type of food, and / or amount of carbohydrates consumed), activity data from various sensors (e.g., step count data, fitness activities performed, or other data indicating user activity or exercise), glucose level responses to stress, combinations thereof, etc.

[0255] Based on data other than user input, at least one prediction range setting of the CGM system is automatically modified without user intervention (box 1412). For example, in response to receiving data indicating that person 102 has viewed an alarm predicting a glucose measurement result 414 as problematic due to meeting an alarm threshold glucose level but has not taken any action relative to the alarm, which is assumed to be a disruptive alarm, the prediction range setting associated with that alarm for CGM system 104 is modified to mitigate the output of subsequent disruptive instances of the alarm. As another example, additional data 404 may indicate that person 102 responds to an urgent low alarm by eating a snack, but the snack does not increase person 102's glucose level before person 102's glucose level exceeds the urgent low threshold level. Based on this data, the prediction range setting of the urgent low alarm for CGM system 104 may be modified to increase the advance warning time of the urgent low alarm, such that person 102 is given additional time to consume the snack or take a similar intervention to prevent their glucose measurement 118 from meeting the urgent low threshold level. In this way, the prediction range setting of the CGM system 104 can be modified based on feedback data describing the explicit user input relative to the alarm, as well as additional data other than the explicit user input relative to the alarm, to fine-tune the alarm prediction range in a personalized manner for person 102.

[0256] In modifying at least one prediction range setting of the CGM system 104, the model manager 1202 specifically updates the alarm response configuration file 1204 of the alarm by modifying the prediction range of the alarm. In some implementations, modifying the prediction range of the alarm includes reducing the amount of time included in the prediction range to mitigate the number of disruptive alarms that would otherwise be associated with the unmodified prediction range. Alternatively, modifying the prediction range of the alarm includes increasing the amount of time included in the prediction range to provide person 102 with additional advance warning time before the predicted problematic glucose level event occurs, so as to take intervention action to avoid the problematic glucose level event.

[0257] Model manager 1202 is configured to communicate alarm response profile 1204, which specifies the modified prediction range of an alarm, to machine learning model 412, which uses at least one modified prediction range setting of the CGM system to cause at least one subsequent instance of the output alarm (box 1414).

[0258] Having described exemplary procedures according to one or more specific implementations, exemplary systems and apparatuses that can be used to implement the various techniques described herein are now considered.

[0259] Exemplary systems and apparatus

[0260] Figure 15An exemplary system, generally designated 1500, is illustrated. This exemplary system includes an exemplary computing device 1502, which represents one or more computing systems and / or devices capable of implementing the various technologies described herein. This is illustrated by including the CGM platform 112 within it. The computing device 1502 may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), a system-on-a-chip, and / or any other suitable computing device or computing system.

[0261] As shown in the figure, an exemplary computing device 1502 includes a processing system 1504, one or more computer-readable media 1506, and one or more I / O interfaces 1508 communicatively connected to each other. Although not shown, the computing device 1502 may also include a system bus or other data and command transfer system that connects various components to each other. The system bus may include any of the different bus architectures or combinations thereof, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of the various bus architectures. Various other examples, such as control lines and data lines, are also contemplated.

[0262] Processing system 1504 represents the functionality of performing one or more operations using hardware. Therefore, processing system 1504 is shown as including hardware elements 1510 that can be configured as processors, function blocks, etc. This may include other logic devices implemented in hardware as application-specific integrated circuits (ASICs) or formed using one or more semiconductors. Hardware elements 1510 are not limited by the materials forming them or the processing mechanisms employed therein. For example, a processor may include semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In this context, processor-executable instructions may be electronically executable instructions.

[0263] Computer-readable medium 1506 is shown as including memory / storage device 1512. Memory / storage device 1512 represents a memory / storage capacity associated with one or more computer-readable media. Memory / storage device 1512 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disk, magnetic disk, etc.). Memory / storage device 1512 may include fixed media (e.g., RAM, ROM, fixed hard disk drive, combinations thereof, etc.) and removable media (e.g., flash memory, removable hard disk drive, optical disk, combinations thereof, etc.). Computer-readable medium 1506 may be configured in a variety of other ways, as described in further detail below.

[0264] Input / output interface 1508 represents a function that enables a user to input commands and / or information to computing device 1502 and to present information to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, cursor control device (e.g., mouse), microphone, scanner, touch functionality (e.g., capacitive sensor or other sensor configured to detect physical touch), camera (e.g., device configured to recognize movement as a gesture not involving touch using visible or invisible wavelengths (such as infrared frequencies), etc. Examples of output devices include display devices (e.g., monitor or projector), speakers, printers, network interface cards, haptic response devices, etc. Therefore, computing device 1502 can be configured to support user interaction in various ways as further described below.

[0265] This document describes various technologies in the general context of software, hardware components, or program modules. Generally, a program module includes routines, programs, objects, components, parts, data structures, etc., that perform a specific task or implement a specific abstract data type. The terms “module,” “function,” and “part” used herein typically refer to software, firmware, hardware, or a combination thereof. The technologies described herein are characterized by platform independence, meaning that these technologies can be implemented on a variety of commercial computing platforms with multiple processors.

[0266] Specific implementations of the described modules and technologies may be stored on or transmitted across some form of computer-readable medium. The computer-readable medium may include a variety of media accessible by the computing device 1502. By way of example, and not limitation, the computer-readable medium may include a “computer-readable storage medium” and a “computer-readable signal medium.”

[0267] "Computer-readable storage medium" can refer to a medium and / or device capable of persistently and / or non-transitory storing information, and not merely signal transmission, carrier waves, or signals themselves. Therefore, a computer-readable storage medium refers to a non-signal-bearing medium. Computer-readable storage media include hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented in a manner or technique suitable for storing information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, hard disks, magnetic tape cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or articles of art suitable for storing desired information and accessible by a computer.

[0268] "Computer-readable signal medium" can refer to a signal-bearing medium configured to transmit instructions, such as via a network, to the hardware of computing device 1502. Signal media typically embody computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves, data signals, or other transmission mechanisms). Signal media also includes any information delivery medium. The term "modulated data signal" refers to a signal whose characteristics are set or altered in a manner that encodes information in the signal. By way of example, and not limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic media, RF media, infrared media, and other wireless media.

[0269] As previously described, hardware element 1510 and computer-readable medium 1506 represent modules, programmable device logic, and / or fixed device logic implemented in hardware, which may be used in some embodiments to implement at least some aspects of the techniques described herein to execute one or more instructions. The hardware may include integrated circuits or systems-on-a-chip, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other components of specific implementations in silicon or other hardware. In this context, the hardware may operate as a processing means for executing program tasks defined by instructions and / or logic embodied in the hardware, and as hardware for storing instructions for execution (e.g., the computer-readable storage medium described herein).

[0270] The various techniques described herein can also be implemented using combinations of the foregoing. Therefore, software, hardware, or executable modules can be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage medium and / or embodied by one or more hardware elements 1510. The computing device 1502 can be configured to implement specific instructions and / or functions corresponding to software and / or hardware modules. Thus, for example, by using a computer-readable storage medium and / or the hardware elements 1510 of the processing system 1504, a specific implementation of a module executable by the computing device 1502 as software can be implemented at least partially in hardware. Instructions and / or functions can be executed / operated by one or more articles of manufacture (e.g., one or more computing devices 1502 and / or processing systems 1504) to implement the techniques, modules, and examples described herein.

[0271] The techniques described herein can be supported by various configurations of computing device 1502, and are not limited to specific examples of the techniques described herein. This functionality can also be implemented, in whole or in part, using distributed systems, such as on “cloud” 1514 via platform 1516, as described below.

[0272] Cloud 1514 includes and / or represents platform 1516 for resource 1518. Platform 1516 abstracts the underlying functionality of the hardware (e.g., server) and software resources of cloud 1514. Resource 1518 may include applications and / or data that can be utilized when computer processing is performed on a server remote from computing device 1502. Resource 1518 may also include services provided via the Internet and / or via subscriber networks such as cellular or Wi-Fi networks.

[0273] Platform 1516 can abstract resources and functions to connect computing device 1502 to other computing devices. Platform 1516 can also be used to abstract resource scaling to provide corresponding scaling levels to meet the needs of resource 1518 implemented via platform 1516. Therefore, in interconnected device implementations, the specific implementation of the functions described herein can be distributed throughout system 1500. For example, the function can be implemented partly on computing device 1502 and via platform 1516, which abstracts the functions of cloud 1514.

[0274] in conclusion

[0275] Although the systems and techniques have been described in language specific to structural features and / or methodological actions, it should be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or actions described. Rather, specific features or actions are disclosed as exemplary forms for implementing the claimed subject matter.

Claims

1. A method for use in a system, the system including a processor, the method comprising: Receives data describing glucose measurement results from a user-worn continuous glucose monitoring (CGM) system; Based on the data, predict the user's glucose level during a future time period; Determine at least one predicted glucose value that meets a threshold for an alarm, the alarm being associated with a prediction range that defines how far the predicted glucose value is considered to be entering the future time period relative to the threshold; This results in the alarm being output in the user interface of the computing device in response to determining that the at least one predicted glucose value meets the threshold within the predicted range relative to the current time; Receive additional data describing the glucose measurements observed during the said future time period; Compare one or more of the predicted glucose values ​​with one or more of the observed glucose measurements during the future time period; The prediction range is modified based on the difference between one or more of the observed glucose measurements and one or more of the predicted glucose values. as well as This results in subsequent instances of the alert being output in the user interface based on the modified prediction range.

2. The method of claim 1, wherein the modification of the prediction range is performed based on the user's historical glucose measurement patterns.

3. The method of claim 1, wherein predicting the user's glucose value during the future time period is performed based on the user's historical glucose measurement patterns.

4. The method of claim 1, wherein predicting the glucose value of the user during the future time period comprises processing the data using at least one machine learning model trained to predict the glucose value using training data describing glucose measurements of a user group.

5. The method of claim 4, wherein the at least one machine learning model is further trained to predict glucose values ​​using additional data from the user group.

6. The method of claim 1, further comprising causing a feedback prompt to be output in the user interface relative to the alarm and receiving a response to the prompt, wherein the modification of the prediction range is performed based on the response to the prompt.

7. The method of claim 6, wherein the feedback prompt includes at least one of the following: Feedback prompts regarding the adequacy of the advance warning time associated with the alarm; Regarding whether the alert provided helpful feedback; or Feedback prompts regarding the user's response to the alarm.

8. The method of claim 1, wherein the alarm indicates one of a high glucose level alarm, a low glucose level alarm, or an emergency low glucose level alarm.

9. The method of claim 1, wherein modifying the prediction range includes adjusting the advance warning time of the alarm.

10. The method of claim 1, wherein the modification of the prediction range is performed based on data describing a subset of users having user profile attributes similar to those of the user.

11. The method of claim 1, wherein modifying the prediction range is performed based on the confidence level of the at least one predicted glucose value.

12. The method according to claim 1, further comprising: The alarm has been determined to be a disruption alarm; as well as The prediction range is modified in response to determining that the alarm is a hindrance alarm.

13. A system comprising: At least one processor; and One or more computer-readable storage media, the one or more computer-readable storage media including instructions executable by the at least one processor to perform operations, the operations including: Receive data describing the user's glucose measurement results; Based on the data, predict the user's glucose level during a future time period; Determine at least one predicted glucose value that meets a threshold for an alarm, the alarm being associated with a prediction range that defines how far the predicted glucose value is considered to be entering the future time period relative to the threshold; This results in the output of the alarm in response to determining that the at least one predicted glucose value meets the threshold within the predicted range relative to the current time; Receive additional data describing the glucose measurements observed during the said future time period; Compare one or more of the predicted glucose values ​​with one or more of the observed glucose measurements during the future time period; The prediction range is modified based on the difference between one or more of the observed glucose measurements and one or more of the predicted glucose values; and This results in subsequent instances of the alert being output based on the modified prediction range.

14. The system of claim 13, wherein the modification of the prediction range is performed based on the user's historical glucose measurement patterns.

15. The system of claim 13, wherein the prediction of the user's glucose value during the future time period is performed based on the user's historical glucose measurement patterns.

16. The system of claim 13, wherein predicting the glucose value of the user during the future time period comprises processing the data using at least one machine learning model trained to predict the glucose value using training data describing glucose measurements of a user group.

17. The system of claim 16, wherein the at least one machine learning model is further trained to predict glucose values ​​using additional data from the user group.

18. The system of claim 13, further comprising causing a feedback prompt relative to the alarm output and receiving a response to the prompt, wherein the modification of the prediction range is performed based on the response to the prompt.

19. The system of claim 18, wherein the feedback prompt includes at least one of the following: Feedback prompts regarding the adequacy of the advance warning time associated with the alarm; Regarding whether the alert provided helpful feedback; or Feedback prompts regarding the user's response to the alarm.

20. The system of claim 13, wherein the alarm indicates one of a high glucose level alarm, a low glucose level alarm, or an emergency low glucose level alarm.

21. The system of claim 13, wherein modifying the prediction range includes adjusting the advance warning time of the alarm.

22. The system of claim 13, wherein the modification of the prediction range is performed based on data describing a subset of users having user profile attributes similar to those of the user.

23. The system of claim 13, wherein the modification of the prediction range is performed based on the confidence level of the at least one predicted glucose value.

24. The system of claim 13, further comprising: The alarm was determined to be a hindrance alarm; as well as The prediction range is modified in response to determining that the alarm is a hindrance alarm.

25. One or more computer-readable storage media storing instructions executable by a computing device to perform operations, the operations including: Receive data describing the user's glucose measurement results; Based on the data, predict the user's glucose level during a future time period; Determine at least one predicted glucose value that meets a threshold for an alarm, the alarm being associated with a prediction range that defines how far the predicted glucose value is considered to be entering the future time period relative to the threshold; This results in the output of the alarm in response to determining that the at least one predicted glucose value meets the threshold within the predicted range relative to the current time; Receive additional data describing the glucose measurements observed during the said future time period; Compare one or more of the predicted glucose values ​​with one or more of the observed glucose measurements during the future time period; The prediction range is modified based on the difference between one or more of the observed glucose measurements and one or more of the predicted glucose values. as well as This results in subsequent instances of the alert being output based on the modified prediction range.

26. One or more computer-readable storage media according to claim 25, wherein the modification of the prediction range is performed based on the user's historical glucose measurement patterns.

27. One or more computer-readable storage media of claim 25, wherein the prediction of the glucose value of the user during the future time period is performed based on the user's historical glucose measurement patterns.

28. One or more computer-readable storage media of claim 25, wherein predicting the glucose value of the user during the future time period comprises processing the data using at least one machine learning model trained to predict the glucose value using training data describing glucose measurements of a user group.

29. The one or more computer-readable storage media of claim 28, wherein the at least one machine learning model is further trained to predict glucose values ​​using additional data from the user population.

30. The operation of one or more computer-readable storage media according to claim 25 further includes causing a feedback prompt relative to the alarm output and receiving a response to the prompt, wherein the modification of the prediction range is performed based on the response to the prompt.

31. The computer-readable storage medium of claim 30, wherein the feedback prompt includes at least one of the following: Feedback prompts regarding the adequacy of the advance warning time associated with the alarm; Regarding whether the alert provided helpful feedback; or Feedback prompts regarding the user's response to the alarm.

32. The computer-readable storage medium of claim 25, wherein the alarm indicates one of a high glucose level alarm, a low glucose level alarm, or an emergency low glucose level alarm.

33. The one or more computer-readable storage media of claim 25, wherein modifying the prediction range includes adjusting the advance warning time of the alarm.

34. The one or more computer-readable storage media of claim 25, wherein the modification of the prediction range is performed based on data describing a subset of users having user profile attributes similar to those of the user.

35. One or more computer-readable storage media according to claim 25, wherein the modification of the prediction range is performed based on the confidence level of the at least one predicted glucose value.

36. The operation further comprises: The alarm was determined to be a hindrance alarm; as well as The prediction range is modified in response to determining that the alarm is a hindrance alarm.

37. An apparatus, the apparatus comprising: A receiving device for receiving data describing glucose measurement results from a user-worn continuous glucose monitoring (CGM) system; A predictive device for predicting the user's glucose levels over a future time period based on the data; A determining means for determining at least one predicted glucose value that meets a threshold for an alarm, the alarm being associated with a prediction range that defines how far the predicted glucose value is from the threshold of the alarm being considered to be entering the future time period; An alarm device for causing an alarm to be output in the user interface of a computing device in response to determining that the at least one predicted glucose value meets the threshold within the predicted range relative to the current time; The receiving device also receives additional data describing glucose measurement results observed during the future time period; A comparison device for comparing one or more of the predicted glucose values ​​with one or more of the observed glucose measurements during the future time period; A modification device for modifying the prediction range based on the difference between one or more of the observed glucose measurements and one or more of the predicted glucose values; and The alarm device is further configured to cause subsequent instances of the alarm to be output in the user interface based on the modified prediction range.

Images