Diabetes prediction using glucose measurements and machine learning

Abstract

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

Description

[0001] This application is a divisional application of Chinese invention patent application No. 202180034453.4, filed on June 18, 2021, entitled "Diabetes Prediction Using Glucose Measurements and Machine Learning". Technical Field

[0002] This paper describes the use of glucose measurements and machine learning for diabetes prediction. In one or more implementations, the observation and analytics platform includes a machine learning model trained using historical glucose measurements and historical outcome data of a user group to predict the diabetes classification of an individual user. Historical glucose measurements of the user group can be provided by glucose monitoring devices worn by users within the user group, while historical outcome data includes one or more diagnostic measurements obtained from sources independent of the glucose monitoring devices. After training, the machine learning model predicts the diabetes classification for the user based on glucose measurements collected by the wearable glucose monitoring device over an observation period spanning multiple days. The predicted diabetes classification can then be output, for example, by generating one or more notifications or user interfaces based on the classification. Background Technology

[0003] Diabetes is a metabolic disease affecting hundreds of millions of people and is one of the leading causes of death worldwide. However, with early detection and appropriate treatment, the serious damage to the heart, blood vessels, eyes, kidneys, and nerves caused by diabetes can be largely avoided. Routine tests for diabetes accepted by clinical and regulatory agencies include glycated hemoglobin (HbA1c), fasting plasma glucose (FPG), and 2-hour postprandial glucose (2Hr-PG)—FPG and 2Hr-PG are both part of the oral glucose tolerance test (OGTT), but FPG can be tested separately from the OGTT. For the FPG test, a blood sample is collected and the results are used to classify a person as “normal” (e.g., no diabetes) or having prediabetes or diabetes. Generally, a person is considered normal if their fasting glucose level is below 100 mg / dL, classified as prediabetes if their fasting glucose level is between 100 and 125 mg / dL, and diagnosed with diabetes if their fasting glucose level is above 126 mg / dL in two separate tests.

