Proposal Based on Continuous Glucose Monitoring

Abstract

Recommendations based on continuous glucose monitoring (CGM) are described. Given the number of people who wear CGM systems, the platforms that provide them may have an enormous amount of data because the CGM systems continuously generate measurements. This amount of data is virtually, if not entirely, impossible for humans to process. In an implementation, the CGM platform includes a data analytics platform that obtains the glucose measurements provided by the CGM system and also obtains additional data associated with the user. The data analytics platform processes these measurements and additional data and predicts health indicators using a model. The predictions serve as the basis for generating recommendations, such as messages suggesting the user take action or adopt a behavior to mitigate a predicted adverse health condition.

Description

Technical Field

[0001] Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 940,715, filed on November 26, 2019. The foregoing application is hereby incorporated by reference in its entirety and made a part hereof as if fully set forth herein.

Background Art

[0002] Diabetes is a metabolic condition that affects hundreds of millions of people and is one of the leading causes of death worldwide. For people with diabetes, access to treatment is crucial for their survival. Appropriate treatment can significantly avoid serious damage to the heart, blood vessels, eyes, kidneys, and nerves caused by diabetes. Appropriate treatment for people with type I diabetes often involves monitoring blood glucose levels throughout the day and adjusting blood glucose levels by combining insulin, diet, and exercise so that the levels remain within a desirable range. With the advancement of medical technology, various systems for monitoring blood glucose levels have been developed.

[0003] Some of these systems also include an assembly for pricking a part of a person's body (e.g., often a person's finger) to obtain blood and a sensor for detecting an analyte in the collected blood that indicates the blood glucose level. Other systems use sensors to detect analytes that indicate blood glucose levels substantially in real time and generate measurements of those blood glucose levels over a period of time, which is called continuous glucose monitoring (CGM). Both types of systems are configured to output (e.g., display) these measurements, and the user can determine how to adjust these blood glucose levels as needed and based on a plan created with a qualified caregiver. The vast amount of blood glucose measurements generated and output by CGM systems shows the user what trends the blood glucose levels are, enabling the user to make more informed decisions regarding treatment.

Summary of the Invention

Means for Solving the Problem

[0004] This specification describes a proposal based on continuous glucose monitoring (CGM). Considering the number of people wearing CGM systems, since CGM systems generate measurements continuously, a CGM platform that provides a sensor for detecting blood glucose levels in such a system and maintains the measurements generated by such a system may have an enormous amount of data, for example, measurements for tens of millions of patient-days. However, this amount of data is related not only to blood glucose measurements but also to a wealth of additional data that can be correlated with blood glucose measurements to accurately predict various conditions, such as health metrics, and it is virtually impossible, if not actually so, for humans to reliably identify patterns.

[0005] In one or more implementations, the CGM platform includes a data analysis platform that obtains blood glucose measurement values provided by a CGM system worn by a user. The data analysis platform also obtains additional data associated with the user. However, the data analysis platform obtains the data from one or more sources different from the sensors of the CGM system, such as a computing device that processes blood glucose measurement values before communicating with the CGM platform, or a third party that provides a device or service capable of generating health-related information such as insulin data, exercise data, diet data, etc.

[0006] The data analysis platform processes these blood glucose measurements and additional data to predict health metrics for the user using one or more models, such as a statistical model, a machine learning model configured as a neural network, or other machine learning models. The data analysis platform generates these models based on past blood glucose measurements and past additional data of a user population, such as multiple users who are or were wearing a CGM system. Based on the predicted health metrics, the data analysis platform generates proposals, such as messages that propose to the user to take actions or adopt behaviors to mitigate a predicted poor health condition. The data analysis platform then communicates at least one of the prediction or the proposal via a network for output to one or more computing devices, such as a computing device associated with the user (e.g., a mobile phone or smartwatch), a computing device associated with the user's caregiver (such as a parent), a computing device associated with a verification service (accessible by a medical professional authorized to validate the proposal), etc.

[0007] This summary introduces a selected set of concepts in a simplified form as an overview of the following invention. Accordingly, this summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Brief Description of the Drawings

[0008] The detailed description is set forth with reference to the accompanying drawings.

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

[0010] Overview This specification describes a proposal based on continuous glucose monitoring (CGM). Considering the number of people wearing CGM systems, since CGM systems generate measurements continuously, a CGM platform that provides a sensor for detecting blood glucose levels in such a system and maintains the measurements generated by such a system can have an enormous amount of data, e.g., measurements for tens of millions of patient-days. However, this amount of data, even if not actually so, is related to rich additional data that can be correlated with blood glucose measurements to accurately predict various states, e.g., health metrics, and it is virtually impossible for humans to reliably identify patterns.

[0011] To overcome these problems, prediction generation by CGM is utilized. The CGM platform obtains blood glucose measurement values from various CGM systems and computing devices of users in the user population. By the described techniques, the CGM system is configured to continuously monitor a person's blood glucose. The CGM system may be configured to include, for example, a CGM sensor that is subcutaneously inserted into a person's skin and detects an analyte indicative of the person's blood glucose. The CGM system can continuously generate blood glucose measurement values based on the detected analyte. As used herein, the term "continuously" means almost continuously, and continuous blood glucose monitoring generates measurement values at time intervals supported by the resources of the CGM system (e.g., battery life, processing power, communication capabilities, etc.) without requiring user manual interaction such as finger pricking. By continuously monitoring blood glucose levels, the CGM system not only enables the user to make more informed decisions regarding the user's treatment, but also allows the user to participate in activities such as driving a vehicle where manual finger pricking can be dangerous while continuing to monitor blood glucose levels.

[0012] The CGM system transmits the blood glucose measurement values to a computing device communicatively coupled to the CGM system, such as a smartwatch worn by a person, the person's smartphone, or a dedicated device associated with the CGM system. The CGM system may communicate the blood glucose measurement values in real time, at set time intervals, or in response to a request from the computing device. The computing device then provides the blood glucose measurement values to the CGM platform, such as by communicating the blood glucose measurement values to a cloud-based service that hosts the CGM platform via a network.

[0013] The CGM platform may obtain additional data of users in a user population derived from various devices, sensors, applications, or services. The additional data may include, by way of example and not limitation, health-related data, application interaction data, environmental data, demographic data, in addition to blood glucose measurements, device data (e.g., sensor identification data, incident reports), supplementary data added by a computing device, third-party data, and the like. Health-related data may include, among other examples, activity data (e.g., step count, exercise frequency, sleep data), biometric data (e.g., insulin level, ketone level, heart rate, temperature, stress), nutritional data (e.g., diet logs, scanned restaurant receipts, carbohydrate consumption, fasting), medical records (such as A1C, cholesterol, electrocardiogram results, and data related to other medical tests or medical history). Application interaction data may include data extracted from application logs that describe user interactions with a particular application, clickstream data that describes clicks, taps, and presses executed in relation to the input / output interface of a computing device, gaze data that describes where the user is looking (e.g., in relation to a display device associated with the computing device or when the user is looking away from the device), voice data that describes audible commands and other spoken phrases of the user or other users (e.g., including when the user is passively listening). Environmental data may include, for example, data that describes various environmental aspects associated with the user, such as the user's location, the temperature and / or weather at the user's location, the user's altitude, barometric pressure, and the like. Demographic data may include, for example, data that describes the user, such as age, gender, height, weight, and the like. The types of additional data described above are merely examples, and the additional data may include more, fewer, or different types of data without departing from the spirit or scope of the techniques described herein.

[0014] The CGM platform stores and aggregates blood glucose measurement values and additional data collected from various individual users within the user population. Optionally, the blood glucose measurement values and additional data can be timestamped, which enables storing the blood glucose measurement values and additional data of each user in a way that maintains the time-based relationships or order between the various data. This allows the CGM platform to make various predictions and inferences based on individual data sets that have not been straightforwardly analyzed on such a large scale by conventional systems.

[0015] To generate predictions and inferences using the aggregated data, the CGM platform utilizes the rich aggregated data maintained by the CGM platform to build various models such as statistical models, machine learning models configured as neural networks, and / or statistical models. For example, the system can build a statistical model, build other machine learning models, train other machine learning models (or otherwise learn policies deployed by such machine learning models), and update these models using the blood glucose measurement values and additional data of the user population.

[0016] In particular, unlike conventional systems, the CGM platform may have access to blood glucose measurements obtained using a CGM system for hundreds of thousands of users (e.g., 500,000 or more) in the user population. Further, these measurements are taken at a continuous rate by the sensors of the CGM system. As a result, the blood glucose measurements available to the system for model building and training can number in the millions or even billions. With such a robust amount of data, the system can build and train models to accurately mimic the actual impact of various behaviors on blood glucose levels. Without the robustness of this aggregated data, conventional systems simply cannot build or train models to adequately cover the state space in a manner that preferably represents how the behaviors and actions of various users affect blood glucose values. Failure to adequately cover these state spaces can lead to inaccurate blood glucose predictions or predictions of other health metrics, potentially leading to the recommendation of dangerous behaviors or actions that can cause death. Given the importance of generating accurate predictions, it is important to build models using a robust amount of blood glucose measurements for rare events.

[0017] The CGM platform uses models built and / or trained using aggregated data to generate various predictions for users wearing the CGM system and recommendations for improving the predicted health states. The predictions may correspond to or otherwise include health metrics. As used herein, the term "health metric" may refer to a predicted health state that can be "negative" or "positive". Examples of poor health states include, for example, pre-diabetes, type I diabetes, type II diabetes, neuropathy, Alzheimer's disease, and heart disease, to name just a few. In contrast, examples of "good" health states can include improved blood tests, body composition, cardiovascular fitness, and the like.

[0018] Furthermore, the predictions generated by the system may include specific predictions for individual users, as well as generalized predictions or trends for the entire user population (e.g., drinking soda causes a sharp increase in blood sugar, which can lead to long-term neuropathy, or a low-carb diet reduces A1C). For example, the system can apply a trained machine learning model to the blood glucose measurements and additional data of individual users over a specific period to generate user-specific predictions of a user's health metrics or events, such as predicting that a user will develop type II diabetes or heart disease in the future. The system may generate an accuracy or probability associated with the prediction, and a period associated with the prediction (e.g., a 75% chance of developing type II diabetes within 40 months). In some cases, the system may generate predictions for individual users based on real-time data to generate short-term predictions. For example, a trained model can be applied in real-time to blood glucose measurements, heart rate, insulin levels, etc. when the data is being captured to generate the predicted blood glucose levels of a user in the near future (e.g., the next 30 minutes).

[0019] Based on these predictions, the CGM platform generates various recommendations. In some cases, the recommendations are generated based on logic that associates a predicted poor health state with one or more actions or behaviors that mitigate the predicted poor health state (e.g., reduce the probability of occurrence of a negative health state). Thus, the recommendations may include one or more actions or behaviors intended to mitigate the predicted poor health state. The recommendations may, for example, instruct the user to perform an action (e.g., download an application to a computing device, rush to the hospital immediately, administer insulin, go for a walk, consume a specific food or beverage), continue a behavior (e.g., continue a diet in a specific way, or exercise in a specific way), change a behavior (e.g., change eating habits or exercise habits), etc.

[0020] For example, based on a prediction that the user's blood glucose level will rise to a hyperglycemic level in the next 30 minutes, the CGM platform may generate a recommendation that includes an action intended to lower the user's blood glucose level, such as by suggesting that the user administer insulin or go for an active walk. Conversely, based on a prediction that the user's blood glucose level will drop to a hypoglycemic level overnight, the CGM platform may suggest that the user eat a banana before going to bed to keep the user's blood glucose level above the hypoglycemic level. As another example, based on a prediction that the user will develop type II diabetes within 40 months, the CGM platform may generate recommendations for the user to adjust their diet or increase their activity level.

[0021] The predictions and recommendations generated by the CGM platform may be provided directly to the user or may be provided to other parties or platforms associated with the user, such as, for example, a healthcare provider, family member, third-party service. Such predictions and recommendations may be communicated to the user or other parties as, for example, an electronic communication (e.g., an email message or text message), a notification (e.g., a notification within an application or on a device), or may be uploaded to a secure platform or website accessible via credentials.

[0022] According to various implementations, the CGM platform includes one or more application programming interfaces (APIs) that enable the exchange of blood glucose measurements and additional data between the CGM platform and one or more third parties. Such APIs may include "output" APIs that enable the communication of blood glucose measurements from the CGM platform to various third parties that provide applications and services that utilize the blood glucose measurements collected by the CGM system. For example, a user may download such third-party applications and permit these third-party applications to access the user's blood glucose measurements. By doing so, it becomes possible for third-party applications to utilize the blood glucose measurements in various ways to improve the user's health. In this manner, third-party service providers can provide various services that use blood glucose measurements without the third-party service providers having to manufacture and deploy their own CGM systems.

[0023] The CGM platform may also include "input" APIs that enable the CGM platform to receive "third-party" data from third-party service providers. Such third-party data may include application interaction data that describes user interactions with third-party services or applications. The CGM platform can aggregate the application interaction data along with the user's blood glucose measurements and other data to determine whether the interaction with a particular application is improving the user's health. Based on this, the CGM platform may recommend that other users in the user population also utilize a particular application.

