Diabetes prediction using glucose measurements and machine learning

Abstract

Diabetes prediction using glucose measurements and machine learning is described.SOLUTION: In one or more implementations, the observation analysis platform includes a machine learning model trained using historical glucose measurements and historical outcome data of a user population to predict a diabetes classification of an individual user. The historical glucose measurements of the user population may be provided by glucose monitoring devices worn by users of the user population, and the historical outcome data includes one or more diagnostic measurements obtained from a source independent of the glucose monitoring devices. Upon completion of the training, the machine learning model predicts a diabetes classification for the user based on glucose measurements collected by the wearable glucose monitoring device during an observation period spanning several days. The predicted diabetes classification may then be output, such as by generating one or more notifications or user interfaces based on the classification.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Diabetes prediction using glucose measurements and machine learning is described. In one or more implementations, an observational analytics platform includes a machine learning model trained using past glucose measurements and past outcome data of a user population to predict diabetes classification for individual users. The past glucose measurements of the user population may be provided by glucose monitoring devices worn by users of the user population, and the past outcome data includes one or more diagnostic measurements obtained from a source independent of the glucose monitoring devices. Once training is complete, the machine learning model predicts the user's diabetes classification based on the glucose measurements collected by the wearable glucose monitoring device over an observation period spanning several days. The predicted diabetes classification may then be output, such as by generating one or more notifications or user interfaces based on the classification. [Background technology]

[0002] Diabetes mellitus (Diabetes mellitus) is a metabolic condition affecting hundreds of millions of people and is one of the leading causes of death worldwide. However, with early detection and appropriate treatment, serious damage to the heart, blood vessels, eyes, kidneys, and nerves caused by diabetes can be largely avoided. Traditional tests for diabetes accepted by the clinical and regulatory community include hemoglobin A1c (HbA1c), fasting plasma glucose (FPG), and 2-hour plasma glucose (2Hr-PG). Both FPG and 2Hr-PG are part of the oral glucose tolerance test (OGTT), but FPG can be tested separately from the OGTT. In an FPG test, a blood sample is taken, and the results are used to classify the individual as "normal" (e.g., not diabetic), prediabetic, or diabetic. Generally, in two separate tests, a fasting blood glucose level below 100 mg / dL is considered normal, a fasting blood glucose level between 100 and 125 mg / dL is prediabetic, or a fasting blood glucose level above 126 mg / dL is diabetic.

[0003] After measuring fasting blood glucose for the FPG test, the OGTT requires the individual to drink a sugary liquid to spike their blood glucose levels. Many people, especially pregnant women, have difficulty tolerating this sugary drink. The individual's blood glucose level is then tested periodically over the next two hours using additional blood samples for the 2Hr-PG. A blood glucose level below 140 mg / dL is considered "normal," while a level above 200 mg / dL two hours after drinking the sugary drink indicates diabetes. A level between 140 and 199 mg / dL indicates prediabetes.

[0004] Unlike the OGTT's FPG and 2Hr-PG tests, which each measure blood glucose levels at a single point in time, the HbA1c test measures a user's average blood glucose levels over the past two to three months. However, the HbA1c test does not measure glucose directly; instead, it measures the percentage of glucose bound to hemoglobin. Note that as glucose accumulates in the blood, it binds to hemoglobin, the oxygen-carrying protein in red blood cells. Because red blood cells live in a person's body for approximately two to three months, the HbA1c test shows the average blood glucose level over the past two to three months. Unlike the FPG and 2Hr-PG tests, fasting is not required to perform the HbA1c test. However, like the FPG and 2Hr-PG tests, measuring a person's HbA1c level requires a blood sample to be taken and used to generate a reading. An HbA1c level of 6.5% or higher on two separate tests indicates that the person has diabetes, while an HbA1c level of 5.7 to 6.4% generally indicates that the person has prediabetes. An HbA1c level of less than 5.7% is considered normal.

[0005] Each of these traditional tests administered to screen for or diagnose diabetes has various drawbacks that often lead to an inaccurate diagnosis. Traditional diabetes tests are often inaccurate because administering a given test to an individual on different days can result in inconsistent diagnoses due to various external factors that can cause fluctuations in blood glucose levels, such as illness, stress, increased physical activity, and pregnancy. In contrast, HbA1c tests measure average glucose levels over the past two to three months, but HbA1c test results are significantly affected by the user's blood glucose levels in the weeks leading up to the test. Thus, HbA1c test results can be significantly affected by changes in blood properties over the three-month period, such as pregnancy or illness. Furthermore, because HbA1c tests do not directly measure blood glucose levels, such tests may be inaccurate for individuals with various blood disorders, such as anemia, or rare forms of hemoglobin.

[0006] Furthermore, such conventional tests often have low concordance rates, meaning that the tests do not always detect diabetes in the same individual. This lack of consistency between test types can lead to an inaccurate diagnosis or failure to determine an appropriate treatment plan. For example, a user may have a high fasting blood glucose level but an HbA1c score within the normal range. In such a scenario, different physicians may reach different conclusions regarding whether the user has diabetes and the user's type of treatment plan.

[0007] Finally, administering these tests to various individuals, such as pregnant women, also has various limitations and drawbacks. For example, these conventional diabetes tests require the user to visit a clinic or laboratory to draw a blood sample, which is time-consuming, expensive, and can be painful for some users. Each of these factors may combine to create psychological barriers that prevent users from being tested for diabetes, thereby mitigating the benefits that could be achieved through early detection. Furthermore, many of these conventional tests require the user to be in a fasting state, which can be difficult or even dangerous for some users, including pregnant women. Summary of the Invention [Means for solving the problem]

[0008] To overcome these problems, diabetes prediction using glucose measurements and machine learning is utilized. In one or more implementations, the observational analytics platform includes a machine learning model trained using past glucose measurements and past outcome data of a user population to predict diabetes classification for individual users. The past glucose measurements of the user population may be provided by glucose monitoring devices worn by the users of the user population, and the past outcome data includes one or more diagnostic measurements obtained from a source independent of the glucose monitoring device. For example, the past outcome data may indicate whether each user of the user population has been clinically diagnosed with diabetes based on one or more diagnostic measures, such as HbA1c, FPG, or 2Hr-PG.

[0009] Once training is complete, the machine learning model predicts the user's diabetes classification based on the glucose measurements collected by the wearable glucose monitoring device during an observation period spanning several days. In particular, the machine learning model generates this prediction based on training with past glucose measurements and past outcome data of a user population. The diabetes classification may describe the user's status during the observation period (e.g., one of diabetes, prediabetes, or no diabetes) or whether the user is predicted to experience adverse effects of diabetes. The predicted diabetes classification may then be output, such as by generating one or more notifications or user interfaces based on the classification, such as a report directed to a healthcare provider that includes the diabetes classification (e.g., the person is predicted to have diabetes) or a notification directed to the person instructing the person to contact a healthcare provider.

[0010] 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]

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

[0012] [Figure 1] FIG. 1 is a diagram of an environment in an example implementation operable to use the techniques described herein. [Figure 2] 2 depicts the example wearable glucose monitoring device of FIG. 1 in more detail. [Figure 3] 1 depicts an example of an implementation in which diabetes-related data, including glucose measurements, is routed to different systems related to diabetes prediction. [Figure 4] 1 depicts in more detail one example of an implementation of the prediction system of FIG. 1 in which diabetes classification is predicted using machine learning. [Figure 5]1 depicts in more detail an example of an implementation of the prediction system of FIG. 1 in which a machine learning model is trained to predict diabetes classification. [Figure 6] 1 depicts one example implementation of a user interface displayed to inform a user about a diabetes prediction generated based on glucose measurements collected during an observation period. [Figure 7] 1 depicts one example implementation of a user interface displayed to report a user's diabetes prediction along with other information generated in connection with the diabetes prediction. [Figure 8] 1 depicts one example of an implementation of a user interface that may be displayed to collect additional data that can be used as input to a machine learning model for generating a diabetes prediction. [Figure 9] 1 depicts the steps in an example implementation in which a machine learning model predicts diabetes classification based on a user's glucose measurements collected by a wearable glucose monitoring device during an observation period. [Figure 10] 1 depicts the steps in an example implementation in which a machine learning model is trained to predict diabetes classification based on historical glucose measurement and outcome data for a user population. [Figure 11] 1 illustrates an example system including various components of an example device that may be implemented as any type of computing device described and / or utilized with reference to FIGS. 1-10 for implementing embodiments of the technology described herein. DETAILED DESCRIPTION OF THE INVENTION

[0013] overview Traditional tests for diabetes accepted by the clinical and regulatory communities include hemoglobin A1c (HbA1c), fasting plasma glucose (FPG), and 2-hour plasma glucose (2Hr-PG). Both FPG and 2Hr-PG are part of the oral glucose tolerance test (OGTT), but FPG can be tested separately from the OGTT. However, such traditional tests often have low concordance; that is, these tests do not always detect diabetes in the same individual. Due to various factors that affect blood glucose levels, a given test administered to individuals on different days can result in inconsistent diagnoses. There are also various limitations and drawbacks to administering these tests to different individuals, such as pregnant women.

[0014] To overcome these problems, diabetes prediction using glucose measurements and machine learning is utilized. To classify people as having diabetes, one or more machine learning models (e.g., regression models, neural networks, reinforcement learning agents) are generated using past glucose measurements and past outcome data of a user population to predict diabetes classification for individual users. The past glucose measurements of the user population may be provided by glucose monitoring devices worn by users of the user population. In contrast, the past outcome data used for training may vary depending on the classification the machine learning model is configured to output. Typically, the past outcome data includes one or more diagnostic measures obtained from a source independent of the glucose monitoring device. For example, the past outcome data may indicate whether each user of the user population has been clinically diagnosed with diabetes based on one or more diagnostic measures, such as HbA1c, FPG, or 2Hr-PG (or OGTT as a combination of FPG and 2Hr-PG).

[0015] Regardless of the particular outcome data used, upon training, the machine learning model is able to predict diabetes classification based on the individual's glucose measurements collected during an observation period. In other words, the machine learning model learns to identify patterns in glucose measurements that correlate with the presence or absence of diabetes. The machine learning model may, for example, learn particular features of glucose data that are highly correlated with the presence or absence of diabetes. Examples of features that the machine learning model may learn to correlate with diabetes classification include, by way of example and not limitation, a time scale above the threshold, a rate of change measure, observation period abnormalities, and the mean or median glucose value over the observation period. In particular, many of the features that the machine learning model learns to correlate with diabetes classification, such as a time scale above the threshold and a rate of change measure, are features that cannot be simply determined using traditional diagnostic tests that output results based on blood samples measured at a single point in time.

[0016] Once the machine learning model is trained, it is used to predict a user's diabetes classification based on glucose measurements collected by a wearable glucose monitoring device worn by the user over an observation period spanning several days. This "diabetes classification," in some implementations, may indicate whether the user has diabetes or is at risk for developing diabetes, and / or indicate the adverse effects the user is predicted to experience. By way of example, a user may monitor their glucose to predict whether they have diabetes (e.g., type 1 diabetes, type 2 diabetes, gestational diabetes mellitus (GDM), cystic fibrosis diabetes, etc.) or are at risk for developing diabetes (e.g., prediabetes), and / or are predicted to experience adverse effects associated with diabetes (e.g., retinopathy, neuropathy, comorbidities, dysglycemia, macrosomia requiring a cesarean section, neonatal hypoglycemia, etc.). In a similar manner to how a diabetes classification indicating a type of diabetes (e.g., Type 2, GDM, etc.) is predicted, in one or more implementations, the machine learning model may additionally or alternatively be configured to predict a type of prediabetes (e.g., impaired fasting glucose (IFG) or impaired glucose tolerance (IGT)). Alternatively or additionally, the diabetes classification may correspond to a risk level of having or developing diabetes, such as high risk, low risk, or no risk. In operation, the diabetes classification predicted by the machine learning model may be used (e.g., by a medical professional) to treat the person or develop a treatment plan similar to how the person would be treated (e.g., type of diabetes and / or prone to experiencing adverse effects) if clinically diagnosed using conventional testing.

[0017] However, unlike such traditional tests that are traditionally performed in a laboratory or clinic, the use of a wearable glucose monitoring device allows glucose measurements to be collected remotely. For example, the wearable glucose monitoring device may be mailed or otherwise provided to a user by, for example, a wearable glucose monitoring device provider, a pharmacy, a medical testing laboratory, a telemedicine service, etc. The user may then wear the wearable glucose monitoring device by, for example, continuously wearing the device at home or at work for the duration of the observation period.

