Recommendations based on continuous glucose monitoring

Abstract

To provide recommendations based on continuous glucose monitoring (CGM).SOLUTION: Given the number of people that wear CGM systems and because CGM systems produce measurements continuously, a platform that provides a CGM system may have an enormous amount of data. This amount of data is practically, if not actually, impossible for humans to process. In implementations, a CGM platform includes a data analytics platform that obtains glucose measurements provided by a CGM system and also obtains additional data associated with a user. The data analytics platform processes these measurements and the additional data to predict a health indicator by using models. This prediction serves as a basis for generating a recommendation, such as a message recommending the user to take action or adopt behavior to mitigate a predicted negative health condition.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 940,715, filed November 26, 2019. The foregoing application is incorporated by reference in its entirety and expressly made a part hereof. [Background technology]

[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 critical to their survival. With proper treatment, serious damage to the heart, blood vessels, eyes, kidneys, and nerves caused by diabetes can be largely avoided. Proper treatment for people with type 1 diabetes often involves monitoring blood glucose levels throughout the day and regulating them with a combination of insulin, diet, and exercise to keep them within the desired range. Advances in medical technology have led to the development of various systems for monitoring blood glucose levels.

[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 draw blood, and a sensor for detecting analytes in the drawn blood that are indicative of blood glucose levels. Other systems use sensors to detect analytes indicative of blood glucose levels in substantially real time and generate measurements of those blood glucose levels over a period of time, which is referred to as continuous glucose monitoring (CGM). Both types of systems are configured to output (e.g., display) these measurements, allowing the user to determine how to adjust those blood glucose levels as needed and based on a plan developed with a qualified caregiver. The vast number of blood glucose measurements generated and output by CGM systems shows the user how their blood glucose levels are trending, allowing the user to make more informed decisions regarding their treatment. Summary of the Invention [Means for solving the problem]

[0004]

[0003] Described herein is a proposal based on continuous blood glucose monitoring (CGM). Given the number of people who wear CGM systems, and because CGM systems continuously generate measurements, a CGM platform that provides a CGM system with a sensor for detecting blood glucose levels and maintains the measurements generated by such a system may have a vast amount of data, e.g., tens of millions of patient-days of measurements. However, this amount of data, in conjunction with not only blood glucose measurements but also the wealth of additional data that can be correlated with blood glucose measurements to accurately predict various conditions, e.g., health indicators, makes it virtually impossible, if not impossible, for a human to reliably identify patterns.

[0005] In one or more implementations, the CGM platform includes a data analysis platform that acquires blood glucose measurements provided by a CGM system worn by a user. The data analysis platform also acquires additional data associated with the user. However, the data analysis platform acquires the additional data from one or more sources other than the sensors of the CGM system, such as a computing device that processes the blood glucose measurements before communicating them to the CGM platform, or a third party that provides devices or services capable of generating health-related information, such as insulin data, exercise data, dietary data, etc.

[0006] The data analysis platform processes these blood glucose measurements and additional data to predict health indicators for the user using one or more models, e.g., statistical models, machine learning models configured as neural networks, 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, e.g., multiple users who wear or have worn a CGM system. Based on the predicted health indicators, the data analysis platform generates suggestions, such as messages suggesting the user take action or adopt a behavior to alleviate the predicted adverse health condition. The data analysis platform then communicates at least one of the predictions or suggestions over a network for output to one or more computing devices, e.g., a computing device associated with the user (e.g., a mobile phone or smartwatch), a computing device associated with the user's guardian (e.g., a parent), a computing device associated with a verification service (accessible to a medical professional authorized to validate the suggestions), etc.

[0007] This Summary introduces a selection of concepts in a simplified form that are further described below in the Detailed Description. As such, 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 explanation of the drawings]

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

[0009] [Figure 1] 1 is an illustration of an environment in an example implementation operable to employ the techniques described herein. [Figure 2] 2 illustrates the example continuous glucose monitoring (CGM) system of FIG. 1 in more detail. [Figure 3]1 depicts an example implementation in which CGM device data, including blood glucose measurements, is routed to different systems to enable the provision of CGM-related services. [Figure 4] 2 depicts an exemplary implementation of the data analytics platform of FIG. 1 in more detail. [Figure 5] 1 depicts an example implementation in which at least one of the predictions or recommendations generated by the data analytics platform is routed to at least one of a validation service or a decision support platform. [Figure 6] 1 depicts an example implementation of a CGM platform user interface displayed on a computing device coupled to a CGM system. [Figure 7] 1 depicts an example implementation of a user interface that outputs updated predictions and updated suggestions. [Figure 8] 1 depicts another exemplary implementation of a user interface that outputs predictions and recommendations for diabetes treatment decision support. [Figure 9] 1 depicts an example implementation of a user interface that outputs information about health trends. [Figure 10] 1 depicts an example implementation of a user interface of a validation service with which authorized users can interact to validate suggestions generated by a CGM platform. [Figure 11] 1 depicts an example implementation of a user interface that outputs information about detected faults and system configuration issues associated with use of a CGM platform. [Figure 12] 1 illustrates a procedure in an exemplary implementation in which predictions and suggestions are generated based on both a user's blood glucose measurements and additional data. [Figure 13] 1 depicts a procedure in an exemplary implementation in which a suggestion to use a particular application is communicated to one or more devices of similar users. [Figure 14]To implement embodiments of the technology described herein, an exemplary system is shown including various components of an exemplary device that may be implemented as any type of computing device described and / or utilized with reference to FIGS. 1-13. DETAILED DESCRIPTION OF THE INVENTION

[0010] overview This specification describes a proposal based on continuous blood glucose monitoring (CGM). Given the number of people who wear CGM systems, and because CGM systems continuously generate measurements, a CGM platform that provides the CGM system with a sensor for detecting blood glucose levels and maintains the measurements generated by such a system may have a vast amount of data, e.g., tens of millions of patient-days of measurements. However, this amount of data makes it virtually impossible for a human to reliably identify patterns, even if it is not practical, not just in blood glucose measurements but also in conjunction with the wealth of additional data that can be correlated with blood glucose measurements to accurately predict various conditions, e.g., health indicators.

[0011] To overcome these problems, CGM prediction generation is utilized. The CGM platform acquires blood glucose measurements from various CGM systems and computing devices of users in a user population. According to the described techniques, the CGM system is configured to continuously monitor a person's blood glucose. The CGM system may, for example, be configured with a CGM sensor that is subcutaneously inserted into the person's skin and detects analytes indicative of the person's blood glucose. The CGM system can continuously generate blood glucose measurements based on the detected analytes. As used herein, the term "continuously" means nearly continuously, and continuous blood glucose monitoring generates measurements at time intervals supported by the CGM system's resources (e.g., battery life, processing power, communication capabilities, etc.) and without the need for manual user interaction, such as a finger prick. 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 continue monitoring blood glucose levels while participating in activities where manual finger pricks may be dangerous, such as driving a car.

[0012] The CGM system transmits the blood glucose measurements to a computing device communicatively coupled to the CGM system, such as a smartwatch worn by the person, the person's smartphone, or a dedicated device associated with the CGM system. The CGM system may communicate the blood glucose measurements 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 measurements to the CGM platform, such as by communicating the blood glucose measurements over a network to a cloud-based service that hosts the CGM platform.

[0013] The CGM platform may obtain additional data for users in the user population 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, blood glucose measurements, as well as device data (e.g., sensor identification data, incident reports), supplemental data added by computing devices, third-party data, etc. Health-related data may include activity data (e.g., step counts, exercise frequency, sleep data), biometric data (e.g., insulin levels, ketone levels, heart rate, temperature, stress), nutritional data (e.g., food and drink 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), to name just a few. Application interaction data may include data extracted from application logs describing user interactions with particular applications, clickstream data describing clicks, taps, and presses performed in connection with the input / output interface of the computing device, gaze data describing where the user is looking (e.g., in connection with a display device associated with the computing device or when the user is looking away from the device), voice data describing the user's or other users' audible commands and other spoken phrases (e.g., including what the user passively listens to), etc. Environmental data may include data describing various environmental aspects associated with the user, such as, for example, the user's location, the temperature and / or weather at the user's location, the user's altitude, barometric pressure, etc. Demographic data may include data describing the user, such as, for example, age, gender, height, weight, etc. 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 measurements and additional data collected from various respective users of a user population. In some cases, the blood glucose measurements and additional data can be time-stamped, allowing each user's blood glucose measurements and additional data to be stored in a manner that maintains a time-based relationship or order among the various data. This allows the CGM platform to make various predictions and inferences based on individual data sets that simply cannot be analyzed at such a large scale by conventional systems.

[0015] To generate predictions and inferences using the aggregated data, the CGM platform leverages the wealth of 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 may build statistical models, 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 blood glucose measurements and additional data for the user population.

[0016] Notably, unlike conventional systems, CGM platforms may have access to blood glucose measurements obtained using CGM systems for hundreds of thousands of users (e.g., 500,000 or more) in a user population. Furthermore, these measurements are taken at a continuous rate by sensors in 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 effects of various behaviors on blood glucose levels. Without the robustness of this aggregate data, conventional systems simply cannot build or train models to cover a state space in a manner that adequately represents how various user behaviors and actions affect blood glucose levels. Failure to adequately cover these state spaces can result in inaccurate blood glucose predictions or predictions of other health indicators, potentially leading to the suggestion of risky actions or behaviors that could cause death. Given the importance of generating inaccurate predictions, it is important to build models using a volume of blood glucose measurements that is robust to rare events.

[0017] The CGM platform uses models built and / or trained using the aggregated data to generate various predictions for the user wearing the CGM system and suggestions for improving the predicted health status. The predictions may correspond to or otherwise include health indicators. As used herein, the term "health indicator" may refer to a predicted health status, which may be "negative" or "positive." Examples of negative health status include, for example, prediabetes, type 1 diabetes, type 2 diabetes, neuropathy, Alzheimer's disease, and heart disease, to name just a few. In contrast, examples of "positive" health status may include improved blood tests, body composition, cardiovascular performance, etc.

[0018] Additionally, predictions generated by the system may include specific predictions for individual users and generalized predictions or trends for the entire user population (e.g., drinking soda spikes blood sugar levels, causing long-term neuropathy, or a low-carb diet lowers A1C). For example, the system can apply a trained machine learning model to an individual user's blood glucose measurements over a specific time period and additional data to generate a user-specific prediction of the user's health indicators or events, such as by predicting that the user will develop type 2 diabetes or heart disease in the future. The system may generate an accuracy or probability associated with the prediction and a time period associated with the prediction (e.g., a 75% chance of developing type 2 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 may be applied to blood glucose measurements, heart rate, insulin levels, etc. in real time as the data is being captured to generate the user's predicted blood glucose levels for the near future (e.g., the next 30 minutes).

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

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

[0021] The predictions and suggestions 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, third-party services, etc. Such predictions and suggestions 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., an in-application or on-device notification), or uploaded to a secure platform or website accessible via credentials.

[0022] According to various implementations, the CGM platform may include one or more application programming interfaces (APIs) that enable the back-and-forth communication of blood glucose measurements and additional data between the CGM platform and one or more third parties. Such APIs may include "output" APIs that allow blood glucose measurements to be communicated 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 allow these third-party applications to access the user's blood glucose measurements. Doing so allows the third-party applications to utilize the blood glucose measurements in various ways to improve the user's health. In this way, third-party service providers may offer 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 an "input" API that allows 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 interacting with a particular application is improving the user's health. Based on this, the CGM platform may suggest that other users in the user population also utilize a particular application.

[0024] As part of this, the system may collect demographic data for a particular user, such as age, gender, and location. Blood glucose measurements collected from a user can be combined with the demographic data and additional data to generate a similarity score with other users in the user population. For example, a 22-year-old female user with an average blood glucose of 162 mg / dL and experiencing a pattern of nocturnal low blood glucose measurements may have a similarity score with other users of that age, gender, average blood glucose measurements, and pattern experience. In this scenario, suggestions for utilizing a particular application may be based on the user's similarity to other users in the population. For example, if use of a particular application improves glycemia for a subset of users in the user population, the CGM platform can suggest use of the particular application to similar users in the user population.

[0025] The following description first describes an example environment in which the techniques described herein may be used. Then, details of example implementations and procedures that may be performed in the example environment and other environments are described. Performance of the example procedures is not limited to the example environment, and the example environment is not limited to performance of the example procedures.

[0026] Example Environment 1 is an illustration of an environment 100 in an example implementation operable to use continuous glucose monitoring (CGM)-based suggestions as described herein. The illustrated environment 100 includes a person 102, who is depicted wearing a CGM system 104, an insulin delivery system 106, and a computing device 108. The illustrated environment 100 also includes other users in a user population 110 of the CGM system, a CGM platform 112, and an Internet of Things 114 (IoT 114). The CGM system 104, the insulin delivery system 106, the computing device 108, the user population 110, the CGM platform 112, and the IoT 114 are communicatively coupled to one another 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 manners, such as 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 communications to form a closed-loop system between each other. In this manner, the insulin delivery system 106 may deliver insulin based on blood glucose predictions calculated in real time (e.g., by the computing device 108) as blood glucose measurements are obtained by the CGM system 104.

[0028] In accordance with 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 with, for example, a CGM sensor that continuously detects analytes 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, along with further aspects of the configuration of the CGM system 104, are described in more detail in connection with FIG. 2.

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

[0030] Although illustrated as a wearable device (e.g., a smart watch), the computing device 108 may be configured in various ways without departing from the spirit or scope of the described techniques. By way of example and not limitation, the computing device 108 may be configured as a different type of mobile device (e.g., a mobile phone or tablet device). In one or more implementations, the computing device 108 may be configured as a dedicated device associated with the CGM platform 112, including functionality to, for example, obtain blood glucose readings 118 from the CGM system 104, perform various calculations related to the blood glucose readings 118, display information related to the blood glucose readings 118 and the CGM platform 112, communicate the blood glucose readings 118 to the CGM platform 112, etc. However, in contrast to implementations in which the computing device 108 is configured as a mobile phone, the computing device 108 may not include some functionality available in a mobile 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, the computing device 108 may represent multiple devices in accordance with the described techniques. In one or more scenarios, for example, the computing device 108 may correspond to 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 readings 118 from the CGM system 104, communicating them to the CGM platform 112 via the network 116, and displaying information related to the blood glucose readings 118. Alternatively or additionally, the different devices may have different capabilities that the other device does not have or that are limited through computing instructions to the particular device. In a scenario in which the computing device 108 corresponds to a separate smartwatch and a 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 activity (e.g., steps) of the person 102. In this scenario, the mobile phone may not be configured with these sensors and functionality or may include a limited amount of it, while in other scenarios the mobile phone may be able to provide the same functionality. Continuing with this particular scenario, the mobile phone may have capabilities that the smartwatch does not, such as an amount of computational resources (e.g., battery and processing speed) that enable the mobile phone to more efficiently perform calculations related to blood glucose measurements 118. Even in scenarios where the smartwatch is capable of performing such calculations, the computational instructions may limit the performance of those calculations on the mobile phone in order not to burden both devices and to efficiently utilize available resources. To this extent, the computing device 108 may be configured in different ways and represent a different number of devices than 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 readings 118 to the CGM platform 112. In the illustrated environment 100, the blood glucose readings 118 are shown stored in the storage device 120 of the CGM platform 112 as part of the CGM data 122. The storage device 120 may 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 to at least a user of the CGM platform 112 and may also be a user of one or more other third-party service providers. To this end, the person 102 is associated with a username and, at some point, may be required to provide authentication information (e.g., a password, biometric data, etc.) to access 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 wearables, social networking systems, etc.), etc. The user profile 124 may include different information about the user within the spirit and scope of the described techniques.