[0024] As part of this, the system may collect demographic data of a particular user, such as age, gender, location, etc. Glucose measurements collected from the user can be combined with demographic data and additional data to generate a similarity score with other users in the user population. For example, a user who is a 22-year-old female with an average blood glucose of 162 mg / dL and experiencing a pattern of nocturnal hypoglycemic measurements may have a similarity score with other users of that age, gender, average blood glucose measurement, and pattern experience. In this scenario, a proposal for using a particular application may be based on the similarity of the user with other users within the population. For example, if the glycemia of a subset of users in the user population is improved by the use of a particular application, the CGM platform can propose the use of the particular application to similar users in the user population.

[0025] In the following description, first, an exemplary environment in which the techniques described herein can be used will be described. Next, details and procedures of exemplary implementations that can be performed in the exemplary environment and other environments will be described. The performance of the exemplary procedures is not limited to the exemplary environment, and the exemplary environment is not limited to the performance of the exemplary procedures.

[0026] Exemplary Environment FIG. 1 is a diagram of an environment 100 in an exemplary implementation operable to use a proposal based on continuous glucose monitoring (CGM) as described herein. The illustrated environment 100 includes a person 102 wearing a CGM system 104, an insulin delivery system 106, and a computing device 108. The illustrated environment 100 also includes other users in the user population 110 of the CGM system, a CGM platform 112, and the Internet of Things 114 (IoT114). The CGM system 104, the insulin delivery system 106, the computing device 108, the user population 110, the CGM platform 112, and the IoT114 are communicatively coupled to each other via a network 116.

[0027] Alternatively or additionally, one or more of the CGM system 104, the insulin delivery system 106, and the computing device 108 may be communicatively coupled in other ways, such as by using one or more short-range communication protocols or techniques. For example, the CGM system 104, the insulin delivery system 106, and the computing device 108 may communicate with each other using one or more of Bluetooth, Near Field Communication (NFC), 5G, etc. The CGM system 104, the insulin delivery system 106, and the computing device 108 may utilize these types of communication to form a closed-loop system among themselves. In this way, the insulin delivery system 106 may deliver insulin based on a blood glucose prediction calculated in real time (e.g., by the computing device 108) since the blood glucose measurement is obtained by the CGM system 104.

[0028] By the described techniques, the CGM system 104 is configured to continuously monitor the blood glucose of the person 102. The CGM system 104 may be configured to include, for example, a CGM sensor that continuously detects an analyte indicative of the blood glucose of the person 102 and enables the generation of blood glucose measurements. In the illustrated environment 100, these measurements are represented as blood glucose measurements 118. This functionality is described in more detail in relation to FIG. 2, along with further aspects of the configuration of the CGM system 104.

[0029] In one or more implementations, the CGM system 104 transmits the blood glucose measurement values 118 to the computing device 108, such as via Bluetooth. The CGM system 104 may communicate these measurement values in real time, for example, since these measurements are generated using a CGM sensor. Alternatively or additionally, the CGM system 104 may communicate the blood glucose measurement values 118 to the computing device 108 at set time intervals, such as every 30 seconds, every minute, every hour, every six hours, daily, etc. Still further, the CGM system 104 may, for example, communicate these measurements in response to a request from the computing device 108 communicated to the CGM system 104 when the computing device 108 causes a display of a user interface having information regarding the blood glucose level of the person 102, updates such a display, predicts the next blood glucose level of the person 102 for the purpose of delivering insulin, etc. Thus, the computing device 108 may maintain the blood glucose measurement values 118 of the person 102 at least temporarily, for example, in a computer-readable storage medium of the computing device 108.

[0030] Although illustrated as a wearable device (e.g., a smartwatch), computing device 108 may be configured in a variety of ways without departing from the spirit or scope of the described techniques. By way of example and not limitation, computing device 108 may be configured as a different type of mobile device (e.g., a cellular phone or a tablet device). In one or more implementations, computing device 108 may be configured as a dedicated device associated with CGM platform 112 and may, for example, acquire blood glucose measurements 118 from CGM system 104, perform various calculations related to blood glucose measurements 118, display blood glucose measurements 118 and information related to CGM platform 112, communicate blood glucose measurements 118 to CGM platform 112, etc. However, in contrast to implementations where computing device 108 is configured as a cellular phone, computing device 108 may not include some of the functionality available in a cellular phone or wearable configuration when configured as a dedicated CGM device, such as the ability to make phone calls, camera functionality, the ability to utilize social networking applications, etc.

[0031] Additionally, computing device 108 may represent a plurality of devices according to the described techniques. In one or more scenarios, for example, computing device 108 may be compatible with both a wearable device (e.g., a smartwatch) and a mobile phone. In such a scenario, both of these devices may be capable of performing at least some of the same operations, such as receiving blood glucose measurements 118 from CGM system 104, communicating them to CGM platform 112 via network 116, and displaying information related to blood glucose measurements 118. Alternatively or additionally, different devices may have different capabilities that are not possessed by other devices or are restricted through calculations for a particular device. In a scenario where computing device 108 corresponds to a separate smartwatch and mobile phone, for example, the smartwatch may be configured with various sensors and functionality to measure various physiological markers (e.g., heart rate, respiration, blood velocity, etc.) and the activities of person 102 (e.g., steps). In this scenario, the mobile phone may not be configured with these sensors and functionality or may include a limited amount of that functionality, although in other scenarios, the mobile phone may be capable of providing the same functionality. Continuing with this particular scenario, the mobile phone may have capabilities that the smartwatch does not have, such as an amount of computing resources (e.g., battery and processing speed) that enable the mobile phone to perform calculations related to blood glucose measurements 118 more efficiently. Even in scenarios where the smartwatch is capable of performing such calculations, the calculation instructions may limit the performance of those calculations for the mobile phone in order to not burden both devices and to efficiently utilize the available resources. In this regard, computing device 108 may be configured differently and represent a different number of devices than those described herein without departing from the spirit and scope of the described techniques.

[0032] As described above, the computing device 108 communicates the blood glucose measurement 118 to the CGM platform 112. In the illustrated environment 100, the blood glucose measurement 118 is shown as being stored in the storage device 120 of the CGM platform 112 as part of the CGM data 122. The storage device 120 can also represent one or more databases and other types of storage capable of storing the CGM data 122. The CGM data 122 also includes a user profile 124. According to the described techniques, the person 102 corresponds at least to a user of the CGM platform 112 and may be a user of one or more other third - party service providers. For this purpose, the person 102 may be associated with a username and may at some point be required to provide authentication information (e.g., password, biometric data, etc.) for accessing the CGM platform 112 using the username. This information may be captured in the user profile 124. The user profile 124 may also include various other information about the user, such as demographic information describing the person 102, information about healthcare providers, payment information, prescription information, determined health metrics, user preferences, account information for other service provider systems (e.g., service providers associated with wearable, social networking systems, etc.). The user profile 124 may include different information about the user within the spirit and scope of the described techniques.

[0033] Furthermore, the CGM data 122 represents not only the data of the user corresponding to the person 102, but also the data of other users in the user population 110. Considering this, the blood glucose measurement values 118 in the memory device 120 include the blood glucose measurement values from the CGM sensor of the CGM system 104 worn by the person 102, and also include the blood glucose measurement values from the CGM sensors of the CGM systems worn by persons corresponding to other users in the user population 110. The blood glucose measurement values 118 of these other users are communicated to the CGM platform 112 by their respective devices via the network 116, and these other users will also each have a user profile 124 on the CGM platform 112.

[0034] The data analysis platform 126 represents the function of processing the CGM data 122 to generate various predictions, such as by using various machine learning models. Based on these predictions, the CGM platform 112 may provide proposals and / or other information regarding the predictions. For example, the CGM platform 112 may provide the proposals or other information directly to the user, to a medical professional associated with the user, etc. Specific types of predictions, proposals, and other information will be described in detail below. Although depicted separately from the computing device 108, part or all of the data analysis platform 126 may alternatively or additionally be implemented in the computing device 108. The data analysis platform 126 may also be configured to generate these predictions using data in addition to the blood glucose measurement values 118, for example, additional data obtained via the IoT 114.

[0035] It should be understood that IoT 114 represents various sources that can provide data describing the activities of person 102 as well as the activities of person 102 as a user of one or more service providers and real-world activities. By way of example, IoT 114 may include various devices of the user, such as, for example, cameras, mobile phones, laptops, etc. For this purpose, IoT 114 may provide information regarding the interaction of the user with various devices, such as, for example, interaction with web-based applications, photographed photos, communication with other users, etc. IoT 114 may also include various real-world articles (such as shoes, clothing, sports equipment, electrical appliances, automobiles, etc.) composed of sensors that provide information describing behavior, such as, for example, the number of steps, the force of the foot hitting the ground, the stride, 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 taken out of the refrigerator, driving habits, etc. IoT 114 may also include third parties, such as healthcare providers (such as the healthcare provider of person 102) and manufacturers (such as the manufacturer of CGM system 104, insulin delivery system 106, or computing device 108), that can each provide medical and manufacturing data that can be utilized by data analysis platform 126. Indeed, IoT 114 may include devices and sensors that can provide rich data in connection with CGM-based proposals without departing from the spirit or scope of the described techniques. Consider the following description of FIG. 2 in the context of continuously measuring blood glucose and obtaining data describing such measurements.

[0036] FIG. 2 depicts in more detail an exemplary implementation 200 of the CGM system 104 of FIG. 1. In particular, the illustrated example 200 includes a top view and a corresponding side view of the CGM system 104.

[0037] The CGM system 104 is illustrated as including the sensor 202 and the sensor module 204. In the illustrated example 200, the sensor 202 is depicted in a side view and is, for example, subcutaneously inserted into the skin 206 of the person 102. The sensor module 204 is depicted as a dashed rectangle in a top view. The CGM system 104 also includes the transmitter 208 in the illustrated example 200. The use of the dashed rectangle for the sensor module 204 indicates that it can be housed or otherwise implemented within the housing of the transmitter 208. In this example 200, the CGM system 104 further includes the adhesive pad 210 and the attachment mechanism 212.

[0038] During operation, the sensor 202, the adhesive pad 210, and the attachment mechanism 212 may be assembled to form an application assembly, which is configured to be applied to the skin 206 such that the sensor 202 is subcutaneously inserted as depicted. In such a scenario, the transmitter 208 may be attached to the assembly via the attachment mechanism 212 after being applied to the skin 206. Additionally or alternatively, the transmitter 208 may be incorporated as part of the application assembly, and the sensor 202, the adhesive pad 210, the attachment mechanism 212, and the transmitter 208 (with the sensor module 204) may all be applied to the skin 206 at once. In one or more implementations, this application assembly is applied to the skin 206 using a separate applicator (not shown). This application assembly can also be removed by peeling the adhesive pad 210 from the skin 206. The illustrated CGM system 104 and its various components are merely an example of a form factor, and it will be understood that the CGM system 104 and its components may have different form factors without departing from the spirit or scope of the described techniques.

[0039] During operation, sensor 202 is communicatively coupled to sensor module 204 via at least one communication channel that 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 implemented actively or passively, and these communications can be continuous (e.g., analog) or discrete (e.g., digital).

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

[0041] In another example, sensor 202 (or an additional sensor (not shown) of CGM system 104) can include a first and a second conductor, and sensor module 204 can electrically detect a change in potential between the first and second conductors of sensor 202. In this example, sensor module 204 and sensor 202 are configured as a thermocouple such that the change in potential corresponds to a change in temperature. In some examples, sensor module 204 and sensor 202 are configured to detect a single analyte, such as blood glucose. In other examples, sensor module 204 and sensor 202 are configured to detect multiple analytes, such as sodium, potassium, carbon dioxide, and blood glucose. Alternatively or additionally, CGM system 104 includes multiple sensors that detect not only one or more analytes (such as sodium, potassium, carbon dioxide, and blood glucose) but also one or more environmental conditions (such as temperature). Thus, sensor module 204 and sensor 202 (and any additional sensors) may detect the presence, absence, and / or change in one or more environmental conditions of one or more analytes.

[0042] In one or more implementations, the sensor module 204 may include a processor and a memory (not shown). The sensor module 204 may generate a blood glucose measurement value 118 based on communication with the sensor 202 indicating the changes described above by leveraging the processor. Based on these communications from the sensor 202, the sensor module 204 is further configured to generate CGM device data 214. The CGM device data 214 is a package of communicable data that includes at least one blood glucose measurement value 118. Alternatively or additionally, the CGM device data 214 includes other data such as, for example, a plurality of blood glucose measurement values 118, a sensor identification 216, a sensor status 218, and the like. In one or more implementations, the CGM device data 214 may include other information such as one or more of a temperature corresponding to the blood glucose measurement value 118 and measurement values of other analytes. It should be understood that the CGM device data 214 may include various data in addition to at least one blood glucose measurement value 118 without departing from the spirit or scope of the described techniques.

[0043] During operation, the transmitter 208 may wirelessly transmit the CGM device data 214 to the computing device 108 as a stream of data. Alternatively or additionally, the sensor module 204 may buffer the CGM device data 214 (e.g., in the memory of the sensor module 204) and cause the transmitter 208 to transmit the buffered CGM device data 214 at various intervals, such as time intervals (per second, every 30 seconds, every minute, every hour, etc.), storage intervals (when the buffered CGM device data 214 reaches a threshold amount of data or a number of instances of the CGM device data 214), and the like.