[0018] Once obtained, the user can insert the sensor of the wearable glucose monitoring device into the user's body, such as by using an automatic sensor applicator. Unlike the blood draw required for conventional tests such as HbA1c, FPG, and 2Hr-PG, user-initiated application of the glucose monitoring device is largely painless and does not require blood draws, the consumption of sugary drinks, or fasting. Furthermore, the automatic sensor applicator allows the user to implant the sensor into the user's skin without the assistance of a clinician or healthcare provider. While an automatic sensor applicator is discussed, the wearable glucose monitoring device may be applied or otherwise worn by a person without the assistance of a medical professional (or the medical professional may simply apply the wearable to the person), such as without an automatic sensor applicator, or by peeling off a protective layer of adhesive and attaching the adhesive to the person, without departing from the spirit or scope of the technology described herein. Once the sensor is inserted into the user's skin, the wearable glucose monitoring device monitors the person's glucose over an observation period of several days. It should also be understood that in some implementations, the sensor may not be inserted into the person's skin. Instead, the sensor may simply be placed against a person's skin in such implementations, such as an adhesive patch. Nevertheless, the sensor of the wearable glucose monitoring device may continuously detect an analyte indicative of the person's glucose, allowing for the generation of a glucose measurement.

[0019] The glucose measurements collected during the observation period and / or data derived by preprocessing the glucose measurements are provided as input to a trained machine learning model. The trained machine learning model processes the glucose measurements to predict the user's diabetes classification. Broadly speaking, the diabetes classification represents the user's status during the observation period, such as diabetes (or a specific type of diabetes, such as GDM or type 2 diabetes), prediabetes (or a specific type of prediabetes, such as IFG or IGT), or not diabetes. Notably, unlike traditional tests, the diabetes classification predicted by the machine learning model is based on glucose values ​​observed over several days. As such, the prediction is more accurate than tests that rely on blood samples taken at a single time point. Furthermore, unlike HbA1c tests, which are an indirect measurement of blood glucose levels and may be affected by recent changes in blood glucose levels caused by external factors or conditions, such as illness or pregnancy, the diabetes classification predicted by the machine learning model is based on blood glucose measurements obtained directly during the current observation period.

[0020] The predicted diabetes classification is then presented to the user, a physician, or the user's guardian, such as by displaying an indication of the diabetes classification via a user interface. In addition to a visualization of the glucose measurements, other information, such as other statistics derived from the glucose measurements, may also be displayed. In some cases, the predicted diabetes classification is presented in a glucose observation report. The glucose observation report may also include one or more treatment options for the user, a visual representation of the glucose measurements collected by the glucose monitoring device during the observation period, the user's glucose statistics generated based on the collected glucose measurements, a severity level, next steps (e.g., for a physician, medical professional, or the user), a request for follow-up, a request to order additional sensors for the wearable glucose monitoring device, activity levels, trends in glucose or other markers, patterns of glucose or other markers, patterns of exercise, interpretations of the glucose measurements, or blood glucose-related activities. Thus, unlike traditional blood glucose test results, a glucose observation report generated by one or more machine learning models may include a detailed analysis of the prediction and various treatment options. It should be understood that the diabetes classification and information related to such classification may be provided in a variety of ways, including, for example, as an audio signal via a speaker or digital assistant.

[0021] Advantageously, using a wearable glucose monitoring device and machine learning to generate predictions that classify people as having a type of diabetes eliminates many of the unpleasant aspects of the diagnostic tests described above and does not limit who can be tested. For example, unlike HbA1c, pregnant women can safely wear a wearable glucose monitoring device during the observation period. Furthermore, because the machine learning model is applied to glucose records collected over several days, the inconsistencies associated with traditional testing are reduced, thereby improving the accuracy of predictions compared to traditional testing based on a single blood sample. By accurately predicting diabetes classification and notifying the user, healthcare provider, and / or telehealth service, the described machine learning model enables early detection of diabetes and identifies treatment options that can be taken to alleviate potentially harmful health conditions before the user's diabetes worsens. In doing so, serious damage to the heart, blood vessels, eyes, kidneys, and nerves, as well as death, due to diabetes, can be largely avoided.

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

[0023] Example Environment 1 is a diagram of an environment 100 in one example of an implementation operable to use the glucose measurements and diabetes prediction using machine learning described herein. The illustrated environment 100 includes a person 102 shown wearing a wearable glucose monitoring device 104. The illustrated environment also includes an observation kit provider 106 and an observation analysis platform 108.

[0024] In the depicted example 100, the wearable glucose monitoring device 104 is shown being provided to the person 102 by an observation kit provider 106, e.g., as part of an observation kit. The wearable glucose monitoring device 104 may be provided as part of the observation kit for purposes of monitoring the glucose of the person 102 over an observation period lasting, e.g., several days. By way of example, the person 102 may monitor their glucose to predict whether they have diabetes (e.g., type 1 diabetes, type 2 diabetes, gestational diabetes mellitus (GDM), cystic fibrosis diabetes, etc.) or whether they are at risk for developing diabetes (e.g., prediabetes) and / or whether they are expected to experience adverse outcomes associated with diabetes (e.g., comorbidities, dysglycemia, macrosomia requiring a cesarean section (C-section), neonatal hypoglycemia, etc.). Instructions may be provided to the person 102 in connection with the observation period. The instructions instruct person 102 to perform one or more actions during the observation period, for example, instructing person 102 to consume a beverage or a specific meal (e.g., the same beverage consumed in connection with an OGTT), avoid one or more specific foods, exercise, rest, etc. In one or more implementations, the instructions may be provided as part of an observation kit, for example, as written instructions. Alternatively, or additionally, the observation analysis platform 108 may communicate the instructions to a computing device associated with person 102 and output them via the computing device associated with person 102 (e.g., for display or audio output). The observation analysis platform 108 may provide these instructions for output after a predetermined time (e.g., two days) of the observation period has elapsed and / or based on a pattern of obtained glucose measurements. In connection with providing such instructions, the wearable glucose monitoring device 104 automatically monitors person 102's glucose level after performing the instructed activity, such as by monitoring person 102's glucose change after consuming the instructed meal, performing the instructed exercise, etc.

[0025] Although described throughout as lasting several days, in one or more implementations, the observation period may be variable, such that the observation period may end once enough glucose measurements have been collected to accurately predict the diabetes classification of the person 102. For example, in some cases, glucose measurements of the person 102 over just a few hours may be processed to predict with statistical certainty that the person 102 has diabetes. In this case, the length of the observation period may be several hours rather than days. However, typically, the observation period lasts several days to obtain data from which features can be extracted to describe day-to-day fluctuations in glucose and to explain or prevent erroneous predictions that cannot explain abnormal measurements or observations.

[0026] To this end, the monitoring kit provider 106 may represent one or more of various entities involved in obtaining a prediction regarding whether the person 102 has diabetes or is predicted to suffer from the adverse effects of diabetes. For example, the monitoring kit provider 106 may represent a provider of the wearable glucose monitoring device 104 and, if it also corresponds to the provider of the wearable glucose monitoring device 104, a provider of a platform that monitors and analyzes glucose measurements obtained therefrom, such as the observation analysis platform 108. Alternatively or additionally, the monitoring kit provider 106 may correspond to, for example, a healthcare provider (e.g., a primary care physician, OB / GYN, endocrinologist), a clinic, a hospital, an insurance provider, a medical testing laboratory, or a telemedicine service. Alternatively or additionally, the monitoring kit provider 106 may correspond to a pharmacist or pharmacy that has a physical brick-and-mortar store and / or may provide services online. It should be understood that these are just a few examples, and the monitoring kit provider 106 may represent different entities without departing from the spirit or scope of the described technology.

[0027] With this in mind, providing the wearable glucose monitoring device 104 to the person 102 may occur in a variety of ways in accordance with the described techniques. For example, the wearable glucose monitoring device 104 may be given to the person 102 at a clinic, hospital, medical testing laboratory, or brick-and-mortar pharmacy, e.g., as part of an observation kit. Alternatively, the wearable glucose monitoring device 104 may be mailed to the person 102 from, e.g., a wearable glucose monitoring device 104 provider, a pharmacy, a medical testing laboratory, a telehealth service, etc. Indeed, the person 102 may obtain the wearable glucose monitoring device 104 for the observation period in other ways in one or more implementations.

[0028] Regardless of how the wearable glucose monitoring device 104 is acquired by the person 102, the device is configured to monitor the glucose of the person 102 during an observation period lasting a period spanning several days. The wearable glucose monitoring device 104 may be configured with, for example, a glucose sensor that continuously detects analytes indicative of the person's 102's glucose and enables the generation of glucose measurements. In the illustrated environment 100, these measurements are represented as glucose measurements 110. In one or more implementations, the wearable glucose monitoring device 104 is a continuous glucose monitoring (“CGM”) system. As used herein, the term “continuous” used in connection with glucose monitoring may refer to the ability of the device to generate measurements substantially continuously, such that the device may be configured to generate glucose measurements 110 at time intervals (e.g., every hour, every 30 minutes, every 5 minutes, etc.), in response to establishing a communication coupling with a different device (e.g., when a computing device establishes a wireless connection with the wearable glucose monitoring device 104 to retrieve one or more of the measurements), etc. The functionality of the wearable glucose monitoring device 104 to generate glucose measurements 110, along with further aspects of the device's configuration, are discussed in more detail with respect to FIG.

[0029] The wearable glucose monitoring device 104 may be configured similarly to wearable glucose monitoring devices used to treat diabetes, although in one or more implementations, the wearable glucose monitoring device 104 may be configured differently from devices used in treatment. These different configurations may be deployed to control for confounding factors during the observation period and to obtain measurements that accurately reflect the effects of the user's normal daily behavior on glucose. This may include, for example, limiting and / or completely preventing the user from examining these measurements during the observation period. By preventing the user from examining glucose measurements 110 during the observation period, the observation configuration further prevents the user from seeing or otherwise observing glucose measurement events (e.g., glucose spikes) and modifying behavior to counter such events.

[0030] In some cases, the wearable glucose monitoring device 104 may be a specialized device designed specifically for the purpose of collecting a user's glucose measurements over an observation period spanning several days so that a diabetes classification can be generated, which may be distinguished in one or more respects from wearable glucose monitoring devices worn by users to treat diabetes. In other examples, such wearable glucose monitoring devices 104 may have the same hardware characteristics as wearable glucose monitoring devices used to treat diabetes, but may include software that disables or enables different functionality, such as software that prevents a user from viewing glucose measurements 110 during the observation period. In these examples, features that were disabled during the observation period may be enabled after the observation period ends, thereby allowing the user to access previously disabled features, such as the ability to view glucose measurements in substantially real time.

[0031] Different configurations may also be based on differences between how glucose measurements 110 are used in connection with an observation period for diabetes prediction and how the measurements are used in connection with diabetes treatment. In treatment, continuous or near-continuous receipt and output of glucose measurements, substantially as those measurements are generated, may be used to inform treatment decisions, for example, to help a person or their caregiver decide what to eat, how to administer insulin, whether to contact a healthcare provider, etc. In these scenarios, timely (e.g., substantially real-time) knowledge of measurements and / or measurement trends may be important to effectively mitigate potentially serious adverse effects. In contrast, receipt and output of glucose measurements to the person being observed (or caregiver) as those measurements are generated may not be necessary in connection with diabetes prediction in these scenarios. Instead, glucose measurements generated for diabetes prediction are processed to generate an accurate prediction regarding diabetes at the end of the observation period or after some other period (e.g., when enough measurements have been generated to achieve statistical certainty).

[0032] Based on such differences in how glucose measurements are used, a wearable glucose monitoring device 104 may have more local storage than a wearable glucose measuring device used for diabetes treatment, e.g., 10-15 days' worth of glucose measurement storage in an observation configuration versus 3 hours' worth of glucose measurement storage in a treatment configuration. The larger storage capacity of the wearable glucose monitoring device 104 may be suitable for storing glucose measurements 110 for the duration of an observation period. In contrast, a wearable glucose measuring device used for treatment may be configured to offload glucose measurements such that, once measurements are suitably offloaded, they are not stored locally on the device. By way of example, a wearable glucose measuring device used for treatment may offload glucose measurements by transmitting them to an external computing device via a wireless connection, e.g., at predetermined time intervals and / or in response to establishing or re-establishing a connection with the computing device.

[0033] To the extent that the wearable glucose monitoring device 104 may be configured to store glucose measurements 110 throughout an observation period, in one or more implementations the wearable glucose monitoring device 104 may be configured without wireless transmission means, e.g., without any antenna for wirelessly transmitting glucose measurements 110 and without hardware or firmware for generating packets for such wireless transmission. Alternatively, the wearable glucose monitoring device 104 may be configured with hardware that communicates glucose measurements 110 via a physical wired connection. In such a scenario, the wearable glucose monitoring device 104 may be "plugged in" to retrieve glucose measurements 110 from the device's storage.