[0004] After measuring a person's fasting glucose for an FPG test, the OGTT requires the person to drink a sugary liquid to bring their blood glucose level to a peak. Many people find this sugary drink difficult to tolerate, especially pregnant women. The person's glucose level is then periodically tested using additional blood samples over the next two hours for a 2-hour postprandial glucose test (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. Readings between 140 and 199 mg / dL indicate prediabetes.

[0005] Unlike the FPG and 2Hr-PG tests in OGTT, which measure a person's glucose levels at a single time point, the HbA1c test measures a user's average glucose levels over the past two to three months. However, the HbA1c test does not directly measure glucose; instead, it measures the percentage of glucose attached to hemoglobin. Note that when glucose accumulates in a person's blood, it attaches to hemoglobin, the oxygen-carrying protein in red blood cells. Red blood cells have a lifespan of approximately two to three months in a human body, so the HbA1c test shows the average glucose level in the blood over the past two to three months. Unlike FPG and 2Hr-PG tests, a person does not need to be fasting when performing an HbA1c test. However, similar to FPG and 2Hr-PG tests, a blood sample must be taken from the person to generate a reading in order to measure their HbA1c level. In two separate tests, an HbA1c level of 6.5% or higher indicates that the person has diabetes, while an HbA1c level between 5.7% and 6.4% generally indicates that the person has prediabetes. An HbA1c level below 5.7% is considered normal.

[0006] Every routine test used to screen for or diagnose diabetes has various limitations that often lead to incorrect diagnoses. Routine diabetes tests are generally inaccurate because a given test performed on an individual on different dates can result in inconsistent diagnoses, as various external factors can cause fluctuations in glucose levels, such as illness, stress, increased exercise, or pregnancy. In contrast, even though an HbA1c test measures the average glucose level over the previous two to three months, HbA1c test results can be greatly affected by the user's glucose levels in the weeks leading up to the test. Therefore, HbA1c test results can be significantly influenced by changes in blood characteristics over the three-month period, such as due to pregnancy or illness. Furthermore, because an HbA1c test is not a direct measurement of glucose, such tests can be inaccurate for people with various blood conditions, such as anemia or hemoglobin abnormalities.

[0007] Furthermore, these routine tests often exhibit poor consistency. In other words, these tests may not detect diabetes in the same person. This lack of consistency between test types can lead to inaccurate diagnoses or an inability to determine an appropriate treatment plan. For example, a user may have a high fasting glucose level but a normal HbA1c score. In this case, different doctors may reach different conclusions regarding whether the user has diabetes and what type of treatment plan is appropriate.

[0008] Finally, there are various limitations and drawbacks to performing these tests on different people (such as pregnant women). For example, these traditional diabetes tests require users to go to a doctor's office or laboratory to have a blood sample collected, which can be time-consuming, expensive, and painful for some users. Each of these factors combined can create psychological barriers, preventing users from undergoing diabetes testing and thus reducing the potential benefits of early detection. In addition, many of these routine tests require users to fast, which can be difficult or even dangerous for some users, including pregnant women. Summary of the Invention

[0009] To overcome these problems, glucose measurements and machine learning are used for diabetes prediction. In one or more implementations, the observation and analysis platform includes a machine learning model trained using historical glucose measurements and historical outcome data of a user group to predict the diabetes classification of an individual user. Historical glucose measurements of the user group may be provided by glucose monitoring devices worn by users within the user group, while historical outcome data includes one or more diagnostic measurements from sources independent of the glucose monitoring devices. For example, historical outcome data may indicate whether a corresponding user within the user group has been clinically diagnosed with diabetes based on one or more diagnostic measurements, such as HbA1c, FPG, or 2Hr-PG.

[0010] After training, the machine learning model predicts a diabetes category for a user based on glucose measurements collected by a wearable glucose monitoring device over a multi-day observation period. Specifically, the machine learning model generates this prediction based on training with historical glucose measurements and historical outcome data for the user group. The diabetes category can describe the user's status during the observation period (e.g., having diabetes, prediabetes, or no diabetes) or whether the user is predicted to experience the adverse effects of diabetes. The predicted diabetes category can then be output, for example, by generating one or more notifications or user interfaces based on the category, such as a report to a healthcare provider that includes the diabetes category (e.g., the person is predicted to have diabetes) or a notification to the person instructing them to contact their healthcare provider.

[0011] This summary presents some concepts in a simplified form, which will be further described in the detailed embodiments below. Therefore, this summary is not intended to identify the 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. Attached Figure Description

[0012] The detailed specification is described with reference to the accompanying drawings.

[0013] Figure 1 This is an environmental diagram of one embodiment of an implementation that operatively employs the techniques described herein.

[0014] Figure 2 A more detailed description Figure 1 Examples of wearable glucose monitoring devices.

[0015] Figure 3 An embodiment of one implementation is described, in which diabetes-related data, including glucose measurements, is sent to different systems associated with diabetes prediction.

[0016] Figure 4 A more detailed description Figure 1 An embodiment of the prediction system is provided, wherein machine learning is used to predict diabetes classification.

[0017] Figure 5 A more detailed description Figure 1 An embodiment of the prediction system, wherein a machine learning model is trained to predict diabetes classification.

[0018] Figure 6 An embodiment of a user interface displayed to notify a user of a diabetes prediction based on glucose measurements collected during observation is described.

[0019] Figure 7 An embodiment of a user interface for displaying a user's diabetes prediction and other information related to the prediction is described.

[0020] Figure 8 An embodiment of a display user interface is depicted for collecting additional data that can be used as input to a machine learning model for generating diabetes predictions.

[0021] Figure 9 The process in one embodiment of the implementation is described, in which a machine learning model predicts diabetes classification based on glucose measurements of the user collected by a wearable glucose monitoring device during observation.

[0022] Figure 10The process in an embodiment of the implementation is described, wherein a machine learning model is trained to predict diabetes classification based on historical glucose measurements and outcome data of a user group.

[0023] Figure 11 System embodiments including various components of a device are shown, the device being implemented as any type of computing device, such as... Figure 1-10 The described and / or implementation methods used to implement the techniques described herein. Detailed Implementation

[0024] Overview Routine diabetes testing accepted by clinical and regulatory bodies includes glycated hemoglobin (HbA1c), fasting plasma glucose (FPG), and 2-hour postprandial glucose (2Hr-PG)—FPG and 2Hr-PG are both part of the oral glucose tolerance test (OGTT), but FPG can be tested separately from the OGTT. However, this routine testing often lacks consistency. In other words, these tests may not detect diabetes in the same person. A given test performed on an individual on different dates can also lead to inconsistent diagnoses due to various factors affecting glucose levels. There are also various limitations and drawbacks to performing these tests on different people (such as pregnant women).

[0025] To overcome these problems, glucose measurements and machine learning are used for diabetes prediction. To classify people as having diabetes, one or more machine learning models (e.g., regression models, neural networks, reinforcement learning agents) are generated using historical glucose measurements and historical outcome data of a user group to predict the diabetes classification of an individual user. Historical glucose measurements of the user group can be provided by glucose monitoring devices worn by users within the user group. Conversely, the historical outcome data used for training can vary depending on the classification the machine learning model is configured to output. Typically, historical outcome data includes one or more diagnostic measurements obtained from sources independent of glucose monitoring devices. For example, historical outcome data can indicate whether a corresponding user in the user group is clinically diagnosed with diabetes based on one or more diagnostic measurements, such as HbA1c, FPG, or 2Hr-PG (or OGTT as a combination of FPG and 2Hr-PG).

[0026] Regardless of the specific outcome data used, training enables machine learning models to predict diabetes classification based on individual glucose measurements collected during the observation period. In other words, the machine learning model learns to identify patterns in glucose measurements that are associated with having or not having diabetes. For example, the machine learning model can learn specific features of glucose data that are highly correlated with having or not having diabetes. Examples of features that the machine learning model can learn that are associated with diabetes classification include, by way of example and not limitation, time measurements exceeding thresholds, rate of change measurements, observation period anomalies, and mean or median glucose values ​​during the observation period. It is worth noting that many features associated with diabetes classification learned by the machine learning model, such as time measurements exceeding thresholds and rate of change measurements, are features that cannot be determined using traditional diagnostic tests that output results from blood samples measured at a single time point.

[0027] Once trained, the machine learning model 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 a multi-day observation period. This "diabetes classification" can, in some implementations, indicate whether the user has diabetes or is at risk of developing diabetes and / or indicate the adverse effects the user is expected to experience. For example, a user can monitor his or her glucose to predict whether he or she has diabetes (e.g., type 1 diabetes, type 2 diabetes, gestational diabetes mellitus (GDM), cystic fibrotic diabetes, etc.) or is at risk of developing diabetes (e.g., prediabetes), and / or whether she is expected to experience diabetes-related adverse effects (e.g., retinopathy, neuropathy, comorbidities, abnormal blood glucose, macrosomia requiring cesarean section, neonatal hypoglycemia, etc., to name a few). In a similar manner to predicting diabetes classification indicating the type of diabetes (e.g., type 2, GDM, etc.), in one or more implementations, the machine learning model may additionally or alternatively be configured to predict the type of prediabetes (e.g., impaired fasting glucose (IFG) or impaired glucose tolerance (IGT)). Alternatively or additionally, diabetes classification can correspond to a level of risk of having or developing diabetes, such as high risk, low risk, or no risk. In practice, the diabetes classification predicted by a machine learning model (e.g., by a healthcare professional) can be used to treat the person or develop a treatment plan similar to how the person would have been treated if clinically diagnosed using routine testing (e.g., having a certain type of diabetes and / or being prone to adverse effects).

[0028] However, unlike routine testing traditionally conducted in a laboratory or doctor's office, wearable glucose monitoring devices allow for remote glucose measurement. For example, wearable glucose monitoring devices can be mailed or otherwise provided to users, such as by providers of wearable glucose monitoring devices, pharmacies, medical testing laboratories, telemedicine services, etc. Users can then wear the wearable glucose monitoring device during the observation period, such as continuously at home or at work.

[0029] Once acquired, the user can insert the sensor of the wearable glucose monitoring device into their body, for example, by using an automated sensor applicator. Unlike routine tests such as HbA1c, FPG, and 2Hr-PG, which require blood draws, the application of the user-initiated glucose monitoring device is virtually painless and requires no blood draws, sugary drinks, or fasting. Furthermore, the automated sensor applicator allows the user to embed the sensor into their skin without the assistance of a clinician or healthcare provider. While automated sensor applicators have been discussed, wearable glucose monitoring devices can be applied to or worn by a person in other ways without departing from the spirit or scope of the technology described herein, such as without an automated sensor applicator, with the assistance of a healthcare professional (or where a healthcare professional can simply apply the wearable device to a person), or by peeling off a protective layer of adhesive and securing it to the person, to name a few. Once the sensor is inserted into the user's skin, the wearable glucose monitoring device monitors the person's glucose levels over a multi-day observation period. It should also be understood that in some embodiments, the sensor may not be inserted into the person's skin. Instead, in such embodiments, the sensor may simply be attached to the person's skin, like a patch. In any case, the sensors in wearable glucose monitoring devices can continuously detect analytes that indicate a person's glucose levels and generate glucose measurements.

[0030] Glucose measurements collected during the observation period and / or data obtained through preprocessing of glucose measurements are fed 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, diabetes classification describes the user's status during the observation period, such as having 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 having diabetes, to name a few. It is worth noting that, unlike conventional testing, the diabetes classification predicted by the machine learning model is based on glucose values ​​observed over multiple days. Therefore, the prediction is more accurate than testing that relies on blood samples collected at a single time point. Furthermore, unlike HbA1c testing, which is an indirect method of measuring glucose and may be affected by recent changes in blood glucose levels due to disease or external factors or conditions, the diabetes classification predicted by the machine learning model is based on glucose measurements directly obtained within the current observation period.

[0031] The diabetes classification prediction is then presented, for example, by displaying a representation of the diabetes classification to the user, doctor, or guardian via a user interface. Other information may also be presented, such as a visualization of glucose measurements and other statistics derived from those measurements. In some cases, the diabetes classification prediction is presented in a glucose observation report, which may also include one or more treatment options for the user, a visual representation of glucose measurements collected by the glucose monitoring device during the observation period, the user's glucose statistics based on the collected glucose measurements, severity, next steps (e.g., for the doctor, healthcare professional, or user), follow-up requests, requests to order more sensors for the wearable glucose monitoring device, activity generation levels, trends in glucose or other markers, patterns of glucose or other markers, exercise patterns, interpretation of glucose measurements, or blood glucose-related activities. Therefore, unlike routine blood glucose test results, a glucose observation report generated by one or more machine learning models can include a detailed analysis of the predictions and various treatment options. It should be understood that diabetes classification and information associated with such classifications can be provided in a variety of ways, including, for example, as an audio signal output via a speaker or digital assistant.

[0032] Advantageously, utilizing wearable glucose monitoring devices and machine learning to generate predictions classifying people as having diabetes eliminates many of the discomforts associated with the aforementioned diagnostic tests and does not limit who can be tested. For example, unlike HbA1c, pregnant women can safely wear wearable glucose monitoring devices during the observation period. Furthermore, because the machine learning model is applied to glucose trajectories collected over multiple days, it reduces inconsistencies associated with routine testing compared to tests based on a single blood sample, thereby improving predictive accuracy. By accurately predicting diabetes classification and notifying users, healthcare providers, and / or telehealth services, the machine learning model allows for early detection of diabetes and identifies treatment options that can be taken before a user's diabetes worsens, mitigating potential adverse health conditions. Doing so can largely prevent serious damage to the heart, blood vessels, eyes, kidneys, and nerves, as well as death from diabetes.

[0033] In the following discussion, an embodiment of an environment in which the techniques described herein can be employed is first described. Details and processes of embodiments of implementations that can be performed in the discussed environment and other environments are then described. The execution of these processes is not limited to the embodiment of the environment, and the embodiment of the environment is not limited to the execution of these processes.

[0034] Implementation examples of the environment Figure 1 This is a schematic diagram of environment 100 in an embodiment of the implementation, which is operable to employ glucose measurements and machine learning as described herein for diabetes prediction. Environment 100 includes a person 102, depicted wearing a wearable glucose monitoring device 104. The environment also includes an observation kit provider 106 and an observation analysis platform 108.

[0035] In the illustrated embodiment 100, a wearable glucose monitoring device 104 is depicted as being provided to a person 102 by an observation kit provider 106, for example, as part of an observation kit. The wearable glucose monitoring device 104 may be provided as part of an observation kit, for example, for monitoring the person 102's glucose during a multi-day observation period. For example, the person 102 may monitor his or her glucose to predict whether he or she has diabetes (e.g., type 1 diabetes, type 2 diabetes, gestational diabetes mellitus (GDM), cystic fibrotic diabetes, etc.) or is at risk of developing diabetes (e.g., prediabetes), and / or whether he or she is expected to experience adverse effects related to diabetes (e.g., comorbidities, abnormal blood sugar, macrosomia requiring a C-section, and neonatal hypoglycemia, to name a few). In conjunction with the observation period, the person 102 may be provided with instructions to perform one or more activities during the observation period, such as instructing the person 102 to drink beverages or specific meals (e.g., the same beverages associated with OGTT), avoid one or more specific foods, exercise, and rest, to name a few. In one or more embodiments, operating instructions may be provided as part of the observation kit, such as written instructions. Alternatively or additionally, the observation analysis platform 108 may transmit and output instructions via a 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 amount of time in the observation period has elapsed (e.g., two days) and / or based on patterns in the obtained glucose measurements. In conjunction with providing such instructions, the wearable glucose monitoring device 104 automatically monitors person 102's glucose levels after performing the instructed activity, for example by monitoring changes in glucose levels after person 102 consumes the instructed diet, performs the instructed exercise, etc.

[0036] Although in one or more embodiments, while the duration is discussed consistently as several days, the observation period can be variable, for example, such that the observation period can end when enough glucose measurements have been collected to accurately predict the diabetes classification of person 102. For example, in some cases, glucose measurements of person 102 over just a few hours can be processed to predict that person 102 has diabetes with statistical certainty. In this case, the duration of the observation period can be several hours rather than several days. However, in general, the observation period lasts for several days to obtain data, so that features can be extracted to describe the daily variations in glucose and to prevent erroneous predictions that lead to or cannot explain outlier measurements or observations.

[0037] Therefore, the observation kit provider 106 may represent one or more entities associated with obtaining predictions about whether a person 102 has diabetes or is predicted to experience the adverse effects of diabetes. For example, the observation kit provider 106 may represent a provider of a wearable glucose monitoring device 104 and a platform for monitoring and analyzing glucose measurements obtained therefrom, such as the observation analysis platform 108, when it also corresponds to a provider of the wearable glucose monitoring device 104. Alternatively or additionally, the observation kit provider 106 may correspond to a healthcare provider (e.g., a primary care physician, obstetrician / gynecologist (OB / GYN), endocrinologist), doctor's office, hospital, insurance provider, medical testing laboratory, or telemedicine service, to name just a few. Alternatively or additionally, the observation kit provider 106 may correspond to a pharmacist or pharmacy that may have a physical store and / or offer services online. It should be understood that these are merely a few embodiments, and the observation kit provider 106 may represent different entities without departing from the spirit or scope of the described technology.

[0038] In view of this, according to the described technology, the wearable glucose monitoring device 104 can be provided to person 102 in various ways. For example, the wearable glucose monitoring device 104 can be given to person 102 in a doctor's office, hospital, medical testing laboratory, or physical pharmacy (e.g., as part of an observation kit). Alternatively, the wearable glucose monitoring device 104 can be mailed to person 102, for example, from the provider of the wearable glucose monitoring device 104, pharmacy, medical testing laboratory, telemedicine service, etc. Of course, person 102 can obtain the wearable glucose monitoring device 104 for the observation period in other ways through one or more implementations.

[0039] Regardless of how person 102 obtains the wearable glucose monitoring device 104, the device is configured to monitor person 102's glucose levels during an observation period that spans multiple days. The wearable glucose monitoring device 104 may be configured with a glucose sensor, for example, that continuously detects analytes indicating glucose in person 102 and is capable of generating glucose measurements. In the illustrated environment 100, these measurements are represented as glucose measurements 110. In one or more embodiments, the wearable glucose monitoring device 104 is a continuous glucose monitoring ("CGM") system. As used herein, the term "continuous" when used in conjunction with glucose monitoring can refer to the ability of the device to generate measurements substantially continuously, such that the device can 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 different devices (e.g., when a computing device establishes a wireless connection with the wearable glucose monitoring device 104 to retrieve one or more measurements), etc. Figure 2 The function of the wearable glucose monitoring device 104 in generating glucose measurements 110 and other aspects of the device configuration will be discussed in more detail.

[0040] While the wearable glucose monitoring device 104 can be configured in a manner similar to that of a wearable glucose monitoring device used to treat diabetes, in one or more embodiments, the wearable glucose monitoring device 104 may differ from a device used for treatment. These different configurations can be used to control confounding factors during the observation period to obtain measurements that accurately reflect the impact of a user's normal daily behavior on their glucose levels. For example, this can include restricting and / or completely preventing the user from checking these measurements during the observation period. By preventing the user from checking 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 changing their behavior to counteract these events.

[0041] In some cases, the wearable glucose monitoring device 104 may be a dedicated device specifically designed to collect glucose measurements for a user over a multi-day observation period, thereby generating a diabetes classification that can be distinguished in one or more ways from wearable glucose monitoring devices worn by the user for the treatment of diabetes. In other cases, such a wearable glucose monitoring device 104 may have the same hardware characteristics as wearable glucose monitoring devices used for the treatment of diabetes, but may include software that disables or enables different functions, such as software that prevents the user from checking glucose measurements 110 during the observation period. In these cases, functions that were disabled during the observation period can be enabled after the observation period ends so that the user can access previously disabled functions, such as the ability to view glucose measurements in real time.

[0042] Different configurations can also be based on the differences between the use of glucose measurements 110 in relation to the observation period for diabetes prediction and in relation to diabetes treatment. During treatment, glucose measurements are received and output continuously or nearly continuously, and essentially, as these measurements are generated, they can be used to inform treatment decisions, such as helping a person or their caregiver decide what to eat, how to administer insulin, whether to contact a healthcare provider, etc. In these cases, timely (e.g., substantially real-time) understanding of measurements and / or trends can be crucial for effectively mitigating potentially serious adverse effects. In contrast, in these cases, the reception and output of glucose measurements to the subject (or caregiver) may be irrelevant to diabetes prediction. Instead, glucose measurements generated for diabetes prediction are processed so that, at the end of the observation period, or after some other range (e.g., when sufficient measurements have been generated to achieve statistical certainty), an accurate prediction of diabetes can be produced.

[0043] Based on this difference in how glucose measurements are used, wearable glucose monitoring device 104 can have more local storage than wearable glucose measuring devices used for diabetes treatment, for example, 10-15 days of glucose measurement storage configured for observation, compared to 3 hours of storage configured for treatment. The larger storage capacity of wearable glucose monitoring device 104 can be suitable for storing glucose measurements 110 over the duration of the observation period. In contrast, wearable glucose measuring devices used for treatment can be configured to offload glucose measurements so that once the measurements are properly offloaded, they are no longer stored locally on those devices. For example, wearable glucose devices used for treatment can offload glucose measurements by wirelessly transmitting them to an external computing device, for example, at predetermined time intervals and / or in response to establishing or re-establishing a connection with the computing device.

[0044] Regarding the wearable glucose monitoring device 104 being configured to store glucose measurements 110 throughout the observation period, in one or more embodiments, the wearable glucose monitoring device 104 may be configured without wireless transmission means, e.g., without any antenna to wirelessly transmit glucose measurements 110, and without the need for hardware or firmware to generate data packets for such wireless transmission. Instead, the wearable glucose monitoring device 104 may be configured with hardware to transmit glucose measurements 110 via physical, wired coupling. In such a case, the wearable glucose monitoring device 104 may be "plugged in" to retrieve glucose measurements 110 from the device's storage.

[0045] Therefore, the wearable glucose monitoring device 104 can be configured with one or more ports to enable wired transmission of glucose measurements to an external computing device. Embodiments of this physical coupling may include a micro-USB connection, a mini-USB connection, and a USB-C connection, to name just a few. While the wearable glucose monitoring device 104 can be configured to retrieve glucose measurements 110 via a wired connection as described above, in different cases, the wearable glucose monitoring device 104 may alternatively or additionally be configured to offload glucose measurements 110 via one or more wireless connections. Implementations involving wired and / or wireless communication of glucose measurements will be further discussed below.

[0046] In addition to differences in storage and communication, the wearable glucose monitoring device 104 may also include one or more sensors or sensor circuits configured differently from devices designed for diabetes treatment. For example, the sensors and circuitry (e.g., including measurement algorithms) of a wearable glucose monitoring device for treating diabetes may be optimized for measurements ranging from 40 mg / dL to 400 mg / dL. This is because diabetes treatment typically involves deciding what actions to take to mitigate serious glycemic events, such as hypoglycemia and hyperglycemia, that may occur at the ends of the range. However, for diabetes prediction, it may not be necessary to perform fidelity measurements over such a wide range. Instead, diabetes prediction can appropriately generate predictions associated with a smaller range, such as a glucose measurement range from 120 mg / dL to 240 mg / dL. Therefore, the wearable glucose monitoring device 104 may include one or more sensors or sensor circuits optimized to produce measurements within this smaller range. It should be understood that the above differences are merely embodiments of how the wearable glucose monitoring device 104 differs from wearable glucose monitoring devices configured for the treatment of diabetes, and the wearable glucose monitoring device 104 may differ from those devices in different ways without departing from the spirit or scope of the art.

[0047] Once the wearable glucose monitoring device 104 generates a glucose measurement 110, it provides the measurement to the observation and analysis platform 108. As described above, the glucose measurement 110 can be transmitted to the observation and analysis platform 108 via a wired and / or wireless connection. In cases where the observation and analysis platform 108 is partially or entirely implemented on the wearable glucose monitoring device 104, for example, the glucose measurement 110 can be transferred from the device's local storage to the device's processing system via a bus. Where the wearable glucose monitoring device 104 is configured to generate a diabetes classification prediction by processing the glucose measurement 110, the wearable glucose monitoring device 104 may also be configured to provide the predicted diabetes classification as output, for example, by transmitting the diabetes classification to an external computing device. In other cases, the glucose measurement 110 can be processed by an external computing device configured to predict a diabetes classification.

[0048] In one or more embodiments, the wearable glucose monitoring device 104 is configured to transmit glucose measurements 110 to an external device via a wired connection (e.g., via USB-C or some other physical, communication coupling). Here, a connector may be inserted into the wearable glucose monitoring device 104, or the wearable glucose monitoring device 104 may be inserted into an instrument with a socket that mates with corresponding contacts of the device. The glucose measurements 110 can then be retrieved from the storage of the wearable glucose monitoring device 104 via this wired connection, for example, transmitted to the external device via the wired connection. Such a connection can be used in cases where the wearable glucose monitoring device 104 is mailed by person 102 after the observation period, for example, to a healthcare provider, telemedicine service, provider of the wearable glucose monitoring device 104, or medical testing laboratory. For this purpose, the observation kit (not shown) may include packaging (e.g., an envelope or box) to mail the wearable glucose monitoring device 104 to such an entity after the observation period. Such a connection can also be used after the observation period ends, when person 102 puts down the wearable glucose monitoring device 104, for example, in a doctor's office or hospital (or other institution of a healthcare provider), pharmacy, or medical testing laboratory. Alternatively or additionally, wired connections may involve person 102 plugging the wearable glucose monitoring device 104 into an external computing device after the monitoring period, for example, using a wire provided as part of the observation kit. In these cases, the external computing device can transmit glucose measurements 110 to the observation analysis platform 108 via a network (not shown), such as the Internet.

[0049] Alternatively or additionally, providing glucose measurement values ​​110 to the observation and analysis platform 108 may involve a wearable glucose monitoring device 104 transmitting glucose measurement values ​​110 via one or more wireless connections. For example, the wearable glucose monitoring device 104 may wirelessly transmit glucose measurement values ​​110 to external computing devices, such as mobile phones, tablets, tablet PCs, smartwatches, other wearable health trackers, etc. Therefore, the wearable glucose monitoring device 104 may be configured to communicate with external devices using one or more wireless communication protocols or technologies. For example, the wearable glucose monitoring device 104 may use one or more of Bluetooth (e.g., Bluetooth Low Energy), Near Field Communication (NFC), Long Term Evolution (LTE) standards such as 5G to communicate with external devices. When glucose measurement values ​​110 are transmitted to external devices for processing, the wearable glucose monitoring device 104 may be configured with appropriate antennas and other wireless transmission devices. In those cases, glucose measurements 110 can be transmitted to the observation and analysis platform 108 in various ways, such as at predetermined time intervals (e.g., daily, hourly, or every five minutes), in response to the occurrence of certain events (e.g., filling the storage buffer of the wearable glucose monitoring device 104), or in response to the end of the observation period, to name just a few.

[0050] Therefore, regardless of where the observation and analysis platform 108 is implemented, it obtains glucose measurements 110 generated by the wearable glucose monitoring device 104. In one or more embodiments, the observation and analysis platform 108 may be implemented wholly or partially at the wearable glucose monitoring device 104. Alternatively or additionally, the observation and analysis platform 108 may be implemented wholly or partially using one or more computing devices external to the wearable glucose monitoring device 104, such as one or more computing devices associated with a person 102 (e.g., mobile phone, tablet, laptop, desktop, or smartwatch) or with a service provider (e.g., healthcare provider, telemedicine service, service corresponding to the provider of the wearable glucose monitoring device 104, medical testing laboratory service, etc.). In the latter case, the observation and analysis platform 108 may be implemented at least partially on one or more server devices.

[0051] In the illustrated embodiment 100, the observation and analysis platform includes a storage device 112. According to the technology, the storage device 112 is configured to maintain glucose measurements 110. The storage device 112 may represent one or more databases and other types of memory capable of storing glucose measurements 110. The storage device 112 may also store various other data, such as demographic information describing person 102, information about healthcare providers, information about insurance providers, payment information, prescription information, identified health indicators, 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 within the user group.

[0052] In the illustrated embodiment 100, the observation and analysis platform 108 also includes a prediction system 114. The prediction system 114 represents the functionality to process glucose measurements 110 to generate diabetes predictions, such as predicting whether a person 102 has diabetes (e.g., type 2 diabetes, GDM, cystic fibrotic diabetes, etc.) or is at risk of developing diabetes (e.g., prediabetes), and / or whether a person 102 is predicted to experience adverse effects related to diabetes (e.g., comorbidities, abnormal blood sugar, macrosomia requiring cesarean section, and neonatal hypoglycemia, to name a few). 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, utilizing one or more models generated using machine learning techniques and historical glucose measurements and historical outcome data of a user group.

[0053] The illustrated embodiment 100 also includes a diabetes classification 116, which can be output by the prediction system 114. According to the technology, the diabetes classification 116 can indicate whether the person is predicted to have diabetes or whether they are predicted to experience adverse effects related to diabetes. The diabetes classification 116 can also be used to generate one or more classification-based notifications or user interfaces, such as reports to healthcare providers that include a diabetes classification (e.g., the person is predicted to have diabetes) or notifications instructing the person 102 to contact their healthcare provider. Embodiments of user interfaces that can be generated based on the diabetes classification 116 will be combined with... Figure 6 and Figure 7 To provide a more detailed description, consider, for example, the following context: continuously measuring glucose levels and obtaining data describing these measurements. Figure 2 The discussion.

[0054] Figure 2 A more detailed description Figure 1Embodiment 200 illustrates a method for implementing the wearable glucose monitoring device 104. Specifically, Embodiment 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 be implemented in one or more ways and for one or more reasons related to the methods discussed below. Figure 1 They are different.

[0055] In this embodiment 200, the wearable glucose monitoring device 104 is shown as including a sensor 202 and a sensor module 204. Here, the sensor 202 is depicted in the side view as skin 206 inserted under the skin, for example, a person 102. The sensor module 204 is depicted in the top view as a dashed rectangle. The wearable glucose monitoring device 104 also includes the transmitter 208 shown in embodiment 200. The dashed rectangle indicates that the sensor module 204 can be housed or otherwise implemented within the housing of the transmitter 208. In this embodiment 200, the wearable glucose monitoring device 104 also includes an adhesive pad 210 and an attachment mechanism 212.

[0056] In operation, sensor 202, adhesive pad 210, and attachment mechanism 212 can be assembled to form an application component, which is configured to be applied to skin 206 such that sensor 202 is inserted subcutaneously as shown. In this case, transmitter 208 can be attached to the component via attachment mechanism 212 after application to skin 206. Alternatively or additionally, transmitter 208 can be incorporated as part of the application component, such that sensor 202, adhesive pad 210, attachment mechanism 212, and transmitter 208 (with sensor module 204) can all be used simultaneously on skin 206. In one or more embodiments, the application component is applied to skin 206 using a separate sensor applicator (not shown). Unlike conventional tests such as HbA1c, FPG, and 2Hr-PG, which require blood draws, the application of the user-initiated wearable glucose monitoring device 104 is virtually painless and does not require blood draws, drinking sugary drinks, or fasting for several hours. Furthermore, the automated sensor applicator enables person 102 to subcutaneously embed sensor 202 into skin 206 without the assistance of a clinician or healthcare provider.

[0057] The application component can also be removed by peeling the adhesive pad 210 off the skin 206. It should be understood that the wearable glucose monitoring device 104 and its various components shown are merely one embodiment of form without departing from the spirit or scope of the technology described, and the wearable glucose monitoring device 104 and its components may have different form factors.

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

[0059] 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 sensor 202. Sensor module 204 is implemented to receive indications of changes in sensor 202 or changes caused by sensor 202. For example, sensor 202 may include glucose oxidase, which reacts with glucose and oxygen to form hydrogen peroxide, which may be electrochemically detected by sensor module 204, which may include electrodes. In this embodiment, sensor 202 may be configured as or include a glucose sensor configured to detect analytes in blood or tissue fluid indicating glucose levels using one or more measurement techniques. In one or more embodiments, sensor 202 may also be configured to detect analytes in blood or interstitial fluid indicating other markers, such as lactate levels, which may improve the accuracy of predicting diabetes classification. Additionally or alternatively, wearable glucose monitoring device 202 may include additional sensors to sensor 202 to detect those analytes indicating other markers.

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

[0061] In one or more embodiments, sensor module 204 may include a processor and memory (not shown). By maximizing the use of the processor, sensor module 204 may generate glucose measurement values ​​110 based on communication with sensor 202 indicating the changes described above. Based on these communications from sensor 202, sensor module 204 is also configured to generate observation device data 214. Observation device data 214 is a communicable data packet including at least one glucose measurement value 110. Alternatively or additionally, observation device data 214 includes other data, such as multiple glucose measurements 110, sensor identification 216, sensor status 218, etc. In one or more embodiments, observation device data 214 may include other information, such as one or more temperatures corresponding to measurements of glucose measurement value 110 and other analytes. It should be understood that, without departing from the spirit or scope of the art, observation device data 214 may include a variety of data in addition to at least one glucose measurement value 110.

[0062] In an embodiment where the wearable glucose monitoring device 104 is configured for wireless transmission, the transmitter 208 can wirelessly transmit the observation device data 214 as a data stream to a computing device. Alternatively or additionally, the sensor module 204 can buffer the observation device data 214 (e.g., in the memory of the sensor module 204) and cause the transmitter 208 to transmit the buffered observation device data 214 at various intervals, such as time intervals (every second, every thirty seconds, every minute, every five minutes, every hour, etc.), storage intervals (when the buffered observation device data 214 reaches a threshold amount of data or the number of instances of observation device data 214), etc.

[0063] Regarding observation 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 can also be used to identify other aspects of sensor 202, such as the manufacturing batch of sensor 202, packaging details of sensor 202, shipping details of sensor 202, etc. In this way, various problems detected by sensors manufactured, packaged, and / or shipped in a similar manner to sensor 202 can be identified and used in different ways (e.g., to calibrate glucose measurement values ​​110, to notify the user of defective sensors, to notify the manufacturing plant of processing problems, etc.).

[0064] Sensor state 218 represents the state of sensor 202 at a given time, for example, the state of the sensor at the moment one of the glucose measurements 110 is generated. To this end, sensor state 218 may include an entry for each glucose measurement 110, such that there is a one-to-one relationship between the glucose measurement 110 and the state captured in the sensor state 218 information. Generally, sensor state 218 describes the operating state of sensor 202. In one or more embodiments, sensor module 204 may identify one of a plurality of predetermined operating states for a given glucose measurement 110. The identified operating state may be based on communication from sensor 202 and / or the characteristics of those communications.

[0065] For example, sensor module 204 may include (e.g., in memory or other storage) a lookup table having a predetermined number of operating states and a basis for selecting one state from the others. For instance, the predetermined states may include a "normal" operating state, where the basis for selecting this state could be that communication from sensor 202 falls within a threshold indicating normal operation, such as a threshold for expected time, a threshold for expected signal strength, a threshold for ambient temperature being within a suitable temperature range to continue operation as expected, and so on. The predetermined states may also include operating states indicating that one or more characteristics of communication from sensor 202 exceed normal activity and may lead to potential errors in the glucose measurement 110.

[0066] For example, the basis for these abnormal operating states may include receiving communication from sensor 202 outside of a threshold expected time, detecting signal strength of sensor 202 outside of a expected signal strength threshold, detecting ambient temperature outside of a suitable temperature range to continue operation as expected, detecting that person 102 has rolled onto (e.g., on a bed) the wearable glucose monitoring device 104, and so on. Without departing from the spirit or scope of the described technology, sensor state 218 may indicate multiple aspects of sensor 202 and wearable glucose monitoring device 104.

[0067] Having considered the environmental embodiments and the embodiments of wearable glucose monitoring devices, we now consider and discuss some detailed embodiments of diabetes prediction techniques using glucose measurements and machine learning in a digital media environment, according to one or more implementations.

[0068] Diabetes prediction Figure 3 Example 300 of the implementation is described, in which diabetes-related data, including glucose measurements, is routed to different systems associated with diabetes prediction.

[0069] The illustrated embodiment 300 includes from Figure 1The illustrated embodiment 300 also depicts an observation and analysis platform 108 and a person 102. The illustrated embodiment 300 also depicts a device 302 associated with the person 102, which can provide glucose measurements 110 to the observation and analysis platform 108 and / or storage device 112 related to diabetes prediction. The depicted device 302 includes a wearable glucose monitoring device 104 worn by the person 102 during observation to generate glucose measurements 110, and additional devices external to the wearable glucose monitoring device 104. Specifically, the depicted additional external devices include mobile phones and smartwatches, although in one or more embodiments, various other devices may be configured to provide glucose measurements 110 to the observation and analysis platform 108 and / or storage device 112, such as laptops, tablets, wearable health trackers, etc.

[0070] As described above, glucose measurement value 110 can be transmitted or otherwise provided to observation and analysis platform 108 and / or storage device 112 via wired or wireless connection. For example, wearable glucose monitoring device 104 can provide glucose measurement value 110 to observation and analysis platform 108 and / or storage device 112 via wired or wireless connection as described above. In the case where glucose measurement value 110 is provided by one of the attached external devices 302, glucose measurement value 110 can be provided from wearable glucose monitoring device 104 to the attached external device, such that the attached external device communicates or otherwise provides glucose measurement value 110 to observation and analysis platform 108 and / or storage device 112.

[0071] In these scenarios, the additional external device 302 can act as an intermediary between the wearable glucose monitoring device 104 and the observation and analysis platform 108 and storage device 112, allowing the external device 302 to "route" glucose measurements 110 from the wearable glucose monitoring device 104 to the observation and analysis platform 108 and / or storage device 112. Alternatively or additionally, other devices can route glucose measurements 110 from the wearable glucose monitoring device 104 to the observation and analysis platform 108 and / or storage device 112. These other devices may include dedicated devices configured to extract data from the 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.

[0072] The illustrated embodiment 300 also includes a user group 304. User group 304 represents multiple users corresponding to individuals wearing glucose monitoring devices (e.g., wearable glucose monitoring device 104). The glucose measurements 110 of these other users are then provided to the observation and analysis platform 108 and / or storage device 112 by their respective monitoring devices and / or by external computing devices. In one or more embodiments, user group 304 includes users selected as part of one or more “studies” at least in part for collecting data (including glucose measurements 110) such that the data can be used to generate one or more models using machine learning, such as supervised learning, unsupervised learning, reinforcement learning, etc.

[0073] Alternatively or additionally, user group 304 may include users for whom a diabetes prediction was previously generated based on their glucose measurements during observation involving wearable glucose monitoring device 104—in a manner similar to generating a diabetes prediction for person 102. Data generated prior to a diabetes prediction for person 102 and related to research conducted for data collection is referred to as “historical” data because it was generated at a point in time prior to the generation of person 102’s glucose measurement 110. Similarly, data generated prior to a diabetes prediction for person 102, as well as data related to diabetes predictions for other users, is also historical data. According to the technology, historical data includes, for example, historical glucose measurements and historical outcome data. This historical data is used, along with machine learning, to train or otherwise learn a base model regarding… Figure 5 To describe in more detail.

[0074] For example, studies collecting data related to diabetes prediction may require participants to wear glucose monitoring devices over a multi-day period to generate glucose measurements 110 for these participants. Without departing from the spirit or scope of the described technique, this period may have the same or different duration as the observation period used to generate the glucose measurements 110 for person 102. In addition to collecting glucose measurements 110, these studies can be used to obtain other data about the participants. Outcome data 306 corresponds to at least some of these other data and can describe various aspects of the users in user group 304.

[0075] In the context of a study, participants may, in addition to wearing a glucose monitoring device, be tested using conventional techniques that produce one or more diagnostic measurements, such as HbA1c, FPG, and / or 2Hr-PG. Independent diagnostic measurement 308 represents data describing the results of one or more such tests relevant to users in user group 304. For example, independent diagnostic measurement 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) relevant to users in user group 304. Given this, a study participant's glucose measurement 110 can be associated with the corresponding participant's independent diagnostic measurement 308, for example, by labeling the measurement. As discussed in more detail below, machine learning can learn, through a training process, patterns in glucose measurement 110 that indicate specific values ​​of independent diagnostic measurement 308, such as a pattern in glucose measurement 110 suggesting that the corresponding person's HbA1c might be 10.0.