[0044] In addition to generating CGM device data 214 and communicating it to computing device 108, sensor module 204 may include additional functionality according to the described techniques. This additional functionality may include generating a prediction of a future person 102's blood glucose level and communicating a notification based on the prediction, such as by communicating a warning when the prediction indicates that the person 102's blood glucose level is likely to become dangerously low in the near future. This computational ability of sensor module 204 can be advantageous particularly when connectivity to services via network 116 is limited or non-existent. In this way, a warning can be received about a dangerous condition, for example, without relying on connectivity to the Internet. This additional functionality of sensor module 204 may also include initially or continuously calibrating sensor 202 and calibrating any other sensors of CGM system 104.

[0045] Regarding CGM device data 214, sensor identification 216 represents information that uniquely identifies sensor 202 from other sensors, such as other sensors of other CGM systems 104, other sensors previously or subsequently implanted in skin 206, etc. By uniquely identifying sensor 202, sensor identification 216 may also be used to identify other aspects regarding sensor 202, such as the manufacturing lot of sensor 202, details of the packaging of sensor 202, details of the shipment of sensor 202, etc. In this way, it may be used in different ways to identify various problems detected with sensors manufactured, packaged, and / or shipped in a similar manner as sensor 202, such as to calibrate blood glucose measurements 118, notify the user to change or discard defective sensors, or notify the manufacturing facility of machining problems.

[0046] The sensor status 218 represents the state of the sensor 202 at a given point in time, e.g., the state of the sensor at the same time when one of the blood glucose measurements 118 is generated. For this purpose, the sensor status 218 may include an entry for each of the blood glucose measurements 118, such that there is a one-to-one relationship between the blood glucose measurements 118 and the status captured in the sensor status 218 information. Generally speaking, the sensor status 218 describes the operating state of the sensor 202. In one or more implementations, the sensor module 204 may identify one of several predetermined operating states for a given blood glucose measurement 118. The identified operating state may be based on the communication from the sensor 202 and / or the characteristics of those communications.

[0047] As an example, the sensor module 204 may include (e.g., in memory or other storage) a lookup table having a predetermined number of operating states and bases for selecting one state from another. For example, the predetermined state may include a "normal" operating state, and the basis for selecting this state is that the communication from the sensor 202 falls within a threshold indicating normal operation, e.g., within a threshold of expected time, a threshold of expected signal strength, a threshold of temperature suitable for the environment to continue operating as expected, etc. The predetermined state may also include an operating state indicating that one or more characteristics of the communication of the sensor 202 are outside the range of normal activity and may result in a potential error in the blood glucose measurement 118.

[0048] For example, the bases for these non-normal operating states may include receiving communication from the sensor 202 outside the threshold expected time, detecting the signal strength of the sensor 202 outside the threshold of expected signal strength, detecting the environmental temperature outside the suitable temperature for continuing operation as expected, detecting that the person 102 has rolled on the CGM system 104 (e.g., is in bed), etc. The sensor status 218 may indicate various aspects regarding the sensor 202 and the CGM system 104 without departing from the spirit or scope of the described techniques.

[0049] Having considered the exemplary environment and the exemplary CGM system, next, some exemplary details of techniques for proposals based on CGM in a digital media environment according to one or more implementations will be considered.

[0050] Proposals Based on CGM FIG. 3 depicts an exemplary implementation 300 in which CGM device data including blood glucose measurement values is routed to different systems to enable the provision of CGM-related services.

[0051] The illustrated example 300 includes, from FIG. 1, examples of the CGM system 104 and the computing device 108. The illustrated example 300 also includes a data analysis platform 126 and a storage device 120, which store CGM data 122 including blood glucose measurement values 118 as discussed above. In this example 300, the CGM system 104 is depicted as sending CGM device data 214 to the computing device 108. As discussed above in connection with FIG. 2, the CGM device data 214 includes blood glucose measurement values 118 along with other data. The CGM system 104 may send the CGM device data 214 to the computing device 108 in various ways.

[0052] The illustrated example 300 also includes a CGM package 302, which includes CGM device data 214 and supplementary data 304. In this example 300, the CGM package 302 is depicted as being routed from the computing device 108 to the storage device 120 of the CGM platform 112. Generally speaking, the computing device 108 generates supplementary data 304 based at least in part on the CGM device data 214, packages this data together into the CGM package 302, and includes functionality to communicate the CGM package 302 to the CGM platform 112 for storage in the storage device 120, e.g., via the network 116.

[0053] Regarding supplemental data 304, the computing device 108 may generate various supplemental data to supplement the CGM device data 214. According to the described techniques, the supplemental data 304 may describe one or more aspects of the user's context so as to be able to identify the correspondence between the user's context and the CGM device data 214 (e.g., the blood glucose measurement value 118). As an example, the supplemental data 304 may describe the user's interaction with the computing device 108, for example, including data extracted from an application log that describes the interaction of a specific application (e.g., selections made, actions performed). The supplemental data 304 may also include clickstream data that describes clicks, taps, and presses performed in relation to the input / output interface of the computing device 108. As another example, the supplemental data 304 may include fixation data that describes where the user is looking (e.g., with respect to a display device associated with the computing device 108, or when the user has looked away from the device), audio data that describes audible commands and other spoken phrases of the user or other users (e.g., including passively listening to the user), device data that describes the device (e.g., manufacture, model, operating system and version, camera type, applications being executed by the computing device 108), and the like. The supplemental data 304 may also describe other aspects of the user's context, such as the user's location, the temperature at that location (e.g., outdoors, using a temperature sensing functionality in proximity to the user), the weather at that location, the user's altitude, barometric pressure, environmental aspects such as context information obtained in relation to the user via IoT 114 (e.g., food the user is eating, the manner in which the user is using sports equipment, clothing the user is wearing), and the like. The supplemental data 304 may also describe health-related aspects detected regarding the user, such as, for example, the number of steps, heart rate, sweating, the user's temperature (e.g., detected by the computing device 108). To the extent that the computing device 108 may include functionality to detect or otherwise measure some of the same aspects as the CGM system 104, the data from these two sources may be compared, for example, for accuracy, fault detection, and the like.The supplemental data 304 of the type described above is merely an example, and the supplemental data 304 may include more, less, or different types of data without departing from the spirit or scope of the technology described herein.

[0054] Regardless of how robustly the supplemental data 304 describes the user's context, the computing device 108 may communicate the CGM package 302 to the CGM platform 112 for processing at various intervals. In one or more implementations, the computing device 108 may stream the CGM package 302 to the CGM platform 112 substantially in real time, for example, because the CGM system 104 continuously provides CGM device data 214 to the computing device 108. The computing device 108 may alternatively or additionally communicate one or more of the CGM packages 302 to the CGM platform 112 at predetermined intervals, such as every second, every 30 seconds, every hour, etc.

[0055] Although not depicted in the illustrated example 300, the CGM platform 112 may process these CGM packages 302 and store at least a portion of the CGM device data 214 and the supplemental data 304 in the storage device 120. As described in more detail below, from the storage device 120, this data may be provided to or otherwise accessed by the data analysis platform 126, for example, to generate various predictions and provide recommendations. Alternatively or additionally, the data may be provided to a third party 306, such as a third party service provider. In this way, the third party service provider may be able to provide various services that use the blood glucose measurements 118 without having to manufacture and deploy its own CGM system.

[0056] In the illustrated example 300, a blood glucose measurement value 118 is depicted as being communicated from the memory device 120 of the CGM platform 112 via the network 116 to the memory device 308 (or other type of storage) of the third party 306. In particular, the blood glucose measurement value 118 is depicted as being communicated via the CGM platform application programming interface (API) 310. In this type of scenario, the CGM platform API 310 may be considered an “output” of data such as the blood glucose measurement value 118. By “output,” it is meant that the flow of data is generally outbound from the CGM platform 112 to the third party 306.

[0057] In one or more implementations, the CGM platform 112 provides access to data from the memory device 120 via the CGM platform API 310. In the context of data provision, the CGM platform API 310 may expose one or more “calls” (e.g., a specific format for a data request) to the third party 306. As an example, the CGM platform API 310 may expose calls to the third party 306 after, for example, the third party 306 has agreed to a business corresponding to the CGM platform 112, whereby the third party 306 can obtain data from the memory device 120 via the CGM platform API 310. As part of this agreement, the third party 306 may agree to exchange payment to obtain data from the CGM platform 112. Alternatively or additionally, the third party 306 may agree to exchange data that it generates, for example, via an associated device, to obtain data from the CGM platform 112. Parties that enter into an agreement to obtain data (e.g., the blood glucose measurement value 118) from the CGM platform 112 via the CGM platform API 310 may be referred to as “data partners.”

[0058] Broadly speaking, the CGM platform API 310 enables a third party 306 to request data (e.g., a blood glucose measurement of 118) in a specific request format, and when the request is made in the specific format, the CGM platform API 310 provides the requested data in a specific response format. In other words, the CGM platform API 310 is configured to receive a request for a blood glucose measurement of 118 in a specific request format from a third party 306, obtain the requested blood glucose measurement of 118 from the memory device 120, and provide the requested blood glucose measurement of 118 to the third party 306 in a formatted response. The CGM platform API 310 may expose calls that enable a third party 306 to request blood glucose measurements of 118 for one or more periods (e.g., the past 10 days), blood glucose measurements of 118 for a specific user or segment of users, or blood glucose measurements of 118 over a specific period (e.g., the past 10 days) for a number of users (e.g., 10,000 users). The CGM platform 310 may also expose various calls that enable a third party to request blood glucose measurements of 118 that meet certain criteria in various ways without departing from the spirit or scope of the described techniques. In operation, the CGM platform API 310 may limit which data different third parties can access according to the corresponding agreed-upon conditions, such as, for example, limiting how frequently a blood glucose measurement of 118 can be obtained or introducing a latency in providing the blood glucose measurement of 118 after the blood glucose measurement has been obtained from the CGM system 104 and the computing device 108, etc.

[0059] When the third party 306 obtains the blood glucose measurement value 118, the third party 306 may generate one or more third party proposals 312 based on the obtained blood glucose measurement value 118. As an example, the third party 306 may provide a lifestyle application to the user and use the blood glucose measurement value 118 to provide third party proposals 312 related to one or more lifestyle behaviors tracked through such an application, such as proposals to increase exercise, proposals to decrease exercise, proposals to continue a predetermined behavior (e.g., number of steps, eating a specific food, sleeping), proposals to reduce or eliminate a specific behavior (e.g., eating a specific food, drinking alcohol, sleeping), etc. Examples of lifestyle applications may include exercise applications, health measurement applications, food tracking applications, sports-specific applications, and the like.

[0060] As described above, third party 306 may generate its own additional data, such as via a device that the third party 306 manufactures and / or deploys, e.g., a wearable device. In view of this, third party 306 may generate third party proposal 312 based not only on blood glucose measurement value 118 but also on additional data generated by third party 306. For example, third party 306 may provide the acquired blood glucose measurement value 118 and this additional data as inputs to one or more machine learning models trained using past blood glucose measurement values 118 and past additional data. In response to this input, third party 306 obtains, as an output, at least one prediction generated by one or more models. Third party 306 may use such a prediction as the basis for third party proposal 312. Third party proposal 312 is output and shown by third party 306. This represents that third party 306 may deliver third party proposal 312 to computing device 108 or another computing device, e.g., a computing device of user population 110, via network 116 by communicating it thereto. Third party proposal 312 may then be output by the receiving computing device, e.g., by displaying the proposal, outputting the proposal as audio, etc.

[0061] Illustrated example 300 also includes third party data 314 communicated from a third party to data analysis platform 126. As described above, third party 306 may manufacture and / or deploy associated devices. Additionally or alternatively, third party 306 may obtain data via other sources such as corresponding applications. Thus, this data may include user input data entered via corresponding third party applications, such as social networking applications, lifestyle applications, etc. In view of this, data generated by third party 306 may be configured in various ways, including dedicated data structures, text files, images obtained via a user's mobile device, formats indicating text entered into public fields or dialog boxes, formats indicating option selections, etc. Third party data 314 may describe various aspects related to one or more services provided by the third party without departing from the spirit or scope of the described techniques. Third party data 314 may include, for example, application interaction data that describes the use or interaction of a user with a particular application provided by third party 306. Generally, application interaction data enables data analysis platform 126 to determine the use or usage of a particular application by users of user population 110. Such data may include, for example, data extracted from an application log that describes a user's interaction with a particular application, clickstream data that describes clicks, taps, and presses executed in relation to an application's input / output interface, etc. Thus, in one or more implementations, data analysis platform 126 may receive third party data 314 generated or otherwise obtained by third party 306.

[0062] In illustrated example 300, third-party data 314 is depicted as being communicated via CGM platform API 310. In this type of scenario, CGM platform API 310 may be considered the “ingress” of third-party data 314. By “ingress,” it is meant that the data flow is generally inward from third party 306 to CGM platform 112. CGM platform API 310 is shown as supporting both output and input data flows, but in one or more implementations, the functionality enabling data output from CGM platform 112 and data input to CGM platform 112 may be handled by different APIs. For example, the input functionality may be handled by an API corresponding to third party 306 rather than an API of CGM platform 112. In any case, in addition to the data of CGM platform 112 (blood glucose measurements 118 and supplemental data 304), data analysis platform 126 may utilize third-party data 314 in one or more scenarios.