[0034] Thus, the wearable glucose monitoring device 104 may be configured with one or more ports to enable wired transmission of glucose measurements to an external computing device. Examples of such physical connections may include, for example, a micro-universal serial bus (USB) connection, a mini-USB connection, and a USB-C connection. While the wearable glucose monitoring device 104 may be configured for extraction of glucose measurements 110 via a wired connection as described above, in different scenarios, the wearable glucose monitoring device 104 may alternatively or additionally be configured to offload glucose measurements 110 over one or more wireless connections. Implementations involving wired and / or wireless transmission of glucose measurements are further described below.

[0035] In addition to differences in storage and communication, the wearable glucose monitoring device 104 may also include one or more sensors or sensor circuits that are configured differently than devices designed for diabetes treatment. For example, the sensors and circuitry (e.g., including measurement algorithms) of a wearable glucose monitoring device used to treat diabetes may be optimized for a measurement range extending from 40 mg / dL to 400 mg / dL. This is because treating diabetes often involves determining actions to take to mitigate severe glycemic events, such as hypoglycemia and hyperglycemia, that may occur toward the end of the range. However, measurement fidelity across a wide range may not be necessary to predict diabetes. Rather, a diabetes prediction may be suitably generated in association with a narrower range, such as a range of glucose measurements extending from 120 mg / dL to 240 mg / dL. Accordingly, the wearable glucose monitoring device 104 may include one or more sensors or sensor circuits optimized to produce measurements in such a narrower range. It should be understood that the above differences are merely examples of how the wearable glucose monitoring device 104 may differ from wearable glucose monitoring devices configured for the treatment of diabetes, and that the wearable glucose monitoring device 104 may differ in various ways from these devices without departing from the spirit or scope of the described technology.

[0036] When the wearable glucose monitoring device 104 generates a glucose measurement 110, the measurement is provided to the observational analysis platform 108. As described above, the glucose measurement 110 may be communicated to the observational analysis platform 108 via a wired and / or wireless connection. For example, in scenarios in which the observational analysis platform 108 is implemented partially or fully on the wearable glucose monitoring device 104, the glucose measurement 110 may be transferred from the device's local storage to the device's processing system via a bus. In scenarios in which the wearable glucose monitoring device 104 is configured to generate a prediction of a diabetes classification by processing the glucose measurement 110, the wearable glucose monitoring device 104 may also be configured to provide the predicted diabetes classification as an output, for example, by communicating the diabetes classification to an external computing device. In other scenarios, the glucose measurement 110 may be processed by an external computing device configured to predict a diabetes classification.

[0037] In one or more implementations, the wearable glucose monitoring device 104 is configured to transmit glucose measurements 110 to the external device via a wired connection with the external device, e.g., via USB-C or some other physical communication coupling. Here, a connector may be plugged into the wearable glucose monitoring device 104, or the wearable glucose monitoring device 104 may be inserted into an apparatus having a receptacle that interfaces with corresponding contacts on the device. The glucose measurements 110 may then be retrieved from the storage of the wearable glucose monitoring device 104 via this wired connection and transferred to the external device, for example, via a wired connection. Such a connection may be used in scenarios in which the wearable glucose monitoring device 104 is mailed by the person 102 after an observation period to a healthcare provider, telemedicine service, provider of the wearable glucose monitoring device 104, medical testing laboratory, or the like. To this end, an observation kit (not shown) may include packaging (e.g., an envelope or box) for mailing the wearable glucose monitoring device 104 to such an entity after observation. Such a connection may also be used in scenarios where the person 102 removes the wearable glucose monitoring device 104 after the observation period, such as at a clinic or hospital (or other facility of a healthcare provider), a pharmacy, or a medical testing laboratory. Alternatively or additionally, scenarios involving a wired connection may involve the person 102 plugging the wearable glucose monitoring device 104 into an external computing device after the testing period, for example, using a cord provided as part of an observation kit. In these scenarios, the external computing device may communicate the glucose measurements 110 to the observation analysis platform 108 over a network (not shown), such as the Internet.

[0038] Alternatively or additionally, providing the glucose measurements 110 to the observational analysis platform 108 may involve the wearable glucose monitoring device 104 communicating the glucose measurements 110 via one or more wireless connections. For example, the wearable glucose monitoring device 104 may wirelessly communicate the glucose measurements 110 to an external computing device, such as a mobile phone, tablet device, laptop, smartwatch, other wearable health tracker, etc. Accordingly, the wearable glucose monitoring device 104 may be configured to communicate with the external device using one or more wireless communication protocols or technologies. By way of example, the wearable glucose monitoring device 104 may communicate with the external device using one or more of Bluetooth (e.g., a Bluetooth Low Energy link), near field communication (NFC), a Long Term Evolution (LTE) standard such as 5G, etc. The wearable glucose monitoring device 104 may be configured with a corresponding antenna and other wireless transmission means in scenarios where the glucose measurements 110 are communicated to an external device for processing. In these scenarios, the glucose measurements 110 may be communicated to the observation analysis platform 108 in a variety of ways, such as at predetermined time intervals (e.g., daily, hourly, or every 5 minutes), in response to the occurrence of some event (e.g., filling the storage buffer of the wearable glucose monitoring device 104), or in response to the end of the observation period.

[0039] Thus, regardless of where the observational analysis platform 108 is implemented, it obtains glucose measurements 110 generated by the wearable glucose monitoring device 104. In one or more implementations, the observational analysis platform 108 may be implemented in whole or in part within the wearable glucose monitoring device 104. Alternatively, or additionally, the observational analysis platform 108 may be implemented in whole or in part using one or more computing devices external to the wearable glucose monitoring device 104, such as one or more computing devices associated with the person 102 (e.g., a mobile phone, a tablet device, a laptop, a desktop, or a smartwatch) or one or more computing devices associated with a service provider (e.g., a healthcare provider, a telehealth service, a service corresponding to the provider of the wearable glucose monitoring device 104, a medical testing laboratory service, etc.). In the latter scenario, the observational analysis platform 108 may be implemented at least in part on one or more server devices.

[0040] In the depicted example 100, the observational analytics platform includes a storage device 112. In accordance with the described techniques, the storage device 112 is configured to maintain the glucose measurements 110. The storage device 112 may represent one or more databases and other types of storage capable of storing the glucose measurements 110. The storage device 112 may also store a variety of other data, such as demographic information describing the person 102, information about a healthcare provider, information about an insurance provider, payment information, prescription information, determined health metrics, account information (e.g., username and password), etc. As discussed in more detail below, the storage device 112 may also maintain data for other users of the user population.

[0041] In the depicted example 100, the observational analytics platform 108 also includes a prediction system 114. The prediction system 114 represents functionality that processes the glucose measurements 110 to generate diabetes predictions, such as predicting whether the person 102 has diabetes (e.g., type 2 diabetes, GDM, cystic fibrosis diabetes, etc.) or is at risk for developing diabetes (e.g., prediabetes) and / or whether the person 102 is expected to experience adverse outcomes associated with diabetes (e.g., comorbidities, dysglycemia, macrosomia requiring a cesarean section, neonatal hypoglycemia, etc.). As discussed in more detail below, the prediction system 114 uses machine learning to predict diabetes classification. The use of machine learning may include, for example, leveraging one or more models generated using machine learning techniques and using past glucose measurements and past outcome data of a user population.

[0042] The depicted example 100 also includes a diabetes classification 116 that may be output by the prediction system 114. In accordance with the described techniques, the diabetes classification 116 may indicate whether a person is predicted to have diabetes or is predicted to suffer from adverse effects related to diabetes. The diabetes classification 116 may also be used to generate one or more notifications or user interfaces based on the classification, such as a report directed to a healthcare provider that includes the diabetes classification (e.g., that the person is predicted to have diabetes) or a notification directed to the person 102 that instructs the person to contact a healthcare provider. Examples of user interfaces that may be generated based on the diabetes classification 116 are described in more detail with respect to FIGS. 6 and 7. Consider the following discussion of FIG. 2 in the context of measuring glucose, e.g., continuously, and obtaining data describing such measurements.

[0043] Figure 2 depicts in more detail one example implementation 200 of the wearable glucose monitoring device 104 of Figure 1. In particular, the illustrated example 200 includes a top view and a corresponding side view of the wearable glucose monitoring device 104. It should be understood that the wearable glucose monitoring device 104 may vary in implementation in one or more ways from the following description and for one or more of the reasons discussed above in connection with Figure 1.

[0044] In this example 200, the wearable glucose monitoring device 104 is shown to include a sensor 202 and a sensor module 204. Here, 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 wearable glucose monitoring device 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 wearable glucose monitoring device 104 further includes an adhesive pad 210 and an attachment mechanism 212.

[0045] In operation, the sensor 202, adhesive pad 210, and attachment mechanism 212 may be assembled to form an application assembly 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 after it has been applied to the skin 206 via the attachment mechanism 212. Additionally or alternatively, the transmitter 208 may be incorporated as part of the application assembly, such that the sensor 202, adhesive pad 210, attachment mechanism 212, and transmitter 208 (with sensor module 204) can all be applied to the skin 206 at once. In one or more implementations, this application assembly is applied to the skin 206 using a separate sensor applicator (not shown). Unlike the blood draws required for conventional tests such as HbA1c, FPG, and 2Hr-PG, user-initiated application of the wearable glucose monitoring device 104 is largely painless and does not require blood draws, consumption of sugary drinks, or periods of fasting. Additionally, the automatic sensor applicator allows the person 102 to implant the sensor 202 subcutaneously in the skin 206 without the assistance of a clinician or healthcare provider.

[0046] The application assembly may also be removed by peeling the adhesive pad 210 from the skin 206. It will be understood that the illustrated wearable glucose monitoring device 104 and its various components are merely one exemplary form factor, and that the wearable glucose monitoring device 104 and its components may have different form factors without departing from the spirit or scope of the described techniques.

[0047] 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).

[0048] The sensor 202 may be a device, molecule, and / or chemical that changes or causes a change in response to an event 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 glucose oxidase, which reacts with 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 glucose sensor configured to detect an analyte in blood or interstitial fluid indicative of glucose levels using one or more measurement techniques. In one or more implementations, the sensor 202 may also be configured to detect analytes in blood or interstitial fluid indicative of other markers, such as lactate levels, which may improve the predictive accuracy of diabetes classification. Additionally or alternatively, the wearable glucose monitoring device 202 may include additional sensors in the sensor 202 to detect analytes indicative of other markers.

[0049] In another example, the sensor 202 (or an additional sensor of the wearable glucose monitoring device 104, not shown) 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., 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 glucose. Alternatively or additionally, the wearable glucose monitoring device 104 includes multiple sensors for detecting not only one or more analytes (e.g., sodium, potassium, carbon dioxide, glucose, and insulin) but also one or more environmental conditions (e.g., temperature). Thus, 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.

[0050] 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 glucose readings 110 based on communications with the sensor 202 indicating the changes discussed above. Based on these communications from the sensor 202, the sensor module 204 is further configured to generate monitoring device data 214. The monitoring device data 214 is a communicable package of data including at least one glucose reading 110. Alternatively or additionally, the monitoring device data 214 includes other data, such as multiple blood glucose readings 110, a sensor identification 216, a sensor status 218, etc. In one or more implementations, the monitoring device data 214 may include other information, such as one or more of the temperature and other analyte measurements corresponding to the blood glucose readings 110. It should be understood that the monitoring device data 214 may include a variety of data in addition to at least one glucose reading 110 without departing from the spirit or scope of the described technology.

[0051] In implementations in which the wearable glucose monitoring device 104 is configured for wireless transmission, the transmitter 208 may wirelessly transmit the observational device data 214 as a data stream to the computing device. Alternatively or additionally, the sensor module 204 may buffer the observational device data 214 (e.g., in memory of the sensor module 204) and cause the transmitter 208 to transmit the buffered observational device data 214 at later intervals, such as time intervals (e.g., every 1 second, every 30 seconds, every minute, every 5 minutes, every hour, etc.), storage intervals (when the buffered observational device data 214 reaches a threshold amount of data or multiple instances of observational device data 214), etc.

[0052] With respect to observational device data 214, sensor identification 216 represents information that uniquely identifies sensor 202 from other sensors, such as other sensors in other wearable glucose monitoring devices 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 110, notify a user of a defective sensor, notify a manufacturing facility of a machining issue, etc.

[0053] 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 glucose readings 110 is generated. To this end, the sensor status 218 may include an entry for each glucose reading 110, such that there is a one-to-one relationship between the glucose reading 110 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 glucose reading 110. The identified operational state may be based on communications from the sensor 202 and / or characteristics of those communications.

[0054] By way of example, the sensor module 204 may include (e.g., in memory or other storage) a lookup table having a predetermined number of operating conditions and a basis for selecting one condition from another. For example, the predetermined condition 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, potentially resulting in a potential error in the glucose reading 110.