[0033] Furthermore, CGM data 122 not only represents data for the user corresponding to person 102, but also represents data for other users in user population 110. With this in mind, blood glucose measurements 118 in storage device 120 include blood glucose measurements from CGM sensors of CGM system 104 worn by person 102, and also include blood glucose measurements from CGM sensors of CGM systems worn by persons corresponding to other users in user population 110. The blood glucose measurements 118 of these other users are communicated by their respective devices over network 116 to CGM platform 112, and these other users will also have respective user profiles 124 on CGM platform 112.

[0034] The data analytics platform 126 represents functionality that processes 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 suggestions and / or other information regarding the predictions. For example, the CGM platform 112 may provide the suggestions or other information directly to the user, to a medical professional associated with the user, or the like. Specific types of predictions, suggestions, and other information are described in more detail below. While depicted separately from the computing device 108, portions or the entire data analytics platform 126 may alternatively or additionally be implemented in the computing device 108. The data analytics platform 126 may also be configured to generate these predictions using data in addition to the blood glucose measurements 118, such as additional data obtained via the IoT 114.

[0035] It should be understood that the IoT 114 represents various sources that can provide data describing the person 102 as well as the person's 102 activities and real-world activities as a user of one or more service providers. By way of example, the IoT 114 may include the user's various devices, such as, for example, a camera, a mobile phone, a laptop, etc. To this end, the IoT 114 may provide information about the user's interactions with the various devices, such as interactions with web-based applications, photographs taken, communications with other users, etc. The IoT 114 may also include various real-world items (e.g., shoes, clothing, sporting equipment, appliances, automobiles, etc.) that are configured with sensors that provide information describing behavior, such as, for example, the number of steps taken, the force of the foot striking the ground, stride length, the user's body temperature (and other physiological measurements), the temperature surrounding the user, the types of food stored in the refrigerator, the types of food removed from the refrigerator, driving habits, etc. The IoT 114 may also include third parties in the CGM platform 112, such as healthcare providers (e.g., healthcare providers of the person 102) and manufacturers (e.g., manufacturers of the CGM system 104, insulin delivery system 106, or computing device 108), which can provide medical and manufacturing data, respectively, that can be leveraged by the data analytics platform 126. Indeed, the IoT 114 may include devices and sensors that can provide rich data related to CGM-based recommendations without departing from the spirit or scope of the described techniques. Consider the following description of FIG. 2 in the context of measuring blood glucose, for example, continuously, and obtaining data describing such measurements.

[0036] Figure 2 depicts in more detail an example implementation 200 of the CGM system 104 of Figure 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 shown to include a sensor 202 and a sensor module 204. In the illustrated example 200, the sensor 202 is depicted in a side view, e.g., 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 a transmitter 208 in the illustrated example 200. The dashed rectangle is used for the sensor module 204 to indicate that it may be contained within or otherwise implemented within the housing of the transmitter 208. In this example 200, the CGM system 104 further includes an adhesive pad 210 and an attachment mechanism 212.

[0038] In operation, the sensor 202, adhesive pad 210, and 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 inserted subcutaneously, 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, adhesive pad 210, attachment mechanism 212, and transmitter 208 (with sensor module 204) may all be applied to the skin 206 at once. In one or more implementations, the application assembly is applied to the skin 206 using a separate applicator (not shown). The application assembly can also be removed by peeling the adhesive pad 210 from the skin 206. It will be understood that the illustrated CGM system 104 and its various components are merely example form factors, and 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] In operation, the sensor 202 is communicatively coupled to the sensor module 204 via at least one communication channel, which may be a "wireless" connection or a "wired" connection. Communications from the sensor 202 to the sensor module 204 or from the sensor module 204 to the sensor 202 may be implemented actively or passively, and these communications may be continuous (e.g., analog) or discrete (e.g., digital).

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

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