[0063] Data analysis platform 126 is shown as including prediction system 316. According to the described system, prediction system 316 is configured to generate a prediction 318 based at least on blood glucose measurements 118. In one or more implementations, for example, prediction system 316 may generate prediction 318 based on both blood glucose measurements 118 and additional data, where the additional data may include one or more portions such as CGM device data 214, supplemental data 304, third-party data 314, data from IoT 114, etc. in addition to blood glucose measurements 118. As will be described below, prediction system 316 may generate such a prediction 318 by using one or more machine learning models. These models may be trained or otherwise constructed using blood glucose measurements 118 and additional data obtained from user population 110.

[0064] In one or more implementations, prediction 318 may correspond to or otherwise include a health metric. As used herein, the term "health metric" may refer to a predicted health state that can be "negative" or "positive". Examples of negative health states include, for example, but are not limited to, prediabetes, type I diabetes, type II diabetes, neuropathy, Alzheimer's disease, and heart disease. In contrast, examples of "positive" health states may include the risk of developing a negative health state or a positive health state related to body fat, cardiovascular fitness, etc. In some cases, the health metric may refer to a predicted medical condition such as a predicted A1C. In particular, prediction 318 is based on the blood glucose measurements 118 and additional data collected over a particular period of time. Thus, in some cases, prediction 318 predicts that the user currently has the predicted health state based on the aggregated data. Alternatively, the predicted health state may correspond to a period of time that occurs after the particular period during which the aggregated data was collected (e.g., a prediction of type II diabetes within 40 months). Some additional types of predictions, and the particular types of information used to generate these predictions, are described in further detail below.

[0065] Based on the generated prediction 318, the data analysis platform 126 generates a proposal 320. The proposal 320 may, for example, instruct the user to perform an action (e.g., download an application to the computing device 108, rush to the hospital immediately, administer insulin, go for a walk, consume a particular food or beverage), continue a behavior (e.g., continue to eat in a particular way, or exercise in a particular way), change a behavior (e.g., change eating habits or exercise habits), and so on. In such scenarios, the prediction 318 and / or the proposal 320 are communicated from the data analysis platform 126 and output via the computing device 108. In the illustrated example 300, the prediction 318 is also communicated to and illustrated on the computing device 108. It should be understood that either or both of the prediction 318 and the proposal 320 may be communicated to the computing device 108. Additionally or alternatively, the prediction 318 and / or the proposal 320 may be routed to a decision support platform and / or a verification platform, for example, before the prediction and / or the proposal are permitted to be delivered to the computing device 108. Consider the following description of FIG. 4 in the context of generating one or more predictions that may function as the basis for the proposal 320.

[0066] FIG. 4 depicts an exemplary implementation 400 of the data analysis platform 126 in more detail. As in FIG. 3, the data analysis platform 126 includes a prediction system 316.

[0067] In the illustrated example 400, the prediction system 316 includes a model manager 402 that manages a statistical model 406 and an additional machine learning model 408, such as a model 404 that includes a neural network. It will be understood that the model 404 may include different models, such as a plurality of different statistical models, a plurality of machine learning models configured as neural networks, and / or a plurality of other types of machine learning models, without departing from the spirit or scope of the described techniques. These different machine learning models may be constructed or trained (or the models may be learned in other ways) using different data, having different architectures, and following different algorithms according to different statistical modeling techniques. Thus, it will be understood that the following description of the functionality of the model manager 402 is applicable to various machine learning models. However, for purposes of illustration, the functionality of the model manager 402 will be generally described in relation to the statistical model 406 and the additional machine learning model 408.

[0068] Generally, the model manager 402 is configured to manage the model 404. This model management includes, for example, constructing the statistical model 406, constructing the machine learning model 408, training the machine learning model 408, updating these models, and the like. Specifically, the model manager 402 is configured to perform this model management using at least in part the rich data maintained in the storage device 120 of the CGM platform 112. As illustrated, this data includes the blood glucose measurements 118 of the user population 110 and additional data 410. Stated another way, the model manager 402 constructs the statistical model 406, constructs the machine learning model 408, trains the machine learning model 408 (or otherwise learns the policies deployed thereby), and updates these models using the blood glucose measurements 118 of the user population 110 and the additional data 410.

[0069] Generally, the CGM platform 112 obtains additional data 410 of the user population from various devices, sensors, applications, or services. Thus, the additional data may be obtained from one or more "sources" different from the CGM system 104 where the blood glucose measurement value 118 is detected. In one or more implementations, this additional data 410 may include at least one or more portions of the CGM device data 214, supplementary data 304, third-party data 314, data from IoT 114, etc., in addition to the blood glucose measurement value 118 (e.g., sensor identification 216 and sensor status 218 data).

[0070] The additional data 410 may include, by way of example and not limitation, health-related data, application interaction data, environmental data, demographic data, blood glucose measurements, in addition to device data (e.g., sensor identification data, incident reports), supplementary data added by a computing device, third-party data, and the like. Health-related data may include, among other examples, activity data (e.g., step count, exercise frequency, sleep data), biometric measurement data (e.g., insulin level, ketone level, heart rate, temperature, stress, temperature), nutritional data (e.g., diet logs, scanned restaurant receipts, carbohydrate consumption, fasting), medical records (such as A1C, cholesterol, electrocardiogram results, data related to other medical tests or medical history). Application interaction data may include data extracted from application logs that describe user interactions with a particular application, clickstream data that describes clicks, taps, and presses executed in relation to the input / output interface of a computing device, gaze data that describes where the user is looking (e.g., in relation to a display device associated with the computing device, or when the user is looking away from the device), voice data that describes audible commands and other spoken phrases of the user or other users (e.g., including when the user is passively listening). Environmental data may include, for example, data that describes various environmental aspects associated with the user, such as the user's location, the temperature and / or weather at the user's location, the user's altitude, barometric pressure, and the like. Demographic data may include, for example, data that describes the user, such as age, gender, height, weight, and the like. The types of additional data described above are merely examples, and the additional data may include more, fewer, or different types of data without departing from the spirit or scope of the techniques described herein.

[0071] Unlike conventional systems, the CGM platform 112 stores (e.g., in the memory device 120) or otherwise has access to the blood glucose measurements 118 obtained using the CGM system 104 for hundreds of thousands of users (e.g., 500,000 or more) in the user population 110. Further, these measurements are taken at a continuous rate by the sensors of the CGM system 104. As a result, the blood glucose measurements 118 are available to the model manager 402 for millions or even billions of model building and training instances. With such a robust amount of data, the model manager 402 can build and train the model 404 to accurately mimic the actual impact of various behaviors on blood glucose levels. Without the robustness of the blood glucose measurements 118 of the CGM platform 112, conventional systems simply cannot build or train a model to cover the state space in a manner that adequately represents how various behaviors affect blood glucose values. Failure to adequately cover these state spaces can result in inaccurate blood glucose predictions or predictions of other health metrics, potentially leading to dangerous actions or behaviors that can cause death. Given the importance of generating accurate predictions, it is important to build the model 404 using a robust amount of blood glucose measurements 118 for rare events.

[0072] In one or more implementations, the model manager 402 constructs the statistical model 406 by extracting observations corresponding to at least one attribute from the blood glucose measurement value 118 and the additional data 410. Once constructed, the statistical model 406 is configured to predict and output the values of this at least one attribute, and the values of the at least one attribute do not function as inputs to the model. For example, in a scenario where the statistical model 406 is a regression model, these values may correspond to one or more dependent variables of the statistical model 406. The values of these attributes (corresponding to the dependent variables of the statistical model 406) may be referred to as a first set of values in the following description. Also, the model manager 402 extracts observations corresponding to at least one other attribute from the blood glucose measurement value 118 and the additional data 410. Once constructed, the values of this at least one other attribute function as inputs to the statistical model 406, for example, as a vector of such values. In a scenario where the statistical model 406 is a regression model, the at least one other attribute may correspond to one or more explanatory (or independent) variables. The extracted values of these independent variables may be referred to as a second set of values in the following description.

[0073] Considering the first set of values and the second set of values, the model manager 402 is adapted to generate the first set of values from the second set of values within some tolerance using one or more known approaches for "fitting" these values to an equation. Examples of such fitting approaches include using a least squares approach, using least absolute deviation regression, minimizing a penalized version of the least squares cost function (such as ridge regression or lasso), and the like. By "fitting", it is meant that the model manager 402 uses one or more approaches and these data sets to estimate the model parameters of the equation. The parameters to be estimated include, for example, the weights applied to the values of the independent variables when values are input to the statistical model 406 during operation. The model manager 402 incorporates these parameters estimated from the observed values into the equation to generate the statistical model 406. During operation, the prediction system 316 inputs the values of the independent variables to the statistical model 406 (e.g., as one or more vectors or matrices), and the statistical model 406 applies the estimated weights to these input values and then outputs values for one or more dependent variables. This output is represented as the prediction 318.

[0074] In one statistical model building scenario, the model manager 402 uses the blood glucose measurements 118 of the user population 110 having timestamps before a specific timestamp, and also uses the corresponding additional data 410 (e.g., having timestamps corresponding to the blood glucose measurements 118 and associated with the users corresponding to the blood glucose measurements) as the values of the independent variables for the statistical model 406. In this scenario, the model manager 402 may use the blood glucose measurements 118 of the user population 110 having timestamps after the specific timestamp as the values of the dependent variables of the statistical model 406. Here, the model manager 402 uses one or more known approaches to fit an equation to the data before and after the timestamp. By doing so, the model manager 402 estimates the parameters of the equation such that, by inputting the data values before the timestamp, blood glucose measurements 118 after the timestamp (or values within some tolerance of those measurements) are output.

[0075] The model manager 402 then incorporates the estimated parameters into the equation and persists this incorporation as the statistical model 406 such that the statistical model 406 holds the estimated parameters along with the equation. In this way, the model manager 402 constructs a statistical model 406 capable of generating a prediction 318 of the blood glucose measurements after a specific time when receiving input blood glucose measurements and corresponding additional data before the specific time. Thus, during operation and continuing in this scenario, the prediction system 316 may obtain a subset of the blood glucose measurements 118 of the person 102 before a specific time (e.g., the current time) along with the additional data 410 of the person 102 corresponding to the independent variables used to train the statistical model 406. The prediction system 316 may then provide this data of the person 102 as input to the statistical model 406. In the continuing scenario, the statistical model 406 generates a prediction 318 as the blood glucose measurements of the person 102 after a specific time, e.g., the current time.

[0076] The prediction of blood glucose measurement values after a specific time (e.g., the current time) is described in connection with constructing and actually using the statistical model 406. However, the model manager 402 may construct a statistical model 406 that predicts in a manner different from the patterns in the observed blood glucose measurement values 118 and the additional data 410. As an example, the model manager 402 may construct a statistical model 406 that predicts an upward or downward trend in the health metrics of person 102, such as by maintaining the health metrics of person 102 over a period of time. That is, the blood glucose measurement values 118 and the additional data 410 of the user population 110 are used to construct a model that maintains the correlation with these health metrics and the trends among the user population 110.

[0077] Returning now to the description of the additional machine learning model 408 (configured, for example, as a neural network) according to the described techniques. In a manner similar to the statistical model 406, the model manager 402 extracts a first set of observed values corresponding to at least one attribute and a second set of values corresponding to at least one other attribute, i.e., both sets extracted from the blood glucose measurement values 118 and the additional data 410 of the user population 110. The model manager 402 uses these sets of values to train the machine learning model 408 or to provide feedback to the machine learning model 408 regarding its predictions so that it learns a policy for generating predictions.

[0078] Also, similar to the statistical model 406, when an additional machine learning model 408 is trained or at least an initial policy for deployment is learned, the machine learning model 408 is configured to predict the values of at least one attribute corresponding to the first set and output those values. Further, when the machine learning model 408 is trained or used to deploy at least the initial policy, it is configured to receive, as input, the values of at least one other attribute of the second set, for example, as a vector of such values. Thus, in a scenario where the machine learning model 408 is a neural network, for example, during operation, the machine learning model 408 may receive, as input, one or more vectors (e.g., feature vectors) representing the values of at least one other attribute. In such a scenario, during operation, the machine learning model 408 may also output one or more vectors (e.g., feature vectors) representing the values of at least one attribute.

[0079] In the context of training, the model manager 402 may train the machine learning model 408 by providing an instance of data from the second set of values as input to the machine learning model 408. In response, the machine learning model generates a prediction 318, for example, a prediction of the values of at least one attribute corresponding to the first set. The model manager 402 obtains this training prediction from the machine learning model 408 as output and compares the training prediction with the actually extracted first set of values corresponding to the instance of data input. As an example, the model manager 402 uses a cost function to compare the training prediction with the actually extracted values. Based on this comparison, the model manager 402 adjusts the internal weights of the machine learning model 408 so that when an instance of data is provided as future input, the machine learning model can substantially reproduce the actually extracted values.

[0080] An instance of the observation data is input into the machine learning model 408, a training prediction is received from the machine learning model 408, and the training prediction is compared with the expected output value (observed value) corresponding to the input instance (e.g., using a cost function), and based on these comparisons, the internal weights of the machine learning model 408 are adjusted. This process can be repeated using instances of the training data over hundreds, thousands, or even millions of times, i.e., for each iteration.