[0076] As shown in the figure, the results data 306 also includes observed adverse effects 310 and clinical diagnoses 312. Observed adverse effects 310 represent data describing the adverse effects experienced by users in user group 304. For example, observed adverse effects 310 could describe whether a user has experienced one or more adverse effects associated with type 2 diabetes, such as diabetic retinopathy, cataracts, glaucoma, blindness, severe hyperglycemia or hypoglycemia, heart and vascular disease, neuropathy, erectile dysfunction, kidney failure or end-stage renal disease, slow healing, hearing impairment, skin diseases (e.g., bacterial and fungal infections), sleep apnea, and Alzheimer's disease, to name just a few.

[0077] Alternatively or additionally, the observed adverse effects 310 may describe whether the user has experienced any of one or more adverse effects associated with GDM, such as her baby being born with excessive weight (requiring a cesarean section), being premature (premature infant), having respiratory distress syndrome, neonatal hypoglycemia, her baby becoming obese or developing type 2 diabetes later in life, stillbirth, etc.

[0078] Alternatively or concurrently, the observed adverse effects 310 may describe whether the user has experienced one or more adverse effects associated with other types of diabetes, such as those associated with type 1 diabetes, cystic fibrotic diabetes, pancreatic diabetes, etc. In this context, the glucose measurements 110 of study participants may be correlated with the observed adverse effects 310 for each participant, for example, by labeling the measurements. As discussed in more detail below, machine learning can learn, through a training process, patterns in the glucose measurements 110 that indicate the occurrence and non-occurrence of the observed adverse effects 310, such as patterns in the glucose measurements 110 indicating the probability that the corresponding individual has a baby with excessive birth weight requiring a cesarean section.