[0055] For example, the basis for these non-normal operating conditions 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 (e.g., in bed) on the wearable glucose monitoring device 104, etc. The sensor status 218 may indicate various aspects related to the sensor 202 and the wearable glucose monitoring device 104 without departing from the spirit or scope of the described techniques.

[0056] Having considered an example environment and an example wearable glucose monitoring device, we now turn to a detailed discussion of some example techniques for glucose measurement and diabetes prediction using machine learning in a digital media environment according to one or more implementations.

[0057] Diabetes prediction FIG. 3 depicts an example of an implementation 300 in which diabetes-related data, including glucose measurements, is routed to different systems related to diabetes prediction.

[0058] The depicted example 300 includes the observational analysis platform 108 and person 102 from FIG. 1. The depicted example 300 also depicts a device 302 associated with the person 102 that may provide glucose measurements 110 to the observational analysis platform 108 and / or storage device 112 in connection with diabetes prediction. The depicted device 302 includes a wearable glucose monitoring device 104 worn by the person 102 during an observation period to generate the glucose measurements 110 in conjunction with additional devices external to the wearable glucose monitoring device 104. Specifically, the depicted additional external devices include a mobile phone and a smartwatch, although various other devices, such as, for example, a laptop, a tablet device, a wearable health tracker, etc., may be configured to provide glucose measurements 110 to the observational analysis platform 108 and / or storage device 112 in one or more implementations.

[0059] As described above, glucose measurements 110 may be communicated or otherwise provided via a wired or wireless connection to observational analysis platform 108 and / or storage device 112. For example, wearable glucose monitoring device 104 may provide glucose measurements 110 to observational analysis platform 108 and / or storage device 112 via a wired or wireless connection as described above. In a scenario in which one of additional external devices 302 provides glucose measurements 110, glucose measurements 110 may first be provided from wearable glucose monitoring device 104 to the additional external device, which then communicates or otherwise provides glucose measurements 110 to observational analysis platform 108 and / or storage device 112.

[0060] In these scenarios, additional external device 302 may act as an intermediary between wearable glucose monitoring device 104 and observational analysis platform 108 and storage device 112, whereby external device 302 is used to "route" glucose measurements 110 from wearable glucose monitoring device 104 to observational analysis platform 108 and / or storage device 112. Alternatively or additionally, other devices may route glucose measurements 110 from wearable glucose monitoring device 104 to observational analysis platform 108 and / or storage device 112. These other devices may include dedicated devices configured to extract data from wearable glucose monitoring device 104 and associated with entities involved in diabetes prediction, such as healthcare providers, hospitals, pharmacies, telemedicine services, medical testing laboratories, etc.

[0061] The depicted example 300 also includes a user population 304. The user population 304 represents a plurality of users corresponding to people wearing glucose monitoring devices, such as the wearable glucose monitoring device 104. The glucose measurements 110 of these other users will be provided by their respective monitoring devices and / or by external computing devices to the observational analysis platform 108 and / or storage device 112. In one or more implementations, the user population 304 includes, at least in part, users selected as part of one or more “studies” conducted to collect data (including the glucose measurements 110) so that the data can be used to generate one or more models using machine learning, e.g., using supervised learning, unsupervised learning, reinforcement learning, etc.

[0062] Alternatively or additionally, the user population 304 can include users for whom a diabetes prediction was previously generated based on their glucose measurements generated during an observation period involving the wearable glucose monitoring device 104, in a manner similar to the way a diabetes prediction was generated for the person 102. Data generated prior to the diabetes prediction for the person 102 and in connection with a study conducted to collect the data is referred to as “historical” data because it was generated at a time before the glucose measurements 110 for the person 102 were generated. Similarly, data generated prior to the diabetes prediction for the individual 102 and in connection with diabetes predictions for other users is also historical data. In accordance with the described techniques, historical data includes, for example, past glucose measurements and past outcome data. This historical data is used in conjunction with machine learning to train or otherwise learn underlying models, as described in more detail with respect to FIG. 5 .

[0063] By way of example, a study to collect data related to predicting diabetes may require participants to wear glucose monitoring devices for a period of several days to generate the participants' glucose measurements 110. The period may have the same or different duration as the observation period used to generate the glucose measurements 110 of the persons 102 without departing from the spirit or scope of the described technology. In addition to collecting glucose measurements 110, such studies may be utilized to obtain other data about the participants. Outcome data 306 may correspond to at least a portion of this other data and describe various aspects about the users of the user population 304.

[0064] For example, in the context of a study, participants may be tested using conventional techniques to generate one or more diagnostic measures, such as HbA1c, FPG, and / or 2Hr-PG, in addition to wearing a glucose monitoring device. The independent diagnostic measure 308 represents data describing the results of one or more such tests associated with users of the user population 304. For example, the independent diagnostic measure 308 may describe the results of HbA1c, FPG, 2Hr-PG (or OGTT as a combination of FPG and 2Hr-PG), and / or random plasma glucose (RPG) associated with users of the user population 304. Thus, study participants' glucose measurements 110 may be associated with their respective independent diagnostic measure 308, e.g., by labeling the measurements. As described in more detail below, machine learning, through a training process, may learn patterns of glucose measurements 110 that indicate particular values ​​of the independent diagnostic measure 308, such as a pattern of glucose measurements 110 that indicate an individual's HbA1c is likely 10.0.

[0065] As shown, outcome data 306 also includes observed adverse effects 310 and clinical diagnoses 312. Observed adverse effects 310 represent data describing adverse effects experienced by users of user population 304. By way of example, observed adverse effects 310 may describe whether a user has or has not experienced one or more adverse effects associated with type 2 diabetes, such as, for example, diabetic retinopathy, cataracts, glaucoma, blindness, hyperglycemia or hypoglycemia, heart and vascular disease, neuropathy, erectile dysfunction, kidney failure or end-stage renal disease, delayed healing, hearing loss, skin conditions (such as bacterial and fungal infections), sleep apnea, Alzheimer's disease, etc.

[0066] Additionally or alternatively, observed adverse outcomes 310 may describe whether the user has or has not experienced any of one or more adverse outcomes associated with GDM, such as a baby with excessive birth weight (requiring a C-section), preterm birth (premature birth), infant respiratory distress syndrome, neonatal hypoglycemia, a baby who later develops obesity or type 2 diabetes, or stillbirth.

[0067] Additionally or alternatively, the observed adverse effects 310 may describe whether the user has experienced or not experienced one or more adverse effects associated with other types of diabetes, such as effects associated with type 1 diabetes, cystic fibrosis diabetes, pancreatic diabetes, etc. Thus, the glucose measurements 110 of study participants may be associated with their respective observed adverse effects 310, for example, by labeling the measurements. As described in more detail below, machine learning, through a training process, may learn patterns of glucose measurements 110 that indicate the occurrence and non-occurrence of the observed adverse effects 310, such as patterns of glucose measurements 110 that indicate the likelihood of each person having a baby with an excessive birth weight requiring a C-section.

[0068] Clinical diagnosis 312 represents data describing whether a user of user population 304 has been (or has not been) diagnosed with diabetes by a clinician, or whether they have been provisionally or preliminarily diagnosed with diabetes. By way of example, a diagnosis may be made by a clinician based on one or more of independent diagnostic measures 308 and / or observed adverse effects 310. Additionally or alternatively, clinical diagnosis 312 may be configured to represent a labeling based on a diagnostic test that has not been approved for diagnosis by the clinical community at large, such as the Food and Drug Administration (FDA) or A1CNOW+. The value of clinical diagnosis 312 may represent, for example, whether the respective user has been clinically diagnosed with diabetes (or any type of diabetes), clinically diagnosed with prediabetes (or any of the different types of prediabetes), provisionally or preliminarily diagnosed with diabetes, does not have diabetes (i.e., has been screened), has been diagnosed with diabetes using an unapproved test, or has been diagnosed with prediabetes using an unapproved test. Given this independent diagnostic measure 308, for example, glucose measurements 110 may be associated with each study participant's independent diagnostic measure 308 and each participant's clinical diagnosis 312. Through training, machine learning may learn patterns of glucose measurements 110 that indicate particular values ​​of the independent diagnostic measure 308 and that further indicate different diabetes diagnoses, such as a pattern of glucose measurements 110 that indicate a person's HbA1c is likely 6.0 (e.g., a "probable A1c") and that a clinician's analysis is likely to lead to a diagnosis of prediabetes. While this example is discussed with respect to a person's HbA1c, it should be understood that a clinical diagnosis may be made based on different measurements (e.g., FPG) and / or observations (e.g., weight gain, neuropathy, and sleep apnea) without departing from the spirit or scope of the described technology.

[0069] In one or more implementations, the outcome data 306 may include or be usable as a label. For example, the value of the independent diagnostic measure 308 may be used to label the glucose readings 110 of each user in the user population 304. Alternatively or additionally, a label indicating an observed adverse effect 310 experienced by each user may be used to label the glucose readings 110 of each user. Alternatively or additionally, a label indicating a clinical diagnosis 312 may be used to label the glucose readings 110 of each user; for example, a glucose reading 110 of a user clinically diagnosed with pre-diabetes may be associated with a “pre-diabetes” label, while a glucose reading 110 of another user clinically diagnosed with diabetes may be associated with a “diabetes” label. While an independent diagnostic measure 308, an observed adverse effect 310, and a clinical diagnosis 312 are shown in the example 300, it should be understood that the outcome data 306 may include data describing different, additional, or fewer aspects of the users in the user population 304 without departing from the spirit or scope of the described technology.

[0070] As shown in the depicted example 300, glucose measurements 110 and outcome data 306 of users of a user population 304 are communicated or otherwise provided to an observational analytics platform 108 and / or a storage device 112. In addition to the glucose measurements 110 and outcome data 306, additional data describing other aspects of the users of the user population 306 may be obtained by the observational analytics platform 108 and / or the storage device 112. By way of example, this additional data may include demographic data (e.g., age, gender, ethnicity), medical history data (e.g., height, weight, body mass index (BMI), body fat percentage, presence or absence of various conditions), stress data, nutritional data, exercise data, prescription data, height and weight data, occupational data, etc. These types of additional data 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 technology described herein. In one or more implementations, the observational analysis platform 108 and / or the storage device 112 may obtain such additional data (or at least a portion of the additional data) regarding the people 102 and users of the user population 304 .

[0071] In particular, the depicted example 300 shows the observational analysis platform 108 and the storage device 112 separately, and also shows a dashed arrow between the storage device 112 and the observational analysis platform 108. Generally speaking, the arrow represents that data maintained on the storage device 112 may be retrieved by the observational analysis platform 108 from the storage device 112. Stated differently, data maintained by the storage device 112 may be provided to the observational analysis platform 108. As described above, the storage device 112 may store glucose measurements 110 for the person 102, as well as glucose measurements 110 and result data 306 for the user population 304.

[0072] In one or more implementations, the observational analysis platform 108 and the storage device 112 may correspond to the same entity, such as a provider of glucose monitoring devices (e.g., wearable glucose monitoring devices 104) and services related to glucose monitoring. In such implementations, the observational analysis platform 108 and the storage device 112 may be implemented in the “cloud” across multiple computing devices (e.g., servers) and storage resources allocated to or otherwise associated with (e.g., via subscription or ownership) the entity. To this end, the glucose readings 110 of the person 102, as well as the glucose readings 110 and result data 306 of the user population 304, may be retrieved by the observational analysis platform 108 from the storage device 112 in a manner such that a server associated with the service provider retrieves the data from storage associated with the service provider.

[0073] In other implementations, the observational analysis platform 108 and the storage device 112 may correspond to different entities. By way of example, the storage device 112 may correspond to a first entity, such as the person's 102 computing device (e.g., a mobile phone or tablet device), and the observational analysis platform 108 may correspond to a second entity, such as a provider of glucose monitoring devices and services related to glucose monitoring. In this example, the observational analysis platform 108 may be implemented, at least in part, as an application of the second entity running on the person's 102 computing device. Alternatively, or additionally, the observational analysis platform 108 may be implemented using the second entity's server device. In an application implementation, the second entity's application may retrieve one or more of the person's 102 glucose readings 110, the user population's 304 glucose readings 110, or the user population's 304 result data from the storage device 112 implemented locally on the computing device, e.g., via the computing device's bus or other local transmission means. In a server implementation, the second entity's server may retrieve data from the storage device 112 implemented on the computing device over one or more networks, such as the Internet.

[0074] In another example where the observational analytics platform 108 and the storage device 112 correspond to different entities, the storage device 112 may correspond to a first entity, such as a glucose monitoring device and services related to glucose monitoring (or limited services related to glucose monitoring). In this latter example, the observational analytics platform 108 may correspond to a second, different entity, such as a service provider, e.g., a data partner of the first entity. In this example, the second entity may be considered a “third party” with respect to the entity corresponding to the storage device 112 (and the wearable glucose monitoring device 104). When corresponding to a data partner, the observational analytics platform 108 may obtain data from the first entity (i.e., the storage device 112) pursuant to one or more legal agreements between the first and second entities. Provision of data maintained on the storage device 112 to the observational analytics platform 108 may be controlled by an application programming interface (API).