[0081] The model manager 402 may perform such iterations until the machine learning model 408 can generate predictions 318 that are consistent with and substantially match the expected output, e.g., substantially match the observed values of the first data set. The ability of a machine learning model to consistently generate predictions that substantially match the expected output is sometimes referred to as "convergence." In view of this, it can be said that the model manager 402 trains the machine learning model 408 until it "converges" to a solution. For example, the internal weights of the model are suitably adjusted by the iterations of the training so that the model generates predictions that substantially match the expected output.

[0082] It should be understood that this is only one additional example of the machine learning model 408 and how it is trained. In fact, machine learning models are constructed according to various paradigms (e.g., supervised learning, unsupervised learning, reinforcement learning, etc.) and may be trained using various approaches without departing from the spirit or scope of the described techniques. As an example, the machine learning model 408 may first be trained on the blood glucose measurement values 118 of the user population and the additional data 410, and then the training may be further updated using training instances from the blood glucose measurement values 118 and the additional data 410 of person 102 to further adjust various parameters of the machine learning model 408, for example.

[0083] Anyway, when the machine learning model 408 is trained using at least in part the blood glucose measurement values 118 and additional data 410 of the user population 110, the machine learning model 408 may be used during operation to generate a prediction 318 of the user corresponding to the person 102. Similar to the statistical model construction scenario and use described above, consider an example of an implementation form that utilizes the machine learning model 408 instead of utilizing the statistical model 406.

[0084] In this example of machine learning, the model manager 402 uses the blood glucose measurement values 118 of the user population 110 having a time stamp before a specific time stamp, and also uses the corresponding additional data 410 (for example, having a time stamp corresponding to the blood glucose measurement value 118 and associated with the user corresponding to the blood glucose measurement value) as training inputs to the machine learning model 408. In this scenario, the model manager 402 may use the blood glucose measurement values 118 of the user population 110 having a time stamp after the specific time stamp as the expected output (target or label) of the machine learning model 408. Here, the model manager 402 uses one or more known approaches to adjust the parameters of the model that predicts data after the time stamp given data before the time stamp as input. Examples of these approaches include supervised learning approaches such as the gradient descent method and the stochastic gradient descent method. However, other approaches may be used without departing from the spirit or scope of the described techniques.

[0085] By using these approaches, the model manager 402 adjusts the internal weights of the machine learning model 408 such that by inputting the data values before the timestamp, a post - timestamp blood glucose measurement value 118 (or a value within some tolerance of those measurements) is output. Further, the machine learning model 408 holds these internal weights, for example, in relation to specific nodes of the model. In this way, the model manager 402 constructs a machine learning model 408 capable of generating a prediction 318 of a blood glucose measurement value after a specific time when receiving an input blood glucose measurement value and corresponding additional data before that specific time.

[0086] Accordingly, during operation and continuing in this scenario, the prediction system 316 may obtain a subset of the blood glucose measurement values 118 of person 102 before a specific time (e.g., the current time), along with additional data 410 of person 102 corresponding to the input data used to train the machine learning model 408. The prediction system 316 may then provide this data of person 102 as input to the machine learning model 408. In the continuing scenario, the machine learning model 408 generates a prediction 318 as the blood glucose measurement value of person 102 after a specific time, e.g., the current time. In one or more implementations, the machine learning model 408 outputs this prediction in the form of a vector.

[0087] The prediction of blood glucose measurement values after a specific time (e.g., the current time) is described in relation to training and actually using the machine learning model 408. However, the model manager 402 may construct a machine learning model 408 that predicts in a manner different from the patterns in the observed blood glucose measurement values 118 and the additional data 410. As an example, the model manager 402 may construct a machine learning model 408 that predicts an upward or downward trend in the health metrics of person 102, such as maintaining the health metrics of person 102 over a period of time. That is, using the blood glucose measurement values 118 and the additional data 410 of the user population 110, a model is constructed that preserves the correlation between these health metrics and the trends among the user population 110. In part, because the machine learning model 408 is trained with a large amount of training data, the machine learning model 408 is capable of capturing potential features within the data, which may include hidden relationships and spurious correlations within the data, but it is virtually impossible for a human analyst to reveal the absences that occur randomly in the relationships.

[0088] Regardless of whether the statistical model 406, the additional machine learning model 408, or some combination (ensemble) of the statistical and / or additional machine learning models is used to generate the prediction 318, it can be obtained by the recommendation system 412. The recommendation system 412 is configured to generate a recommendation 320 based on the prediction 318. The recommendation system 412 may be implemented using or otherwise have access to the logic that constructs the recommendation 320 according to the prediction. As an example, if the prediction 318 indicates a good health trend for person 102 (e.g., her A1C is lower), the recommendation system 412 can generate a recommendation 320 that recommends continuing various actions.

[0089] The logic used by the proposal system 412 that generates proposal 320 may vary in complexity without departing from the spirit or scope of the described techniques, such as heuristics manually coded into one or more additional machine learning models for constructing a proposal based on receiving prediction 318 as input. Further implementation examples of the types of predictions and proposals that may be generated by model 404 and proposal system 412, respectively, are described in more detail below. Consider the following description of FIG. 5 related to a verification service and a decision-making support platform according to the described techniques.

[0090] FIG. 5 depicts an example implementation 500 in which at least one of the predictions or proposals generated by the data analysis platform is routed to at least one of the verification service or the decision-making support platform.

[0091] The illustrated example 500 includes a data analysis platform 126 having a computing device 108 and a prediction system 316. In this example 500, the data analysis platform is depicted as communicating a prediction 318 and a proposal 320. Here, the proposal 320 is related to a user of the computing device 108, e.g., person 102. By way of example, the prediction 318 includes information about a person (e.g., predicted blood glucose levels over the next period, predicted health trends over the next period, etc.), and the recommendation 320 includes one or more suggestions targeted at the user (e.g., one or more actions to perform or eliminate, behaviors to adopt or eliminate, etc.).

[0092] In contrast to illustration example 300 of FIG. 3, illustration example 500 includes a verification service 502 and a decision support platform 504 as mediators between the data analysis platform 126 and the computing device 108. Thus, prediction 318 and / or proposal 320 may be routed to one or both of the verification service 502 or the decision support platform 504. Although the verification service 502 and the decision support platform 504 are not depicted in FIG. 3, it should be understood that predictions 318 and proposals 320 generated in the scenarios described in connection with FIG. 3 may also be routed through the verification service 502 and / or the decision support platform 504.

[0093] In accordance with the described techniques, the verification service 502 is configured to enable proposal 320. This means determining whether the proposal is valid (e.g., safe) and can communicate directly to the decision support platform 504 and / or the computing device 108. The verification service 502 may disclose proposal 320 to a user, such as a clinician, who is permitted by the verification service 502 as having the authority to enable proposals. By way of example, the verification service 502 may send proposal 320 to the clinician via email, provide proposal 320 through a clinician portal (e.g., whether or not the clinician can consider and enable multiple proposals), and provide a notification of proposal 320 on the screen of a mobile device. That is, to name just a few examples, it enables a clinician to approve, reject, or obtain additional information with just a gesture. The verification service 502 may surface the proposal to a user (e.g., a clinician) permitted to enable the proposal in various ways without departing from the spirit or scope of the techniques described herein.

[0094] In response to a proposal that has been enabled (e.g., by a clinician or by the logic of the validation service 502), the proposal may be further routed to the decision support platform 504 or directly to the computing device 108. When a proposal is not enabled (i.e., rejected), the proposal may not be further routed to the decision support platform 504 or to the computing device 108. Instead, the validation service 502 may modify the proposal (e.g., according to a clinician's input) and / or provide a notification to the data analysis platform 126 that the proposal was not enabled. In this scenario, the data analysis platform 126 may be able to add the indication that was not enabled as an input to the prediction system and initiate the generation of different predictions 318 and / or proposals 320.

[0095] In fact, the model 404 may be updated based on the enabling and non - enabling received from the validation service 502. In a scenario where the validation service 502 enables the proposal 320, such that the proposal 320 can be directly transferred to the computing device 108, the computing device 108 may output the proposal 320 via, for example, a display device, an audio device (e.g., speakers, headphones, earphones), tactile feedback, etc., as described above and below. Examples of how a proposal may be surfaced by the validation service 502 for a user (e.g., a clinician) permitted to enable the proposal are described in more detail below in connection with FIG. 10.

[0096] As described above, prediction 318 and / or proposal 320 may be communicated to decision support platform 504 by verification service 502, or alternatively, may bypass verification service 502 and be communicated directly from data analysis platform 126 to decision support platform 504. Decision support platform 504 is configured to provide assistance to users of one or more health states, e.g., users of CGM platform 112 for managing diabetes. In response to receiving proposal 320, e.g., decision support platform 504 may provide the proposal to a customer support specialist, e.g., via email, a support specialist portal, etc.

[0097] Based on proposal 320 and other information accessible regarding the corresponding user, a customer service specialist may determine how to assist the user. By way of example, the customer service specialist may call the user to provide voice assistance during a call, select one or more pre-configured messages (e.g., text messages, mobile phone notifications, email messages, etc.) to send to the user (e.g., via a support specialist portal), construct one or more messages to send to the user from pre-configured message components, simply forward proposal 320 to computing device 108, contact a clinician or other medical professional associated with the user, contact an emergency service, contact the user's caregiver or other guardian (such as a parent), etc. Decision support platform 504 may provide tools, content, and services for assisting in the management of the user's health state in various ways based on predictions 318 and proposals 320 without departing from the spirit or scope of the described techniques.

[0098] Since CGM system 104, as well as data collected from various sources, has been described as being used in blood glucose measurements to generate predictions related to a user's health and provide proposals, consider the following example implementations of CGM-based proposals.

[0099] Prediction and Proposal Generation Using Models FIG. 6 depicts an example 600 of a user interface of a CGM platform displayed on a computing device coupled to a CGM system.

[0100] The illustrated example 600 includes a CGM user interface 602 displayed by a computing device 108. In this example, the CGM interface 602 is depicted as displaying a prediction 604 along with a proposal 606. As described throughout, the prediction 604 is generated by a prediction system 316 and uses one or more models, such as a statistical model 406 or an additional machine learning model 408, to process the user's blood glucose measurements 118 and additional data 410 to predict the user's health metrics.

[0101] For the purposes of this example, assume that after receiving an A1C and fasting blood glucose test results indicating that the user has "prediabetes," which has a risk of developing type II diabetes in the near future, the CGM system 104 is used to begin measuring blood glucose levels. In consideration of this, the user begins wearing the CGM system 104 that automatically provides the blood glucose measurements 118 to the prediction system 316. The CGM platform 112 processes the blood glucose measurements 118 collected for the user and determines that the user's blood glucose is increasingly in the "high" range (e.g., >250 mg / dl).

[0102] Along with the blood glucose measurement value of 118, the prediction system 316 obtains the user's nutritional data, such as food and beverage purchase data provided by various third parties 306 (e.g., grocery stores, restaurants, liquor stores) and / or user-provided nutritional data (e.g., food logs, captured images of consumed food and beverages, scanned restaurant or grocery store receipts). This nutritional data indicates that the user consumes an average of 1 liter of soda per week, dines at a fast-food restaurant three times a week, drinks beer most weekends, and eats potato chips. The prediction system 316 may also make various inferences based on foods or beverages not consumed by the user. In this case, the prediction system 316 analyzes the nutritional data and determines that the user rarely purchases "whole foods" such as fruits, vegetables, or meat. Additionally, the prediction system 316 obtains the user's activity data, including step count data indicating that the user rarely walks more than 5,000 steps per day and does not exercise, and sleep data indicating that the user sleeps an average of only 5 hours per night.

[0103] The prediction system applies the model 404 to the blood glucose measurement value of 118 and the additional data 410, which in this example includes the user's nutritional data and activity data described above. Considering the increase in the user's blood glucose measurement, poor dietary choices, and lack of activity, the prediction system 316 generates a prediction 604 indicating that the user has a 76% chance of developing type II diabetes within 40 months.

[0104] Along with prediction 604, the CGM user interface 602 displays a proposal 606 generated by the proposed system 412 of the data analysis platform 126. The proposal 606 includes one or more actions or behaviors that the user can take to improve the user's predicted poor health state. In this case, the proposal 606 includes a proposal for a customized meal plan, a proposal for a customized exercise plan, and a proposal to obtain guidance that can help the user stay on track with the proposed nutrition and exercise plans. In FIG. 6, it is shown that the user selects a proposal for a customized exercise plan to obtain more detailed information regarding the proposed exercise plan.

[0105] Continuing with this example, assume that the user follows the actions and behaviors proposed by the prediction system 316, for example, by switching to a whole-food diet, using an online food log to track meals, walking 10,000 steps per day and tracking the steps with a smartwatch equipped with a pedometer, working out three times a week, and logging each workout in an online workout log. In this case, the prediction system 316 continuously collects the user's blood glucose measurements 118, nutrition data, and activity data, and determines that the user's improved nutrition choices and exercise frequency are correlated with a decrease in the user's average blood glucose measurement 118.

[0106] Based on the user's updated blood glucose measurement of 118 from the CGM sensor and additional data 410 indicating that the user is making better food choices (as indicated by the user's nutrition log) and exercising more frequently (as indicated by the step data and exercise log), the prediction system 316 generates an updated prediction, which is communicated to the computing device 108 for display as a notification 702, as shown in FIG. 7. In this example, the updated prediction of the notification 702 indicates that the likelihood that the user will develop type II diabetes within the next 40 months is "low". In particular, the updated prediction of the notification 702 provides good feedback to the user, which may further motivate the user to continue with a healthy diet and exercise. Conversely, if the updated prediction indicates a deteriorating health condition, the updated prediction may serve to motivate the user to get back on track.