[0042] In one or more implementations, the sensor module 204 may include a processor and memory (not shown). The sensor module 204 may utilize the processor to generate blood glucose readings 118 based on communications with the sensors 202 indicating the changes described above. Based on these communications from the sensors 202, the sensor module 204 is further configured to generate CGM device data 214. The CGM device data 214 is a communicable package of data including at least one blood glucose reading 118. Alternatively or additionally, the CGM device data 214 includes other data, such as, for example, multiple blood glucose readings 118, a sensor identification 216, a sensor status 218, etc. In one or more implementations, the CGM device data 214 may include other information, such as one or more of temperature and other analyte measurements corresponding to the blood glucose readings 118. It should be understood that the CGM device data 214 may include various data in addition to the at least one blood glucose reading 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 as a stream of data to the computing device 108. Alternatively or additionally, the sensor module 204 may buffer the CGM device data 214 (e.g., in 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 (every 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 number of instances of CGM device data 214), etc.

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

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

[0046] The sensor status 218 represents the state of the sensor 202 at a given time, for example, the state of the sensor at the same time that one of the blood glucose readings 118 is generated. To this end, the sensor status 218 may include an entry for each blood glucose reading 118, such that there is a one-to-one relationship between the blood glucose reading 118 and the status captured in the sensor status 218 information. Generally speaking, the sensor status 218 describes the operational state of the sensor 202. In one or more implementations, the sensor module 204 may identify one of several pre-defined operational states for a given blood glucose reading 118. The identified operational state may be based on communications from the sensor 202 and / or characteristics of those communications.

[0047] By way of example, the sensor module 204 may include a lookup table (e.g., in memory or other storage) having a predetermined number of operating conditions and a basis for selecting one condition from another. For example, the predetermined conditions may include a “normal” operating condition, and the basis for selecting this condition may be that communications from the sensor 202 fall within thresholds indicative of normal operation, such as within an expected time threshold, an expected signal strength threshold, an environmental temperature threshold suitable for continued operation as expected, etc. The predetermined conditions may also include operating conditions that indicate one or more characteristics of the sensor 202 communications are outside the range of normal activity and may result in potential errors in the blood glucose reading 118.

[0048] For example, these unusual operating condition basis may include receiving a communication from the sensor 202 outside of a threshold expected time, detecting a signal strength of the sensor 202 outside of a threshold of expected signal strength, detecting an environmental temperature outside of a suitable temperature for continued operation as expected, detecting that the person 102 has rolled over on the CGM system 104 (e.g., is in bed), etc. The sensor status 218 may indicate various aspects related to the sensor 202 and the CGM system 104 without departing from the spirit or scope of the described techniques.

[0049] Having considered an exemplary environment and an exemplary CGM system, we now turn to a description of some exemplary details of techniques for CGM-based suggestions in a digital media environment according to one or more implementations.

[0050] CGM-based suggestions FIG. 3 depicts an example implementation 300 in which CGM device data, including blood glucose measurements, is routed to different systems to enable the provision of CGM-related services.

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

[0052] The illustrated example 300 also includes a CGM package 302, which includes CGM device data 214 and supplemental 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. Broadly speaking, the computing device 108 includes functionality to generate the supplemental data 304 based at least in part on the CGM device data 214, package this data together into the CGM package 302, and communicate the CGM package 302 to the CGM platform 112 for storage on the storage device 120, for example, via the network 116.

[0053] With regard to 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 a user's context such that a correspondence between the user's context and the CGM device data 214 (e.g., blood glucose measurements 118) can be identified. By way of example, the supplemental data 304 may describe a user's interactions with the computing device 108 and may include, for example, data extracted from an application log describing particular application interactions (e.g., selections made, actions performed). The supplemental data 304 may also include clickstream data describing clicks, taps, and presses performed in connection with the input / output interface of the computing device 108. As another example, the supplemental data 304 may include gaze data describing where the user is looking (e.g., with respect to a display device associated with the computing device 108 or when the user is looking away from the device), voice data describing the user's or other users' audible commands and other spoken phrases (e.g., including passively listening to the user), device data describing the device (e.g., make, model, operating system and version, camera type, apps the computing device 108 is running), etc. 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, proximate to the user using temperature-sensing functionality), the weather at that location, the user's altitude, barometric pressure, environmental aspects such as contextual information obtained related to the user via the IoT 114 (e.g., the food the user is eating, the manner in which the user is using sports equipment, the clothing the user is wearing), etc. The supplemental data 304 may also describe health-related aspects detected about the user, including, for example, step count, heart rate, sweat, the user's temperature (e.g., detected by the computing device 108), etc. 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, data from these two sources may be compared, for example, for accuracy, fault detection, etc.The types of supplemental data 304 described above are examples only, and 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 packages 302 to the CGM platform 112 for processing at various intervals. In one or more implementations, the computing device 108 may stream the CGM packages 302 to the CGM platform 112 in substantially real time, for example, because the CGM system 104 continuously provides the 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, for example, 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 some of the CGM device data 214 and supplemental data 304 in the storage device 120. From the storage device 120, this data may be provided to or otherwise accessed by the data analytics platform 126, for example, to generate various predictions and provide recommendations, as described in more detail below. Alternatively or additionally, the data may be provided to a third party 306, such as a third-party service provider. In this manner, the third-party service provider may be able to offer various services that use the blood glucose measurements 118 without having to manufacture and deploy their own CGM systems.

[0056] In the depicted example 300, blood glucose readings 118 are depicted as being communicated from a storage device 120 of the CGM platform 112 over the network 116 to a storage device 308 (or other type of storage) of a third party 306. In particular, the blood glucose readings 118 are depicted as being communicated via a 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 readings 118. By "output," it is meant that the flow of data is generally outward 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 storage device 120 via the CGM Platform API 310. In the context of data provisioning, the CGM Platform API 310 may expose one or more “calls” (e.g., specific formats for data requests) to a third party 306. As an example, the CGM Platform API 310 may expose a call to a third party 306, after the third party 306 has, for example, entered into an agreement with a business corresponding to the CGM platform 112, thereby enabling the third party 306 to retrieve data from the storage device 120 via the CGM Platform API 310. As part of this agreement, the third party 306 may agree to exchange payment to retrieve data from the CGM platform 112. Alternatively or additionally, the third party 306 may agree to exchange data it generates, for example, via an associated device, to retrieve data from the CGM platform 112. The parties that enter into an agreement to retrieve data (e.g., blood glucose readings 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 allows a third party 306 to request data (e.g., blood glucose readings 118) in a particular request format, and if the request is made in a particular format, the CGM Platform API 310 provides the requested data in a particular response format. In other words, the CGM Platform API 310 is configured to receive a request for blood glucose readings 118 in a particular request format from the third party 306, retrieve the requested blood glucose readings 118 from the storage device 120, and provide the requested blood glucose readings 118 to the third party 306 in a formatted response. The CGM Platform API 310 may expose calls that allow the third party 306 to request one or more time periods (e.g., the past 10 days) of blood glucose readings 118, blood glucose readings 118 for a particular user or segment of users, or blood glucose readings 118 over a particular time period (e.g., the past 10 days) for a number of users (e.g., 10,000 users). The CGM platform 310 may expose various calls that allow third parties to request blood glucose readings 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 restrict what data different third parties can access depending on the terms of the corresponding agreements, such as, for example, limiting how often blood glucose readings 118 can be obtained, introducing a latency period in providing blood glucose readings 118 after the blood glucose readings are obtained from the CGM system 104 and computing device 108, etc.

[0059] Once the third party 306 obtains the blood glucose measurement 118, the third party 306 may generate one or more third-party suggestions 312 based on the obtained blood glucose measurement 118. By way of example, the third party 306 may provide a lifestyle application to the user and use the blood glucose measurement 118 to provide third-party suggestions 312 related to one or more lifestyle behaviors tracked via such application, such as suggestions to increase exercise, suggestions to decrease exercise, suggestions to continue a predetermined behavior (e.g., step count, eating certain foods, sleeping), suggestions to reduce or eliminate certain behaviors (e.g., eating certain foods, drinking alcohol, sleeping), etc. Examples of lifestyle applications may include exercise applications, health measurement applications, food tracking applications, sports-specific applications, etc.

[0060] As described above, the third party 306 may generate its own additional data, such as through a device, e.g., a wearable device, that the third party 306 manufactures and / or deploys. With this in mind, the third party 306 may generate the third-party suggestions 312 based not only on the blood glucose measurements 118 but also on the additional data that the third party 306 generates. For example, the third party 306 may provide the acquired blood glucose measurements 118 and this additional data as input to one or more machine learning models trained using the past blood glucose measurements 118 and the past additional data. In response to this input, the third party 306 obtains as output at least one prediction generated by the one or more models. The third party 306 may use such prediction as the basis for the third-party suggestions 312. The third-party suggestions 312 are shown as output by the third party 306. This indicates that the third party 306 may deliver the third-party suggestions 312 by communicating it over the network 116 to the computing device 108 or other computing devices, such as computing devices of the user population 110. The third party suggestions 312 may then be output by the receiving computing device, for example, by displaying the suggestions, outputting the suggestions aloud, etc.

[0061] The depicted example 300 also includes third-party data 314, which is shown communicated from a third party to the data analytics platform 126. As mentioned above, the third party 306 may manufacture and / or deploy the associated device. Additionally or alternatively, the third party 306 may obtain data through other sources, such as a corresponding application. Accordingly, this data may include user-entered data entered through a corresponding third-party application, e.g., a social networking application, a lifestyle application, etc. With this in mind, the data generated by the third party 306 may be organized in a variety of ways, including proprietary data structures, text files, images captured via the user's mobile device, formats showing text entered into public fields or dialog boxes, formats showing option selections, etc. The 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. The third-party data 314 may include, for example, application interaction data describing a user's use of or interaction with a particular application provided by the third party 306. Generally, the application interaction data enables the data analytics platform 126 to determine the use or amount of use of a particular application by users of the user population 110. Such data may include, for example, data extracted from application logs describing user interactions with particular applications, clickstream data describing clicks, taps, and presses performed in connection with an application's input / output interface, etc. Thus, in one or more implementations, the data analytics platform 126 may receive third-party data 314 generated or otherwise obtained by a third party 306.

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

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

[0064] In one or more implementations, the prediction 318 may correspond to or otherwise include a health indicator. As used herein, the term “health indicator” may refer to a predicted health state, which may be “negative” or “positive.” Examples of poor health states include, for example, prediabetes, type 1 diabetes, type 2 diabetes, neuropathy, Alzheimer's disease, and heart disease, to name just a few. In contrast, examples of “good” health states may include risk of developing a poor health state or good health states related to body fat, cardiovascular performance, and the like. In some cases, a health indicator may refer to a predicted medical condition, such as a predicted A1C. In particular, the prediction 318 is based on blood glucose measurements 118 and additional data collected during a particular period. Thus, in some cases, the prediction 318 predicts that the user currently has a predicted health state based on aggregated data. Alternatively, the predicted health state may correspond to a time period that will occur after a particular period for which aggregated data is collected (e.g., predicting type 2 diabetes within 40 months). Some additional types of predictions, and the specific types of information used to generate these predictions, are also described in more detail below.

[0065] Based on the generated prediction 318, the data analytics platform 126 generates a suggestion 320. The suggestion 320 may, for example, instruct the user to perform an action (e.g., download an application to the computing device 108, immediately go to the hospital, administer insulin, go for a walk, consume a particular food or beverage), continue a behavior (e.g., continue eating in a particular way or exercising in a particular way), change a behavior (e.g., change eating or exercise habits), etc. In such a scenario, the prediction 318 and / or the suggestion 320 are communicated from the data analytics platform 126 and output via the computing device 108. In the illustrated example 300, the prediction 318 is also shown communicated to the computing device 108. It should be understood that either or both of the prediction 318 and the suggestion 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 validation platform, for example, before the prediction and / or proposal is allowed to be delivered to the computing device 108. In the context of generating one or more predictions that may serve as the basis for the proposal 320, consider the following description of FIG.

[0066] 4 depicts in more detail an example implementation 400 of the data analytics platform 126. As in FIG. 3, the data analytics 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, e.g., a model 404 that includes a neural network. It will be understood that the model 404 may include different models, such as multiple different statistical models, multiple machine learning models configured as neural networks, and / or multiple other types of machine learning models, without departing from the spirit or scope of the described techniques. These different machine learning models may be built or trained (or otherwise learned) using different data, according to different statistical modeling techniques, have different architectures, follow different algorithms, etc. Accordingly, it will be understood that the following description of the functionality of the model manager 402 is applicable to a variety of machine learning models. However, for purposes of explanation, the functionality of the model manager 402 will be generally described with reference to the statistical model 406 and the additional machine learning model 408.

[0068] Generally, the model manager 402 is configured to manage the models 404. This model management may include, for example, building statistical models 406, building machine learning models 408, training the machine learning models 408, updating these models, etc. Specifically, the model manager 402 is configured to perform this model management at least in part using a wealth of data maintained in the storage device 120 of the CGM platform 112. As shown, this data includes blood glucose measurements 118 of the user population 110 and additional data 410. Stated another way, the model manager 402 builds the statistical models 406, builds the machine learning models 408, trains the machine learning models 408 (or otherwise learns 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 about 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 at which the blood glucose readings 118 are detected. In one or more implementations, this additional data 410 may include the blood glucose readings 118 (e.g., sensor identification 216 and sensor status 218 data) as well as at least one or more portions of CGM device data 214, supplemental data 304, third-party data 314, data from the IoT 114, etc.

[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, as well as device data (e.g., sensor identification data, incident reports), supplemental data added by the computing device, third-party data, etc. Health-related data may include activity data (e.g., step counts, exercise frequency, sleep data), biometric data (e.g., insulin levels, ketone levels, heart rate, temperature, stress, temperature), nutritional data (e.g., food and drink logs, scanned restaurant receipts, carbohydrate consumption, fasting), medical records (A1C, cholesterol, electrocardiogram results, data related to other medical tests or medical history, etc.), just to name a few. Application interaction data may include data extracted from application logs describing user interactions with particular applications, clickstream data describing clicks, taps, and presses performed in connection with the input / output interface of the computing device, gaze data describing where the user is looking (e.g., in connection with a display device associated with the computing device or when the user is looking away from the device), voice data describing the user's or other users' audible commands and other spoken phrases (e.g., including what the user passively listens to), etc. Environmental data may include data describing various environmental aspects associated with the user, such as, for example, the user's location, the temperature and / or weather at the user's location, the user's altitude, barometric pressure, etc. Demographic data may include data describing the user, such as, for example, age, gender, height, weight, etc. 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 storage device 120) or otherwise has access to 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. Furthermore, these measurements are taken at a continuous rate by sensors in the CGM system 104. As a result, millions, or even billions, of blood glucose measurements 118 are available to the model manager 402 for model building and training. With such a robust amount of data, the model manager 402 can build and train models 404 to accurately mimic the actual effects 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 models to cover state spaces in a manner that adequately represents how various behaviors affect blood glucose levels. Failure to adequately cover these state spaces can result in inaccurate blood glucose predictions or predictions of other health indicators, and can lead to suggesting risky actions or behaviors that could potentially cause death. Given the importance of generating inaccurate predictions, it is important to build the model 404 using a volume of blood glucose measurements 118 that is robust to 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 measurements 118 and the additional data 410. Once constructed, the statistical model 406 is configured to predict and output values ​​for the at least one attribute, and the values ​​of the at least one attribute do not serve 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 value set in the following description. The model manager 402 also extracts observations corresponding to at least one other attribute from the blood glucose measurements 118 and the additional data 410. Once constructed, the values ​​of the at least one other attribute serve 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. These extracted values ​​of the independent variables may be referred to as the second value set in the following description.

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

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

[0075] The model manager 402 then incorporates the estimated parameters into the equations and persists this integration as the statistical model 406 such that the statistical model 406 retains the estimated parameters along with the equations. In this manner, the model manager 402 builds the statistical model 406 that is capable of generating a prediction 318 of a blood glucose measurement after a particular time upon receiving input blood glucose measurements and corresponding additional data from before a particular time. Thus, in operation and continuing with this scenario, the prediction system 316 may obtain a subset of the blood glucose measurements 118 of the person 102 before a particular time (e.g., the current time) along with additional data 410 of the person 102 that corresponds to the independent variables used to train the statistical model 406. The prediction system 316 may then provide this data for the person 102 as input to the statistical model 406. In the continuing scenario, the statistical model 406 generates a prediction 318 of a blood glucose measurement for the person 102 after a particular time, e.g., the current time.

[0076] While predicting blood glucose measurements after a particular time (e.g., the current time) is described with reference to building and actually using a statistical model 406, the model manager 402 may build a statistical model 406 that predicts different aspects of patterns in observed blood glucose measurements 118 and additional data 410. As an example, the model manager 402 may build a statistical model 406 that predicts upward or downward trends in health indicators for a person 102, such as by maintaining the health indicators for the person 102 over a period of time. That is, the blood glucose measurements 118 and additional data 410 of a user population 110 are used to build a model that preserves correlations between these health indicators and trends among the user population 110.

[0077] We now return to a discussion of the additional machine learning model 408 (e.g., configured as a neural network) in accordance with 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, both sets extracted from the blood glucose measurements 118 of the user population 110 and the additional data 410. The model manager 402 uses these value sets to train the machine learning model 408 or to provide feedback to the machine learning model 408 about its predictions so that it learns a policy for generating predictions.

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

[0079] In a training context, the model manager 402 may train the machine learning model 408 by providing instances of data from the second set of values ​​as input to the machine learning model 408. In response, the machine learning model generates predictions 318, e.g., predictions of values ​​of at least one attribute corresponding to the first set. The model manager 402 obtains the training predictions from the machine learning model 408 as output and compares the training predictions to the actual extracted values ​​of the first set of values ​​corresponding to the instances of data input. By way of example, the model manager 402 compares the training predictions to the actual extracted values ​​using a cost function. Based on this comparison, the model manager 402 adjusts the internal weights of the machine learning model 408 so that the machine learning model can substantially reproduce the actually extracted values ​​when instances of data are provided as input in the future.

[0080] This process of inputting instances of observed data into the machine learning model 408, receiving training predictions from the machine learning model 408, comparing the training predictions (e.g., using a cost function) with expected output values ​​(observed values) corresponding to the input instances, and adjusting the internal weights of the machine learning model 408 based on these comparisons can be repeated over hundreds, thousands, or even millions of instances of training data, i.e., each iteration.

[0081] The model manager 402 may perform such iterations until the machine learning model 408 is able to generate predictions 318 that consistently and substantially match the expected output, e.g., substantially match the observed values ​​of the first dataset. The ability of a machine learning model to consistently generate predictions that substantially match the expected output is sometimes referred to as “convergence.” With this in mind, the model manager 402 may be said to train the machine learning model 408 until it “converges” to a solution. For example, the model's internal weights are suitably adjusted through the training iterations so that the model generates predictions that substantially match the expected output.

[0082] It should be understood that this is just one additional example of a machine learning model 408 and how it may be trained. Indeed, machine learning models may be constructed according to a variety of paradigms (e.g., supervised learning, unsupervised learning, reinforcement learning, etc.) and trained using a variety of approaches without departing from the spirit or scope of the described techniques. By way of example, the machine learning model 408 may initially be trained on the blood glucose readings 118 and additional data 410 of a user population, and the training may then be further updated using training instances from the blood glucose readings 118 and additional data 410 of the person 102, e.g., to further adjust various parameters of the machine learning model 408.

[0083] Regardless, once the machine learning model 408 has been trained at least in part using the blood glucose measurements 118 and additional data 410 of the user population 110, the machine learning model 408 may be used in operation to generate user predictions 318 corresponding to the person 102. Consider the following example implementation, which is similar to the statistical model building scenario and use described above, but instead of utilizing a statistical model 406, utilizes a machine learning model 408.

[0084] In this machine learning example, the model manager 402 uses blood glucose measurements 118 of the user population 110 having timestamps before a particular timestamp, and also uses corresponding additional data 410 (e.g., corresponding to the blood glucose measurements 118 and having timestamps associated with the users corresponding to the blood glucose measurements) as training inputs to the machine learning model 408. In this scenario, the model manager 402 may use blood glucose measurements 118 of the user population 110 having timestamps after the particular timestamp 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 tune the parameters of a model that predicts data after a timestamp given data before the timestamp as input. Examples of these approaches include supervised learning approaches such as steepest descent and stochastic gradient descent. However, other approaches may be used without departing from the spirit or scope of the described techniques.

[0085] Using these approaches, the model manager 402 adjusts the internal weights of the machine learning model 408 so that inputting data values ​​from before the timestamp will result in outputting blood glucose readings 118 after the timestamp (or values ​​within some tolerance of those readings). Further, the machine learning model 408 maintains these internal weights, for example, in association with particular nodes of the model. In this way, the model manager 402 builds a machine learning model 408 that, upon receiving input blood glucose readings from a particular time before and corresponding additional data, is capable of generating a prediction 318 of a blood glucose reading 118 after a particular time.

[0086] Thus, in operation and continuing with this scenario, the prediction system 316 may obtain a subset of blood glucose measurements 118 for the person 102 prior to a particular time (e.g., the current time), along with additional data 410 for the person 102 that corresponds to the input data used to train the machine learning model 408. The prediction system 316 may then provide this data for the person 102 as input to the machine learning model 408. In the continuing scenario, the machine learning model 408 generates a prediction 318 for the blood glucose measurements for the person 102 after a particular 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] While predicting blood glucose readings after a particular time (e.g., the current time) is described in connection with training and actually using the machine learning model 408, the model manager 402 may build a machine learning model 408 that predicts aspects that differ from patterns in observed blood glucose readings 118 and additional data 410. As an example, the model manager 402 may build a machine learning model 408 that predicts upward or downward trends in a health indicator for a person 102, such as by maintaining the person's 102 health indicators over a period of time. That is, the model manager 402 uses the blood glucose readings 118 and additional data 410 of a user population 110 to build a model that preserves correlations between these health indicators and 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 able to capture latent features in the data, which may include hidden relationships and spurious correlations in the data, but which are virtually impossible for a human analyst to uncover due to randomly occurring absences in the relationships.

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

[0089] The logic used by the recommendation system 412 to generate the recommendations 320 may vary in complexity without departing from the spirit or scope of the described techniques, such as heuristics hand-coded into one or more additional machine learning models for constructing recommendations based on receiving the predictions 318 as input. Further example implementations of the types of predictions and recommendations that may be generated by the model 404 and recommendation system 412, respectively, are described in more detail below. Consider now the following description of FIG. 5 relating to a validation service and decision support platform in accordance with the described techniques.

[0090] FIG. 5 depicts an example implementation 500 in which at least one of the predictions or recommendations generated by a data analytics platform is routed to at least one of a validation service or a decision support platform.

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

[0092] In contrast to the illustrated example 300 of Figure 3, the illustrated example 500 includes a validation service 502 and a decision support platform 504 as intermediaries between the data analytics platform 126 and the computing device 108. Thus, the predictions 318 and / or suggestions 320 may be routed to one or both of the validation service 502 or the decision support platform 504. Although the validation service 502 and the decision support platform 504 are not depicted in Figure 3, it should be understood that the predictions 318 and suggestions 320 generated in the scenario described in connection with Figure 3 may also be routed through the validation service 502 and / or the decision support platform 504.

[0093] In accordance with the described techniques, the verification service 502 is configured to activate the suggestions 320. This means determining whether the suggestions are valid (e.g., secure) and can be communicated to the decision support platform 504 and / or directly to the computing device 108. The verification service 502 may expose the suggestions 320 to users, e.g., clinicians, who have been authorized by the verification service 502 to activate the suggestions. By way of example, the verification service 502 may email the suggestions 320 to the clinician, provide the suggestions 320 through a clinician portal (e.g., where the clinician may review multiple suggestions and activate them), or provide a notification of the suggestions 320 on a mobile device screen, i.e., allowing the clinician to approve, reject, or obtain additional information with a simple gesture, to name just a few examples. The verification service 502 may surface the suggestions to users (e.g., clinicians) who are authorized to activate the suggestions in various ways without departing from the spirit or scope of the technology described herein.

[0094] In response to the suggestion being validated (e.g., by the clinician or by logic in the validation service 502), the suggestion may be routed further to the decision support platform 504 or directly to the computing device 108. When the suggestion is not validated (i.e., rejected), the suggestion may not be routed further to the decision support platform 504 or to the computing device 108. Instead, the validation service 502 may modify the suggestion (e.g., according to clinician input) and / or provide a notification back to the data analytics platform 126 that the suggestion was not validated. In this scenario, the data analytics platform 126 may be able to add the indications that were not validated as inputs to the prediction system and initiate generation of a different prediction 318 and / or suggestion 320.

[0095] Indeed, the model 404 may be updated based on the enablements and disablements received from the validation service 502. In scenarios in which the validation service 502 enables the suggestion 320, thereby allowing the suggestion 320 to be transferred directly to the computing device 108, the computing device 108 may output the suggestion 320 via a display device, an audio device (e.g., speaker, headphones, earphones), haptic feedback, etc., as described above and below. Examples of how suggestions may be surfaced by the validation service 502 to a user (e.g., a clinician) authorized to enable the suggestion are described in more detail below in connection with FIG. 10 .

[0096] As described above, the predictions 318 and / or suggestions 320 may be communicated to the decision support platform 504 by the validation service 502 or, alternatively, may be communicated directly from the data analytics platform 126 to the decision support platform 504, bypassing the validation service 502. The decision support platform 504 is configured to provide assistance to a user of the CGM platform 112 for managing one or more health conditions, e.g., diabetes. In response to receiving the suggestions 320, for example, the decision support platform 504 may provide the suggestions to a customer support specialist, e.g., via email, an assistance specialist portal, etc.

[0097] Based on the suggestions 320 and other accessible information about the corresponding user, a customer service specialist may decide how to assist the user. By way of example, the customer service specialist may decide to call the user to provide voice assistance during the 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 an assistance specialist portal), construct one or more messages to send to the user from pre-configured message components, simply forward the suggestions 320 to the computing device 108, contact a clinician or other medical professional associated with the user, contact emergency services, contact the user's caregiver or other guardian (e.g., parent), etc. The decision support platform 504 may provide tools, content, and services to assist the user in managing their health condition based on the predictions 318 and suggestions 320 in various ways without departing from the spirit or scope of the described techniques.

[0098] Having described how the CGM system 104, as well as data collected from various sources, is used in blood glucose measurements to generate predictions and provide suggestions related to a user's health, consider the following example implementation of CGM-based suggestions.

[0099] Use models to generate predictions and proposals FIG. 6 illustrates an example CGM platform user interface 600 displayed on a computing device coupled to a CGM system.

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

[0101] For purposes of this example, assume that after receiving an A1C and fasting blood glucose test results indicating that the user has "prediabetes," putting them at risk for developing Type 2 diabetes in the near future, the user begins measuring their blood glucose levels using the CGM system 104. With this in mind, the user begins wearing the CGM system 104, which automatically provides blood glucose readings 118 to the predictive system 316. The CGM platform 112 processes the blood glucose readings 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 measurements 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 one liter of soda per week, eats at fast food restaurants 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 to determine 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 work out, and sleep data indicating that the user sleeps an average of only five hours per night.

[0103] The prediction system applies the model 404 to the blood glucose readings 118 and additional data 410, which in this example includes the user's nutritional and activity data as described above. Taking into account the user's increasing blood glucose readings, poor food choices, and lack of activity, the prediction system 316 generates a prediction 604 indicating that the user has a 76% chance of developing type 2 diabetes within 40 months.

[0104] Along with the prediction 604, the CGM user interface 602 displays suggestions 606 generated by the suggestion system 412 of the data analytics platform 126. The suggestions 606 include one or more actions or behaviors the user can take to improve the user's predicted poor health. In this case, the suggestions 606 include a customized meal plan suggestion, a customized exercise plan suggestion, and suggestions for obtaining guidance that can help the user stay on track with the suggested nutrition and exercise plan. In FIG. 6, the user is shown selecting the customized exercise plan suggestion to obtain more detailed information about the suggested exercise plan.

[0105] Continuing with this example, assume the user follows the actions and behaviors suggested by the prediction system 316, for example, by switching to a whole foods diet, tracking their diet using an online food log, walking 10,000 steps per day, tracking their 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 readings 118, nutritional data, and activity data and determines that the user's improved nutritional choices and exercise frequency are correlated with a decrease in the user's average blood glucose readings 118.

[0106] Based on the user's updated blood glucose readings 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 in the notification 702 indicates that the user is "low" likely to develop type 2 diabetes within the next 40 months. Notably, the updated prediction in the notification 702 provides positive feedback to the user, which may further motivate the user to continue eating healthy and exercising. Conversely, if the updated prediction indicates a worsening health condition, the updated prediction may help motivate the user to get back on track.

[0107] Generating application suggestions for similar users As described throughout, the CGM platform 112 utilizes one or more CGM platform APIs 310 to enable communication of blood glucose readings 118 from the CGM platform 112 to various third parties 306, and communication of third-party data 314 from the third parties 306 to the CGM platform 112. As such, applications and services offered by such third parties 306 that utilize blood glucose readings 118 are becoming increasingly available and are often downloadable via an “app store.” Once downloaded to the computing device 108, the user can authorize the third party 306 to access the user's blood glucose readings 118 via the API 310. Doing so allows the third party 306 to utilize the blood glucose readings 118 in a variety of different ways to improve the user's health. In this manner, the third party 306 may be able to offer a variety of applications and services that use the blood glucose readings 118 without such third party 306 having to manufacture and deploy its own CGM system. As the number of third-party “apps” and services grows, it becomes increasingly difficult for a population of users to find apps and services that will work best for their individual circumstances.

[0108] CGM platform 112 may include an "input" API 310 that enables CGM platform 112 to receive third-party data 314 from various third parties 306 (e.g., via third-party servers of the third parties 306). Such third-party data 314 may include application interaction data describing user interactions with third-party services or applications. Such data may include, for example, data extracted from application logs describing user interactions with particular applications, clickstream data describing clicks, taps, and presses performed in connection with the input / output interface of a computing device, etc.

[0109] The CGM platform 112 can aggregate the application interaction data, along with the 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. The CGM platform 112 can consider a variety of different factors based on the blood glucose measurements when determining whether application use improves the user's health, including improvements in average blood glucose levels, time in range, alleviation of certain undesirable patterns, or any combination thereof. Additionally, the CGM platform 112 may provide various controls to account for differences in blood glucose measurements 118, such as sensor usage 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 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 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, correlations between particular applications and improved health status may be determined for a subset of users in the user population 110.

[0110] The recommendation system 412 can then identify similar users with health conditions and generate suggestions for those users to utilize specific applications that have helped improve the health conditions of the subset of similar users. To do so, the recommendation system 412 can predict the probability of similar improvements in health conditions through use of specific applications by other users in the user population and suggest applications that are likely to improve health for other target users. Such application suggestions may be targeted to individual users similar to the subset of users whose improved health conditions correlate with use of the specific applications. For example, if use of a specific application is correlated with improved glycemia for a subset of users in the user population, the CGM platform 112 can suggest 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 similar users. For example, similar users may be identified as having the same health condition based in part on the blood glucose measurements 118 provided by the CGM system 104 worn by the user. The CGM platform 112 may initially generate a user profile for a new user who begins wearing the CGM system 104, including demographic data such as age, gender, location, and existing medical records. As the CGM platform 112 collects blood glucose measurements 118 and additional data 410 from the user, the CGM platform 112 refines the user's similarity score with other users. For example, a 22-year-old female user with an average blood glucose of 162 mg / dL and experiencing a pattern of nocturnal low blood glucose measurements may have a similarity score with other users of that age, gender, average blood glucose measurements, and pattern experience.

[0112] The similarity score is then combined with previous application success of similar users to determine application suggestions. For example, if users similar to the target user download and use a particular application and subsequently experience improvement in glycemia (e.g., as evidenced by reduced average blood glucose levels and reduced overnight dips), the suggestion system 412 may be configured to generate a high suggestion score for the target user's particular application. Conversely, if no such improvement is seen with other applications, those applications will have a lower suggestion score for the target user. The application suggestions can be communicated to the computing device 108 for output.

[0113] In the context of generating application suggestions, consider FIG. 8 , which depicts an additional example 800 of a CGM platform user interface 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 suggested applications 804. As described throughout, the suggested applications 804 may be determined by the suggestion system 412 to improve a target user's health status based on the user's similarity to other users in the user population 110 whose health status has improved based on use of at least one of the suggested applications 804. In this case, the suggested applications 804 correspond to various third-party applications. In FIG. 8 , the user is depicted selecting the application “Nutrition by Neha” to download this application to the user's smartphone.

[0114] In particular, the suggestion system 412 can further enhance application suggestions as target users download and use the applications, thus reinforcing or negating previous suggestions and leading to improved future suggestions. For example, if the suggestion system 412 obtains blood glucose readings 118 from similar users that indicate similar improvements in health status, this feedback positively reinforces the correlation between the improved health status of the subset of users and the use of the particular application. Conversely, if blood glucose readings 118 from similar users do not indicate improvements in health status (or indicate deterioration in health status) for the similar users, this feedback negatively reinforces the correlation between the improved health status of the subset of users and the use of the particular application.

[0115] 8 , for example, when a user begins interacting 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 readings 118 and additional data. In this manner, the CGM platform 112 may continuously update the model 404 used to suggest applications based on feedback received from use of the application by the user population 110. In configurations in which the machine learning model 408 is updated based on feedback, the model may be configured as a reinforcement learning model, for example. The updated model 404 is then used to generate improved application suggestions.

[0116] Additionally, if the CGM platform 112 detects that use of a particular application is improving the user's health status based on 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 use of the "Nutrition by Neha" application has improved the user's neuropathy. It should be appreciated that this positive notification may motivate the user to continue using the application.

[0117] Verification Services FIG. 10 depicts an example implementation 1000 of a verification service user interface with which authorized users can interact to validate suggestions generated by a CGM platform.

[0118] In the illustrated example 1000, a display device 1002 is depicted displaying a user interface 1004 of a verification service 502. Broadly speaking, interface elements of the user interface 1004 allow an authorized user to interact with them to validate or reject a suggestion provided by the data analytics platform 126 and intended for delivery to a user, e.g., person 102. In response to receiving input through a user interface element that validates a suggestion (e.g., suggestion 320), the verification service 502 may route the suggestion to the respective user's computing device 108. As described above, the verification service 502 may also route the suggestion to the decision support platform 504. In response to receiving input through a user interface element of the user interface 1004 that rejects the suggestion, the verification service 502 does not communicate the suggestion to the computing device 108. Instead, the verification service may communicate a notification to the data analytics platform 126 indicating that the suggestion has been rejected. Additionally or alternatively, an authorized user of the validation service 502 may modify the suggestions and then transmit the modified suggestions to the user's computing device 108. As mentioned above, users authorized to validate suggestions provided by the data analytics platform 126 may include clinicians or other medical professionals qualified to provide health guidance to patients.

[0119] In the depicted example 1000, the user interface 1004 displays suggestion stubs 1006 provided by the data analytics platform 126 to the validation service 502. These stubs 1006 are configured as interactive elements with which a user can interact to review, validate, reject, and / or take some other course of action (e.g., modify) associated with each suggestion. While suggestion stubs are depicted in this example, other user interface elements may be used that allow an authorized user to review, validate, reject, and / or take some other course of action (e.g., modify) associated with each suggestion without departing from the spirit or scope of the described techniques.

[0120] In this example 1000, each of the stubs 1006 also includes a user or patient name, an indication of the prediction 318 on which the respective suggestion 320 is based, and an indication of the suggestion 320. A user 1008 is depicted performing a gesture in association with one of the stubs 1006 (in this case, a right-to-left swipe gesture) to expose further interface elements selectable to enable or reject the respective suggestion 320. It should be understood that the elements to enable or reject each suggestion may be exposed in other ways, such as being displayed as part of each stub without requiring an interaction such as a swipe gesture, or as part of a menu launched in response to some interaction on the stub (e.g., a right-click with a mouse). Although not shown, the stubs 1006 may also be selectable to expose a unique user interface that outputs the suggestions, i.e., the entire prediction and the entire suggestion for review, including options to enable and reject the suggestions and other options, as well as multiple options for processing the suggestions.

[0121] Fault detection and system configuration issues FIG. 11 depicts an example implementation 1100 of a user interface that outputs information about detected faults and system configuration issues associated with use of a CGM platform.

[0122] The depicted example depicts a display device 1102 displaying a fault detection and system configuration service user interface 1104. In one or more implementations, the fault detection and system configuration service may be included as part of or otherwise accessible to the CGM platform 112. It should also be understood that portions of the user interface 1102 may be provided to and displayed by other entities, such as manufacturers or service providers that offer devices or services that may be used in connection with the CGM system 104, via respective portals. These devices may include one or more of the computing device 108, the insulin delivery system 106, myriad physiological marker measurement devices, various components of the CGM system 104, etc.

[0123] The user interface 1104 displays stubs 1106 for multiple detected faults and system configuration issues. Although various faults and issues are displayed in the user interface 1104, the faults and / or issues displayed to a given entity (e.g., a particular manufacturer or a regulatory body such as the U.S. Food and Drug Administration (FDA)) may be limited (e.g., faults or issues related to a particular manufacturer's devices, or information required by law to be disclosed to a regulatory body). In contrast, users who authorize 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 issues related to the CGM platform 112.

[0124] In this example 1100, stubs 1106 include stubs for events (e.g., faults) reported by one or more devices communicatively coupled to or otherwise associated with CGM platform 112, such as reported by CGM system 104 with respect to sensors 202, computing devices 108, insulin delivery systems 106, third parties 306, just to name a few. Stubs 1106 also include stubs related to issues that arise in association with particular system configurations that include CGM system 104 but with different combinations of other devices, such as configurations with particular computing devices 108 (e.g., particular manufacturers), particular ensembles of computing devices 108 (e.g., cell phones corresponding to a first manufacturer and smart watches corresponding to a second manufacturer), particular insulin delivery systems (e.g., insulin pens versus insulin pumps from different manufacturers), particular firmware and software versions, etc.

[0125] The stubs 1106 also include stubs that convey one or more measures of reliability, such as the reliability of data acquired by various components (e.g., manufacturing lots of the sensors 202), system configuration, user associations with various demographics, etc. In one or more implementations, the measure of reliability is a confidence interval. Additionally, the stubs 1106 include stubs that indicate the use of platform features (e.g., application functionality and / or user interface elements corresponding to the CGM platform 112). This information can be used by the system developer to determine whether to continue development and / or provide support related to various features.

[0126] With respect to stubs describing events reported by one or more devices, it is difficult, if not impossible, for developers corresponding to the CGM platform 112 to test every combination of devices and CGM platform 112 applications, e.g., mobile phone and smartwatch applications, that may be used in connection with the CGM system 104 prior to deployment. Instead, those developers may limit testing to those device combinations most likely to be used (e.g., the most popular mobile devices or insulin delivery systems 106) and / or combinations suggested by the CGM platform 112 in content disseminated by the CGM platform 112, e.g., via publications, web pages, packaging, emails, advertisements, etc. To this extent, the developers may be aware of and fix only a subset of issues with the device combinations tested, but not issues with the combinations not tested.

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

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

[0129] This information can also be used by the model 404 to predict that users with a combination of devices will experience the same problems as a subset of the population. In particular, this information can be used to ensure that effective (e.g., safe) recommendations are generated and provided to these users. The data analytics platform 126 may use its capabilities to identify problems, such as faults, with different combinations of devices in various ways without departing from the spirit or scope of the described techniques.

[0130] In connection with stubs describing the use of the platform's features, this information may be used to determine whether to continue developing and / or providing support for various features, as described above. In one or more implementations, the data analytics platform 126 can analyze the data maintained on the storage device 120 to determine the costs to the company corresponding to the CGM platform 112 of supporting various features of the CGM platform 112, such as the various functionalities provided by its CGM system 104 and applications. As part of this, the data analytics platform 126 is configured to measure the variability, covariability, and statistical dependency between each functionality deployed by the CGM platform 112, such as the functionality of the CGM system 104 measuring the person's 102 temperature, the functionality of the CGM platform's 112 mobile phone application identifying likely occurrences of hypoglycemia during the night, the functionality of the CGM platform's 112 smartwatch application to use haptic feedback (e.g., vibration) in connection with output notifications, etc.

[0131] In one or more implementations, the data analytics platform 126 determines variation 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 potentially ceasing development or support. In the following description, the predetermined number of users is represented by the term m, and the number of features is represented by the term n. To this end, the data analytics platform 126 constructs an m×n matrix, with each cell of the matrix indicating whether a sampled user uses the corresponding feature. The data analytics platform 126 may determine that a user uses a feature in various ways, and use may be defined differently for different features. For example, the data analytics platform 126 may determine that a user has used a feature if data from the storage device 120 indicates that the user has used the feature, spent more than a threshold amount of time using or with the feature active, used the feature more than a threshold number of times, allowed the feature to be activated (e.g., allowed notifications), etc.

[0132] Using the m×n matrix, the data analytics platform 126 calculates a variability score for a given feature i as a function of the number a of users that "use" the given feature i from the number m of sampled users. In one example, the data analytics platform 126 calculates the variability according to:

number

[0133] where the term φ(i) represents a variation score. The data analytics platform 126 is also configured to calculate a covariation score for a given feature i and another feature j as a function of a number of users a that use the given feature i and as a function of a second number of users b that use another given feature j from a sampled number of users m. The data analytics platform 126 also calculates the covariation as a function of a third number of users c that simultaneously use the given feature i and the other feature j. In one example, the data analytics platform 126 calculates the covariation score according to:

number

[0134] where the term φ(i,j) represents the covariation score and the term φ(j) represents the variation score for any given feature j.

[0135] The data analysis platform 126 measures 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, the output of which 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., P-value) of the known independence test for each table with a significance level threshold. If the output meets the significance level threshold, the data analysis platform identifies the feature pair as dependent features.

[0136] Data analytics platform 126 then determines the cost of a given feature i as a function of the pairwise scores φ(i,j) for other features that are statistically dependent on the given feature i, plus the variance φ(i) of the given feature. Data analytics platform 126 may then present these scores to an authorized user (e.g., an engineer, a marketer, etc.) corresponding to CGM platform 112, such as by display via user interface 1104 or some other interface. It should be understood that the cost of a feature on CGM platform 112 may also be determined in other manners.

[0137] Exemplary Procedure This section describes exemplary proposed procedures based on continuous glucose monitoring (CGM). Aspects of the procedures may be implemented in hardware, firmware, software, or a combination thereof. The procedures are illustrated as a set of blocks specifying operations to be performed by one or more devices and are not necessarily limited to the order shown for performing the operations by the respective blocks. In at least some implementations, the procedures are performed by a data analysis platform, such as the data analysis platform 126 of the CGM platform 112, which utilizes the prediction system 316 and the recommendation system 412.

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

[0139] A blood glucose measurement provided by a CGM system worn by the user is obtained (block 1202). By way of example, the CGM platform 112 obtains a blood glucose measurement 118 detected by a 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 configured with a sensor 202 subcutaneously inserted into the skin 206 of the person 102, which continuously measures an analyte indicative of the person's 102's blood glucose to generate the blood glucose measurement. In one or more implementations, the CGM platform 112 obtains the blood glucose measurement 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). By way of example, the CGM platform 112 obtains the additional data 410 from various devices, sensors, applications, or services. Thus, in accordance with principles described herein, the additional data may be obtained from one or more “sources” different from the CGM system 104 to which the blood glucose reading 118 is provided. The additional data 410 may include, in addition to the blood glucose reading 118, at least one or more portions of CGM device data 214, supplemental data 304, third-party data 314, data from the IoT 114, etc.

[0141] The user's health indicators are predicted by processing the blood glucose measurements and the 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 the user population's past blood glucose measurements and the past additional data. By way of example, the prediction system 316 of the data analytics platform 126 generates a prediction 318 including a health indicator by processing the person's 102's blood glucose measurements 118 and the additional data 410 using one or more models 404. The one or more models 404 are generated based on the user population's 110's blood glucose measurements 118 and the additional data 410. 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] Recommendations are generated based on the user's health indicators (block 1208). By way of 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 predictions 318, the predictions 318 are obtained by a recommendation system 412 of the data analytics platform 126. The recommendation system 412 is configured to generate recommendations 320 based on the predictions 318. In some cases, the health indicators correspond to a predicted adverse health condition, such as a prediction that the user will develop type 2 diabetes within the next 40 months. In this scenario, the recommendation system 412 can generate the recommendations 320 based on logic that associates the predicted adverse health condition with one or more actions or behaviors that mitigate the predicted adverse health condition. As such, the recommendations 320 may include one or more actions or behaviors intended to mitigate the predicted adverse health condition.