[0075] In this type of scenario, such an API may be considered an “egress” for data, such as glucose readings 110 and result data 306. “Egress” means that the flow of data is generally outward from a first entity to a third party (e.g., a second entity). In the context of data provision, an API may expose one or more “calls” (e.g., a particular format for requesting data) to a third party. As an example, an API may expose these calls to a third party after the third party enters into an agreement, e.g., with a business corresponding to the first entity, that allows the third party to retrieve data from the storage device 112 via the API. As part of this agreement, the third party may agree to exchange payment to retrieve data from the first entity. Alternatively or additionally, the third party may agree to exchange data it generates, e.g., via an associated device, to retrieve data from the first entity. Parties agreeing to retrieve data (e.g., glucose readings 110) from a first entity via an API may be referred to as “data partners.” In operation, the API allows a third party to request data (e.g., glucose measurements 110 and / or result data 306) maintained on the storage device 112 in a specific request format, and if the request is made in the specific format, the first entity provides the requested data in a specific response format. The requested data may be provided in the specific response format in one or more communications (e.g., packets) over a network, e.g., the Internet. Examples of second entities that may be considered "third parties" include various service providers, such as service providers offering one or more health monitoring / tracking services, fitness-related services, telemedicine services, medical testing laboratory services, etc. In practice, the storage device 112 and the observational analytics platform 108 may be implemented using various devices and / or resources (e.g., computing, communications, storage, etc.), and the division (or non-division) between the entities corresponding to the various devices and / or resources may differ from that described above without departing from the spirit or scope of the technology described herein.

[0076] Nevertheless, the observational analysis platform 108 is configured to obtain the glucose measurements 110 of the person 102, as well as the glucose measurements 110 and outcome data 306 of the user population 304, and process them according to the described techniques. For example, using the glucose measurements 110 and outcome data 306 of the user population 304, the prediction system 114 is configured to generate one or more machine learning models, e.g., regression models, neural networks, reinforcement learning agents. Once one or more such models are generated, the prediction system 114 is configured to use the one or more models to process the glucose measurements of the person 102 and predict a diabetes classification 116 for the person 102.

[0077] In the depicted example 300, the prediction system 114 is shown outputting a notification 314. The notification 314 may be based on or include the diabetes classification 116. Consider an example in which the diabetes classification 116 output by one or more machine learning models of the prediction system 114 is a label indicating that the person 102 is predicted to have diabetes, e.g., a text label such as “1” (where “0” indicates no diabetes) or “diabetes.” In this case, it may be undesirable to simply provide the diabetes classification 116 to the person 102. If such information is not delivered with appropriate educational materials or is not delivered in a personalized manner in an appropriate setting, providing such information may affect the person 102 in various negative ways, such as by causing confusion, anger, depression, etc. Thus, the notification 314 may simply be based on the diabetes classification 116, such as by informing the person 102 that the results of the observation period are available and instructing them to schedule an appointment with a relevant healthcare provider.

[0078] In contrast, providing the diabetes classification 116 to the person's 102 healthcare provider may not be desirable. Instead, providing the diabetes classification 116 to the healthcare provider (as opposed to not providing a classification) may be preferable so that the healthcare provider can appropriately notify the person 102 and develop a treatment plan for the person 102. In such a scenario, the notification 314 may simply correspond to the diabetes classification 116. Alternatively, the notification communicated to the healthcare provider (or others) may be configured as a report that includes the diabetes classification 116 along with other information, such as a record of the person's 102 glucose measurements 110 over an observation period, measurements derived from those glucose measurements 110, treatment recommendations (e.g., learned from historical data of the user population 304), etc. Examples of these notifications are described in more detail with respect to FIGS. 6 and 7. Consider the following description of FIG. 4 in the context of predicting a person's 102 glucose classification 116 from their glucose measurements 110.

[0079] FIG. 4 illustrates in more detail an example implementation 400 of the prediction system of FIG. 1 in which machine learning is used to predict diabetes classification.

[0080] In the depicted example 400, a prediction system 114 is shown retrieving a glucose measurement 110, for example, from a storage device 112. Here, the glucose measurement 110 corresponds to a person 102. The example 400 depicts the prediction system 114 including a pre-processing manager 402 and a machine learning model 404 configured to generate a prediction of a diabetes classification 116 based on the glucose measurement 110 of the person 102. While the prediction system 114 is depicted as including these two components, it should be understood that the prediction system 114 may have more, fewer, and / or different components for generating a diabetes classification 116 based on the glucose measurement 110 without departing from the spirit or scope of the described technology.

[0081] In one or more implementations, the glucose measurements 110 are arranged as time-series data, such that each glucose measurement 110 corresponds to a timestamp. For example, the glucose measurements 110 may be arranged as one or more glucose “records.” While the glucose measurements 110 may generally be received or maintained sequentially from the wearable glucose monitoring device 104 and / or an external device, for example, by the observational analysis platform 108, in some cases, one or more of the glucose measurements 110 may not be received or maintained in the same order in which the glucose measurements 110 are generated. For example, packets having glucose measurements 110 may be received out of order. Thus, the order of reception may not chronologically match the order in which the glucose measurements 110 are generated by the wearable glucose monitoring device 104. Additionally, or alternatively, a transmission containing one or more of the glucose measurements 110 may be corrupted. Indeed, there may be a variety of reasons why the glucose measurements 110 obtained by the prediction system 114 are not perfectly chronologically ordered.

[0082] To this end, the pre-processing manager 402 may be configured to determine a chronological sequence of the glucose measurements 110 according to their respective timestamps. Due to corruption and communication errors, the glucose measurements 110 obtained by the prediction system 114 may not only be out of chronological order, but may also be missing one or more measurements, presenting gaps in the chronological sequence where one or more measurements are expected. In these instances, the pre-processing manager 402 may be configured to interpolate the missing glucose measurements and incorporate them into the chronological sequence. While this functionality is described, in one or more implementations, the glucose measurements 110 obtained by the prediction system 114 may already be in chronological order (e.g., one or more time series of glucose measurements 110), such that ordering those measurements and interpolating missing measurements is not performed by the pre-processing manager 402.

[0083] In general, the pre-processing manager 402 is configured to pre-process the glucose measurements 110 to generate data (e.g., one or more feature vectors) that can be provided as input to the machine learning model 404 and data that can be reported in association with the diabetes classification 116 (e.g., included as part of the notification 314). The illustrated example 400 depicts the pre-processing manager 402 outputting extracted glucose features 406. The pre-processing manager 402 may determine the extracted glucose features 406 by processing the glucose measurements 110 according to one or more predetermined algorithms or functions. Each different extracted glucose feature 406 may correspond to a different algorithm or function by which the pre-processing manager 402 processes the glucose measurements 110.

[0084] Here, the extracted glucose features 406 include a time above threshold measure 408, a rate of change measure 410, and anomalies over the observation period 412. It should be understood that the extracted glucose features 406 may differ from the combinations shown without departing from the spirit or scope of the described technology. For example, the extracted glucose features 406 may also, or alternatively, include one or more of: mean glucose (e.g., during the observation period or for each day), median glucose, interquartile range of glucose measurements 110, variance of glucose measurements 110, nocturnal hyperglycemia, difference between mean awake blood glucose and mean sleep blood glucose, day-to-day variability of glucose, day-to-night variability of glucose, statistical distribution of glucose, a threshold percentile of glucose (e.g., a statistically significant threshold percentile such as the 94th percentile or above), a 10th-90th percentile range of glucose, standard deviation of glucose, mean daily difference (MODD), and mean amplitude of blood glucose excursion (MAGE), etc.

[0085] Notably, the time above threshold measure 408 and the rate of change measure 410 are measures that cannot simply be determined using traditional diagnostic tests. Instead, the time above threshold measure 408 and the rate of change measure 410 are necessarily time-based, requiring each of the data points (i.e., glucose measurements 110) to be associated with a point in time and ordered according to their time. Generally, the time above threshold measure 408 corresponds to the amount of time during an observation period that the person's 102 glucose measurements 110 are above the glucose threshold. To calculate the time above threshold measure 408, for example, the pre-processing manager 402 may identify consecutive glucose measurements 110 that exceed the glucose threshold (e.g., based on comparing the measurements to the threshold) and determine the time difference between the first of those measurements that exceed the threshold and the last measurement that exceeds the threshold. Without a time associated with each measurement and without generating measurements at time increments of suitable granularity to capture such features, it is simply not possible to determine the amount of time above the glucose threshold. It should be understood that the amount of time above the threshold is in contrast to the number of measurements above the threshold or the percentage of measurements above the threshold, which the pre-processing manager 402 may also be configured to determine.

[0086] Generally, the rate of change measures 410 correspond to the difference in the user's glucose measurements 110 over a unit of time. To determine the rate of change measures 410, the pre-processing manager 402 may determine the difference in glucose measurements and the time difference between at least two measurements, thereby determining the change in the amount of glucose over a unit of time, e.g., mg / dL per minute. It should be understood that such a rate of change may be determined using three or more of the glucose measurements 110. In any case, the rate of change measures 410 cannot simply be determined without the time ordering of the glucose measurements 110. These rate of change measures 410 can indicate how quickly the person's 102 body responds when their glucose spikes as a result of eating carbohydrates, which may further indicate the person's 102 insulin response. In summary, the time series of glucose measurements 110 allows for the determination of various measures that cannot be determined using data from other diagnostic tests.

[0087] Examples of above-threshold time scale 408 may include, by way of example and not limitation, time above 130 mg / dL (which corresponds to the amount of time during the lapse of the observation period that the glucose level of person 102 exceeds 130 mg / dL) and time above 140 mg / dL (which corresponds to the amount of time during the lapse of the observation period that the glucose level of person 102 exceeds 140 mg / dL). In one or more implementations, above-threshold time scale measurement 408 may correspond to an amount of time above a threshold that may range from 120 mg / dL to 240 mg / dL. Furthermore, above-threshold time scale 408 may include a time scale above a single threshold, such as time above 140 mg / dL, or multiple scales, such as the amount of time above 130 mg / dL, the amount of time above 140 mg / dL, and the amount of time above 150 mg / dL.

[0088] Other time-based threshold measures that the pre-processing manager 402 may determine as part of or in addition to the extracted glucose features 406 include an in-range time measure corresponding to the amount of time during the elapse of the observation period that the person's 102 glucose is between a first glucose level and a second glucose level that is less than the first glucose level, the second glucose level corresponding to the upper and lower limits of the range, respectively. Conversely, the pre-processing manager 402 may determine an out-of-range time measure corresponding to the amount of time during the observation period that the person's 102 glucose readings 110 are outside such range. Examples of rate of change measures 410 may include, for example, an average rate of change measure after a glucose high, an average rate of change measure after carbohydrate consumption, rate of change over time of day (e.g., night), etc.

[0089] The pre-processing manager 402 may determine the observation period anomalies 412 using any of a variety of known statistical anomaly detection techniques, including, for example, unsupervised, supervised, and semi-supervised anomaly detection techniques. Additionally, the pre-processing manager 402 may determine one or more statistical measures related to the time of day, such as the mean and median glucose readings for the night. Again, such measures cannot be determined unless the glucose readings 110 have a corresponding time.

[0090] In addition to determining these different features of glucose, the pre-processing manager 402 may determine which glucose measurements 110 will serve as the basis for input to the machine learning model 404. In other words, the pre-processing manager 402 may filter the glucose measurements 110 by removing at least some of the glucose measurements 110 from the input to the machine learning model 404. The pre-processing manager 402 may then determine extracted glucose features 406 from the filtered glucose measurements.

[0091] As an example, the pre-processing manager 402 may select a subset of the glucose measurements 110 (e.g., measurements from the three “worst” days), generate extracted glucose features 406 for the subset of measurements, and then generate input data for input to the machine learning model 404 based on the extracted glucose features 406 of the subset of measurements. Alternatively, the pre-processing manager may select a subset of days in which x number of the worst days are removed (or deselected for inclusion in the subset). Nevertheless, the unselected measurements and / or data corresponding to the unselected measurements may not be input to the machine learning model 404 in one or more implementations. The pre-processing manager 402 may select which glucose measurements 110 to serve as the basis for the input data in various ways, such as based on daily averages of glucose measurements (e.g., the worst days are the days with the highest average glucose, such as the three days with the highest average glucose), based on performance of the wearable glucose monitoring device 104 (e.g., the first and last days may be eliminated or several days may be eliminated due to receipt of a device or sensor error), etc. In addition to data removal, the pre-processing manager 402 may alternatively or additionally replace or add one or more of the glucose measurements 110 with higher fidelity measurements, such as measurements interpolated during pre-processing.