[0079] Clinical diagnosis 312 represents data describing whether users in user group 304 have been diagnosed (or not) with diabetes by a clinician or whether they have been provisionally or preliminarily diagnosed with diabetes. For example, a diagnosis may be made by a clinician based on one or more of independent diagnostic measurements 308 and / or observed adverse effects 310. Additionally or alternatively, clinical diagnosis 312 may be configured to represent a marker based on diagnostic tests that are not approved for diagnosis by, for example, the Food and Drug Administration (FDA) or the general clinical community (e.g., A1CNOW+). A value for clinical diagnosis 312 may indicate that the corresponding user is clinically diagnosed with diabetes (or some type of diabetes), clinically diagnosed with prediabetes (or any different type of prediabetes), provisionally or preliminarily diagnosed with diabetes, does not have diabetes (i.e., was screened), diagnosed with diabetes using an unapproved test, or diagnosed with prediabetes using an unapproved test, to name just a few. In light of this and independent diagnostic measurements 308, for example, a glucose measurement 110 may be associated with the independent diagnostic measurement 308 of the corresponding study participant and the corresponding participant's clinical diagnosis 312. Machine learning can be trained to learn patterns in glucose measurements 110 that indicate specific values ​​in independent diagnostic measurements 308, and also indicate different diagnoses of diabetes, such as a pattern in glucose measurements 110 suggesting a person's HbA1c might be 6.0 (e.g., "estimated A1c"), and also indicate that a clinician's analysis might lead to a diagnosis of prediabetes. While this embodiment is discussed in conjunction with a person's HbA1c, it should be understood that clinical diagnoses can 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 technique.

[0080] In one or more embodiments, outcome data 306 may include or be used as a marker. For example, the value of an independent diagnostic measurement 308 may be used to marker the glucose measurement 110 of a corresponding user in user group 304. Alternatively or additionally, a marker indicating an observed adverse effect 310 experienced by a corresponding user may be used to marker the glucose measurement 110 of that user. Alternatively or additionally, a marker indicating a clinical diagnosis 312 may be used to marker the glucose measurement 110 of a corresponding user; for example, the glucose measurement 110 of a user clinically diagnosed with prediabetes may be associated with the “prediabetes” marker, while the glucose measurement 110 of a different user clinically diagnosed with diabetes may be associated with the “diabetes” marker. Although independent diagnostic measurements 308, observed adverse effects 310, and clinical diagnoses 312 are described in embodiment 300, it should be understood that outcome data 306 may include data describing different, additional, or fewer aspects of the users in user group 304 without departing from the spirit or scope of the described technology.