[0143] At least one of the predictions or suggestions is communicated to one or more computing devices for output via a network (block 1210). For example, the data analytics platform 126 communicates the prediction 318 and / or the suggestion 320 to the computing device 108 for output. The computing device 108 can then display the prediction 318 and / or the suggestion 320 in a CGM interface. As shown in FIG. 6 , for example, the CGM user interface 602 displays the prediction 604 along with suggestions 606. In this example, the prediction 604 indicates that the user has a 76% chance of developing type 2 diabetes in 40 months. The suggestions 606 include one or more actions or behaviors the user can take to improve the user's predicted poor health. For example, in FIG. 6 , the suggestions 606 include a suggested customized meal plan, a suggested customized exercise plan, and a suggestion for obtaining guidance that can help the user stay on track with the suggested nutrition and exercise plan.

[0144] In one or more implementations, the prediction or suggestion may be communicated to the validation service 502 and / or the decision support platform 504 before or instead of being communicated to the user's computing device 108. In this manner, the validation service 502 and the decision support platform 504 may act as intermediaries between the data analytics platform 126 and the computing device 108. In scenarios in which the prediction or suggestion is communicated to the validation service 502, the validation service 502 may validate the suggestion 320. This means determining whether the suggestion is valid (e.g., secure) and can be further communicated to the decision support platform 504 and / or directly to the computing device 108. The validation service 502 may expose the suggestion 320 to users authorized by the service 502, such as clinicians, to validate the suggestion.