[0092] Regardless of the particular glucose feature extracted, the pre-processing manager 402 is configured to generate input data for input into the machine learning model 404. In one or more implementations, this input data may be configured as a feature vector representing one or more features. In one example, the input data may correspond to a single feature, such as the time scale above threshold 408, e.g., time above 140 mg / dL. In this example, the pre-processing manager 402 may generate a feature vector representing the amount of time (or percentage of time) that the person's 102 glucose was above the threshold during the observation period. In other examples, the input data may correspond to multiple features, such as the time scale above threshold 408 and an average glucose. Thus, the pre-processing manager 402 may generate a feature vector representing both the amount of time (or percentage of time) that the person's 102 glucose was above the threshold during the observation period and the person's 102 average glucose during the observation period. It should be understood that any of the extracted glucose features 406 (or other determinations) described above may be used in a single-feature implementation, and any combination of those features (or determinations) may be used in a multi-feature implementation.

[0093] In addition to features extracted from the glucose measurements 110, the pre-processing manager 402 may also incorporate features from additional data describing different aspects of the person 102. As described above, this additional data may include additional analyte data (e.g., lactate measurements), environmental data (e.g., a person's temperature), previously observed adverse effect data (e.g., data describing that any of various adverse effects associated with diabetes have already been observed), demographic data collected via questionnaire or otherwise (e.g., describing age, gender, ethnicity), medical history data, stress data, nutritional data, exercise data, prescription data, height and weight data, occupational data, etc. In other words, the data provided as input to the machine learning model 404 or an ensemble of machine learning models 404 may, in one or more implementations, describe various aspects about the person 102 (e.g., as features of an input feature vector) in addition to glucose-based features without departing from the spirit or scope of the described technology. In such a scenario, the machine learning model 404 is trained using similar historical data of the user population 304.

[0094] While the depicted example 400 shows the pre-processing manager 402 pre-processing the glucose measurements 110 to generate extracted glucose features 406 and using these features as input to the machine learning model (e.g., a feature vector indicative of the extracted features), in one or more implementations the pre-processing manager 402 may generate a feature vector that represents (alone or with other features) one or more time series (e.g., recordings) of the glucose measurements 110. Thus, the input data to the machine learning model 404 may correspond to or otherwise include a vectorized time series of the glucose measurements 110 or multiple vectorized time series of the glucose measurements 110. In implementations in which the time series of glucose measurements are vectorized, the machine learning model 404 may correspond to, for example, a neural network. In implementations in which the extracted glucose features 406, such as the threshold crossing time measure 408 and statistical features (e.g., interquartile range), are vectorized, the machine learning model may correspond to, for example, a regression model, such as a linear or logistic regression model.

[0095] In response to receiving input data from the pre-processing manager 402, the machine learning model 404 is configured to generate and output the diabetes classification 116. Specifically, the machine learning model 404 may be trained to output the diabetes classification 116. By way of example, the machine learning model 404 may be trained, or underlying representations may be learned, using past glucose measurements and outcome data from which a diabetes classification can be derived, such as using the glucose measurements 110 and outcome data 306 of the user population 304, based on one or more training techniques. In accordance with the described techniques, the machine learning model 404 may represent one or more models, including, for example, a model trained to predict whether a person has diabetes, and in one or more implementations, an additional model for predicting whether a person does not have diabetes (i.e., a diabetes classification that can be used to screen a person for diabetes with some degree of certainty). Each model in a multi-model configuration may receive different configurations of input data describing different aspects, e.g., feature vectors having features representing different aspects related to diabetes. It should be understood that in other implementations, a single model may be configured to generate both types of predictions. In one or more implementations, the machine learning models 404 may be configured as a collection of models, each of which produces a diabetes-related prediction that differs from the other models.

[0096] The diabetes classifier 116 may classify the person 102 with respect to one or more outcomes corresponding to outcomes described by the outcome data 306 used to train the machine learning model 404. In implementations in which the machine learning model 404 is trained or learned using clinical diagnoses 312 of the user population 304, the machine learning model 404 may classify the glucose measurements 110 of the person 102 into a class corresponding to one of the diagnoses, e.g., diabetes, pre-diabetes, or no diabetes. To this end, a healthcare provider may use the diabetes classifier 116 to treat the person 102 or create a treatment plan similar to how the healthcare provider 102 would if diabetes were diagnosed according to conventional techniques, e.g., HbA1c, FPG, and / or 2Hr-PG.

[0097] Similarly, when a machine learning model is trained or learned, using the observed adverse effects 310 of the user population, the machine learning model 404 may output a likelihood that the glucose reading 110 of the person 102 indicates that the person will experience a different adverse effect, for example, a zero to one likelihood that the person will experience any of various adverse effects associated with different types of diabetes. In some implementations, there may be a machine learning model trained or built for each effect, such that the machine learning model 404 represents a collection of models that can generate predictions regarding whether the person 102 will experience each effect or the likelihood that the person will experience each effect.

[0098] In implementations in which a machine learning model is trained or trained using independent diagnostic measures 308 of a user population, the machine learning model 404 may output a prediction of the value of a particular diagnostic measure, such as an HbA1c value, an FPG value, a 2Hr-PG value, or an OGTT value. The output diabetes classification 116 depends heavily on how the machine learning model 404 is trained, and in particular, the information that the diabetes classification 116 represents—such as a label indicating whether a person has diabetes or is at risk for diabetes (e.g., a diabetes label, a pre-diabetes label, or a diabetes-free label), a label, probability, or scale value indicating whether a person has a particular type of diabetes (e.g., type 1 diabetes, type 2 diabetes, and GDM)—depends on the training. Furthermore, different types of machine learning models may be better suited to generating predictions related to the various types of outcomes that can be represented by the diabetes classification 116. In the context of training a machine learning model, consider the following description of FIG. 5.

[0099] FIG. 5 depicts in more detail one example implementation 500 of the prediction system 114 in which a machine learning model is trained to predict diabetes classification.

[0100] In the depicted example 500, the forecasting system 114 includes a model manager 502 that manages machine learning models 404. According to the described techniques, the machine learning models 404 may represent a single machine learning model or a collection of multiple models. The machine learning models 404 may correspond to different types of machine learning models, where the underlying models are trained using different approaches, such as using supervised learning, unsupervised learning, and / or reinforcement learning. By way of example, these models include regression models (e.g., linear, polynomial, and / or logistic regression models), classifiers, neural networks, reinforcement learning-based models, and the like.

[0101] The machine learning models 404 may be configured as or include other types of models without departing from the spirit or scope of the described technology. These different machine learning models may each be built or trained (or the models may be otherwise learned) using, at least in part, different data and different algorithms according to different architectures and / or learning paradigms. Accordingly, it will be understood that the following discussion of the functionality of the model manager 502 is applicable to a variety of machine learning models. However, for purposes of explanation, the functionality of the model manager 502 is generally described with reference to statistical models and neural networks.

[0102] Generally speaking, the model manager 502 is configured to manage machine learning models, including the machine learning models 404. This model management includes, for example, building the machine learning models 404, training the machine learning models 404, updating the models, etc. Specifically, the model manager 502 is configured to perform this model management, at least in part, using a wealth of data maintained on the storage device 112. As shown, this data includes the glucose measurements 110 and outcome data 306 of the user population 304. Stated another way, the model manager 502 builds the machine learning models 404, trains the machine learning models 404 (or otherwise learns the underlying model), and updates the models using the glucose measurements 110 and outcome data 306 of the user population 304. In implementations in which the machine learning models 404 receive data in addition to glucose measurements or extracted features of those measurements as input, the model manager 502 also uses such additional data of the user population 304 to build, train, and update the machine learning models 404.

[0103] In one or more implementations, the model manager 502 generates training data for training the machine learning model 404 or otherwise learning the model's parameters. Broadly speaking, the generation of the training data depends on the diabetes classification the machine learning model is designed to output. This training data will differ, for example, if the machine learning model 404 is configured to generate a prediction of a diagnostic measure for a person, a predicted adverse effect that the person will experience, or a clinical diagnosis for the person. Regardless of the predicted outcome, the generation of the training data may include time-sequencing the glucose measurements 110 of the user population 304 (if the glucose measurements 110 are not already time-series) and extracting glucose features from those time-ordered glucose measurements 110. The model manager 502 may leverage the functionality of the pre-processing manager 402 to form a time series of glucose measurements 110 and extract glucose features from those time-ordered glucose measurements 110, for example, in a manner similar to that described above in connection with generating the extracted glucose features 406.

[0104] Generating the training data also includes associating the glucose measurements 110 records, or features extracted from the glucose measurements 110 (e.g., similar to the extracted glucose features, but for the glucose measurements 110, the user population 304), with the outcome data 306 of each user in the user population 304. This associates the glucose measurements or extracted glucose features corresponding to a particular user with the outcome data 306 for that particular user. As an example, a particular user may have been clinically diagnosed with diabetes, and their glucose was above a threshold 27% of the time during the observation period. This may cause the model manager 502 to create training instances that include an input portion with a value indicating the user's time above the threshold 27% of the time, and an associated output portion with a value, e.g., "1" or other corresponding value, indicating that the person has diabetes.

[0105] In one or more implementations, the model manager 502 may build a statistical model by extracting, from the outcome data 306, observed values ​​or labels corresponding to at least one type of outcome, such as values ​​of the clinical diagnosis 312, e.g., values ​​indicating “diabetes,” “prediabetes,” and “no diabetes,” or their labels. Once built, the statistical model is configured to predict values ​​or labels of this at least one outcome type and output them as the diabetes classification 116, and the values ​​or labels indicating the at least one outcome type do not serve as inputs to the model. For example, in a scenario where the statistical model is a regression model, the outcome values ​​or labels may correspond to one or more dependent variables. In contrast, one or more of the glucose features extracted from the glucose measurements 110 may serve as inputs to the model. Thus, in a scenario where the machine learning model 404 is configured as a statistical model, one or more glucose features may correspond to one or more explanatory (or independent) variables.

[0106] Given a set of outcome values ​​or labels from the outcome data 306 and a set of feature values ​​extracted from the glucose measurements 110, the model manager 502 uses one or more known approaches to "fit" these sets of values ​​to a formula, such that the model manager 502 generates outcome values ​​or labels that are responsive to the input of the extracted glucose feature 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 502 estimates the model parameters of the formula using one or more approaches and these sets of values ​​from the training data.

[0107] The estimated parameters include, for example, weights applied to values ​​of independent variables (e.g., extracted glucose features 406) when they are input into the machine learning model during operation. The model manager 502 incorporates these parameters estimated from fitting observed values ​​of the user population 304 to the equation to generate the machine learning model 404 as a statistical model. During operation, the prediction system 114 inputs values ​​of the independent variables (e.g., one or more values ​​of the extracted glucose features 406) into the statistical model (e.g., as one or more vectors or matrices), which applies the estimated weights to these input values ​​and then outputs values ​​or labels for one or more dependent variables. This output corresponds to the diabetes classification 116.

[0108] In the following description, the model manager's 502 functionality for building and training machine learning models is described in relation to configuring machine learning models 404 that correspond to or include at least one neural network.

[0109] With regard to the training data used, the model manager 502 may generate training data instances that include an input portion and an expected output portion, i.e., ground truth, for comparison with the output of the model during training, as described above. The input portion of the training data instance may correspond to one or more records of a particular user's glucose measurements 110 and / or one or more extracted features of the glucose measurements 110. The output portion may correspond to one or more values ​​of the particular user's outcome data 306, such as a value indicative of a clinical diagnosis of diabetes or the user's observed HbA1c value. Again, whether records are used for training, which extracted features are used for training, and which outcome data are used for training depend on the data the machine learning model 404 is designed to receive (and trained) as input and the data it is designed to output (and trained).

[0110] The model manager 502 uses the training input portions, along with the respective expected output portions, to train the machine learning model 404. In a training context, the model manager 502 may train the machine learning model 404 by providing it with instances of data from a set of training input portions. In response, the machine learning model 404 generates a prediction of a diabetes classification, such as by predicting a value indicative of a clinical diagnosis of diabetes or a user's observed HbA1c value. The model manager 502 obtains this training prediction from the machine learning model 404 as an output and compares the training prediction to the expected output portions corresponding to the training input portions. For example, if the machine learning model 404 outputs a diabetes classification indicating that the user has diabetes, this prediction is compared to the output data (e.g., classifying the user as having or not having diabetes) to determine whether the prediction was correct. Based on this comparison, the model manager adjusts the internal weights of the machine learning model 404 so that the machine learning model substantially reproduces the expected output portions when each training input portion is provided as an input in the future.

[0111] This process of inputting instances of training input portions into the machine learning model 404, receiving training predictions from the machine learning model 404, comparing the training predictions (e.g., using a loss function such as mean squared error) to the (observed) expected output portions corresponding to the input instances, and adjusting the internal weights of the machine learning model 404 based on these comparisons can be repeated over hundreds, thousands, or even millions of iterations, i.e., using an instance of the training data for each iteration.

[0112] The model manager 502 may perform such iterations until the machine learning model 404 is able to consistently generate predictions that substantially match the expected output portion. The ability of a machine learning model to consistently generate predictions that substantially match the expected output portion may be referred to as “convergence.” With this in mind, the model manager 502 may be said to train the machine learning model 404 until it “converges” to a solution, e.g., until the model's internal weights are suitably adjusted through training iterations such that the model generates predictions that substantially match the expected output portion.

[0113] As described above, the machine learning model 404 may be configured in one or more implementations to receive inputs in addition to recorded glucose measurements and / or features extracted from those measurements. In such implementations, the model manager 502 may form training instances that include training input portions, respective expected output portions, and additional input data describing any other aspects of the user population 304 used to predict diabetes classification, e.g., demographic information, medical history, exercise, and / or stress. This additional data and training input portions may be processed by the model manager 502 according to one or more known techniques to generate an input vector. This input vector describing the training input portions and other aspects may then be provided to the machine learning model 404. In response, the machine learning model 404 may generate a prediction of diabetes classification in a manner similar to that discussed above, such that the prediction can be compared to the expected output portions of the training instances and the model weights can be adjusted based on the comparison.

[0114] Once the machine learning model 404 is trained, it is used to predict a diabetes classification, as discussed above and below. Also, as noted, the diabetes classification output by the machine learning model 404 serves as the basis for various information provided to the person 102 in relation to which the prediction was generated, and to others associated with the person, such as the person's 102 healthcare provider, caregiver, telemedicine or health tracking service. With regard to information that may be output based on a prediction, consider the following discussion of Figures 6-8.

[0115] FIG. 6 depicts an example implementation 600 of a user interface that is displayed to inform a user about a diabetes prediction that is generated based on glucose measurements generated during an observation period.

[0116] The illustrated example 600 includes a computing device 602 displaying a user interface 604. In this example 600, the user interface 604 may correspond to the notification 314. This example 600 represents a scenario in which the notification 314 (i.e., the user interface 604) is generated based on, but does not include, the diabetes classification 116. Here, the computing device 602 may be associated with the person 102 whose glucose measurements were collected during an observation period and in which the diabetes classification 116 was generated (or the computing device 604 may be associated with another person related to the person 102, such as a caregiver).

[0117] To this end, the user interface 604 may be displayed to inform the individual 102 (or interested parties) about the diabetes classification 116 without revealing the predicted classification. This is because outputting the diabetes classification 116 to the actual person 102 to which the classification corresponds may affect the person 102 in various negative ways, such as by causing confusion, anger, depression, etc. In this example 600, the user interface 604 includes a summary regarding the processing of the glucose measurements of the person 102. The user interface 604 also includes suggestions for possible actions based on the diabetes classification, in this case suggesting that the individual 102 follow up with their healthcare provider. Furthermore, the user interface 604 includes graphical user interface elements 606 that are selectable to perform the suggested actions. Each of the user interface elements 606 may be selectable to schedule a follow-up appointment with the individual's 102 healthcare provider, such as an appointment at the healthcare provider's physical location or via telephone or video conference, for example, in connection with remote healthcare and / or telemedicine services. It should be understood that notifications based on, but not including, diabetes classification 116 may be configured in different ways without departing from the spirit or scope of the described technology.

[0118] FIG. 7 depicts an example implementation 700 of a user interface that may be displayed to report a user's diabetes prediction along with other information generated in connection with the diabetes prediction.

[0119] The illustrated example 700 includes a display device 702 displaying a user interface 704 configured as a report. In this example, the user interface 704 may correspond to a notification 314. In contrast to the example shown in FIG. 6 , this example 700 represents a scenario in which the notification includes a diabetes classification 116. In this illustrated example 700, a graphical diagnostic element 706 represents or otherwise indicates the diabetes classification 116. Here, the display device 702 may be associated with a healthcare provider associated with the person 102 for whom glucose measurements are collected during an observation period and for whom the diabetes classification 116 is generated.

[0120] To this end, a user interface 704 may be displayed to report the diabetes classification 116 to a healthcare provider and to report additional information that may be related to the classification. In operation, the healthcare provider may independently analyze the reported additional information and provide a diagnosis different from that indicated by the diabetes classification 116. In this example 700, the additional information includes glucose records 708, 710. These records represent two days' worth of glucose measurements 110 for the person 102 collected over an observation period. The user interface 704 is also shown with controls that allow the user to navigate to other glucose measurements 110 that were collected, such as records corresponding to days before or after the observation period.

[0121] The user interface 704 also includes a graphical glucose feature element 712 that represents or otherwise illustrates one or more of the extracted glucose features 406 determined by the pre-processing manager 402 based on the glucose measurements 110 of the person 102. In addition to the predicted clinical diagnosis, as indicated by the graphical diagnosis element 706, the user interface 704 also includes a predicted adverse effect element 714 and a probability element 716. The inclusion of these elements indicates that the machine learning model 404 may be configured (e.g., through configuration as an ensemble of models and / or based on architecture and training) to generate predictions of two or more types of diabetes classifications. By way of example, the machine learning model 404 may be configured to predict the clinical diagnosis of the person 102, the value of one or more of a plurality of independent diagnostic measures (e.g., HbA1c, FPG, 2Hr-PG, and OGTT), and the probability that the person 102 will experience one or more of a plurality of adverse effects of diabetes.

[0122] In particular, the predicted adverse effect element 714 corresponds to the adverse effect indicated by the diabetes classification and indicates a high probability that the person 102 will experience, for example, based on a greater than 50% probability output by the machine learning model of experiencing those effects. It should be understood that the adverse effect that the machine learning model 404 predicts the likelihood of occurring may also be output in one or more scenarios along with the corresponding probability. The probability element 716 includes a probability that the adverse effect indicated by element 714 will occur. The probabilities indicated by these probability elements 716 may be output by the machine learning model 404 in one or more implementations. It should be understood that the report including the diabetes classification 116 may be configured in a variety of ways, such as a document suitable for printing, without departing from the spirit or scope of the described technology.

[0123] FIG. 8 depicts an example implementation 800 of a user interface that may be displayed to collect additional data that can be used as input to a machine learning model for generating a diabetes prediction.

[0124] The illustrated example 800 includes a computing device 802 displaying a user interface 804. In this example 800, the user interface 804 may be displayed to collect data about the person 102 in addition to the glucose measurements 110 collected during an observation period. This additional data may be provided as input to the machine learning model 404 along with the records of the glucose measurements 110 and / or one or more of the extracted glucose features 406. That is, the additional data may be represented by features of a feature vector input to the model. To train the machine learning model 404, this additional data may also be collected from users of the user population 304. Thus, the user interface 804 may be displayed to users of the user population 304 to collect this additional data from these users, for example, data representing demographics, medical history, exercise, and / or stress.

[0125] In the illustrated example 800, the user interface 800 includes various graphical elements with which a user can interact (e.g., select or enter values) to provide additional data about themselves. However, it should be understood that the included graphical elements are merely examples, and that a user interface for collecting such additional data may be configured in different ways to include more, fewer, or different elements that enable the collection of various additional data without departing from the spirit or scope of the described technology.

[0126] Having discussed detailed examples of techniques for diabetes prediction using glucose measurements and machine learning, some example procedures will now be considered to illustrate additional aspects of the techniques.

[0127] Step-by-step example This section describes an example procedure for predicting diabetes using glucose measurements and machine learning. Aspects of the procedure may be implemented in hardware, firmware, software, or a combination thereof. The procedure is illustrated as a set of blocks specifying operations to be performed by one or more devices and is not necessarily limited to the order shown for performing the operations by each block. In at least some implementations, the procedure is performed by a prediction system, such as prediction system 114, utilizing pre-processing manager 402, machine learning model 404, and model manager 502.

[0128] FIG. 9 depicts steps 900 in an example implementation in which a machine learning model predicts diabetes classification based on a user's glucose measurements collected by a wearable glucose monitoring device during an observation period.

[0129] A user's glucose measurements are obtained (block 902). In accordance with the principles discussed herein, the glucose measurements are collected by a wearable glucose monitoring device during an observation period. By way of example, the machine learning model 404 obtains the user's glucose measurements 110 collected by a wearable glucose monitoring device 104 worn by the person 102 during the observation period. The wearable glucose monitoring device 104 may be provided as part of an observation kit, for example, for purposes of monitoring the glucose of the person 102. Regardless of how the wearable glucose monitoring device 104 is obtained by the person 102, the device is configured to monitor the glucose of the person 102 during the observation period, which generally lasts for a period spanning several days. In particular, the wearable glucose monitoring device 104 may be configured with a sensor 202 that can be inserted subcutaneously into the skin of the person 102 and used to measure glucose in the blood of the person 102.

[0130] Although discussed throughout as being inserted subcutaneously into the skin of person 102, in one or more implementations, sensor 202 may not be inserted subcutaneously. In such implementations, sensor 202 may instead be placed on the skin or muscle of person 102. For example, sensor 202 may be a patch that is attached to the skin of person 102 for a period of time. The patch may then be removed. Alternatively or additionally, the noninvasive glucose sensor may be optically based, using, for example, photoplethysmography (PPG). Sensor 202 may be configured in various ways to obtain measurements indicative of glucose in person 102 without departing from the spirit or scope of the described technology.

[0131] The user's diabetes classification is predicted by processing the glucose measurements using one or more machine learning models (block 904). In accordance with principles described herein, the one or more machine learning models are generated based on past glucose measurements and past outcome data of a user population. As an example, machine learning model 404 predicts diabetes classification 116. Machine learning model 404 generates this prediction by processing glucose measurements 110 based on patterns of glucose measurements 110 and outcome data 306 of user population 304 learned during training. As noted above, user population 304 includes users who wear a wearable glucose monitoring device, such as wearable glucose monitoring device 104.

[0132] The diabetes classification is output (block 906). By way of example, the machine learning model 404 outputs the diabetes classification 116. As described throughout, the diabetes classification 116 may indicate whether the person is predicted to have diabetes or is predicted to experience adverse effects related to diabetes. The diabetes classification 116 may also be used to generate one or more notifications or user interfaces based on the classification, such as a report directed to a healthcare provider that includes the diabetes classification (e.g., that the person is predicted to have diabetes) or a notification directed to the person 102 instructing the person to contact a healthcare provider.

[0133] FIG. 10 depicts a procedure 1000 in an example implementation in which a machine learning model is trained to predict diabetes classification based on historical glucose measurement and outcome data of a user population.

[0134] Glucose measurements collected by wearable glucose monitoring devices worn by users of the user population are obtained (block 1002). As an example, model manager 502 obtains glucose measurements 110 of users of user population 304. Outcome data describing one or more aspects of users of the user population related to diabetes is obtained (block 1004). As an example, model manager 502 obtains outcome data 306. In the above example, the outcome data describes exemplary aspects such as one or more of independent diagnostic measures 308 of users of user population 304, observed adverse effects 310 of users of user population 304, and clinical diagnoses 312 of users of user population 304.

[0135] Instances of training data are generated (block 1006), including a training input portion and an expected output portion. In accordance with the principles discussed herein, the training input portion includes at least one of a record of a user's glucose readings or features of the user's glucose readings. Additionally, the expected output portion includes one or more values ​​of outcome data corresponding to the user. By way of example, model manager 502 generates the instances of training data by associating the record of glucose readings or features of the user's glucose readings obtained in block 1002 with one or more values ​​of the user's outcome data obtained in block 1004. In one or more implementations, model manager 502 "labels" the record of glucose readings or features of the user's glucose readings with one or more labels that represent the values ​​of the outcome data corresponding to the user.

[0136] Here, blocks 1008-1014 may be repeated until the machine learning model has been suitably trained to "converge" to a solution, e.g., until the model's internal weights have been suitably adjusted through training iterations, such that the model produces predictions that substantially match expected classification labels, etc. Alternatively, or additionally, blocks 1008-1014 may be repeated for several instances (e.g., all instances) of the training data.

[0137] The training input portion of the instances of training data is provided as input to the machine learning model (block 1008). By way of example, the model manager 502 provides the training input portion of the instances of training data generated in block 1006 as input to the machine learning model 404.

[0138] A diabetes classification prediction is received as output from the machine learning model (block 1010). In accordance with the principles discussed herein, the diabetes classification prediction corresponds to the same diabetes-related aspect as one or more values ​​of the user's outcomes data included in the training instance. By way of example, the machine learning model 404 predicts a diabetes classification (e.g., the user's classification in a "diabetes" class, a "pre-diabetes" class, or a "no diabetes" class, or a value indicative of one of those classes) based on the training input portion provided in block 1008, and the model manager 502 receives the diabetes classification as an output of the machine learning model 404.