[0107] Generation of similar user-oriented application proposals As described throughout, the CGM platform 112 utilizes one or more CGM platform APIs 310 to enable communication of blood glucose measurements 118 from the CGM platform 112 to various third parties 306, and communication of third party data 314 from third parties 306 to the CGM platform 112. As a result, applications and services provided by such third parties 306 that utilize blood glucose measurements 118 are becoming increasingly available and can often be downloaded via an “app store.” Once downloaded to a computing device 108, the user can permit a third party 306 to access the user's blood glucose measurements 118 via the API 310. By doing so, it becomes possible for third parties 306 to utilize blood glucose measurements 118 in a variety of different ways to improve the user's health. In this way, third parties 306 may be able to provide a variety of applications and services that use blood glucose measurements 118 without having to manufacture and deploy their own CGM systems. As the number of third party “apps” and services increases, it becomes increasingly difficult for the user population to find apps and services that will operate optimally for their individual situations.

[0108] The CGM platform 112 may include an “input” API 310 that enables the CGM platform 112 to receive third party data 314 from various third parties 306 (e.g., via a third party's third party server). Such third party data 314 may include application interaction data that describes user interactions with third party services or applications. Such data may include, for example, data extracted from application logs that describe a user's interactions with a particular application, clickstream data that describes clicks, taps, and presses executed in relation to an input / output interface of a computing device, and the like.

[0109] The CGM platform 112 can aggregate application interaction data, along with blood glucose measurements 118 and additional data, to determine whether a user's interaction with a particular application or service correlates with an improvement in the user's health. For example, based on the blood glucose measurements 118, the CGM platform 112 can objectively determine an improvement in the user's health state. The CGM platform 112 can consider various different factors based on the blood glucose measurements when determining whether the use of an application improves the user's health, including improvements in average blood glucose levels, time in range, mitigation of certain undesirable patterns, or any combination thereof. Additionally, the CGM platform 112 may provide various controls to account for differences in the blood glucose measurements 118, such as sensor utilization and calibration frequency. The CGM platform 112 may also consider data provided by a third party 306 when determining an improvement in the user's health. The CGM platform 112 can then correlate an improvement or decline in the user's health with the use of a particular application based on the application interaction data. For example, if the CGM platform 112 detects an improvement in the user's health state that coincides with frequent use of a particular application, the CGM platform 112 may determine that the particular application is correlated with the improvement. Based on the amount of data available to the CGM platform 112, a correlation between a particular application and an improvement in health state may be determined for a subset of users in the user population 110.

[0110] Next, the proposed system 412 can identify similar users with a health condition and generate proposals to similar users to utilize specific applications that have helped improve the health condition of a subset of similar users. To do so, the proposed system 412 predicts the probability of a similar improvement in health condition through the use of specific applications by other users in the user population, and can propose applications that are likely to improve the health of other target users. Proposals for such applications may target individual users similar to a subset of users having an improved health condition correlated with the use of a specific application. For example, if the use of a specific application correlates with an improvement in glycemia of a subset of users in the user population, the CGM platform 112 can propose the use of the specific application to similar users in the user population 110.

[0111] Identification of similar users may be based on at least one of demographics or observed patterns in the blood glucose measurements of the similar users. For example, similar users may be identified as having the same health condition, based in part on blood glucose measurement values 118 provided by the CGM system 104 worn by the user. The CGM platform 112 may first generate a user profile for a new user beginning to wear the CGM system 104, including demographic data such as age, gender, location, existing medical records, and the like. Since the CGM platform 112 collects blood glucose measurement values 118 and additional data 410 from the user, the CGM platform 112 refines the user's similarity score with other users. For example, a user who is a 22-year-old female with an average blood glucose of 162 mg / dL and who experiences a pattern of nocturnal hypoglycemic measurements may have a similarity score with other users having that age, gender, average blood glucose measurement, and pattern experience.

[0112] Next, to determine an application recommendation, the similarity score is combined with the success of previous applications of similar users. For example, if a user similar to the target user downloads and uses a particular application and then an improvement in glycemia is seen (e.g., as evidenced by a reduction in average blood glucose level and a reduction in nocturnal lows), the recommendation system 412 can be configured to generate a high recommendation score for the particular application for the target user. Conversely, if no such improvement is seen with other applications, these applications will have a lower recommendation score for the target user. The application recommendations can be communicated to the computing device 108 for output.

[0113] In the context of generating application recommendations, consider FIG. 8 depicting an example 800 of an addition to a user interface of a CGM platform that is displayed on a computing device coupled to a CGM system. The illustrated example 800 includes a CGM user interface 802 displayed by the computing device 108. In this example, the CGM user interface 802 is depicted as displaying a recommended application 804. As described throughout, the recommended application 804 may be determined by a recommendation system 412 that improves the health state of the target user based on the similarity to other users in a user population 110 whose health state has improved based on the use of at least one of the recommended applications 804 by the user. In this case, the recommended application 804 corresponds to various third-party applications. In FIG. 8, the user is depicted as selecting the application "Nutrition by Neha" to download the application to the user's smartphone.

[0114] In particular, the proposed system 412 can further enhance the application proposals when the target user downloads and uses the application, thus strengthening or negating previous proposals and leading to improvements in future subsequent proposals. For example, if the proposed system 412 obtains a blood glucose measurement value 118 from a similar user indicating a similar improvement in health status, this feedback positively reinforces the correlation between the improvement in the health status of a subset of users and the use of a particular application. Conversely, if the blood glucose measurement value 118 from a similar user does not indicate an improvement in the health status of the similar user (or indicates a deterioration in health status), this feedback negatively reinforces the correlation between the improvement in the health status of a subset of users and the use of a particular application.

[0115] With respect to FIG. 8, for example, when a user begins an interaction with the "Nutrition by Neha" application, application interaction data may be communicated to the CGM platform 112 via the API 310 and correlated with the user's blood glucose measurement value 118 and additional data. In this way, the CGM platform 112 may continuously update the model 404 used to propose applications based on the feedback received from the use of the application by the user population 110. In a configuration where the machine learning model 408 is updated based on the feedback, for example, the model may be configured as a reinforcement learning model. The updated model 404 is then used to generate improved application proposals.

[0116] Furthermore, if the CGM platform 112 detects that the use of a particular application is improving the user's health based on the updated blood glucose measurements 118, the CGM platform 112 may communicate a notification of the improvement to the computing device 108 for output. In FIG. 9, for example, a notification 902 is displayed by the computing device 108 indicating that the use of the "Nutrition by Neha" application has improved the user's neuropathy. This positive notification should be understood to potentially motivate the user to continue using the application.

[0117] Verification service FIG. 10 depicts an exemplary implementation 1000 of a user interface of a verification service through which an authorized user can interact to enable a proposal generated by the CGM platform.

[0118] In the illustrated example 1000, a display device 1002 is depicted that displays a user interface 1004 of the verification service 502. Broadly speaking, the interface elements of the user interface 1004 enable an authorized user to interact with those elements to enable or reject a proposal provided by the data analysis platform 126 and intended for delivery to a user, e.g., person 102. In response to receiving an input via a user interface element of the user interface 1004 that enables a proposal (e.g., proposal 320), the verification service 502 may route the proposal to the respective user's computing device 108. As described above, the verification service 502 may also route the proposal to the decision-making support platform 504. In response to receiving an input via a user interface element of the user interface 1004 that rejects the proposal, the verification service 502 does not communicate the proposal to the computing device 108. Instead, the verification service may communicate a notice indicating that the proposal has been rejected to the data analysis platform 126. Additionally or alternatively, an authorized user of the verification service 502 may modify the proposal and then transmit the modified proposal to the user's computing device 108. As described above, an authorized user permitted to enable a proposal provided by the data analysis platform 126 may include a clinician or other medical professional qualified to provide health guidance to a patient.

[0119] In the illustrated example 1000, the user interface 1004 displays stubs 1006 of proposals provided to the verification service 502 by the data analysis platform 126. These stubs 1006 are configured as interactive elements that a user can interact with to consider, enable, reject, and / or take some other course of action (e.g., modify) in relation to each proposal. Although proposal stubs are depicted in this example, other user interface elements may be used that enable an authorized user to consider, enable, reject, and / or take some other course of action (e.g., modify) in relation to each proposal without departing from the spirit or scope of the described techniques.

[0120] In this Example 1000, each of the stubs 1006 includes a display of a username or patient name, a prediction 318 on which each respective proposal 320 is based, and a display of the proposal 320. User 1008 is depicted as performing a gesture in relation to one of the stubs 1006 (in this case, a right-to-left swipe gesture), revealing additional interface elements that are selectable to either activate or reject each respective proposal 320. The elements for activating or rejecting each proposal may be presented as part of each stub without requiring an interaction such as a swipe gesture, or may be presented as part of a menu that is launched in response to some interaction on the stub (e.g., a right click with a mouse), among other ways. Although not shown, the stub 1006 may also be selectable to expose a proprietary user interface that outputs proposals including options for activating and rejecting proposals and other options, i.e., the entire prediction and the entire review for proposals, as well as multiple options for processing proposals.

[0121] Fault Detection and System Configuration Issues FIG. 11 depicts an exemplary implementation 1100 of a user interface that outputs information regarding faults and system configuration issues detected in relation to the use of a CGM platform.

[0122] In the illustrated example, a display device 1102 is depicted that displays a user interface 1104 for fault detection and system configuration services. In one or more implementations, the fault detection and system configuration services may be included as part of the CGM platform 112 or otherwise be accessible. Also, portions of the user interface 1102 may be provided and displayed to other entities via respective portals, such as manufacturers or service providers that each provide a device or service that can be used in connection with the CGM system 104. These devices may include one or more of a computing device 108, an insulin delivery system 106, numerous physiological marker measurement devices, various components of the CGM system 104, and the like.

[0123] The user interface 1104 displays stubs 1106 for a plurality of detected faults and system configuration problems. While various faults and problems are displayed on the user interface 1104, the faults and / or problems displayed to a given entity (e.g., a particular manufacturer or a regulatory agency such as the U.S. Food and Drug Administration (FDA)) may be restricted (e.g., faults or problems associated with a particular manufacturer's device, or information mandated by law for disclosure to the regulatory agency). In contrast, users permitted to the CGM platform 112 as employees or similar users (e.g., engineers, quality assurance, development partners, etc.) may have permission to view all faults and / or problems associated with the CGM platform 112.

[0124] In this example 1100, the stub 1106 includes stubs for events (e.g., malfunctions) reported by the CGM system 104 regarding, by way of example only, the sensor 202, the computing device 108, the insulin delivery system 106, the third party 306, that are communicatively coupled or otherwise related to the CGM platform 112. The stub 1106 also includes stubs related to problems that occur in connection with specific system configurations, including the CGM system 104 but different combinations of other devices, e.g., configurations having a specific computing device 108 (e.g., a specific manufacturer), a specific ensemble of computing devices 108 (e.g., a cellular phone corresponding to a first manufacturer and a smartwatch corresponding to a second manufacturer), a specific insulin delivery system (e.g., an insulin pen vs. an insulin pump, from different manufacturers), specific firmware and software versions, etc.

[0125] The stub 1106 also includes stubs carrying one or more measures of reliability, such as the reliability of data obtained by various components (e.g., manufacturing lots of the sensor 202), system configuration, user - related for various demographics, etc. In one or more implementations, the measure of reliability is a confidence interval. Additionally, the stub 1106 includes stubs indicating the use of platform features (e.g., functionality of an application corresponding to the CGM platform 112 and / or user interface elements). This information can be used by system developers to determine whether to continue development and / or provide support in connection with various features.

[0126] Regarding the stub that describes events reported by one or more devices, it is difficult, if not impossible, for developers corresponding to the CGM platform 112 to test all combinations of devices and applications of the CGM platform 112 that can be used in relation to the CGM system 104 before deployment, such as all combinations of mobile phones and smartwatch applications. Instead, those developers may limit testing to combinations of devices that are most likely to be used (e.g., the most popular mobile devices or insulin delivery system 106) and / or combinations proposed by content promoted by the CGM platform 112, such as via publications, web pages, packaging, emails, advertisements, etc. In this regard, developers may recognize and fix only a subset of issues regarding the tested combinations of devices, but do not recognize or fix issues regarding untested combinations.

[0127] By collecting and maintaining a vast amount of blood glucose measurements 118, CGM device data 214, and supplemental data 304 within the memory device 120, the data analysis platform 126 can train the model 404 and then utilize it to identify problems (e.g., malfunctions) with different combinations of devices used by the user population 110, such as problems observed in both tested and untested combinations during real-world use. In fact, the tested combinations of devices may not have been tested in all the various ways that the user population 110 in the real world actually uses them. Therefore, by using the model 404 to identify these problems, the data analysis platform 126 can notify the developers of the problems, and the developers can develop fixes for the problems and then deploy them, for example, as firmware or software updates, as updates to the model 404, etc.

[0128] Alternatively or additionally, the data analysis platform 126 may use the identification of these problems to adjust the prediction and recommendation of the combinations experiencing the problems. As an example, if the combination of devices used by a small subset (e.g., 1%) of the user population provides consistently (and predictably) lower blood glucose measurements 118 to the CGM platform 112 than the blood glucose measurements 118 provided by other combinations, this information can be used to update the real-time blood glucose measurements 118 presented to the user via the computing device 108.

[0129] This information can also be used for the model 404 to predict that users with a combination of devices will experience the same problems as the subset of the population. In particular, this information can be used to generate effective (e.g., safe) recommendations and provide them to these users. The data analysis platform 126 may use the ability to identify problems such as impairments related to different combinations of devices in various ways without departing from the spirit or scope of the described techniques.

[0130] In connection with stubs that describe the use of the functions of the platform, this information may be used to determine whether to continue development and / or provide support in connection with various functions, as described above. In one or more implementations, data analysis platform 126 may analyze data maintained in memory device 120 to determine the costs to a company corresponding to CGM platform 112 that support various functions of CGM platform 112, such as the various functionality provided by its CGM system 104 and applications. As part of this, data analysis platform 126 is configured to measure the variation, co-variation, and statistical dependencies between each functionality deployed by CGM platform 112, such as the functionality of CGM system 104 that measures the temperature of person 102, the functionality of the mobile phone application of CGM platform 112 that identifies occurrences likely to result in hypoglycemia at night, the functionality of the smartwatch application of CGM platform 112 for using tactile feedback (e.g., vibration) in connection with output notifications, etc.

[0131] In one or more implementations, the data analysis platform 126 determines variance and covariance by generating a matrix having dimensions corresponding to a predetermined number of users (e.g., 50,000 users) sampled from the user population 110 and a number of features (e.g., functionality) deployed by the CGM platform 112, or a number of features being considered for potential discontinuation of development or support. In the following description, the predetermined number of users is represented by term m, and the number of features is represented by term n. For this purpose, the data analysis platform 126 constructs an m×n matrix, where each cell of the matrix indicates whether the sampled user uses the corresponding feature. The data analysis platform 126 may determine that users use features in various ways, and the use may be defined differently for different features. For example, the data analysis platform 126 may determine that a user has used a feature if data from the storage device 120 indicates that the user has ever used the feature, has consumed more than a threshold amount of time with the feature or function active, has used the feature more than a threshold number of times, has been allowed (e.g., an allowance notification) to activate the feature, etc.

[0132] Using the m×n matrix, the data analysis platform 126 calculates a variance score for a given feature i as a function of the number of users a who "use" the given feature i from the number of sampled users m. In one example, the data analysis platform 126 calculates variance as follows.

Equation

[0133] Here, the term φ(i) represents a variance score. The data analysis platform 126 is also configured to calculate a co-variance score for a given feature i as a function of the number of users a using the given feature i and as a function of a second number of users b using another given feature j, from the sampled number of users m. The data analysis platform 126 is also configured to calculate a co-variance as a function of a third number of users c using the given feature i and another feature j simultaneously. In one example, the data analysis platform 126 calculates the co-variance score as follows. [Number]

[0134] Here, the term φ(i,j) represents a co-variance score and the term φ(j) represents a variance score of another given feature j.

[0135] The data analysis platform 126 measures the statistical independence between different features by constructing a contingency table for each pair of features such that each feature is paired with m - 1 features and a contingency table is generated for each pair. The data analysis platform 126 performs a known independence test on each table. In one or more implementations, the known independence test includes a chi-squared test of independence and its output is a P-value, e.g., the probability of observing a sample statistic as extreme as the test statistic. The data analysis platform 126 then compares the output (e.g., the P-value) of the known independence test for each table to a significance level threshold. If the output meets the significance level threshold, the data analysis platform identifies the pair of features as dependent features.

[0136] Next, data analysis platform 126 determines the cost of a given feature i as a function of the pairwise score φ(i,j) in addition to the variation φ(i) of the given feature, for other features that are statistically dependent on the given feature i. The data analysis platform 126 may then present these scores to an authorized user (e.g., an engineer, a marketing person, etc.) corresponding to the CGM platform 112, such as via a display through the user interface 1104 or some other interface. It should be understood that the cost of the features of the CGM platform 112 can also be determined in other ways.

[0137] Exemplary Procedure In this section, an exemplary procedure for a proposal based on continuous glucose monitoring (CGM) is described. Aspects of the procedure may be implemented in hardware, firmware, software, or a combination thereof. The procedure is shown as a set of blocks that specify operations to be performed by one or more devices and is not necessarily limited to the order shown for performing the operations by each block. In at least some implementations, the procedure is performed by a data analysis platform, such as the data analysis platform 126 of the CGM platform 112 that utilizes the prediction system 316 and the proposal system 412.

[0138] FIG. 12 depicts an exemplary procedure 1200 in which predictions and proposals are generated based on both a user's glucose measurements and additional data.

[0139] The blood glucose measurement values provided by the CGM system worn by the user are obtained (block 1202). As an example, the CGM platform 112 obtains the blood glucose measurement value 118 detected by the CGM system 104 worn by the person 102. As described throughout, the CGM system 104 is configured to continuously monitor the blood glucose of the person 102. For example, the CGM system 104 may be composed of a sensor 202 subcutaneously inserted into the skin 206 of the person 102, and continuously measures an analyte indicating the blood glucose of the person 102 to generate a blood glucose measurement value. In one or more implementations, the CGM platform 112 obtains the blood glucose measurement value 118 from a computing device 108 communicatively coupled to the CGM system 104, such as the user's mobile phone or wearable device.

[0140] Additional data associated with the user is obtained (block 1204). As an example, the CGM platform 112 obtains additional data 410 from various devices, sensors, applications, or services. Thus, in accordance with the principles described herein, the additional data may be obtained from one or more "sources" different from the CGM system 104 that provides the blood glucose measurement value 118. The additional data 410 may include at least one or more portions of the CGM device data 214, supplementary data 304, third-party data 314, data from the IoT 114, etc., in addition to the blood glucose measurement value 118.

[0141] The user's health metrics are predicted by processing blood glucose measurements and additional data using one or more models (block 1206). In accordance with the principles described herein, the one or more models are generated based on past blood glucose measurements and past additional data of the user population. As an example, the prediction system 316 of the data analysis platform 126 uses one or more models 404 to generate a prediction 318 that includes health metrics by processing the blood glucose measurements 118 and additional data 410 of person 102. The one or more models 404 are generated based on the blood glucose measurements 118 and additional data 410 of the user population 110. The one or more models 404 may include, by way of example and not limitation, a statistical model 406 and / or an additional machine learning model 408.

[0142] The recommendation is generated based on the user's health metrics (block 1208). As an example, regardless of whether a statistical model 406, a machine learning model 408, or some combination of statistical and / or machine learning models is used to generate the prediction 318, the prediction 318 is obtained by the recommendation system 412 of the data analysis platform 126. The recommendation system 412 is configured to generate a recommendation 320 based on the prediction 318. In some cases, the health metrics correspond to a predicted poor health condition, such as a prediction that the user will develop type II diabetes within the next 40 months. In this scenario, the recommendation system 412 can generate the recommendation 320 based on logic that associates the predicted poor health condition with one or more actions or behaviors that mitigate the predicted poor health condition. Thus, the recommendation 320 may include one or more actions or behaviors intended to mitigate the predicted poor health condition.

[0143] Communicate at least one of the prediction or the recommendation to one or more computing devices for output via the network (block 1210). As an example, data analysis platform 126 communicates prediction 318 and / or recommendation 320 to computing device 108 for output. Computing device 108 can then display prediction 318 and / or recommendation 320 in the CGM interface. As shown in FIG. 6, for example, CGM user interface 602 displays prediction 604 along with recommendation 606. In this example, prediction 604 indicates that there is a 76% likelihood that the user will develop type II diabetes in 40 months. Recommendation 606 includes one or more actions or behaviors that the user can take to improve the user's predicted poor health state. For example, in FIG. 6, recommendation 606 includes a recommendation for a customized meal plan, a recommendation for a customized exercise plan, and a recommendation to obtain coaching that can help the user stay on track with the recommended nutrition and exercise plans.

[0144] In one or more implementations, the prediction or the recommendation can be communicated to verification service 502 and / or decision support platform 504 before or instead of being communicated to the user's computing device 108. In this way, verification service 502 and decision support platform 504 may act as intermediaries between data analysis platform 126 and computing device 108. In a scenario where the prediction or the recommendation is communicated to verification service 502, verification service 502 can validate recommendation 320. This means determining whether the recommendation is valid (e.g., safe) and can further be communicated to decision support platform 504 and / or directly to computing device 108. Verification service 502 may disclose recommendation 320 to a user permitted by service 502, such as a clinician, to validate the recommendation.

[0145] (For example, in response to a proposal enabled by a clinician or the logic of the validation service 502), the proposal may be further routed to the decision support platform 504 or directly to the computing device 108. When the proposal is not enabled (i.e., rejected), the proposal may not be further routed to the decision support platform 504 or directly to the computing device 108. Instead, the validation service 502 may modify the proposal (e.g., according to the clinician's input) and / or provide a notification to the data analysis platform 126 that the proposal has been rejected. In this scenario, the data analysis platform 126 may be able to add a rejection indication as an input to the prediction system and initiate the generation of different predictions 318 and / or proposals 320. In fact, the model 404 may be updated based on the enabling and rejection received from the validation service 502. In a scenario where the validation service 502 enables the proposal 320, thereby allowing the proposal 320 to be directly transferred to the computing device 108, the computing device 108 may output the proposal 320 via a display, speaker, tactile feedback, etc., as described above and below.

[0146] As described above, the proposal 320 may also be communicated by the validation service 502 to the decision support platform 504, or alternatively, bypassing the validation service, may be communicated directly from the data analysis platform 126 to the decision support platform 504. Based on the proposal 320 and other information accessible regarding the corresponding user, a customer service specialist may determine how to assist the user. As an example, the customer service specialist may decide to call the user to provide voice assistance during a phone call.

[0147] The updated health metrics are predicted by processing the user's updated blood glucose measurements and additional data using one or more models, and based on the updated health metrics, notifications are communicated via a network to one or more computing devices for output (block 1212). As an example, data analytics platform 126 continuously collects blood glucose measurements 118 and additional data 410 for the user. Thus, prediction system 316 can predict updated health metrics by processing the updated blood glucose measurements and additional data using one or more models 404. As shown in FIG. 7, for example, based on the user's updated blood glucose measurements 118 from CGM system 104 and additional data 410 indicating that the user is making better food choices (as indicated by the user's nutrition log) and exercising more frequently (as indicated by the step data and exercise log), prediction system 316 generates an updated prediction, which is communicated to computing device 108 for display as notification 702.

[0148] FIG. 13 depicts an exemplary procedure 1300 in which a proposal for using a particular application is communicated to one or more devices of similar users.

[0149] Blood glucose measurements of a user population and application interaction data associated with users of the user population are maintained in one or more storage devices (block 1302). In accordance with the principles described herein, application interaction data describes the use of an application (e.g., use of the "app" by various users of the user population). As an example, CGM platform 112 obtains blood glucose measurements 118 detected by CGM system 104 worn by person 102 and maintains blood glucose measurements 118 in storage device 120. Additionally, the CGM platform obtains application interaction data from various applications, such as applications provided by third party 306.

[0150] Improvement of the health state of a subset of users of a user population is identified, at least in part, based on blood glucose measurements (block 1304), and improvement of the health state of the subset of users is correlated with the use of a particular application based on application interaction data (block 1306). As an example, the CGM platform 112 can aggregate application interaction data, along with blood glucose measurements 118 and additional data, to determine whether a user's interaction with a particular application or service correlates with an improvement in the user's health. For example, based on the blood glucose measurements 118, the CGM platform 112 can objectively determine an improvement in the user's health state. The CGM platform 112 can then correlate an improvement or decline in the user's health with the use of a particular application based on the application interaction data. For example, if the CGM platform detects an improvement in the user's health state that coincides with frequent use of a particular application, the CGM platform may determine that the particular application is correlated with the improvement.

[0151] Similar users having a health state are identified (block 1308), and a proposal for using a particular application is communicated to one or more devices associated with the similar users (block 1310). As an example, the proposal system 412 can identify similar users having a health state and generate a proposal to the similar users to utilize a particular application that has helped improve the health state of a subset of the similar users. To do so, the proposal system 412 can predict the probability of a similar improvement in health state through the use of a particular application by other users in the user population and propose applications that are likely to improve the health of other similar users.

[0152] The proposed application can communicate with the computing device 108 for output. As an example, as shown in FIG. 8, the CGM user interface 802 is depicted as displaying the proposed application 804. In this case, the proposed application 804 corresponds to various third-party applications. In FIG. 8, the user is depicted as selecting the application "Nutrition by Neha" to download this application to the user's smartphone.

[0153] Exemplary procedures according to one or more implementations have been described, so consider exemplary systems and devices that can be used to implement the various techniques described herein.

[0154] Exemplary Systems and Devices FIG. 14 shows an exemplary system generally at 1400, including an exemplary computing device 1402 representative of one or more computing systems and / or devices that can implement the various techniques described herein. This is shown by including the CGM platform 112. The computing device 1402 can be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and / or any other suitable computing device or computing system.

[0155] The illustrated exemplary computing device 1402 includes a processing system 1404, one or more computer-readable media 1406, and one or more I / O interfaces 1408 communicatively coupled to each other. Although not shown, computing device 1402 may further include a system bus or other data and command transfer system that couples the various components to each other. The system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus that utilizes any of various bus architectures. Various other examples, such as control lines and data lines, are also contemplated.

[0156] The processing system 1404 is representative of functionality for performing one or more operations using hardware. Accordingly, processing system 1404 is illustrated as including hardware elements 1410 that can be configured as, for example, a processor, functional blocks, and the like. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. Hardware elements 1410 are not limited by the materials from which they are formed or the processing mechanisms used therein. For example, a processor may be comprised of semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically executable instructions.

[0157] Computer-readable medium 1406 is shown as including memory / storage 1412. Memory / storage 1412 represents the memory / storage capacity associated with one or more computer-readable media. Memory / storage component 1412 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks, etc.). Memory / storage component 1412 may include fixed media (e.g., RAM, ROM, fixed hard drive, etc.) as well as removable media (e.g., flash memory, removable hard drive, optical disk, etc.). Computer-readable medium 1406 may be configured in various other ways, as further described below.

[0158] Input / output interface 1408 is representative of functionality that enables a user to input commands and information into computing device 1402 and also enables information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., capacitive or other sensors configured to detect a physical touch), a camera (e.g., which may use visible or infrared wavelengths, such as an invisible wavelength, to recognize movement as a gesture without touch), etc. Examples of output devices include a display device (e.g., a monitor or a projector), a speaker, a printer, a network card, a tactile response device, etc. Thus, computing device 1402 may be configured in various ways to assist user interaction, as further described below.

[0159] In this specification, various techniques may be described in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, etc. that perform a particular task or implement a particular abstract data type. The terms "module", "functionality", and "component" as used in this specification generally represent software, firmware, hardware, or combinations thereof. The features of the techniques described herein are platform-independent. That is, this technique means that it can be implemented on various commercial computing platforms having various processors.

[0160] Implementations of the described modules and techniques may be stored on or transmitted via some form of computer-readable medium. The computer-readable medium may include various media that can be accessed by the computing device 1402. By way of example and not limitation, the computer-readable medium may include "computer-readable storage media" and "computer-readable signal media".

[0161] "Computer-readable storage medium" may refer to a medium and / or device that enables persistent and / or non-transitory storage of information, as contrasted with mere signal transmission, carrier waves, or signals themselves. Thus, a computer-readable storage medium refers to a non-signal transmission medium. A computer-readable storage medium includes hardware such as volatile and non-volatile, removable and non-removable media, and / or storage devices implemented in a suitable method or technology 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 RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage devices, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage devices, tangible media, or products suitable for storing desired information and accessible by a computer, but are not limited thereto.

[0162] "Computer-readable signal medium" may refer to a signal transmission medium configured to send instructions to the hardware of computing device 1402, such as via a network. A signal medium may typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism. A signal medium also includes any information delivery medium. The term "modulated data signal" means a signal having one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media includes wired media such as a wired network or direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0163] As described above, the hardware element 1410 and the computer-readable medium 1406 are representative of modules, programmable device logic, and / or fixed device logic implemented in hardware form that can be used in some embodiments to implement at least some aspects of the techniques described herein for executing one or more instructions. Hardware may include components of an integrated circuit or on-chip system, application specific integrated circuit (ASIC), field programmable gate array (FPGA), complex programmable logic device (CPLD), and other implementations in silicon or other hardware. In this context, hardware may operate as a processing device that executes instructions and / or logic embodied by the hardware, as well as the program tasks defined thereby, and that utilizes hardware, such as the computer-readable storage medium described above, to store instructions for execution.

[0164] Using the foregoing combinations, various techniques described herein may be implemented. Thus, software, hardware, or executable modules may be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage medium and / or by one or more hardware elements 1410. The computing device 1402 may be configured to implement specific instructions and / or functions corresponding to software and / or hardware modules. Thus, an implementation of a module executable by the computing device 1402 as software may be at least partially achieved in hardware, for example, through the use of the computer-readable storage medium and / or the hardware elements 1410 of the processing system 1404. Instructions and / or functions may be executable / operable by one or more products (e.g., one or more computing devices 1402 and / or processing systems 1404) for implementing the techniques, modules, and examples described herein.

[0165] The techniques described herein may be assisted by various configurations of the computing device 1402 and are not limited to specific examples of the techniques described herein. This functionality may be implemented in whole or in part through the use of a distributed system, such as on a "cloud" 1414 via a platform 1416 as described below.

[0166] The cloud 1414 includes a platform 1416 for resources 1418 and / or is representative thereof. The platform 1416 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of the cloud 1414. The resources 1418 may include applications and / or data that can be utilized while computer processing is being executed on a server remote from the computing device 1402. The resources 1418 may also include services provided over the Internet and / or through a subscriber network such as a cellular or Wi-Fi network.

[0167] The platform 1416 may abstract resources and functionality to connect the computing device 1402 with other computing devices. The platform 1416 may also abstract resource scaling to function to provide a level of scale that corresponds to the demand encountered by the resources 1418 implemented via the platform 1416. Thus, in embodiments of interconnected devices, the implementation of the functions described herein may be distributed throughout the system 1400. For example, the functionality may be implemented partially on the computing device 1402 and via a platform 1416 that abstracts the functionality of the cloud 1414.

[0168] Conclusion The systems and techniques are described in terms of language inherent in structural features and / or methodological acts, but it should be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms for implementing the claimed subject matter.

Explanation of Reference Numerals

[0169] 112 CGM Platform 1402 Computing Device 1404 Processing System 1406 Computer-Readable Medium 1408 I / O Interface 1410 Hardware Elements 1412 Memory / Storage 1414 Cloud 1416 Platform 1418 Resource

Claims

1. Receiving blood glucose measurement values provided by a continuous glucose monitoring (CGM) system worn by a user; Receiving first additional data associated with the user, wherein the first additional data is obtained from one or more sources different from the CGM system, and the one or more sources include third-party applications; Based on the blood glucose measurement values and the first additional data, using one or more models to generate a determination of the user's health status or event, wherein the one or more models are generated based on past blood glucose measurement values and past additional data of a user population; Based on the determined health status or event of the user, the past blood glucose measurement values of the user population, and the past additional data of the user population, generating a proposal, wherein the proposal includes a behavior plan, and the behavior plan includes at least one of a diet plan or an exercise plan; Communicating the behavior plan to one or more computing devices for output via a network; Receiving second additional data indicating the user's compliance with the behavior plan, wherein the second additional data is obtained from the one or more sources different from the CGM system; Based on the received second additional data of the user, using the one or more models to generate an updated determination of the health status or event; Communicating a notification to the one or more computing devices for output via the network based on the updated determined health status or event. A method performed by a computer, comprising:

2. The method according to claim 1, wherein the health status or event includes a poor health status.

3. The method according to claim 2, wherein the proposal is generated based on logic associating the poor health status with one or more actions or behaviors that mitigate the poor health status, and the behavior plan includes the one or more actions or behaviors.

4. The method according to claim 1, wherein the first additional data associated with the user includes at least one of activity data, nutrition data, third-party data, application interaction data, device data, or environmental data.

5. the one or more models include a machine learning model, and the method further comprises: receiving the past blood glucose measurement values of the user population provided by a CGM system worn by users of the user population; receiving past additional data of the user population from one or more sources different from the CGM system; training the machine learning model using the past blood glucose measurement values and the past additional data of the user population. The method according to claim 1.

6. The method according to claim 1, wherein the CGM system detects the blood glucose measurement values via a sensor subcutaneously inserted into the skin of the user.

7. A system comprising: a storage device for maintaining blood glucose measurement values of a user population and additional data associated with users of the user population; one or more machine learning models trained using the blood glucose measurement values and the additional data of the user population; a data analysis platform, comprising: generating a determination of the health state or event of an individual user of the user population based on the blood glucose measurement values and first additional data of the individual user using the one or more machine learning models; generating a recommendation based on the determined health state or event of the individual user, the blood glucose measurement values of the user population, and the additional data associated with users of the user population, the recommendation including a behavior plan, the behavior plan including at least one of a diet plan or an exercise plan; communicating the behavior plan to one or more computing devices via a network for output; receiving second additional data indicating compliance of the individual user with the behavior plan, the second additional data being obtained from one or more sources different from the source of the blood glucose measurement values of the individual user; generating an updated determination of the health state or event using the one or more machine learning models based on the received second additional data of the individual user; communicating a notification to the one or more computing devices via the network for output based on the updated determined health state or event. A data analysis platform for performing the above. A system comprising.

8. The system of claim 7, wherein the one or more computing devices are associated with the individual users, and the proposal is configured for output via at least one of a display device or an audio device associated with the one or more computing devices.

9. The system of claim 8, wherein the storage device obtains at least a portion of the blood glucose measurement values and the first additional data of the individual users from the one or more computing devices associated with the individual users.

10. The system of claim 7, wherein the one or more computing devices are associated with a caregiver of the individual users.

11. The one or more computing devices are associated with a verification service, and the verification service receives the proposal from the data analysis platform, publishes the proposal to one or more users permitted to activate the proposal via a user interface, communicates the proposal to the computing device of the individual user in response to receiving activation of the proposal by a permitted user, or communicates a notification that the proposal has been rejected to the data analysis platform in response to receiving rejection of the proposal by the permitted user, the system of claim 7.

12. The one or more computing devices are associated with a decision-making support platform, and the decision-making support platform receives the proposal from the data analysis platform, and publishes the proposal to one or more users permitted to assist in managing the health of the individual users via a user interface, the system of claim 7.

13. The system of claim 7, further comprising at least one application programming interface (API), the API being configured to expose a call to enable a third party to request the blood glucose measurement values from the storage device.

14. The system of claim 7, further comprising at least one application programming interface (API), the API being configured to obtain at least a portion of the first additional data from a third party.

15. One or more computer-readable storage media storing instructions, the instructions being executable by one or more processors to perform operations, the operations including receiving a blood glucose measurement value provided by a wearable blood glucose monitoring system worn by a user; receiving first additional data associated with the user, the first additional data being obtained from one or more sources different from the wearable blood glucose monitoring system, the one or more sources including third-party applications; using one or more models to generate a determination of the user's health status or an event based on the blood glucose measurement value and the first additional data, the one or more models being generated based on past blood glucose measurement values and past additional data of a user population; generating a proposal based on the determined health status or event of the user, the past blood glucose measurement values of the user population, and the past additional data of the user population, the proposal including a behavior plan, the behavior plan including at least one of a diet plan or an exercise plan; communicating the behavior plan to one or more computing devices for output via a network; receiving second additional data indicating compliance of the user with the behavior plan, the second additional data being obtained from the one or more sources different from the wearable blood glucose monitoring system; using the one or more models to generate an updated determination of the health status or event based on the received second additional data of the user; communicating a notification to the one or more computing devices for output via the network based on the updated determined health status or event. One or more computer-readable storage media comprising.

16. The one or more computer-readable storage media of claim 15, wherein the health status or event includes a poor health status.

17. The one or more computer-readable storage media according to claim 16, wherein the proposal is generated based on logic associating the poor health condition with one or more actions or behaviors that alleviate the poor health condition, and the behavior plan includes the one or more actions or behaviors.

18. The one or more computer-readable storage media according to claim 15, wherein the first additional data associated with the user includes at least one of activity data, nutritional data, third-party data, application interaction data, device data, or environmental data.

19. The one or more models include a machine learning model, and the operations include receiving the past blood glucose measurement values of the user population provided by a wearable blood glucose monitoring system worn by users of the user population; receiving the past additional data of the user population from one or more sources different from the wearable blood glucose monitoring system worn by users of the user population; The one or more computer-readable storage media according to claim 15, further comprising training the machine learning model using the past blood glucose measurement values and the past additional data of the user population.

20. The one or more computer-readable storage media according to claim 15, wherein the wearable blood glucose monitoring system includes a continuous glucose monitoring (CGM) system worn by the user.

21. The one or more computer-readable storage media according to claim 20, wherein the CGM system detects the blood glucose measurement values via a sensor subcutaneously inserted into the user's skin.

22. Receiving means for receiving blood glucose measurement values provided by a continuous glucose monitoring (CGM) system worn by a user and first additional data associated with the user, wherein the first additional data is obtained from one or more sources different from the CGM system, and the first additional data indicates the user's compliance with a behavior plan including at least one of a meal plan or an exercise plan. Determination means for generating a determination of the health state or event of the user using one or more models based on the blood glucose measurement value and the first additional data, wherein the one or more models are generated based on past blood glucose measurement values and past additional data of a user population, the determination means; Proposal means for generating a proposal based on the health state or event of the user and the past blood glucose measurement values of the user population; Communication means for communicating the proposal to one or more computing devices for output via a network, the apparatus comprising.

23. The apparatus according to claim 22, wherein the receiving means obtains the first additional data from one or more sources different from the CGM system.

Images