[0145] In response to the suggestion being validated (e.g., by a clinician or by logic in the validation service 502), the suggestion may be routed further to the decision support platform 504 or directly to the computing device 108. When the suggestion is not validated (i.e., rejected), the suggestion may not be routed further to the decision support platform 504 or directly to the computing device 108. Instead, the validation service 502 may modify the suggestion (e.g., according to clinician input) and / or provide a notification back to the data analytics platform 126 that the suggestion has been rejected. In this scenario, the data analytics platform 126 may be able to add an indication of the rejection as an input to the prediction system and initiate the generation of a different prediction 318 and / or suggestion 320. Indeed, the model 404 may be updated based on the validations and rejections received from the validation service 502. In a scenario in which the validation service 502 validates the suggestion 320, thereby allowing the suggestion 320 to be transferred directly to the computing device 108, the computing device 108 may output the suggestion 320 via a display, a speaker, haptic feedback, etc., as described above and below.

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

[0147] Updated health indicators are predicted by processing the user's updated blood glucose measurements and additional data using one or more models, and a notification based on the updated health indicators is communicated over the network to one or more computing devices for output (block 1212). As an example, the data analysis platform 126 continuously collects blood glucose measurements 118 and additional data 410 for the user. Thus, the prediction system 316 can predict updated health indicators 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 the CGM system 104 and the 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 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.

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