[0139] The prediction of the diabetes classification is compared to the expected output portion of the training data instances (block 1012). By way of example, the model manager 502 compares the diabetes classification predicted in block 1010 to the expected output portion of the training instances generated in block 1006 using a loss function such as mean squared error (MSE). It should be understood that the model manager 502 may use other loss functions during training to compare the predictions of the machine learning model 404 to the expected output without departing from the spirit or scope of the described technology.

[0140] Based on the comparison, the weights of the machine learning model are adjusted (block 1014). By way of example, the model manager 502 may adjust the internal weights of the machine learning model 404 based on the comparison. In one or more implementations, the model manager 502 may optionally utilize one or more hyperparameter optimization techniques during training to adjust the hyperparameters of the utilized learning algorithm.

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

[0142] System and Device Examples 11 illustrates an example system, generally 1100, including an example computing device 1102 that is representative of one or more computing systems and / or devices that may implement various techniques described herein. This is illustrated by the inclusion of a prediction system 114 at the platform level and at the individual computing device level. The prediction system 114 may be implemented at one level or the other, or at least partially at both levels. The computing device 1102 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 computational system.

[0143] The illustrated example computing device 1102 includes a processing system 1104, one or more computer-readable mediums 1106, and one or more I / O interfaces 1108 communicatively coupled to each other. Although not shown, the computing device 1102 may further include a system bus or other data and command transfer system that couples the 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.