[0081] As depicted in Embodiment 300, glucose measurements 110 and outcome data 306 of users in user group 304 are transmitted or otherwise provided to observation and analysis platform 108 and / or storage device 112. In addition to glucose measurements 110 and outcome data 306, supplementary data describing other aspects of users in user group 306 can be obtained by observation and analysis platform 108 and / or storage device 112. For example, such supplementary data may include demographic data (e.g., age, sex, 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 supplementary data are merely examples without departing from the spirit or scope of the described technology, and supplementary data may include more, less, or different types of data. In one or more embodiments, observation and analysis platform 108 and / or storage device 112 may obtain such supplementary data (or at least some supplementary data) regarding person 102 and users in user group 304.

[0082] It is worth noting that the illustrated embodiment 300 depicts both the observation and analysis platform 108 and the storage device 112, and also shows a dashed arrow between the storage device 112 and the observation and analysis platform 108. Generally, this arrow indicates that the data maintained in the storage device 112 can be retrieved by the observation and analysis platform 108 from the storage device 112. In other words, the data maintained by the storage device 112 can be provided to the observation and analysis platform 108. As described above, the storage device 112 can store the glucose measurement values ​​110 of person 102, as well as the glucose measurement values ​​110 and result data 306 of user group 304.

[0083] In one or more embodiments, the observation and analysis platform 108 and storage device 112 may correspond to the same entity, such as a glucose monitoring device (e.g., wearable glucose monitoring device 104) and a provider of services related to glucose monitoring. In such embodiments, the observation and analysis platform 108 and storage device 112 may be implemented in the “cloud,” spanning multiple computing devices (e.g., servers) and storage resources allocated to or otherwise associated with the entity (e.g., through subscription or ownership). For this purpose, glucose measurements 110 of person 102 and glucose measurements 110 and result data 306 of user group 304 can be obtained by the observation and analysis platform 108 from storage device 112 in such a manner that the server associated with the service provider obtains data from storage associated with that service provider.

[0084] In other embodiments, the observation and analysis platform 108 and the storage device 112 may correspond to different entities. For example, the storage device 112 may correspond to a first entity, such as a person 102's computing device (e.g., a mobile phone or tablet device), and the observation and analysis platform 108 may correspond to a second entity, such as glucose monitoring devices and service providers related to glucose monitoring. In this embodiment, the observation and analysis platform 108 may be implemented at least partially as an application of the second entity running on the person 102's computing device. Alternatively or additionally, the observation and analysis platform 108 may be implemented using a server device of the second entity. In the application embodiment, the application of the second entity may obtain glucose measurements 110 of one or more individuals 102, glucose measurements 110 of user group 304, or result data of user group 304 from the storage device 112 (e.g., via a bus or other local transmission device of the computing device) implemented locally on the computer device. In the server embodiment, the server of the second entity may obtain data from the storage device 112 implemented on the computing device via one or more networks, such as the Internet.

[0085] In another embodiment, the observation and analysis platform 108 and the storage device 112 correspond to different entities, with the storage device 112 potentially corresponding to a first entity, such as a glucose monitoring device and a provider of glucose monitoring-related services (or limited services related to glucose monitoring). In yet another embodiment, the observation and analysis platform 108 may correspond to a second, different entity, such as a service provider, or a data partner of the first entity. In this embodiment, the second entity can be considered a "third party" related to the entity corresponding to the storage device 112 (and the wearable glucose monitoring device 104). When corresponding to a data partner, the observation and analysis platform 108 may retrieve data from the first entity (i.e., the storage device 112) according to one or more legal agreements between the first and second entities. Providing the data maintained in the storage device 112 to the observation and analysis platform 108 may be controlled by an application programming interface (API).

[0086] In this type of situation, such an API can be considered an "exit" of data, such as glucose measurement 110 and result data 306. An "exit" refers to a data flow that typically originates from a first entity and flows outward to a third party (e.g., a second entity). In the context of data provision, the API may expose one or more "calls" (e.g., a specific format of a data request) to a third party. For example, the API may expose these calls to a third party (e.g., an enterprise corresponding to the first entity) after entering into an agreement that allows the third party to obtain data from storage device 112 via the API. As part of this agreement, the third party may agree to exchange payment in order to obtain data from the first entity. Alternatively or additionally, the third party may agree to exchange its generated data (e.g., via associated devices) in order to obtain data from the first entity. The parties entering into an agreement to obtain data (e.g., glucose measurement 110) from the first entity via the API can be referred to as "data partners." In operation, the API allows a third party to request data (e.g., glucose measurement 110 and / or result data 306) maintained in storage device 112 in a specific request format. If the request is made in a specific format, the first entity provides the requested data in a specific response format. The requested data may be provided in a specific response format in one or more communications (e.g., data packets) on a network (e.g., the Internet). Embodiments of a second entity that can be considered a “third party” include various service providers, such as those providing one or more health monitoring / tracking services, fitness-related services, telemedicine services, medical testing laboratory services, etc. In practice, storage device 112 and observation and analysis platform 108 may be implemented using various devices and / or resources (e.g., computing, communication, storage, etc.), and the division (or non-division) between entities corresponding to various devices and / or resources may differ from the division described above without departing from the spirit or scope of the technology described herein.

[0087] Regardless, the observation and analysis platform 108 is configured to obtain glucose measurements 110 for person 102 and glucose measurements 110 for user group 304, as well as result data 306, and process them according to the described technique. For example, using glucose measurements 110 and result data 306 from user group 304, the prediction system 114 is configured to generate one or more machine learning models, such as regression models, neural networks, or reinforcement learning agents. Once one or more such models are generated, the prediction system 114 is configured to use those models to process the glucose measurements of person 102 to predict the diabetes classification 116 of person 102.

[0088] In the illustrated embodiment 300, the prediction system 114 is shown as outputting a notification 314. Notification 314 may be based on or include a diabetes classification 116. Consider an embodiment where the diabetes classification 116 output by one or more machine learning models of the prediction system 114 is a label indicating that person 102 is predicted to have diabetes, such as "1" (where "0" indicates no diabetes) or a text label, such as "diabetes". In this case, simply providing person 102 with the diabetes classification 116 may be undesirable. If this information is not provided along with relevant educational materials, or is not provided in a personalized manner within an appropriate context, then the provision of this information can negatively impact person 102 in various ways, such as causing confusion, anger, depression, etc. Therefore, notification 314 may simply be based on the diabetes classification 116, for example, by informing person 102 that the results of the observation period are available and instructing them to schedule an appointment with his or her relevant healthcare provider.

[0089] In contrast, providing diabetes classification 116 to person 102's healthcare provider may not be undesirable. Instead, providing diabetes classification 116 to the healthcare provider (as opposed to not providing classification) is preferable, allowing the healthcare provider to appropriately inform person 102 and also develop a treatment plan for person 102. In such a case, notification 314 could simply correspond to diabetes classification 116. Alternatively, the notification delivered to the healthcare provider (or others) could be configured to include a report that includes diabetes classification 116 as well as other information, such as a trajectory of person 102's glucose measurements 110 during the observation period, measurements derived from those glucose measurements 110, treatment recommendations (e.g., learned from historical data from user group 304), and so on. Examples of these notifications will be combined... Figure 6 and Figure 7 A more detailed discussion follows. Considering the context of predicting the glucose classification 116 of human 102 based on glucose measurements 110, the following considerations are made. Figure 4 The following discussion will follow.

[0090] Figure 4 A more detailed description Figure 1 Example 400 of the implementation of the prediction system, wherein machine learning is used to predict diabetes classification.

[0091] In the illustrated embodiment 400, the prediction system 114 is shown to acquire, for example, a glucose measurement 110 from a storage device 112. Here, the glucose measurement 110 may correspond to a person 102. In this embodiment 400, the prediction system 114 is depicted as including a preprocessing manager 402 and a machine learning model 404, which are configured to generate a prediction of a diabetes classification 116 based on the glucose measurement 110 of person 102. Although 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 to generate a diabetes classification 116 based on the glucose measurement 110 without departing from the spirit or scope of the described technique.

[0092] In one or more embodiments, glucose measurements 110 are configured as time-series data, such that each glucose measurement 110 corresponds to a timestamp. For example, glucose measurements 110 may be configured as one or more glucose “trajectories.” While glucose measurements 110 are typically received or maintained sequentially, for example, from wearable glucose monitoring device 104 and / or external devices via observation and analysis platform 108, in some cases, the order in which one or more glucose measurements 110 are received or maintained may not be the same as the order in which the glucose measurements 110 were generated. For example, data packets containing glucose measurements 110 may be received out of order. Therefore, the order of reception may not match temporally the order in which wearable glucose monitoring device 104 generates glucose measurements 110. Furthermore or alternatively, transmissions including one or more glucose measurements 110 may be disrupted. In fact, there are several reasons why the glucose measurements 110 obtained by prediction system 114 may not be exactly in chronological order.

[0093] To this end, the preprocessing manager 402 can be configured to determine the time series of glucose measurements 110 based on 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 one or more measurements may also be missing—gaps may exist in the time-ordered sequence of predicted measurements. In these cases, the preprocessing manager 402 can also be configured to interpolate the missing glucose measurements and incorporate them into the time series. Although this functionality has been discussed, in one or more embodiments, 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 the preprocessing manager 402 does not perform sorting of those measurements and interpolation of the missing measurements.

[0094] Typically, the preprocessing manager 402 is configured to preprocess glucose measurements 110 to generate data (e.g., one or more feature vectors) that can be provided as input to a machine learning model 404, and data that can be reported in relation to a diabetes classification 116 (e.g., included as part of a notification 314). In the illustrated embodiment 400, the preprocessing manager 402 is depicted as outputting extracted glucose features 406. The preprocessing manager 402 can determine the extracted glucose features 406 by processing the glucose measurements 110 according to one or more predetermined algorithms or functions. Each of the different extracted glucose features 406 may correspond to a different algorithm or function used by the preprocessing manager 402 to process the glucose measurements 110.

[0095] Here, the extracted glucose features 406 include time measurements exceeding a threshold 408, rate of change measurements 410, and observation period anomalies 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 technique. For example, the extracted glucose features 406 may also, or alternately, include one or more of the following: mean glucose (e.g., duration or daily of the observation period), median glucose, quartile range of glucose measurements 110, variance of glucose measurements 110, nocturnal hyperglycemia, difference between mean glucose during wakefulness and mean glucose during sleep, diurnal variability of glucose, diurnal variability of glucose, statistical distribution of glucose, and threshold percentiles of glucose (e.g., statistically significant threshold percentiles, such as 94%). th Glucose ranges from percentiles or higher, 10th to 90th percentiles, standard deviation of glucose, mean daily deviation (MODD), and mean glucose variability (MAGE), to name just a few.

[0096] It is worth noting that the time measurement 408 and the rate of change measurement 410 exceeding the threshold are measurements that cannot be determined using conventional diagnostic testing. Instead, the time measurement 408 and the rate of change measurement 410 exceeding the threshold must be time-based, requiring that each data point (i.e., glucose measurement 110) be associated with a time point and ordered according to their time. Typically, the time measurement 408 exceeding the threshold corresponds to the amount of time during which the glucose measurement 110 of person 102 is higher than the glucose threshold during the observation period. For example, to calculate the time measurement 408 exceeding the threshold, the preprocessing manager 402 can identify sequentially consecutive glucose measurements 110 exceeding the glucose threshold (e.g., based on a comparison of the measurement with the threshold) and determine the time difference between the first measurement exceeding the threshold and the last measurement exceeding the threshold. Without a time associated with each measurement, and without generating measurements with an appropriate granular time increment to capture these characteristics, it is impossible to simply determine the amount of time exceeding the glucose threshold. It should be understood that the amount of time exceeding the threshold is contrasted with the number of measurements exceeding the threshold or the percentage of measurements exceeding the threshold, and the preprocessing manager 402 can also be configured to determine these measurements.

[0097] Typically, the rate of change measurement 410 corresponds to the difference in glucose measurements 110 taken by the user within a unit of time. To determine the rate of change measurement 410, the preprocessing manager 402 can determine the difference in the amount of glucose measured and the difference in time between at least two measurements, making it possible to determine the change in glucose levels over a given time unit, such as a change in mg / dL per minute. It should be understood that such a rate of change can be determined using more than two glucose measurements 110. In any case, the rate of change measurement 410 cannot be determined without the temporal sequence of the glucose measurements 110. These rate of change measurements 410 can indicate the rate at which the body of person 102 responds to a glucose spike caused by carbohydrate consumption—which can further indicate the insulin response of person 102. In summary, the temporal sequence of glucose measurements 110 makes it possible to determine multiple measurements that cannot be determined using data from other diagnostic tests.

[0098] Embodiments of the time measurement 408 exceeding the threshold may include, by way of example and not limitation, times exceeding 130 mg / dL (corresponding to the amount of time during which the human 10² glucose level exceeds 130 mg / dL) and times exceeding 140 mg / dL (corresponding to the amount of time during which the human 10² glucose level exceeds 140 mg / dL). In one or more embodiments, the time measurement 408 exceeding the threshold may correspond to the amount of time exceeding the threshold, which may range from 120 mg / dL to 240 mg / dL. Furthermore, the time measurement 408 exceeding the threshold may include only a single measurement exceeding the threshold, such as the amount of time exceeding 140 mg / dL, or multiple measurements, such as the amount of time exceeding 130 mg / dL, the amount of time exceeding 140 mg / dL, and the amount of time exceeding 150 mg / dL.

[0099] As part of or in addition to the extracted glucose feature 406, other time-based threshold measurements that the preprocessing manager 402 may determine include time measurements within a range that correspond to the amount of time during the observation period of person 102. Glucose is between a first glucose level and a second glucose level below the first glucose level, corresponding to the upper and lower limits of the range, respectively. Conversely, the preprocessing manager 402 may determine time measurements outside the range that correspond to the amount of time during the observation period when person 102's glucose measurement 110 is outside such a range. Embodiments of the rate of change measurement 410 may include, for example, the average rate of change after a high glucose measurement, the average rate of change after a carbohydrate consumption measurement, the rate of change at different times of day (e.g., at night), etc.

[0100] The preprocessing manager 402 can use any of a variety of known statistical anomaly detection techniques to determine the observation period anomaly 412, including, for example, unsupervised anomaly detection techniques, supervised anomaly detection techniques, and semi-supervised anomaly detection techniques. Furthermore, the preprocessing manager 402 can determine one or more statistical measurements related to the time of day, such as nighttime average and median glucose measurements. Similarly, if the glucose measurement 110 does not have a corresponding time, these measurements cannot be determined.

[0101] In addition to identifying these different features of glucose, the preprocessing manager 402 can determine which glucose measurements 110 will be used as the basis for input into the machine learning model 404. In other words, the preprocessing manager 402 can filter glucose measurements 110 by removing at least a portion of the glucose measurements 110 from the input into the machine learning model 404. The preprocessing manager 402 can then determine the extracted glucose features 406 from the filtered glucose measurements.

[0102] For example, the preprocessing manager 402 can select a subset of glucose measurements 110 (e.g., measurements from three “worst” days), generate extracted glucose features 406 for that subset, and then generate input data based on the extracted glucose features 406 to feed into the machine learning model 404. Alternatively, the preprocessing manager can select a subset of days where x worst days are removed (or unselected to be included in the subset). In any case, in one or more implementations, unselected measurements and / or data corresponding to unselected measurements may not be fed into the machine learning model 404. The preprocessing manager 402 can select which glucose measurements 110 will be used as the basis for input data in a variety of ways, such as based on daily averages of glucose measurements (e.g., where the worst days are the highest average glucose based on the performance of the wearable glucose monitoring device 104, such as the three days with the highest average glucose) (e.g., the first and last days may be eliminated, or several days may be eliminated due to receiving device or sensor errors), and so on. In addition to data deletion, the preprocessing manager 402 may alternatively or additionally replace or add one or more glucose measurements 110 with higher fidelity measurements, such as measurements interpolated during preprocessing.

[0103] Regardless of the specific glucose features extracted, preprocessing manager 402 is configured to generate input data to be fed into machine learning model 404. In one or more embodiments, this input data may be configured as a feature vector representing one or more features. In one embodiment, the input data may correspond to a single feature, such as a time measurement 408 exceeding a threshold, for example, the amount of time exceeding 140 mg / dL. In this embodiment, preprocessing manager 402 may generate a feature vector representing the amount of time (or percentage of time) during which glucose in person 102 exceeds the threshold. In other embodiments, the input data may correspond to multiple features, such as the time measurement 408 exceeding the threshold and average glucose. Thus, preprocessing manager 402 may generate a feature vector representing the amount of time (or percentage of time) during which glucose in person 102 exceeds the threshold and the average glucose in person 102 during the observation period. It should be understood that any of the extracted glucose features 406 (or other determinations) described above can be used in single-feature embodiments, and any combination of these features (or determinations) can be used in multi-feature embodiments.

[0104] In addition to the features extracted from glucose measurements 110, the preprocessing manager 402 may also incorporate features from supplementary data to describe different aspects of person 102. As described above, this supplementary data may include supplementary analyte data (e.g., lactate measurements), environmental data (e.g., body temperature), data on observed adverse effects (e.g., data describing any of the various adverse effects associated with diabetes that have been observed), demographic data obtained through questionnaires or otherwise (e.g., descriptions of age, sex, race), medical history data, stress data, nutritional data, exercise data, prescription data, height and weight data, occupational data, and so on. In other words, the data provided as input to machine learning model 404 or a set of data for machine learning model 404 can describe multiple aspects of person 102 (e.g., features as input feature vectors) in one or more embodiments without departing from the spirit or scope of the technique, except for glucose-based features. In such a case, machine learning model 404 is trained using similar historical data from user group 304.

[0105] Although the illustrated embodiment 400 depicts a preprocessing manager 402 preprocessing glucose measurements 110 to produce extracted glucose features 406, and using these features as input to a machine learning model (e.g., feature vectors indicating the extracted features), in one or more embodiments, the preprocessing manager 402 may produce feature vectors representing one or more time series (e.g., trajectories) of glucose measurements 110 (alone or with other features). Therefore, the input data to the machine learning model 404 may correspond to or otherwise include a vectorized time series of glucose measurements 110 or multiple vectorized time series of glucose measurements 110. In embodiments where time series glucose measurements are vectorized, the machine learning model 404 may, for example, correspond to a neural network. In embodiments where extracted glucose features 406 (e.g., time measurements 408 exceeding a threshold) and statistical features (e.g., quartile ranges) are vectorized, the machine learning model may, for example, correspond to a regression model, such as a linear or logistic regression model.

[0106] In response to receiving input data from preprocessing manager 402, machine learning model 404 is configured to generate and output diabetes classification 116. Specifically, machine learning model 404 can be trained to output diabetes classification 116. For example, machine learning model 404 can be trained based on one or more training methods and using historical glucose measurements and outcome data from which diabetes classification can be derived (e.g., using glucose measurements 110 and outcome data 306 of user group 304), or it can learn a base representation. According to the technique, machine learning model 404 can represent one or more models, including, for example, a model trained to predict whether a person has diabetes, and in one or more embodiments, additional models trained for predicting whether a person has diabetes (i.e., diabetes classifications that can be used to filter out individuals who do not have diabetes to some extent). Each model in the multi-model configuration can receive input data describing different configurations of different aspects, e.g., feature vectors having features representing different aspects related to diabetes. It should be understood that in other embodiments, a single model can be configured to generate two types of predictions. In one or more implementations, the machine learning model 404 can be configured as a collection of models, each producing different diabetes-related predictions than the other models.

[0107] The diabetes classification 116 can classify a person 102 based on one or more results corresponding to the results described in the result data 306 used to train the machine learning model 404. In an implementation where the machine learning model 404 is trained or learns using the clinical diagnoses 312 of the user population 304, the machine learning model 404 can classify the person 102's glucose measurement 110 into a category corresponding to one of these categories, such as diabetes, prediabetes, or no diabetes. For this purpose, a healthcare provider can use the diabetes classification 116 to treat the person 102 or to develop a treatment plan similar to how a healthcare provider 102 would be treated if diagnosed with diabetes based on conventional techniques (e.g., HbA1c, FPG, and / or 2Hr-PG).

[0108] Similarly, when using observed adverse effects 310 from a user group to train or learn a machine learning model, then the machine learning model 404 can output the glucose measurement 110 of person 102 indicating the probability that the person is experiencing different adverse effects, for example, a probability from zero to one that the person will experience various adverse effects associated with different types of diabetes. In some implementations, there may be machine learning models trained or built for each effect, such that machine learning model 404 represents a set of models capable of generating predictions about whether person 102 will experience each effect or the probability that the person experiences each effect.

[0109] In implementations where the machine learning model is trained or learned, using independent diagnostic measurements 308 of the user group, the machine learning model 404 can output predictions of values ​​for specific diagnostic measurements, such as HbA1c, FPG, 2Hr-PG, or OGTT. The output diabetes classification 116 largely depends on how the machine learning model 404 was trained and the information available. Specifically, the diabetes classification 116 represents—for example, a marker indicating whether a person has diabetes or has a risk of developing diabetes (e.g., a diabetes marker, a prediabetes marker, or a nondiabetes marker), a marker indicating whether a person has a specific type of diabetes (e.g., type 1 diabetes, type 2 diabetes, and GDM), a probability, or a measurement—depending on the training. Furthermore, different types of machine learning models may be better suited to generating predictions associated with different types of outcomes, which can be represented by the diabetes classification 116. In the context of training the machine learning model, let's now consider... Figure 5 The following discussion will follow.

[0110] Figure 5 An embodiment 500 of the implementation of the prediction system 114 is described in more detail, wherein a machine learning model is trained to predict diabetes classification.

[0111] In the illustrated embodiment 500, the prediction system 114 includes a model manager 502 that manages machine learning models 404. According to the technology, machine learning model 404 can represent a single machine learning model or a collection of multiple models. Machine learning model 404 can correspond to different types of machine learning models, where different methods are used to learn the underlying model, such as supervised learning, unsupervised learning, and / or reinforcement learning. For example, these models can include regression models (e.g., linear, multinomial, and / or logistic regression models), classifiers, neural networks, and reinforcement learning-based models, to name just a few.

[0112] Without departing from the spirit or scope of the described technology, machine learning model 404 may be configured as or include other types of models. These different machine learning models may be constructed or trained (or otherwise learned) using different algorithms, at least in part due to different structures and / or learning paradigms. Therefore, it should be understood that the following discussion of the functionality of model manager 502 applies to a variety of machine learning models. However, for illustrative purposes, the functionality of model manager 502 will be described in general terms in relation to statistical models and neural networks.

[0113] Broadly speaking, model manager 502 is configured to manage machine learning models, including machine learning model 404. For example, this model management includes building machine learning model 404, training machine learning model 404, updating the model, and so on. Specifically, model manager 502 is configured to perform this model management using at least part of a large amount of data maintained in storage device 112. As shown, this data includes glucose measurements 110 and result data 306 of user group 304. In other words, model manager 502 uses glucose measurements 110 and result data 306 of user group 304 to build machine learning model 404, train machine learning model 404 (or otherwise learn a base model), and update the model. In embodiments where machine learning model 404 receives data other than glucose measurements or extracted features of these measurements as input, model manager 502 also uses this additional data from user group 304 to build, train, and update machine learning model 404.

[0114] In one or more implementations, model manager 502 generates training data to train machine learning model 404 or otherwise learn the parameters of the model. Broadly speaking, the generation of training data depends on the diabetes classification output by the machine learning model design. This training data will vary, for example, if machine learning model 404 is configured to generate predictions of a person's diagnostic measurements, the adverse effects that person will experience, or a person's clinical diagnosis. Regardless of the outcome to be predicted, generating training data may include temporally sorting glucose measurements 110 of user group 304 (if glucose measurements 110 have not yet been temporally sorted) and extracting glucose features from those temporally sorted glucose measurements 110. Model manager 502 may utilize the functionality of preprocessing manager 402 to form time-series glucose measurements 110 and extract glucose features, for example, in a similar manner to generate extracted glucose features 406.

[0115] Generating training data also includes associating the trajectory of glucose measurement 110 or features extracted from glucose measurement 110 (e.g., similar extracted glucose features, but for glucose measurement 110, user group 304) with the result data 306 of the corresponding user in user group 304. In this way, the glucose trajectory or extracted glucose features corresponding to a specific user are associated with the result data 306 of that specific user. For example, a specific user may have been clinically diagnosed with diabetes, and his or her glucose levels may have consistently been above a threshold for 27% of the observation period. In this case, model manager 502 can form training instances that include an input portion whose value indicates that the user's glucose levels were above the threshold for 27% of the time, and an associated output portion whose value indicates that the patient has diabetes, such as "1" or some other corresponding value.

[0116] In one or more embodiments, model manager 502 can build a statistical model by extracting observations or labels corresponding to at least one outcome type from outcome data 306, such as values ​​for clinical diagnoses 312, such as “diabetes,” “prediabetes,” and “no diabetes,” or values ​​indicating these labels. Once built, the statistical model is configured to predict values ​​or labels for that at least one outcome type and output it as a diabetes classification 116—indicating that values ​​or labels for that at least one outcome type are not used as input to the model. For example, in the case where the statistical model is a regression model, outcome values ​​or labels may correspond to one or more dependent variables. Conversely, one or more glucose features extracted from glucose measurements 110 may be used as input to the model. Thus, in the case where 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.

[0117] Given a set of result values ​​or labels in the result data 306 and a set of feature values ​​extracted from glucose measurements 110, model manager 502 "fits" these sets of values ​​to the equation using one or more known methods, such that result values ​​or labels are produced within a certain tolerance in response to the input of the extracted glucose feature values. Examples of such fitting methods include using least squares, using minimum absolute deviation regression, minimizing a penalized version of the least squares cost function (e.g., ridge regression or lasso regression), and so on. "Fitting" refers to model manager 502 using one or more methods and these sets of values ​​from the training data to estimate the model parameters of the equation.

[0118] The estimated parameters include, for example, weights applied to the values ​​of the independent variables (e.g., extracted glucose feature 406) when they are input into the machine learning model during operation. Model manager 502 incorporates these parameters, estimated by fitting observations of user population 304, into the equations to generate machine learning model 404 as a statistical model. In operation, prediction system 114 inputs the values ​​of the independent variables (e.g., values ​​of one or more 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 diabetes classification 116.

[0119] In the following discussion, the ability of model manager 502 to build and train machine learning models is discussed in relation to the configuration of machine learning model 404 that corresponds to or includes at least one neural network.

[0120] Regarding the training data used, as described above, the model manager 502 can generate instances of training data, including an input portion and an expected output portion, i.e., basic facts used for comparison with the model's output during training. The input portion of the training data instance may correspond to one or more trajectories of glucose measurements 110 and / or one or more extracted features of glucose measurements 110 for a specific user. The output portion may correspond to one or more values ​​of outcome data 306 for a specific user, such as values ​​indicating a clinical diagnosis of diabetes or HbA1c values ​​observed by the user. Similarly, whether trajectories are used for training, which extracted features are used for training, and which outcome data are used for training depends on the data received as input and the data designed (and trained) as output by the machine learning model 404.

[0121] Model manager 502 trains machine learning model 404 using training inputs along with corresponding expected outputs. For training purposes, model manager 502 can train machine learning model 404 by providing data instances from the training input set to machine learning model 404. In response, machine learning model 404 generates a prediction of diabetes classification, such as by predicting a value indicating a clinical diagnosis of diabetes or a user's observed HbA1c value. Model manager 502 obtains this training prediction as output from machine learning model 404 and compares the training prediction with the predicted output corresponding to the training inputs. For example, if machine learning model 404 outputs a diabetes classification indicating that the user has diabetes, this prediction is compared with the output data (e.g., classifying the user as having diabetes or not having diabetes) to determine if the prediction is correct. Based on this comparison, model manager adjusts the internal weights of machine learning model 404 so that the machine learning model can substantially reproduce the predicted output when provided with responsive training inputs in the future.

[0122] The process of feeding instances of the training input into the machine learning model 404, receiving training predictions from the machine learning model 404, comparing the training predictions with the expected output (observed) corresponding to the input instances (e.g., using a loss function such as root mean square error), and adjusting the internal weights of the machine learning model 404 based on these comparisons can be repeated hundreds, thousands, or even millions of times—each iteration using instances of the training data.

[0123] Model manager 502 can perform such iterations until machine learning model 404 is able to generate predictions that are consistent with and substantially match the expected output. The ability of a machine learning model to consistently generate predictions that substantially match the expected output can be termed "convergence." Therefore, it can be said that model manager 502 trains machine learning model 404 until it "converges" to a solution, for example, because, due to the training iterations, the model's internal weights have been appropriately adjusted so that the model consistently generates predictions that substantially match parts of the expected output.

[0124] As described above, the machine learning model 404 can be configured in one or more embodiments to receive inputs in addition to receiving trajectories of glucose measurements and / or features extracted from these measurements. In such an embodiment, the model manager 502 can form training instances that include a training input portion, a corresponding expected output portion, and additional input data describing any other aspects of the user group 304 used to predict diabetes classification, such as demographics, medical history, exercise, and / or stress. This additional data, along with the training input portion, can be processed by the model manager 502 according to one or more known techniques to produce an input vector. This input vector describing the training input portion and other aspects can then be provided to the machine learning model 404. In response, the machine learning model 404 can generate diabetes classification predictions in a manner similar to that described above, such that the predictions can be compared with the expected output portion of the training instances, and the model's weights can be adjusted based on this comparison.

[0125] Once the machine learning model 404 is trained, it is used to predict diabetes classifications, as discussed above and below. It is also noted that the diabetes classification output by the machine learning model 404 can serve as the basis for various information provided to the person 102 associated with generating the prediction, as well as others related to that person, such as that person 102's healthcare provider, caregivers, telemedicine, or health tracking services. Considering the information that can be output based on the prediction... Figure 6-8 The following discussion will follow.

[0126] Figure 6 An embodiment 600 depicts an implementation of a user interface displayed to notify a user of a diabetes prediction, the prediction being generated based on glucose measurements taken during observation.

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

[0128] Therefore, a user interface 604 can be displayed to notify person 102 (or an associated person) about diabetes classification 116 without revealing the predicted classification. This is because the output of diabetes classification 116 to the actual person 102 corresponding to the classification can affect person 102 in various negative ways, such as causing confusion, anger, depression, etc. In this embodiment 600, the user interface 604 includes a summary of the processing of person 102's glucose measurement values. The user interface 604 also includes recommendations for actionable behavior based on the diabetes classification—in this case, recommending that person 102 follow up with his or her healthcare provider. Furthermore, the user interface 604 includes graphical user interface elements 606 selectable to perform the recommended behavior. Each of the user interface elements 606 can be selected to schedule a follow-up appointment with person 102's healthcare provider, such as an appointment at the healthcare provider's physical location or via telephone or video conferencing, such as a meeting related to telemedicine and / or telehealth services. It should be understood that notifications based on diabetes classification 116 but not including that classification can be configured in different ways without departing from the spirit or scope of the technology described.

[0129] Figure 7 Example 700 depicts an implementation of a user interface displayed for reporting diabetes predictions and other information related to diabetes predictions to a user.

[0130] The illustrated embodiment 700 includes a display device 702 that displays a user interface 704 configured for reporting. In this embodiment, the user interface 704 may correspond to a notification 314. Figure 6 In contrast to the illustrated embodiment, embodiment 700 represents a notification including diabetes classification 116. In this illustrated embodiment 700, the graphical diagnostic element 706 represents or otherwise indicates diabetes classification 116. Here, the display device 702 may be associated with a healthcare provider associated with a person 102 who has their glucose measurements collected during observation and for whom diabetes classification 116 has been generated.

[0131] To this end, a user interface 704 can be displayed to report diabetes classification 116 to the healthcare provider, along with additional information that may be related to that classification. In operation, the healthcare provider can independently analyze the reported additional information and provide a diagnosis different from that indicated by diabetes classification 116. In this embodiment 700, the additional information includes glucose trajectories 708, 710. Those trajectories represent glucose measurements 110 collected from 102 individuals over two days during the observation period. The user interface 704 also depicts controls that allow the user to navigate to other collected glucose measurements 110, such as trajectories corresponding to the days before or after the observation period.

[0132] User interface 704 also includes a graphical glucose feature element 712, which represents or otherwise indicates one or more extracted glucose features 406 determined by preprocessing manager 402 based on glucose measurement 110 of person 102. In addition to the predicted clinical diagnosis, as shown by the graphical diagnostic element 706, user interface 704 also includes a predicted adverse effects element 714 and a probability element 716. The inclusion of these elements indicates that machine learning model 404 can be configured (e.g., by configuring it as an ensemble of models and / or based on architecture and training) to generate predictions for more than one type of diabetes classification. For example, machine learning model 404 can be configured to predict the clinical diagnosis of person 102, the value of one or more of multiple independent diagnostic measurements (e.g., HbA1c, FPG, 2Hr-PG, and OGTT), and the probability that person 102 will experience one or more of the multiple adverse effects of diabetes.

[0133] Specifically, the predicted adverse effect element 714 corresponds to an adverse effect that the diabetes classification indicates a person 102 is more likely to experience rather than not experience, for example, based on a machine learning model output that the probability of experiencing these effects is greater than 50%. It should be understood that the machine learning model 404 may also output the predicted probability of any adverse effect occurring in one or more cases along with the corresponding probability. The probability element 716 includes the probability of the adverse effect occurring as indicated by element 714. 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 reports including the diabetes classification 116 may be configured differently without departing from the spirit or scope of the technology, such as for a printable document.

[0134] Figure 8 Example 800 depicts one implementation of a user interface for collecting additional data that can be used as input to a machine learning model for generating diabetes predictions.

[0135] The illustrated embodiment 800 includes a computing device 802 that displays a user interface 804. In this embodiment 800, in addition to glucose measurements 110 collected during observation, the user interface 804 can also be displayed to collect data about person 102. This additional data, along with the trajectory of glucose measurements 110 and / or one or more extracted glucose features 406, can be provided as input to a machine learning model 404; that is, the additional data can be represented by features of the feature vector input to the model. To train the machine learning model 404, this additional data can also be collected from users of user group 304. Therefore, the user interface 804 can be displayed to users of user group 304 to collect this additional data from those users, such as data describing demographics, medical history, exercise, and / or stress.

[0136] In the illustrated embodiment 800, the user interface 800 includes a variety of graphical elements with which the user can interact (e.g., select or enter values) to provide additional data about himself or her. However, it should be understood that the included graphical elements are merely embodiments, and the user interface for collecting such additional data can be configured in different ways to include more, fewer, or different elements, enabling these elements to collect a variety of additional data without departing from the spirit or scope of the described technology.

[0137] Having discussed detailed embodiments of diabetes prediction techniques using glucose measurements and machine learning, we now consider embodiments of some procedures to illustrate other aspects of this technique.

[0138] Implementation examples of the program This section describes embodiments of a procedure for predicting diabetes using glucose measurements and machine learning. Aspects of the procedure may be implemented in hardware, firmware, or software, or a combination thereof. These procedures are shown as a set of boxes specifying operations performed by one or more devices, and are not necessarily limited to the order in which the operations for each box are performed. In at least some embodiments, these procedures are performed by a prediction system, such as prediction system 114, which utilizes a preprocessing manager 402, a machine learning model 404, and a model manager 502.

[0139] Figure 9 Process 900 in one embodiment of the implementation is described, wherein a machine learning model predicts diabetes classification based on glucose measurements of the user collected by a wearable glucose monitoring device during observation.

[0140] The user's glucose measurements are obtained (box 902). Based on the principles discussed herein, glucose measurements are collected during the observation period by a wearable glucose monitoring device. For example, machine learning model 404 obtains the user's glucose measurements 110, which are collected by the wearable glucose monitoring device 104 worn by person 102 during the observation period. The wearable glucose monitoring device 104 may be provided as part of an observation kit, for example, for monitoring person 102's glucose. Regardless of how person 102 obtains the wearable glucose monitoring device 104, the device is configured to monitor person 102's glucose during the observation period, which typically spans multiple days. For example, the wearable glucose monitoring device 104 may be configured with a sensor 202 that can be inserted into person 102's skin and used to measure glucose in person 102's blood.

[0141] Although the insertion of sensor 202 under the skin of person 102 has been discussed throughout, in one or more embodiments, sensor 202 may not be inserted under the skin. In such embodiments, sensor 202 may alternatively be disposed 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 can then be peeled off. Alternatively or additionally, non-invasive glucose sensors may be optically based, such as using photoplethysmography (PPG). Sensor 202 may be configured in a variety of ways to obtain measurements indicating glucose levels in person 102 without departing from the spirit or scope of the technology.

[0142] A user's diabetes classification is predicted by processing glucose measurements using one or more machine learning models (box 904). Based on the principles discussed herein, one or more machine learning models are generated based on historical glucose measurements and historical outcome data of a user group. For example, machine learning model 404 predicts diabetes classification 116. Machine learning model 404 produces this prediction by processing glucose measurement 110 based on patterns learned during training and outcome data 306 from user group 304. As mentioned above, user group 304 includes users wearing wearable glucose monitoring devices, such as wearable glucose monitoring device 104.

[0143] Output a diabetes classification (box 906). For example, machine learning model 404 outputs a diabetes classification 116. As discussed throughout, diabetes classification 116 can indicate whether the person is predicted to have diabetes or whether they are predicted to experience adverse effects related to diabetes. Diabetes classification 116 can also be used to generate one or more classification-based notifications or user interfaces, such as reports to healthcare providers that include the diabetes classification (e.g., the person is predicted to have diabetes) or notifications instructing the person 102 to contact their healthcare provider.

[0144] Figure 10 The process 1000 in an embodiment of the implementation is described, wherein a machine learning model is trained to predict diabetes classification based on historical glucose measurements and outcome data of a user group.

[0145] Glucose measurements are obtained from wearable glucose monitoring devices worn by users within a user group (box 1002). For example, model manager 502 obtains glucose measurements 110 for users in user group 304. The obtained outcome data describes one or more aspects of the user group related to diabetes (box 1004). For example, model manager 502 obtains outcome data 306. In the above embodiment, the outcome data describes aspects of the embodiment, such as one or more independent diagnostic measurements 308 for users in user group 304, observed adverse effects 310 for users in user group 304, and clinical diagnoses 312 for users in user group 304.

[0146] A training data instance (box 1006) is generated, comprising a training input portion and an expected output portion. According to the principles discussed herein, the training input portion includes at least one of a trajectory of the user's glucose measurements or a feature of the user's glucose measurements. Furthermore, the expected output portion includes values ​​of one or more result data corresponding to the user. For example, model manager 502 generates the training data instance by associating the trajectory of the glucose measurements or the feature of the user's glucose measurements obtained in box 1002 with one or more values ​​of the user's result data obtained in box 1004. In one or more embodiments, model manager 502 uses one or more tags representing values ​​of the result data corresponding to the user to "tag" the trajectory of the glucose measurements or the feature of the user's glucose measurements.

[0147] Here, boxes 1008-1014 can be repeated until the machine learning model is properly trained, such as until the machine learning model “converges” on the solution, for example, because the model’s internal weights have been properly adjusted due to training iterations so that the model always generates predictions that substantially match the expected output. Alternatively or additionally, boxes 1008-1014 can be repeated for multiple instances of the training data (e.g., all instances).

[0148] Provide a portion of the training input from the training data instance as input to the machine learning model (box 1008). For example, model manager 502 provides a portion of the training input from the training data instance generated in box 1006 as input to machine learning model 404.

[0149] The prediction of diabetes classification is received as the output of the machine learning model (box 1010). According to the principles discussed herein, the prediction of diabetes classification corresponds to one or more values ​​from the user outcome data included in the training instances that relate to the same aspect of diabetes. For example, machine learning model 404 predicts the diabetes classification based on the training input provided in box 1008 (e.g., the user's classification in the "diabetes" category, "prediabetes" category, or "non-diabetes" category, or a value indicating one of these), and model manager 502 receives the diabetes classification as the output of machine learning model 404.

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

[0151] The weights of the machine learning model are adjusted based on the comparison described above (box 1014). For example, model manager 502 may adjust the internal weights of machine learning model 404 based on this comparison. In one or more embodiments, model manager 502 may optionally utilize one or more hyperparameter optimization techniques during training to adjust the hyperparameters of the learning algorithm used.

[0152] Having described embodiments of processes according to one or more implementations, we now consider embodiments of systems and apparatuses that can be used to implement the various techniques described herein.

[0153] Implementation examples of systems and devices Figure 11An embodiment of a system typically located at 1100 is illustrated, which includes an embodiment of computing device 1102, representing one or more computing systems and / or devices that can implement the various technologies described herein. This is illustrated by including a prediction system 114 at both the platform level and 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. For example, computing device 1102 may be a server of a service provider, a device associated with a client (e.g., a client device), a system-on-a-chip, and / or any other suitable computing device or computing system.

[0154] An embodiment of the computing device 1102 shown in the figure includes a processing system 1104, one or more computer-readable media 1106, and one or more communicationally coupled I / O interfaces 1108. Although not shown, the computing device 1102 may also include a system bus or other data and command transmission system that couples the various components to each other. The system bus may include any one or a combination of different bus architectures, 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 embodiments are also contemplated, such as control lines and data lines.

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

[0156] Computer-readable medium 1106 is shown as including memory / storage 1112. Memory / storage 1112 represents the memory / storage capacity associated with one or more computer-readable media. 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 disk, magnetic disk, etc.). Memory / storage component 1112 may include fixed media (e.g., RAM, ROM, fixed hard disk drive, etc.) and removable media (e.g., flash memory, removable hard disk drive, optical disk, etc.). Computer-readable medium 1106 may be configured in a variety of other ways as further described below.

[0157] Input / output interface 1108 represents a function that allows a user to input commands and information into computing device 1102 and also allows information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, cursor control devices (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., a gesture that can be identified as non-touch using visible or invisible wavelengths such as infrared frequencies), and so on. Examples of output devices include display devices (e.g., a monitor or projector), speakers, printers, network interface cards (NICs), haptic-responsive devices, and so on. Therefore, computing device 1102 can be configured in a variety of ways to support user interaction, as further described below.

[0158] Various technologies can be described in the general context of software, hardware components, or program modules. Typically, such modules include routines, programs, objects, elements, components, data structures, etc., that perform specific tasks or implement specific abstract data types. As used herein, the terms "module," "function," and "component" generally refer to software, firmware, hardware, or a combination thereof. The technologies described herein are characterized by platform independence, meaning that these technologies can be implemented on a wide range of commercial computing platforms with various processors.

[0159] Implementations of the described modules and techniques may be stored on or transmitted via some form of computer-readable medium. The computer-readable medium may include a variety of media accessible by the computing device 1102. By way of example and not limitation, the computer-readable medium may include a “computer-readable storage medium” and a “computer-readable signal medium.”

[0160] "Computer-readable storage medium" can refer to a medium and / or device that enables the persistent and / or non-transitory storage of information, compared to mere signal transmission, carrier waves, or signals themselves. Therefore, computer-readable storage medium refers to non-signal-bearing media. Computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented with methods or techniques suitable for storing information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Embodiments of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital universal disk (DVD) or other optical storage, hard disk, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or other storage devices, tangible media, or articles of art suitable for storing desired information and accessible by a computer.

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

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

[0163] The foregoing combinations can also be used to implement the various techniques described herein. Therefore, software, hardware, or executable modules can be implemented as one or more instructions and / or logic contained on some form of computer-readable storage medium and / or implemented by one or more hardware elements 1110. Computing device 1102 can be configured to implement specific instructions and / or functions corresponding to the software and / or hardware modules. Therefore, implementations of modules executable as software by computing device 1102 can be implemented at least partially in hardware, for example, by using the computer-readable storage medium and / or hardware elements 1110 of processing system 1104. Instructions and / or functions can be executed / operated by one or more articles of manufacture (e.g., one or more computing devices 1102 and / or processing systems 1104) to implement the techniques, modules, and embodiments described herein.

[0164] The techniques described herein can be supported by various configurations of computing device 1102, and are not limited to specific embodiments of the techniques described herein. This functionality can also be implemented, in whole or in part, using a distributed system, such as on the “cloud” 1114 via platform 1116 as described below.

[0165] Cloud 1114 includes and / or represents platform 1116, which represents resource 1118. Platform 1116 abstracts the low-level functionality of the hardware (e.g., server) and software resources of cloud 1114. Resource 1118 may include applications and / or data that can be used when performing computer processing on a server remotely located on computing device 1102. Resource 1118 may also include services provided via the Internet and / or via subscriber networks such as cellular or Wi-Fi networks.

[0166] Platform 1116 can extract resources and functions to connect computing device 1102 to other computing devices. Platform 1116 can also be used to extract resource scaling to provide an appropriate level of scaling to any encountered demand for resources 1118 implemented via platform 1116. Therefore, in an interconnect device implementation, the implementation of the functions described herein can be distributed throughout system 1100. For example, the function can be implemented partly on computing device 1102 and partly through platform 1116, which extracts functions from cloud 1114.

[0167] in conclusion Although the systems and techniques have been described in language specific to structural features and / or methodological behavior, it should be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or behaviors described. Rather, specific features and actions are disclosed as embodiments that implement the claimed subject matter.

Claims

1. A method comprising: The user's glucose measurement value is obtained by a wearable glucose monitoring device during the observation period. The user's diabetes classification is predicted by processing the glucose measurement using one or more machine learning models, which are generated based on the user group's historical glucose measurement and historical result data. and Output diabetes classification.

2. The method of claim 1, wherein the diabetes classification refers to describing the user's state during the observation period as one of having diabetes, prediabetes, or no diabetes.

3. The method of claim 1, wherein the diabetes classification indicates whether the user's status during the observation period is gestational diabetes or no gestational diabetes.

4. The method according to claim 1, wherein: The diabetes classification represents one or more adverse effects of diabetes that the user is predicted to experience; and The historical results data describe the adverse effects of diabetes observed in users of the user group.

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 measurement.

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

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

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

9. The method according to claim 1, further comprising: The historical glucose measurement values ​​and historical result data of the user group are obtained, and the historical glucose measurement values ​​are provided by the glucose monitoring devices worn by users in the user group. and The one or more machine learning models are generated by providing the historical glucose measurements to the one or more machine learning models, the diabetes classifications trained from the one or more machine learning models are compared with the diabetes classifications indicated by the historical results data, and the weights of the one or more machine learning models are adjusted based on the comparison.

10. The method of claim 9, further comprising tagging the trajectory of the historical glucose measurements with a marker indicating a diabetes classification of the corresponding user based on the historical outcome data.

11. The method of claim 9, wherein the historical result data relates to diagnostic measurements of the historical glucose values ​​provided by glucose monitoring devices worn by one or more users independent of the user group.

12. The method of claim 1, wherein the historical outcome data includes a marker of the trajectory of the historical glucose measurements, the marker indicating whether a corresponding user in the user group has been clinically diagnosed with diabetes based on one or more diagnostic measurements.

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

14. The method according to claim 1, further comprising: The user's glucose measurements are preprocessed to extract one or more glucose features; and The machine learning model is provided with one or more extracted glucose features as input so that the machine learning model can predict the user's diabetes classification.

15. The method of claim 14, wherein the one or more extracted glucose characteristics comprise at least one of the following: The time measurement exceeding the threshold corresponds to the amount of time during which the user's glucose measurement value is higher than the glucose threshold during the observation period; The time measurement within the range corresponds to the amount of time between the user's glucose measurement during the observation period and a first glucose level and a second glucose level lower than the first glucose level; The rate of change of glucose measurement values ​​per unit time; Average glucose measurement; or Median glucose measurement.

16. The method of claim 14, wherein the machine learning model uses at least two extracted glucose features to predict the user's diabetes classification.

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

18. The method of claim 1, wherein the output includes the diabetes classification and a glucose observation report of at least one of the following; Based on the diabetes classification, provide the user with one or more treatment recommendations; A visual representation of the glucose measurements acquired by the glucose monitoring device during the observation period; or One or more glucose statistics for the user are generated based on the glucose measurements collected by the glucose monitoring device during the observation period.

19. The method of claim 18, wherein the one or more glucose statistics include at least one of the following: The time measurement exceeding the threshold corresponds to the amount of time during which the user's glucose measurement value is higher than the glucose threshold during the observation period; The time measurement within the range corresponds to the amount of time between the user's glucose measurement during the observation period and a first glucose level and a second glucose level lower than the first glucose level; The rate of change of glucose measurement values ​​per unit time; Average glucose measurement; or Median glucose measurement.

20. The method of claim 1, wherein the glucose measurement value is obtained from the memory of the glucose monitoring device or from one or more data packets containing the glucose measurement value transmitted from the glucose monitoring device via a network.

21. A device comprising: One or more processors; and A memory having stored computer-readable instructions executable by one or more processors to perform operations including: The user's glucose measurement value is obtained by a wearable glucose monitoring device during the observation period. The user's diabetes classification is predicted by processing the glucose measurement using one or more machine learning models, which are generated based on the user group's historical glucose measurement and historical result data. and Output diabetes classification.

22. The device of claim 21, wherein the diabetes classification refers to describing the user's state during the observation period as one of having diabetes, prediabetes, or no diabetes.

23. The device according to claim 21, wherein: The diabetes classification represents one or more adverse effects of diabetes that the user is predicted to experience; and The historical results data describe the adverse effects of diabetes observed in users of the user group.

24. One or more computer-readable storage media having instructions stored thereon, executable by one or more processors to perform operations including: The user's glucose measurement value is obtained by a wearable glucose monitoring device during the observation period. Predicting a user's diabetes classification by processing glucose measurements using one or more machine learning models, generating the one or more machine learning models based on historical glucose measurements and historical outcome data of the user group; and Output diabetes classification.

25. The computer-readable storage medium of claim 24, wherein the diabetes classification refers to describing the user's state during the observation period as one of having diabetes, prediabetes, or no diabetes.

26. The computer-readable storage medium according to claim 24, wherein: The diabetes classification represents one or more adverse effects of diabetes that the user is predicted to experience; and The historical results data describe the adverse effects of diabetes observed in users of the user group.

27. An instrument comprising: Acquisition device for acquiring a user's glucose measurement value, which is collected by a wearable glucose monitoring device during observation; A prediction device for predicting a user's diabetes classification by processing the glucose measurement using one or more machine learning models, wherein the one or more machine learning models are generated based on the user group's historical glucose measurements and historical result data; and Output device for outputting diabetes classification.

28. A system comprising: A wearable glucose monitoring device including a sensor for collecting glucose measurements of the user over a multi-day observation period using a sensor inserted subcutaneously into the user's skin. A storage device for maintaining the glucose measurements taken by the user during the observation period; and A prediction system is used to obtain the glucose measurement values ​​of the user collected during the observation period and to predict the user's diabetes classification by processing the glucose measurement values ​​using one or more machine learning models.

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

30. The system of claim 28, further comprising a model manager for: Acquire the historical glucose measurements and historical result data of the user group, including the historical glucose measurements provided by glucose monitoring devices worn by users within the user group; and The one or more machine learning models are generated by providing the historical glucose measurements to the one or more machine learning models, the diabetes classifications trained from the one or more machine learning models are compared with the diabetes classifications indicated by the historical results data, and the weights of the one or more machine learning models are adjusted based on the comparison.

31. The system of claim 30, wherein the historical result data relates to diagnostic measurements of the historical glucose values ​​provided by glucose monitoring devices worn by one or more users independent of the user group.

32. The system of claim 30, wherein the glucose monitoring device is configured to be different from the glucose monitoring device worn by the user group that provides the historical glucose measurements.

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. The system of claim 32, wherein the storage device is implemented at the wearable glucose monitoring device, and wherein the storage device is configured to maintain a greater number of glucose measurements than the glucose monitoring devices worn by the users of the user group.

35. The system of claim 28, wherein the prediction system is implemented at one or more computing devices located remotely from the glucose monitoring device.

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

37. A method comprising: Acquire glucose measurements from wearable glucose monitoring devices worn by users within the user group; Obtain outcome data for the user group that describes one or more aspects of the user group related to diabetes; An instance of training data is generated, comprising a training input portion and an expected output portion, wherein the training input portion includes at least one of a user's glucose measurement trajectory or a feature of the user's glucose measurement, and the expected output portion includes one or more result data corresponding to the user. The following methods were used to train a machine learning model to predict diabetes classification: Provide the training input portion of the training data instance as input to the machine learning model; The prediction of a diabetes classification is received as the output from the machine learning model, and the diabetes classification corresponding to the same aspect related to diabetes is received as one or more values ​​of the user's result data. The prediction of the diabetes classification is compared with the expected output portion of the instance of the training data; and The weights of the machine learning model are adjusted based on the comparison.

Images