[0149] The blood glucose readings of the 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, the application interaction data describes application usage (e.g., use of an "app" by various users of the user population). As an example, the CGM platform 112 obtains blood glucose readings 118 detected by the CGM system 104 worn by the person 102 and maintains the blood glucose readings 118 in the storage device 120. Additionally, the CGM platform obtains application interaction data from various applications, such as applications provided by a third party 306.

[0150] An improvement in the health status of a subset of users of the user population is identified based at least in part on the blood glucose measurements (block 1304), and the improvement in the health status of the subset of users is correlated with use of a particular application based on the application interaction data (block 1306). By way of example, the CGM platform 112 can aggregate the application interaction data along with the blood glucose measurements 118 and additional data to determine whether the 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 status. The CGM platform 112 can then correlate the improvement or decline in the user's health with 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 status consistent with frequent use of a particular application, the CGM platform may determine that the particular application is correlated with the improvement.

[0151] Similar users with health conditions are identified (block 1308), and suggestions for using particular applications are communicated to one or more devices associated with the similar users (block 1310). As an example, the suggestion system 412 may identify similar users with health conditions and generate suggestions to the similar users to utilize particular applications that have helped improve the health conditions of a subset of the similar users. To do so, the suggestion system 412 may predict the probability of similar improvements in health conditions through use of particular applications by other users in the user population and suggest applications that are likely to improve the health of other similar users.