[0144] The processing system 1104 embodies functionality for performing one or more operations using hardware. Accordingly, the processing system 1104 is illustrated as including hardware elements 1110, 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 1110 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.

[0145] The computer-readable medium 1106 is shown as including memory / storage 1112. The memory / storage 1112 represents memory / storage capacity associated with one or more computer-readable media. The memory / storage component 1112 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 1112 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 1106 may be configured in a variety of other ways, as described further below.

[0146] Input / output interface 1108 embodies functionality that allows a user to input commands and information into computing device 1102 and to present information to a user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., 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 1102 may be configured in a variety of ways, described further below, to support user interaction.

[0147] 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. Aspects of the techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.

[0148] 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 1102. By way of example, and not limitation, computer-readable media may include “computer-readable storage media” and “computer-readable signal media.”

[0149] 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 the desired information and that can be accessed by a computer.

[0150] A "computer-readable signal medium" may refer to a signal-bearing medium configured to transmit instructions to the hardware of the computing device 1102, 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.

[0151] As previously mentioned, the hardware elements 1110 and the computer-readable medium 1106 embody 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 techniques 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, the 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 medium described above.

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

[0153] The techniques described herein may be supported by various configurations of computing device 1102 and are not limited to the specific examples of the techniques described herein. This functionality may also be implemented in whole or in part through the use of a distributed system, such as via a "cloud" 1114 via platform 1116, as described below.

[0154] Cloud 1114 includes and / or embodies a platform 1116 for resources 1118. Platform 1116 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of cloud 1114. Resources 1118 may include applications and / or data available while computer processing is running on a server remote from computing device 1102. Resources 1118 may also include services provided over the Internet and / or through a subscriber network, such as a cellular or Wi-Fi network.

[0155] Platform 1116 may abstract resources and functionality for connecting computing device 1102 with other computing devices. Platform 1116 may also function to abstract resource scaling to provide a level of scale corresponding to the encountered demand of resources 1118 implemented via platform 1116. Thus, in embodiments of interconnected devices, implementation aspects of the functionality described herein may be distributed throughout system 1100. For example, functionality may be implemented partially on computing device 1102 as well as via platform 1116, which abstracts the functionality of cloud 1114.

[0156] 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 specific features and acts are disclosed as example forms of implementing the claimed subject matter.

Claims

1. 1. A method comprising: obtaining glucose measurements of a user, the glucose measurements being collected by a wearable glucose monitoring device during an observation period; predicting a diabetes classification of the user by processing the glucose measurements using one or more machine learning models, the one or more machine learning models being generated based on past glucose measurements and past outcome data of a user population; and and outputting the diabetes classification.

2. The method of claim 1 , wherein the diabetes classification is an indication of the user's status during the observation period as one of diabetes, pre-diabetes, or no diabetes.

3. The method of claim 1 , wherein the diabetes classification is an indication of the user's condition during the observation period as either gestational diabetes or not gestational diabetes.

4. the diabetes classification is an indication of one or more adverse effects of diabetes that the user is predicted to experience; The method of claim 1 , wherein the historical outcome data represents adverse effects of diabetes observed among users in the user population.

5. The method of claim 1 , wherein the wearable glucose monitoring device includes a sensor that is subcutaneously inserted into the user's skin during the observation period to collect the glucose measurements.

6. The method of claim 5 , wherein the glucose measurements comprise a time series of glucose measurements collected by the wearable glucose monitoring device during the observation period.

7. 7. The method of claim 6, wherein the time series of glucose measurements is collected by the wearable glucose monitoring device continuously at predetermined intervals during the observation period.

8. 10. The method of claim 1, wherein the observation period spans multiple days.

9. obtaining the past glucose measurements and the past outcome data for the user population, the past glucose measurements being provided by glucose monitoring devices worn by users of the user population; 10. The method of claim 1, further comprising generating the one or more machine learning models by providing the one or more historical glucose measurements to the one or more machine learning models, comparing a training classification of diabetes received from the one or more machine learning models to a classification of diabetes indicated by the historical outcome data, and adjusting weights of the one or more machine learning models based on the comparison.

10. 10. The method of claim 9, further comprising labeling the records of past glucose measurements with a label indicating the respective user's diabetes classification based on the past outcome data.

11. 10. The method of claim 9, wherein the past outcome data is associated with one or more diagnostic measures that are independent of the past glucose measurements provided by the glucose monitoring devices worn by users of the user population.

12. 2. The method of claim 1, wherein the past outcome data includes a label for the past glucose measurement record indicating whether each user in the user population is clinically diagnosed with diabetes based on one or more diagnostic measures.

13. 13. The method of claim 12, wherein the one or more diagnostic measures include at least one of hemoglobin A1c (HbA1c), oral glucose tolerance test (OGTT), or fasting plasma glucose (FPG).

14. pre-processing the glucose measurements of the user to extract one or more glucose features; 10. The method of claim 1, further comprising providing the one or more extracted glucose features as inputs to a machine learning model to enable the machine learning model to predict the diabetes classification of the user.

15. The one or more extracted glucose features may include: an above-threshold time scale corresponding to the amount of time during the observation period that the glucose measurement of the user is above a glucose threshold; an in-range time scale corresponding to the amount of time during an observation period that the user's glucose measurement is between a first glucose level and a second glucose level that is lower than the first glucose level; a rate of change measure corresponding to the difference in glucose measurements over unit time; Average glucose readings, or 15. The method of claim 14, wherein the method comprises at least one of: a median glucose measure;

16. The method of claim 14 , wherein the machine learning model predicts the diabetes classification of the user using at least two extracted glucose features.

17. 15. The method of claim 14, wherein the preprocessing further comprises filtering the glucose measurements by removing at least a portion of the glucose measurements and extracting the one or more glucose features from the filtered glucose measurements.

18. The outputting includes the diabetes classification. recommending one or more treatments to the user based on the diabetes classification; a visual representation of the glucose measurements collected by the glucose monitoring device during the observation period; or and one or more glucose statistics for the user generated based on the glucose measurements collected by the glucose monitoring device during the observation period.

19. The one or more glucose statistics include: an above-threshold time scale corresponding to the amount of time during the observation period that the glucose measurement of the user is above a glucose threshold; an in-range time scale corresponding to the amount of time during the observation period that the user's glucose measurement is between a first glucose level and a second glucose level that is lower than the first glucose level; a rate of change measure corresponding to the difference in glucose measurements over unit time; Average glucose readings, or 19. The method of claim 18, wherein the at least one of the following is included: a median glucose measure;

20. The method of claim 1 , wherein the glucose measurements are obtained from storage on the glucose monitoring device or from one or more data packets containing the glucose measurements communicated from the glucose monitoring device over a network.

21. A device, one or more processors; a memory having stored thereon computer-readable instructions, the instructions being executable by the one or more processors to perform operations, the operations including: obtaining glucose measurements of a user, the glucose measurements being collected by a wearable glucose monitoring device during an observation period; predicting a diabetes classification of the user by processing the glucose measurements using one or more machine learning models, the one or more machine learning models being generated based on past glucose measurements and past outcome data of a user population; and and outputting the diabetes classification.

22. 22. The device of claim 21, wherein the diabetes classification is an indication describing the user's status during the observation period as either diabetes, pre-diabetes, or no diabetes.

23. the diabetes classification is an indication of one or more adverse effects of diabetes that the user is predicted to experience; 22. The device of claim 21, wherein the historical outcome data represents adverse effects of diabetes observed in users of the user population.

24. 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 including: obtaining glucose measurements of a user, the glucose measurements being collected by a wearable glucose monitoring device during an observation period; predicting a diabetes classification of the user by processing the glucose measurements using one or more machine learning models, the one or more machine learning models being generated based on past glucose measurements and past outcome data of a user population; and and outputting the diabetes classification.

25. 25. The computer-readable storage medium of claim 24, wherein the diabetes classification is an indication of the user's status during the observation period as either diabetes, pre-diabetes, or no diabetes.

26. the diabetes classification is an indication of one or more adverse effects of diabetes that the user is predicted to experience; 25. The computer-readable storage medium of claim 24, wherein the historical outcome data represents adverse effects of diabetes observed in users of the user population.

27. 1. An apparatus comprising: acquisition means for acquiring glucose measurements of a user, the glucose measurements being collected by a wearable glucose monitoring device during an observation period; prediction means for predicting a diabetes classification of the user by processing the glucose measurements using one or more machine learning models, the one or more machine learning models being generated based on past glucose measurements and past outcome data of a user population; and and output means for outputting the diabetes classification.

28. 1. A system comprising: a wearable glucose monitoring device comprising a sensor for collecting glucose measurements of a user over a multi-day observation period using the sensor subcutaneously inserted into the skin of the user; a storage device for maintaining the glucose measurements of the user collected during the observation period; a prediction system that obtains the glucose measurements of the user collected during the observation period and processes the glucose measurements using one or more machine learning models to predict a diabetes classification of the user.

29. 30. The system of claim 28, wherein the one or more machine learning models are generated based on past glucose measurements and past outcome data of a user population.

30. obtaining the past glucose measurements and the past outcome data for the user population, the past glucose measurements being provided by glucose monitoring devices worn by users of the user population; 30. The system of claim 29, further comprising a model manager for generating the one or more machine learning models by providing the past glucose measurements to the one or more machine learning models, comparing a training classification of diabetes received from the one or more machine learning models to a diabetes classification indicated by the past outcome data, and adjusting weights of the one or more machine learning models based on the comparison.

31. 31. The system of claim 30, wherein the past outcome data is associated with one or more diagnostic measures independent of the past glucose measurements provided by the glucose monitoring devices worn by users of the user population.

32. 31. The system of claim 30, wherein the glucose monitoring device is configured to be different from the glucose monitoring devices worn by the users of the user population that provide the historical glucose measurements.

33. 33. The system of claim 32, wherein the wearable glucose monitoring device is configured to prevent the user from viewing the collected glucose measurements during the observation period.

34. 33. The system of claim 32, wherein the storage device is implemented in the wearable glucose monitoring device, and the storage device is configured to maintain a greater number of glucose measurements than the storage of the glucose monitoring devices worn by the users of the user population.

35. 30. The system of claim 28, wherein the prediction system is implemented in one or more computing devices separate from the glucose monitoring device.

36. 30. The system of claim 28, wherein the predictive system is implemented at least in part in the wearable glucose monitoring device.

37. 1. A method comprising: obtaining glucose measurements collected by wearable glucose monitoring devices worn by users of a user population; obtaining outcome data for the user population describing one or more aspects of the users of the user population related to diabetes; generating instances of training data including a training input portion and a predicted output portion, the training input portion including at least one of a record of a user's glucose readings or characteristics of the user's glucose readings, and the predicted output portion including one or more values ​​of outcome data corresponding to the user; training a machine learning model to predict a classification of diabetes; providing a training input portion of the instances of the training data as inputs to a machine learning model; receiving a diabetes classification prediction as output from the machine learning model, the diabetes classification prediction corresponding to the same diabetes-related aspect as one or more values ​​of the user's outcomes data; comparing the prediction of the diabetes classification to the predicted output portion of instances of training data; and adjusting weights of the machine learning model based on the comparison.

Images