[0152] The application suggestions can be communicated to the computing device 108 for output. By way of example, as shown in FIG. 8, a CGM user interface 802 is depicted as displaying suggested applications 804. In this case, the suggested applications 804 correspond to various third-party applications. In FIG. 8, the user is depicted as selecting the application "Nutrition by Neha" in order to download this application to the user's smartphone.

[0153] Having described exemplary procedures according to one or more implementations, we now turn to exemplary systems and devices that can be utilized to implement the various techniques described herein.

[0154] Exemplary Systems and Devices 14 illustrates an example system generally at 1400 including an example computing device 1402 that is representative of one or more computing systems and / or devices that may implement various techniques described herein. This is illustrated through the inclusion of a CGM platform 112. The computing device 1402 may be, for example, a service provider's server, a device associated with a client (e.g., a client device), an on-chip system, and / or any other suitable computing device or 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, the computing device 1402 may further include a system bus or other data and command transfer system coupling various components together. The system bus may 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 utilizing any of a variety of bus architectures. Various other examples, such as control and data lines, are also contemplated.

[0156] The processing system 1404 is representative of functionality for performing one or more operations using hardware. Accordingly, the processing system 1404 is illustrated as including hardware elements 1410, which may be configured as processors, functional blocks, etc. This may include hardware implementations as application-specific integrated circuits or other logic devices formed using one or more semiconductors. The hardware elements 1410 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, a processor may be composed of semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In this context, processor-executable instructions may be electronically executable instructions.

[0157] The computer-readable medium 1406 is shown as including memory / storage 1412. The memory / storage 1412 represents memory / storage capacity associated with one or more computer-readable media. The 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.). The memory / storage component 1412 may include fixed media (e.g., RAM, ROM, fixed hard drives, etc.) as well as removable media (e.g., flash memory, removable hard drives, optical disks, etc.). The computer-readable medium 1406 may be configured in a variety of other ways, as described further below.

[0158] Input / output interface 1408 is representative of functionality that allows a user to input commands and information into computing device 1402 and also allows 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, cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., a capacitive or other sensor configured to detect physical touch), a camera (e.g., which may use visible or invisible wavelengths such as infrared frequencies to recognize movements as gestures without touch), etc. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, a tactile response device, etc. Accordingly, computing device 1402 may be configured in various ways, as described further below, to aid in user interaction.

[0159] Various techniques may be described herein 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 particular tasks or implement particular abstract data types. As used herein, the terms "module," "functionality," and "component" generally refer to software, firmware, hardware, or combinations thereof. Features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

[0160] An implementation of the described modules and techniques may be stored on or transmitted across some form of computer-readable media. Computer-readable media may include a variety of media that can be accessed by computing device 1402. By way of example, and not limitation, computer-readable media may include “computer-readable storage media” and “computer-readable signal media.”

[0161] A "computer-readable storage medium" may refer to a medium and / or device that enables persistent and / or non-transitory storage of information, as opposed to merely a signal transmission, carrier wave, or signal itself. Thus, a computer-readable storage medium refers to a non-signal-bearing medium. Computer-readable storage media include hardware, such as volatile and non-volatile, removable and non-removable media, and / or storage devices implemented in any method or technology suitable for storing information, such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, hard disk, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or other storage device, tangible media, or any article of manufacture suitable for storing desired information and that can be accessed by a computer.

[0162] A "computer-readable signal medium" may refer to a signal-bearing medium configured to transmit instructions to the hardware of the computing device 1402, such as over a network. Signal media 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. Signal media also includes any information delivery media. The term "modulated data signal" means a signal that has 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 include 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 noted above, hardware elements 1410 and computer-readable media 1406 are representative of modules, programmable device logic, and / or fixed device logic implemented in hardware that may be used in some embodiments to implement at least some aspects of the technology described herein, such as to execute one or more instructions. The hardware may include integrated circuits or components of on-chip systems, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations in silicon or other hardware. In this context, hardware may operate as a processing device that executes program tasks defined by instructions and / or logic embodied by the hardware, as well as hardware utilized to store instructions for execution, such as the computer-readable storage media described above.

[0164] Combinations of the foregoing may be used to implement the various techniques described herein. 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 functionality corresponding to the software and / or hardware modules. Thus, implementation of modules executable by the computing device 1402 as software may be achieved at least partially in hardware, for example, through the use of computer-readable storage media and / or hardware elements 1410 of the processing system 1404. The instructions and / or functionality may be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 1402 and / or processing systems 1404) to implement the techniques, modules, and examples described herein.

[0165] The techniques described herein may be supported by various configurations of computing device 1402 and are not limited to the 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 the "cloud" 1414 via platform 1416, as described below.

[0166] Cloud 1414 includes and / or is representative of a platform 1416 for resources 1418. Platform 1416 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of cloud 1414. Resources 1418 may include applications and / or data available while computer processing is running on a server remote from computing device 1402. 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 for connecting the computing device 1402 with other computing devices. The platform 1416 may also function to abstract the scaling of resources to provide a level of scale corresponding to the encountered demand of the resources 1418 implemented via the platform 1416. Thus, in embodiments of interconnected devices, implementation of the functionality described herein may be distributed throughout the system 1400. For example, functionality may be implemented partially on the computing device 1402 and partially via the platform 1416 that abstracts the functionality of the cloud 1414.

[0168] conclusion Although the systems and techniques have been described in language specific to structural features and / or methodological acts, it should be understood that the systems and techniques defined in the appended claims are not necessarily limited to the particular features or acts described. Rather, the particular features and acts are disclosed as example forms for implementing the claimed subject matter. [Explanation of symbols]

[0169] 112 CGM Platform 1402 Computing Devices 1404 Processing System 1406 Computer-readable medium 1408 I / O interface 1410 Hardware Elements 1412 memory / storage 1414 Cloud 1416 Platform 1418 resources

Claims

1. obtaining a blood glucose measurement provided by a continuous blood glucose monitoring (CGM) system worn by a user; acquiring additional data associated with the user, the additional data being acquired from one or more sources different from the CGM system; predicting the health indicator of the user by processing the blood glucose measurements and the additional data using one or more models, wherein the one or more models are generated based on past blood glucose measurements and past additional data of a user population; and generating recommendations based on the health indicators of the user; and communicating at least one of the prediction or the proposal over a network to one or more computing devices for output.

2. The method of claim 1 , wherein the health indicator comprises a predicted adverse health condition.

3. 3. The method of claim 2, wherein the suggestion is generated based on logic that associates the predicted adverse health condition with one or more actions or behaviors that mitigate the predicted adverse health condition, and the suggestion includes the one or more actions or behaviors.

4. 4. The method of claim 1, further comprising: predicting updated health indicators by processing the user's updated blood glucose measurements and additional data using the one or more models; and communicating a notification based on the updated health indicators to the one or more computing devices for output via the network.

5. The method of any one of claims 1 to 4, wherein the additional data associated with the user includes at least one of activity data, nutrition data, third party data, application interaction data, device usage data, or environmental data.

6. wherein the one or more models comprise machine learning models, and the method further comprises: obtaining the historical blood glucose measurements of the user population provided by CGM systems worn by users of the user population; obtaining the additional historical data for the user population from the one or more sources different from the CGM system; The method of claim 1 , further comprising: training the machine learning model using the past blood glucose measurements and the past additional data of the user population.

7. The method of any one of claims 1 to 6, wherein the CGM system detects the blood glucose measurements via a sensor inserted subcutaneously into the user's skin.

8. 1. A system comprising: a storage device for maintaining blood glucose measurements of a user population and additional data associated with users of said user population; one or more machine learning models trained using the blood glucose measurements of the user population and the additional data; A data analysis platform, predicting health indicators for individual users of the user population by processing the blood glucose measurements and the additional data of the individual users using the one or more machine learning models; generating recommendations based on the health indicators of the individual users; and a data analytics platform for performing the steps of: communicating at least one of the predictions or the proposals over a network to one or more computing devices for output.

9. 10. The system of claim 8, wherein the one or more computing devices are associated with the individual user, and the suggestions are configured for output via at least one of a display device or an audio device associated with the one or more computing devices.

10. 10. The system of claim 9, wherein the storage device obtains at least a portion of the blood glucose measurements and the additional data for the individual user from the one or more computing devices associated with the individual user.

11. The system of any one of claims 8 to 10, wherein the one or more computing devices are associated with a caregiver of the individual user.

12. The one or more computing devices are configured to include a verification service, the verification service comprising: obtaining the recommendations from the data analytics platform; publishing the suggestions via a user interface to one or more users who are authorized to activate the suggestions; In response to receiving validation of the suggestion by an authorized user, communicating the suggestion to the individual user's computing device; or 12. The system of claim 8, wherein the system is configured, in response to receiving a rejection of the suggestion by the authorized user, to communicate a notification to the data analytics platform that the suggestion has been rejected.

13. The one or more computing devices are configured to include a decision support platform, the decision support platform comprising: obtaining the predictions and the recommendations from the data analytics platform; and publishing, via a user interface, the suggestions to one or more users authorized to assist in managing the individual user's health.

14. 14. The system of any one of claims 8 to 13, further comprising at least one application programming interface (API), the API configured to expose calls to a third party that enable the third party to request the blood glucose measurements from the storage device.

15. The system of any one of claims 8 to 14, further comprising at least one application programming interface (API), said API configured to obtain at least a portion of said additional data from a third party.

16. One or more computer-readable storage media having instructions stored thereon, the instructions being executable by one or more processors to perform operations, the operations comprising: obtaining a blood glucose measurement provided by a wearable blood glucose monitoring system worn by a user; acquiring additional data associated with the user, the additional data being acquired from one or more sources different from the wearable blood glucose monitoring system; predicting the health indicator of the user by processing the blood glucose measurements and the additional data using one or more models, wherein the one or more models are generated based on past blood glucose measurements and past additional data of a user population; and generating recommendations based on the health indicators of the user; and communicating at least one of the prediction or the proposal over a network to one or more computing devices for output.

17. The one or more computer-readable storage media of claim 16 , wherein the health indicator comprises a predicted adverse health condition.

18. 20. The one or more computer-readable storage media of claim 17, wherein the suggestions are generated based on logic that associates the predicted adverse health condition with one or more actions or behaviors that mitigate the predicted adverse health condition, and the suggestions include the one or more actions or behaviors.

19. 19. The one or more computer-readable storage media of claim 16, further comprising: predicting an updated health indicator by processing the user's updated blood glucose measurement value and additional data with the one or more models; and communicating a notification based on the updated health indicator to the one or more computing devices for output via the network.

20. 20. The one or more computer-readable storage media of any one of claims 16-19, wherein the additional data associated with the user includes at least one of activity data, nutrition data, third-party data, application interaction data, device usage data, or environmental data.

21. wherein the one or more models comprise machine learning models, and the method comprises: obtaining the historical blood glucose measurements of the user population provided by wearable blood glucose monitoring systems worn by users of the user population; obtaining the additional historical data for the user population from the one or more sources different from the wearable blood glucose monitoring system; and training the machine learning model using the past blood glucose measurements and the past additional data of the user population.

22. 22. The one or more computer-readable storage media of any one of claims 16-21, wherein the wearable blood glucose monitoring system comprises a continuous blood glucose monitoring (CGM) system worn by the user.

23. 23. The one or more computer-readable storage media of claim 22, wherein the CGM system detects the blood glucose measurements via a sensor inserted subcutaneously into the user's skin.

24. acquisition means for acquiring blood glucose measurements provided by a continuous blood glucose monitoring (CGM) system worn by a user and additional data associated with said user; prediction means for predicting a health indicator of the user by processing the blood glucose measurement value and the additional data using one or more models; suggestion means for generating suggestions based on the health indicators of the user; and communication means for communicating at least one of said prediction or said suggestion over a network to one or more computing devices for output.

25. 25. The apparatus of claim 24, wherein the obtaining means obtains the additional data from one or more sources different from the CGM system.

26. maintaining, in one or more storage devices, blood glucose measurements of a user population and application interaction data associated with users of the user population, the application interaction data describing application usage; identifying an improved health status of the subset of users of the user population based at least in part on the blood glucose measurements; correlating the improvement in the health status of the subset of users with usage of specific applications based on the application interaction data; identifying similar users having the health condition; and communicating to one or more devices associated with the similar user a suggestion to use the particular application.

27. 27. The method of claim 26, wherein identifying the similar users is based on demographics of the similar users.

28. 28. The method of claim 26 or 27, wherein identifying similar users is based on patterns observed in blood glucose measurements of the similar users.

29. 29. The method of any one of claims 26-28, further comprising identifying the similar users as having the health condition based on blood glucose measurements provided by a continuous blood glucose monitoring (CGM) system worn by the users.

30. receiving application data indicative of the use of the particular application by the similar user; receiving blood glucose measurements from the similar user after the similar user begins using the particular application; 30. The method of any one of claims 26-29, further comprising providing the blood glucose measurements from the similar users as feedback to a model correlating the improvement in health status with the use of the particular application.

31. 31. The method of claim 30, wherein if the blood glucose measurements from the similar users indicate the improvement in the health status of the similar users, the feedback proactively reinforces the correlation between the improvement in the health status of the subset of users and the use of the particular application.

32. 32. The method of claim 30 or 31, wherein if the blood glucose measurements from the similar users indicate no improvement in the health status of the similar users, the feedback passively strengthens the correlation between the improvement in the health status of the subset of users and the use of the particular application.

33. The method of any one of claims 26 to 32, wherein the blood glucose measurements of the user population are obtained from wearable blood glucose monitoring devices.

34. The method of any one of claims 26 to 33, wherein the blood glucose measurements of the user population are obtained from a continuous blood glucose monitoring (CGM) system.

35. 1. A system comprising: one or more storage devices that maintain blood glucose measurements of a user population and application interaction data associated with users of the user population, the application interaction data describing application usage; A proposal system, identifying an improvement in health status of one or more users of the user population based at least in part on the blood glucose measurements; correlating the improvement in the health status of one or more users with usage of particular applications based on the application interaction data; identifying similar users having the health condition; and generating suggestions for similar users to utilize a particular application.

36. 36. The system of claim 35, wherein the suggestion system identifies the similar users based at least in part on demographics of the similar users.

37. 37. The system of claim 35 or 36, wherein the suggestion system identifies the similar users based at least in part on patterns observed in the blood glucose measurements of the similar users.

38. 38. The system of any one of claims 35 to 37, wherein the suggestion system identifies the similar users as having the health condition based on blood glucose measurements provided by a continuous blood glucose monitoring (CGM) system worn by the users.

39. The proposed system is receiving application data indicative of the use of the particular application by the similar user; receiving blood glucose measurements from the similar user after the similar user begins using the particular application; 39. The system of any one of claims 35 to 38, further configured to provide the blood glucose measurements from the similar users as feedback to a model correlating the improvement in health status with the use of the particular application.

40. 40. The system of claim 39, wherein if the blood glucose measurements from the similar users indicate an improvement in the health status of the similar users, the feedback proactively reinforces the correlation between the improvement in the health status of the one or more users and the use of the particular application.

41. 41. The system of claim 39 or 40, wherein if the blood glucose measurements from the similar users indicate no improvement in the health status of the similar users, the feedback passively strengthens the correlation between the improvement in the health status of the one or more users and the use of the particular application.

42. The system of any one of claims 35 to 41, wherein the blood glucose measurements of the user population are obtained from wearable blood glucose monitoring devices.

43. The system of any one of claims 35 to 42, wherein the blood glucose measurements of the user population are obtained from a continuous blood glucose monitoring (CGM) system.

44. One or more computer-readable storage media having instructions stored thereon, the instructions being executable by one or more processors to perform operations, the operations comprising: maintaining, in one or more storage devices, blood glucose measurements of a user population and application interaction data associated with users of the user population, the application interaction data describing application usage; identifying an improved health status of the subset of users of the user population based at least in part on the blood glucose measurements; correlating the improvement in the health status of the subset of users with usage of specific applications based on the application interaction data; identifying similar users having the health condition; and communicating a suggestion to use the particular application to one or more devices associated with the similar user.

45. 45. The one or more computer-readable storage media of claim 44, wherein identifying the similar users is based on demographics of the similar users.

46. 46. ​​The one or more computer-readable storage media of claim 44 or 45, wherein identifying the similar users is based on patterns observed in blood glucose measurements of the similar users.

47. 47. The one or more computer-readable storage media of any one of claims 44-46, wherein the operations further include identifying the similar users as having the health condition based on blood glucose measurements provided by a continuous blood glucose monitoring (CGM) system worn by the users.

48. receiving application data indicative of the use of the particular application by the similar user; receiving blood glucose measurements from the similar user after the similar user begins using the particular application; and providing the blood glucose measurements from the similar users as feedback to a model correlating the improvement in health status with the use of the particular application.

49. 49. The one or more computer-readable storage media of claim 48, wherein if the blood glucose measurements from the similar users indicate the improvement in the health status of the similar users, the feedback proactively reinforces the correlation between the improvement in the health status of the subset of users and the use of the particular application.

50. 50. The one or more computer-readable storage media of claim 48 or 49, wherein if the blood glucose measurements from the similar users indicate no improvement in the health status of the similar users, the feedback passively strengthens the correlation between the improvement in the health status of the subset of users and the use of the particular application.

Images