Identifying population diseases using wearable glucose monitoring devices

Abstract

Identifying disease in a population using wearable glucose monitoring devices is described. A disease identification system acquires temperature measurements provided by wearable glucose monitoring devices worn by users of a user population. The disease identification system further acquires location data representing the users' locations and associates each of the temperature measurements with a respective location. The disease identification system utilizes identification logic (e.g., one or more machine learning models) to identify the presence of the disease in the users at one or more of the locations based on the temperature measurements and the location data. The disease identification system generates a communication to notify at least one of the users of the presence of the disease.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 058,253, filed July 29, 2020, entitled "Population Malady Identification with a Wearable Glucose Monitoring Device," the entire disclosure of which is incorporated herein by reference. [Background technology]

[0002] Diseases, such as influenza and coronaviruses, can have widespread and severe population impacts. For example, a given disease can have health-related effects on a population, requiring at least some form of treatment for those who contract the disease. Furthermore, some diseases can have severe economic impacts, paralyzing sectors of the global and local economy, for a variety of reasons, including fear of the disease and rules and regulations to combat the spread of the disease (e.g., quarantines, curfews, and / or the closure of certain businesses). However, the negative impacts of such diseases can be reduced by adopting mitigation behaviors, such as social distancing, increased hand washing or disinfection, increased cleaning of shared spaces, and wearing face coverings, to name a few.

[0003] The effectiveness of these behaviors in actually mitigating disease depends not only on the extent to which the behaviors are adopted, but also on the timeliness of adoption. Widespread adoption of mitigation behaviors early in the course of a disease can significantly reduce the negative impact of the disease than if those behaviors are adopted later. Furthermore, some individuals may be at higher risk than others of experiencing severe side effects if infected. One example of an individual who may be at higher risk than others is individuals with diabetes, as a given disease can cause more severe side effects and be life-threatening in individuals with diabetes compared to individuals without diabetes. Early adoption of mitigation behaviors by these at-risk individuals can limit their exposure to the disease and / or enable them to take preventative measures to prevent contracting the disease, even if they are exposed.

[0004] An indicator of many diseases is an elevated temperature in a sick person, with this elevation relative to an established "normal" temperature, such as 98.6°F. However, in the real world, people typically do not "take their temperature" until they become ill, and after a person begins to feel ill, the person, or a caregiver, may obtain a thermometer to take the person's temperature and / or travel to a doctor's office where the temperature will be taken. However, by this time, the person may have been infected with the disease long enough to unknowingly expose others to the disease. Early in the development of a disease, there is a time lag between contracting the disease and becoming ill enough to take a temperature, so many people in a population may unknowingly contract the disease and expose others to it. Due at least in part to this time lag, traditional approaches that use temperature to identify disease may not be suitable for preventing the spread of disease, which may severely impact the population and even those at high risk of experiencing severe adverse effects. Summary of the Invention [Means for solving the problem]

[0005] To overcome these problems, population disease identification using wearable glucose monitoring devices is utilized. A disease identification system acquires temperature measurements provided by wearable glucose monitoring devices worn by users of a user population. The disease identification system further acquires location data representing the users' locations and associates the temperature measurements with each location. The disease identification system utilizes identification logic (e.g., one or more machine learning models) to identify the presence of the disease in the users at one or more of the locations based on the temperature measurements and the location data. The disease identification system generates a communication to notify at least one of the users of the presence of the disease.

[0006] One aspect is a method that includes obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population, obtaining location data representative of the users' locations and associating each of the temperature measurements with the respective location, identifying the presence of a disease in the users at one or more of the locations based on the temperature measurements and the location data, and notifying at least one of the users of the presence of the disease.

[0007] In the above method, identifying the presence of a disease includes processing the temperature measurements and the location data, in part, using one or more machine learning models, the one or more machine learning models being generated based on past temperature measurements of the user population and past data indicative of the presence of one or more diseases in the user population. In the above method, the wearable glucose monitoring device includes at least one continuous glucose monitoring (CGM) system. In the above method, identifying is further based on glucose measurements provided by wearable glucose monitoring devices worn by users of the user population.

[0008] In the above method, identifying the presence of a disease includes processing the temperature measurements, glucose measurements, and location data using, in part, one or more machine learning models, the one or more machine learning models being generated based on past temperature and glucose measurements of a user population and past data representative of the presence of one or more diseases in the user population.

[0009] The method further includes notifying at least one third party about the presence of the disease, wherein the at least one third party includes at least one of a public health organization, a government organization, a school district, a medical facility, a news source, a telehealth service, or a data partner having a glucose monitoring platform that corresponds to the wearable glucose monitoring device, wherein the users of the user population have user profiles with the glucose monitoring platform.

[0010] In the above method, notifying at least one user about the presence of the disease includes generating a heat map visually distinguishing disease severity across a population of users at different locations and causing display of the heat map on a display device of a computing device associated with the at least one user. In the above method, notifying at least one user about the presence of the disease includes generating an alert having information about the presence of the disease and causing output of the alert via a computing device associated with the at least one user. In the above method, causing output of the alert includes causing display of the alert via a display device of the computing device.

[0011] Another aspect is a system comprising at least one processor and a memory having stored thereon instructions executable by the at least one processor to perform operations including obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population; obtaining location data representative of the users' locations and associating the temperature measurements with the respective locations; identifying the presence of a disease in the users at one or more of the locations based on the temperature measurements and the location data; and notifying at least one of the users of the presence of the disease.

[0012] The system further comprises one or more machine learning models configured to identify the presence of a disease by processing the temperature measurements and location data, the one or more machine learning models being generated based on past temperature measurements of the user population and past data representative of the presence of one or more diseases in the user population.

[0013] In the above system, the wearable glucose monitoring device includes at least one continuous glucose monitoring (CGM) system. In the above system, the identifying is further based on glucose measurements provided by wearable glucose monitoring devices worn by users of the user population. The above system further includes one or more machine learning models configured to identify the presence of a disease by processing the temperature measurements, glucose measurements, and location data, the one or more machine learning models being generated based on past temperature and glucose measurements of the user population and past data representative of the presence of one or more diseases in the user population.

[0014] In the system, the operations further include notifying at least one third party about the presence of the disease, wherein the at least one third party includes at least one of a public health organization, a government organization, a school district, a medical facility, a news source, a telehealth service, or a data partner having a glucose monitoring platform that corresponds to the wearable glucose monitoring device, wherein users of the user population have user profiles with the glucose monitoring platform.

[0015] In the above system, notifying at least one user about the presence of the disease includes generating a heat map visually distinguishing disease severity across a population of users at different locations and causing display of the heat map on a display device of a computing device associated with the at least one user. In the above system, notifying at least one user about the presence of the disease includes generating an alert having information about the presence of the disease and causing output of the alert via a computing device associated with the at least one user. In the above system, causing output of the alert includes causing display of the alert via a display device of the computing device.

[0016] Another aspect is one or more non-transitory computer-readable storage media having stored thereon instructions executable by one or more processors of at least one computing device to cause the at least one computing device to perform operations including obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population, obtaining location data representative of the users' locations and associating the temperature measurements with the respective locations, identifying the presence of a disease in the users at one or more of the locations based on the temperature measurements and the location data, and notifying at least one of the users of the presence of the disease.

[0017] In the storage medium, identifying the presence of the disease includes processing the temperature measurements and the location data, in part, using one or more machine learning models, the one or more machine learning models being generated based on past temperature measurements of the user population and past data indicative of the presence of one or more diseases in the user population. In the storage medium, the wearable glucose monitoring device includes at least one continuous glucose monitoring (CGM) system. In the storage medium, identifying is further based on glucose measurements provided by wearable glucose monitoring devices worn by users of the user population.

[0018] In the storage medium, identifying the presence of the disease includes processing the temperature readings, glucose readings, and location data, in part, using one or more machine learning models, the one or more machine learning models being generated based on past temperature and glucose readings of a user population and past data representative of the presence of one or more diseases in the user population. In the storage medium, the operations further include notifying at least one third party of the presence of the disease.

[0019] In the storage medium, the at least one third party includes at least one of a public health organization, a government organization, a school district, a medical facility, a news source, a telehealth service, or a data partner having a glucose monitoring platform corresponding to the wearable glucose monitoring device. In the storage medium, users of the user population have user profiles with the glucose monitoring platform. In the storage medium, notifying the at least one user of the presence of the disease includes generating a heat map visually distinguishing disease severity across the user population at different locations and causing a display of the heat map on a display device of a computing device associated with the at least one user.

[0020] In the storage medium, notifying at least one user of the presence of the disease includes generating an alert having information about the presence of the disease and triggering output of the alert via a computing device associated with the at least one user, wherein triggering output of the alert includes triggering display of the alert via a display device of the computing device.

[0021] Another aspect is an apparatus comprising: means for acquiring temperature measurements provided by wearable glucose monitoring devices worn by users of a user population; means for acquiring location data representative of the users' locations and associating each of the temperature measurements with the respective location; means for identifying the presence of a disease in the users at one or more of the locations based on the temperature measurements and the location data; and means for notifying at least one of the users of the presence of the disease.

[0022] This Summary introduces a selection of concepts in a simplified form that are further described below in the Detailed Description. As such, this Summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [Brief explanation of the drawings]

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

[0024] [Figure 1] 1 is an illustration of an environment in an example implementation operable to employ the techniques described herein. [Figure 2] 2 depicts the example wearable glucose monitoring device of FIG. 1 in more detail. [Figure 3] 1 depicts an example implementation in which data including temperature measurements collected from a wearable glucose monitoring device is routed to different systems in connection with population disease identification. [Figure 4] 1 depicts an example implementation of a user interface displayed to present information associated with identifying a population disease. [Figure 5] 1 depicts an exemplary implementation of information presented in connection with identifying a population disease via a user interface. [Figure 6] 1 depicts an example implementation of a user interface displayed to present notifications associated with the identification of a population disease. [Figure 7] 1 depicts an example implementation of a user interface displayed to present information associated with the identification of a population disease in a selected location. [Figure 8] 1 depicts a procedure of an exemplary implementation in which the presence of illness in a user at one or more locations is identified based on temperature measurements obtained from a wearable glucose monitoring device. [Figure 9] To implement embodiments of the technology described herein, an exemplary system is shown including various components of an exemplary device that may be implemented as any type of computing device described and / or utilized with reference to FIGS. 1-8. DETAILED DESCRIPTION OF THE INVENTION

[0025] overview An indicator of many illnesses is an elevated temperature in a sick person, relative to an established "normal" temperature, such as 98.6°F. However, in the real world, people generally do not "take their temperature" until they feel ill, and they generally do not continuously monitor their temperature in substantially real time. By the time a sick person's temperature is actually taken, they may have been infected with the disease long enough to unknowingly transmit it to others. Early in the course of a disease, there is a time lag between contracting the disease and becoming sick enough to take a temperature, potentially resulting in many individuals in a population unknowingly contracting the disease and exposing others to the disease. Due, at least in part, to this time lag, traditional approaches using temperature to identify illness may be inadequate for preventing the spread of disease, and thus illness may severely impact populations, even those at high risk of experiencing severe adverse effects. Furthermore, there are various factors that can affect an individual's temperature. For example, exercise and weather can affect an individual's temperature, and an individual's temperature may correspond to a temperature that generally indicates the presence or absence of illness, even though exercise and weather are the cause of the temperature and not the illness. To this end, temperature measurements of individual people may be too noisy to make temperature suitable for identifying illnesses at the individual level.

[0026] To overcome these problems, population disease identification using wearable glucose monitoring devices is utilized. Unlike traditional temperature measurement approaches, wearable glucose monitoring devices configured with temperature sensors can provide temperature measurements of a person continuously (e.g., at predetermined time intervals) and in real time because the glucose monitoring device is configured for continuous wear by a person over a period of time. By providing real-time temperature measurements of a person, the wearable glucose monitoring device captures changes in the person's temperature as they occur, without the person or another person intentionally measuring the person's temperature. To the extent that a significant portion of the people in a geographic region may wear wearable glucose monitoring devices configured with temperature sensors, wearable glucose monitoring devices worn by a significant portion of the people can provide temperature measurements in real time such that changes in temperature measurements across the subset can be identified by identification logic, such as a machine learning model.

[0027] In one or more implementations, the disease identification system obtains these temperature measurements provided by wearable glucose monitoring devices worn by users in the user population. The disease identification system further obtains location data representing the users' locations and associates each of the temperature measurements with the respective locations. For example, the identification system obtains the location data from the users' user profiles or from location data (e.g., Global Positioning System (GPS) coordinates) packaged with the temperature measurements, such as by the users' mobile devices.

[0028] The disease identification system utilizes identification logic (e.g., one or more machine learning models) to identify the presence of a disease in a user at one or more of the locations based on the temperature readings and location data. It will be appreciated that the number of temperature readings obtained for a population of users is too large for a human to practically process, e.g., to identify meaningful patterns in those temperature readings across the population and / or at specific locations (e.g., elevated average temperatures at locations above a threshold temperature). In contrast, however, the identification logic is configured to process a number of temperature readings that is practically impossible for any human to process in a short amount of time.

[0029] If the identification logic identifies the presence or absence of a disease, the disease identification system may generate a communication to notify at least one of the users about the presence of the disease. Additionally or alternatively, the disease identification system may generate a communication to notify a third party, such as a public health organization, a government agency, or a school district. By measuring temperature and notifying about the presence of a disease in real time at a population level, the disease identification system can provide information about the presence of a disease earlier than traditional approaches. As a result, people may be able to adopt mitigation actions earlier, which may be effective in avoiding or at least reducing many of the negative effects of the disease.

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

[0031] Example Environment 1 is an illustration of an environment 100 in an example implementation operable to employ population disease identification with wearable glucose monitoring devices, as described herein. The illustrated environment 100 includes a person 102, who is depicted wearing a wearable glucose monitoring device 104 and a computing device 106. The illustrated environment 100 also includes other users in a user population 108 who wear the wearable glucose monitoring device 104, and a glucose monitoring platform 110. The wearable glucose monitoring device 104, the computing device 106, the user population 108, and the glucose monitoring platform 110 are communicatively coupled, including via a network 112.

[0032] Alternatively or additionally, the wearable glucose monitoring device 104 and the computing device 106 may be communicatively coupled in other manners, such as using one or more wireless communication protocols or techniques. By way of example, the wearable glucose monitoring device 104 and the computing device 106 may communicate with each other using one or more of Bluetooth (e.g., a Bluetooth Low Energy link), near field communication (NFC), 5G, etc.

[0033] According to the described techniques, the wearable glucose monitoring device 104 is configured to provide measurements of the person's 102's blood glucose and also measurements of the person's 102's temperature. The wearable glucose monitoring device 104 may be configured with, for example, a glucose sensor that continuously detects an analyte indicative of the person's 102's glucose and enables the generation of glucose measurements. In the illustrated environment 100 and throughout the detailed description, these measurements are referred to as glucose measurements 114. The wearable glucose monitoring device 104 may be configured with a temperature sensor, such as a thermocouple that continuously measures a temperature-dependent voltage as a result of the thermoelectric effect. The measured voltage can be interpreted as a temperature (e.g., of the person 102). In the illustrated environment 100 and throughout the detailed description, these measurements are referred to as temperature measurements 116.

[0034] In one or more implementations, the wearable glucose monitoring device 104 is a continuous glucose monitoring (CGM) system. As used herein, the term "continuous" when used in connection with glucose monitoring may refer to the ability of a device to provide measurements substantially continuously, such as the device may be configured to provide glucose measurements 114 at time intervals (e.g., every hour, every 30 minutes, every 5 minutes, etc.), in response to establishing a communicative coupling with a different device (e.g., when a computing device establishes a wireless connection with the wearable glucose monitoring device 104 to retrieve one or more of the measurements).

[0035] Similarly, the wearable glucose monitoring device 104 may be configured to provide temperature measurements 116 substantially continuously, such as by enabling temperature measurements 116 to be provided at time intervals (e.g., every 5 minutes, every minute, every 30 seconds, etc.), in response to establishing a communicative coupling with a different device, etc. In one or more implementations, the rate at which temperature measurements 116 are provided is more frequent than the rate at which glucose measurements 114 are provided, e.g., temperature measurements 116 are provided every 30 seconds and glucose measurements 114 are provided every 5 minutes. This functionality, along with further aspects of the configuration of the wearable glucose monitoring device 104, are discussed in more detail in connection with FIG. 2.

[0036] Additionally, the wearable glucose monitoring device 104 transmits glucose measurements 114 and temperature measurements 116 to the computing device 106, such as via a wireless connection. The wearable glucose monitoring device 104 may communicate these measurements in real time, for example, as these measurements are made using glucose and temperature sensors. Alternatively, or additionally, the wearable glucose monitoring device 104 may communicate the glucose measurements 114 and temperature measurements 116 to the computing device 106 at set time intervals. For example, the wearable glucose monitoring device 104 may be configured to communicate glucose measurements 114 to the computing device 106 every five minutes (as they are made), temperature measurements 116 (as they are made) every 30 seconds, or once a day (as part of a “data dump” at predetermined time intervals).

[0037] Certainly, the intervals at which glucose readings 114 and temperature readings 116 are communicated may vary from the above examples without departing from the spirit or scope of the described technology. Readings may be communicated by the wearable glucose monitoring device 104 to the computing device 106 according to other locations in accordance with the described techniques, such as upon request from the computing device 106. Thus, the computing device 106 may at least temporarily maintain the glucose readings 114 and / or temperature readings 116 of the person 102, for example, in a computer-readable storage medium of the computing device 106.

[0038] Although illustrated as a wearable device (e.g., a smart watch), the computing device 106 may be configured in various manners without departing from the spirit or scope of the described techniques. By way of example and not limitation, the computing device 106 may be configured as a different type of mobile device (e.g., a mobile phone or a tablet device). In one or more implementations, the computing device 106 may be configured as a dedicated device associated with the glucose monitoring platform 110, having the functionality to, for example, obtain glucose readings 114 from the wearable glucose monitoring device 104, perform various calculations related to the glucose readings 114, display information related to the glucose readings 114 and the glucose monitoring platform 110, communicate the glucose readings 114 to the glucose monitoring platform 110, etc. However, in contrast to implementations in which the computing device 106 is configured as a mobile phone, the computing device 106 may not include some functionality available in a mobile phone or wearable configuration when configured as a dedicated device, such as the ability to make phone calls, camera functionality, the ability to utilize social networking applications, etc.

[0039] Additionally, computing device 106 may represent more than one device in accordance with the described techniques. In one or more scenarios, for example, computing device 106 may correspond to both a wearable device (e.g., a smart watch) and a mobile phone. In such a scenario, both of these devices may be capable of performing at least some of the same operations, such as receiving glucose readings 114 and temperature readings 116 from wearable glucose monitoring device 104, communicating them over network 112 to glucose monitoring platform 110, and displaying information related to glucose readings 114 and temperature readings 116, etc. Alternatively or additionally, different devices may have different capabilities that other devices do not have or that are limited through computing instructions to the particular device.

[0040] In a scenario in which the computing device 106 corresponds to a separate smartwatch and a mobile phone, for example, the smartwatch may be configured with various sensors and functionality to measure various physiological markers (e.g., heart rate, respiration, blood flow, etc.) and the activity (e.g., steps) of the person 102. In this scenario, the mobile phone may not be configured with these sensors and functionality or may include a limited amount of it, while in other scenarios, the mobile phone may be able to provide the same functionality. Continuing with this particular scenario, the mobile phone may have capabilities that the smartwatch does not have, such as a camera for capturing images of meals used to predict future glucose levels, or an amount of computing resources (e.g., battery and processing speed) that allows the mobile phone to more efficiently perform calculations related to glucose readings 114 and temperature readings 116. Even in scenarios in which the smartwatch is capable of performing such calculations, the computational instructions may limit the performance of those calculations for the mobile phone in order not to burden both devices and to efficiently utilize available resources. To this extent, the computing device 106 may be configured differently and represent a different number of devices than those discussed herein without departing from the spirit and scope of the described technology.

[0041] As described above, computing device 106 communicates glucose readings 114 and temperature readings 116 to glucose monitoring platform 110. In the illustrated environment 100, glucose readings 114 and temperature readings 116 are shown stored in a storage device 118 of glucose monitoring platform 110 along with location data 120. Storage device 118 may represent one or more databases and / or other types of storage capable of storing glucose readings 114, temperature readings 116, and location data 120.

[0042] Storage device 118 may also store a variety of other data. In accordance with the described techniques, for example, person 102 corresponds to at least a user of glucose monitoring platform 110 and may also be a user of one or more other third-party service providers. To this end, person 102 may be associated with a username and, at some point, be required to provide authentication information (e.g., a password or biometric data) to access glucose monitoring platform 110 using the username. This information may be maintained in storage device 118 along with various other information about the user, including, for example, demographic information describing person 102, information about healthcare providers, payment information, prescription information, determined health metrics, user preferences, account information for other service provider systems (e.g., service providers associated with wearables, social networking systems, telehealth services, etc.), and the like.

[0043] Storage device 118 also maintains data for other users in user population 108. With this in mind, glucose readings 114 and temperature readings 116 in storage device 118 include glucose and temperature readings from the glucose and temperature sensors of wearable glucose monitoring device 104 worn by person 102, as well as glucose and temperature readings from glucose and temperature sensors of glucose monitoring devices worn by corresponding individuals in user population 108. This also results in these other users' glucose readings 114 and temperature readings 116 being communicated by their respective devices to glucose monitoring platform 110 via network 112, and these other users having their own user profiles with glucose monitoring platform 110.

[0044] In the illustrated example, the glucose monitoring platform 110 includes a disease identification system 122. The disease identification system 122 is configured to process at least the temperature measurements 116 and the location data 120 to identify the presence of a disease among a population of users in a location, such as identifying an outbreak of coronavirus disease in a geographic region, such as a country, state, county, city, zip code, voting precinct, or school district, to name a few. Based on the identification of a disease within the population, the disease identification system 122 may provide a notification regarding the identification, such as an alert, a recommendation, a "heat" map, or other information based on the prediction. For example, the disease identification system 122 may provide a notification to the person 102 (e.g., via the computing device 106), a public health agency, or the like.

[0045] Although depicted as part of a separate device from the computing device 106, portions or the entire disease identification system 122 may alternatively or additionally be implemented in the computing device 106, for example, in a disease identification app. The disease identification system 122 may also use additional data to identify diseases among a population of users at a location, such as by using glucose measurements 114. Consider the following discussion of FIG. 2 in the context of measuring glucose and temperature, for example, continuously, and obtaining data describing such measurements.

[0046] Figure 2 depicts in more detail an example implementation 200 of the wearable glucose monitoring device 104 of Figure 1. In particular, the illustrated example 200 includes a top view and a corresponding side view of the wearable glucose monitoring device 104. It will be appreciated that the wearable glucose monitoring device 104 may vary in implementation from the following discussion in various ways without departing from the spirit or scope of the described techniques.

[0047] In this example 200, the wearable glucose monitoring device 104 is shown to include a glucose sensor 202, a temperature sensor 204, and a sensor module 206. Here, the glucose sensor 202 is depicted in a side view, for example, subcutaneously inserted into the skin 208 of the person 102. The temperature sensor 204 and the sensor module 206 are depicted in a top view as dashed rectangles. The wearable glucose monitoring device 104 also includes a transmitter 210 in the illustrated example 200. The use of dashed rectangles for the temperature sensor 204 and the sensor module 206 indicates that they may be contained within the housing of the transmitter 210 or otherwise implemented. In this example 200, the wearable glucose monitoring device 104 further includes an adhesive pad 212 and an attachment mechanism 214.

[0048] In operation, the glucose sensor 202, adhesive pad 212, and attachment mechanism 214 may be assembled to form an application assembly, which is configured to be applied to the skin 208 such that the glucose sensor 202 is inserted subcutaneously, as depicted. In such a scenario, the transmitter 210 may be attached to the assembly after it has been applied to the skin 208 via the attachment mechanism 214. Additionally or alternatively, the transmitter 210 may be incorporated as part of the application assembly, thereby allowing the glucose sensor 202, adhesive pad 212, attachment mechanism 214, and transmitter 210 (with the temperature sensor 204 and sensor module 206) to be applied to the skin 208 all at once. Additionally or alternatively, the temperature sensor 204 may be disposed with the glucose sensor 202 so as to be included in an application assembly, which may include the transmitter 210 in some configurations and not in other configurations (e.g., the transmitter 210 may be attached to the application assembly after application). In one or more implementations, the application assembly is applied to the skin 208 using a separate sensor applicator (not shown). In one or more embodiments, the application assembly can be removed by peeling the adhesive pad 212 from the skin 208. It will be understood that the illustrated wearable glucose monitoring device 104 and its various components are merely one exemplary form factor, and that the wearable glucose monitoring device 104 and its components can have different form factors without departing from the spirit or scope of the described techniques.

[0049] In operation, the glucose sensor 202 and the temperature sensor 204 are communicatively coupled to the sensor module 206 via at least one communication channel, which may be a wireless connection or a wired connection. Communication from the glucose sensor 202 and the temperature sensor 204 to the sensor module 206, or communication from the sensor module 206 to the glucose sensor 202 and the temperature sensor 204, may be active or passive, and these communications may be continuous (e.g., analog) or discrete (e.g., digital).

[0050] The glucose sensor 202 may be a device, molecule, and / or chemical that changes or causes a change in response to an event at least partially independent of the glucose sensor 202. The sensor module 206 is implemented to receive an indication of a change to or caused by the glucose sensor 202. For example, the glucose sensor 202 may include glucose oxidase, which reacts with glucose and oxygen to form hydrogen peroxide that is electrochemically detectable by the sensor module 206, which may include electrodes. In this example, the sensor 202 may be configured as or include a glucose sensor configured to detect an analyte in blood or interstitial fluid indicative of a glucose level using one or more measurement techniques. In one or more implementations, the glucose sensor 202 may also be configured to detect an analyte in blood or interstitial fluid indicative of other markers, such as lactate levels. Additionally or alternatively, the wearable glucose monitoring device 104 may include additional sensors in addition to the glucose sensor 202 to detect analytes indicative of other markers.

[0051] The temperature sensor 204 is configured to detect a condition that can be used to determine, for example, a temperature measurement of the person 102. For example, the temperature sensor 204 can be configured as a thermocouple that continuously measures a temperature-dependent voltage as a result of the thermoelectric effect. The sensor module 206 can be configured to interpret the measured voltage as a temperature (e.g., of the person 102) and provide the temperature measurement 116. Alternatively or additionally, the temperature sensor 204 can include or utilize first and second electrical conductors, and the sensor module 206 can electrically detect changes in electrical potential across the first and second electrical conductors of the temperature sensor 204. In this example, the sensor module 206 and the temperature sensor 204 are configured as a thermocouple such that changes in electrical potential correspond to changes in temperature, and the sensor module 206 can be configured to use to provide the temperature measurement 116. It should be understood that the temperature sensor 204 and the sensor module 206 can be configured in various manners to detect the temperature of the person 102 and provide the temperature measurement 116 indicative of the temperature of the person 102.

[0052] In some examples, the sensors of the sensor module 206 and the wearable glucose monitoring device 104 are configured to detect a single analyte, such as glucose. In other examples, the sensors of the sensor module 206 and the wearable glucose monitoring device 104 are configured to detect multiple analytes, such as sodium, potassium, carbon dioxide, testosterone, lactate, insulin, and glucose. Alternatively or additionally, the wearable glucose monitoring device 104 may include multiple sensors that detect not only one or more analytes (e.g., sodium, potassium, carbon dioxide, testosterone, lactate, insulin, and glucose) but also one or more environmental conditions (e.g., the temperature of the person 102, the temperature of the environment in which the person 102 is located). Thus, the sensor module 206, glucose sensor 202, and temperature sensor 204 (as well as any additional sensors) may detect the presence of one or more analytes, the absence of one or more analytes, the temperature of the person 102, and / or a change in one or more environmental conditions.

[0053] In one or more implementations, the sensor module 206 may include a processor and memory (not shown). The sensor module 206 may utilize the processor to generate temperature measurements 116, for example, based on communication with the temperature sensor 204 indicating the interpretations discussed above. Similarly, the sensor module 206 may utilize the processor to generate glucose measurements 114 based on communication with the glucose sensor 202 indicating the changes discussed above. Based on these communications with the glucose sensor 202 and the temperature sensor 204, the sensor module 206 may be further configured to generate streams of temperature measurements 116 and glucose measurements 114. These streams may include communicable packages of data including at least one glucose measurement 114 or at least one temperature measurement 116.

[0054] As described above, the sensor module 206 and the sensor may be operable to provide glucose readings 114 and temperature readings 116 at different time intervals. For example, the sensor module 206 and the temperature sensor 204 may be operable to provide temperature readings 116 (e.g., of the person 102) at a first time interval, such as every 30 seconds. In contrast, the sensor module 206 and the glucose sensor 202 may be operable to provide glucose readings 114 at a second time interval that is different from the first time interval, such as every 5 minutes. Indeed, the time intervals at which the glucose readings 114 and temperature readings 116 are provided using the glucose sensor 202 and the temperature sensor 204 may vary from those discussed above in accordance with the described techniques. For example, the glucose readings 114 and the temperature readings 116 may be provided at the same time interval in at least one implementation, such that a one-to-one relationship exists between the glucose readings 114 and the temperature readings 116.

[0055] In addition to being provided at different time intervals, the glucose measurements 114 and the temperature measurements 116 may be communicated to one or more computing devices at different time intervals. For example, the transmitter 210 may be configured to transmit the glucose measurements 114 to the computing device at a first transmission interval, such as every five minutes. In one or more implementations, the transmission interval for the glucose measurements 114 is the same as the interval at which the glucose measurements 114 are provided, such as every five minutes. In this manner, the transmitter 210 may communicate each individual glucose measurement 114 to the computing device as it is generated. Additionally or alternatively, multiple glucose measurements 114 may be stored by the storage of the wearable glucose monitoring device 104, and the transmitter 210 may communicate the multiple glucose measurements 114 (or a subset thereof) to the computing device.

[0056] With respect to temperature measurements 116, the transmitter 210 may be configured to communicate them to the computing device at a second transmission interval different from the first transmission interval, for example, once per day. To this end, multiple temperature measurements 116 may be at least temporarily maintained in storage of the wearable glucose monitoring device 104. The temperature measurements 116 may be communicated by the transmitter 210 to the computing device at a rate (e.g., once per day) different from the rate at which the measurements are provided (e.g., every 30 seconds). By communicating the temperature measurements 116 less frequently than the measurements are provided, the wearable glucose monitoring device 104 may conserve resources (e.g., battery life and computer processing cycles) that could otherwise be used to generate and communicate more frequent communications of the temperature measurements 116 to the computing device. In contrast, the transmitter 210 may communicate the glucose measurements 114 substantially as they are provided, because the person 102 or a healthcare provider may use the glucose measurements 114 to make treatment decisions for a health condition (e.g., diabetes). Furthermore, such a determination may require that the glucose measurements 114 be timely (i.e., substantially real-time) to avoid adverse effects associated with health conditions, such as dysglycemia. Although less frequent transmission intervals than those providing temperature measurements 116 are discussed above, in one or more implementations, the transmitter 210 may transmit the temperature measurements 116 to the computing device at the same or similar rate as those measurements are provided.

[0057] The transmitter 210 may also cause additional data to be transmitted to the computing device, packaged with or separate from the glucose reading 114 and the temperature reading 116. By way of example, this additional data may include measurements of other analytes, one or more sensor identifiers (e.g., information that uniquely identifies a particular glucose sensor 202 from other glucose sensors), identifiers of other components of the wearable glucose monitoring device 104 (e.g., one or more antennas of the transmitter 210), a sensor status representative of the state of a given sensor (e.g., representative of the operational state of a given sensor), etc.

[0058] Having considered an exemplary environment and an exemplary wearable glucose monitoring device, we now turn to a discussion of some exemplary details of techniques for population disease identification using wearable glucose monitoring devices in a digital media environment according to one or more implementation aspects.

[0059] Identifying disease outbreaks FIG. 3 depicts an example implementation 300 in which data, including temperature measurements, collected from a wearable glucose monitoring device is routed to different systems in connection with population disease identification.

[0060] The illustrated example 300 includes the example glucose monitoring device 104 and computing device 106 from Figure 1. The illustrated example 300 also includes the disease identification system 122 and, as discussed above, the storage device 118 that stores the glucose readings 114 and the temperature readings 116. In this example 300, the wearable glucose monitoring device 104 is depicted transmitting the glucose readings 114 and the temperature readings 116 to the computing device 106. The wearable glucose monitoring device 104 may transmit the glucose readings 114 and the temperature readings 116 to the computing device 106 in a variety of ways.

[0061] The depicted example 300 also includes a data package 302, where the data package 302 includes the temperature reading 116 and location data 120. The location data 120 is illustrated with hashing to indicate that it is optional, and in one or more implementations, the location data is not communicated to the glucose monitoring platform 110 along with the temperature reading 116. In scenarios in which the location data 120 is not communicated with the temperature reading 116, the location data 120 may simply be retained in the storage device 118 of the glucose monitoring platform 110, for example, as a location entered in connection with establishing or updating a user profile of the person 102 with the glucose monitoring platform 110. This is one example of how a temperature reading 116 of the person 102 may be associated with a location.

[0062] In one or more implementations, location data 120 may be generated by computing device 106 and packaged in data package 302 (as shown) along with temperature readings 116 to describe the location of person 102, such as the location of person 102 when glucose reading 114 was taken or communicated to glucose monitoring platform 110. By way of example, computing device 106 may be configured with suitable hardware and processing resources to determine location using Global Positioning System (GPS) coordinates, a triangulation approach involving communication with wireless access points (e.g., wireless routers or cell phone towers), a combination of GPS with other data received wirelessly, etc. In this manner, temperature reading 116 of person 102 at a given time may be associated with the location where person 102 is located or where person's 102's computing device 106 is physically located.

[0063] Data package 302 may include different or additional data than shown, such as one or more of the glucose readings 114, any other data provided by wearable glucose monitoring device 104 and communicated to computing device 106, and supplemental data provided by computing device 106 that describes one or more events (e.g., application usage data, device interaction data, etc.) that correspond (e.g., in time) to one or more of glucose readings 114 and / or temperature readings 116, to name a few. In this example 300, data package 302 is depicted as being routed from computing device 106 to storage device 118 of glucose monitoring platform 110. Thus, computing device 106 may act as an intermediary between wearable glucose monitoring device 104 and glucose monitoring platform 110, and computing device 106 may be configured as, for example, a user's mobile phone or a smartwatch.

[0064] Although not depicted in the illustrated example 300, the glucose monitoring platform 110 may process these data packages 302 and cause at least some of the temperature readings 116 and location data 120 (if included in the data packages 302) to be stored in a storage device 118. The glucose monitoring platform 110 may also process the glucose readings 114 received from the computing device 106 and cause at least some of them to be stored in a storage device 118. From the storage device 118, this data may be provided to or otherwise accessed by a disease identification system 122, for example, to identify diseases among a population of users at a location, as described in more detail below.

[0065] In the illustrated example 300, the disease identification system 122 is depicted receiving location data 120 and temperature measurements 116 from the storage device 118. The disease identification system 122 is configured to identify diseases at different locations using the location data 120 and the temperature measurements 116. The disease identification system 122 is also depicted receiving glucose measurements 114 in the illustrated example 300. However, in contrast to the location data 120 and the temperature measurements 116, the glucose measurements 114 depicted as being communicated to the disease identification system 122 are shown with hashing. This indicates that in one or more implementations, the disease identification system 122 identifies diseases among a population of users at a location without using the glucose measurements 114, and in other implementations, the disease identification system 122 uses the glucose measurements 114 to identify diseases among a population of users at a location. According to the described techniques, the glucose readings 114 , location data 120 , and temperature readings 116 processed by the disease identification system 122 may correspond to one or more users of the user population 108 , which may include the person 102 .

[0066] The illustrated example 300 depicts a disease identification system 122 that includes identification logic 304. Generally, the identification logic 304 is configured to process temperature measurements 116 and location data 120 to identify disease in a population of users at one or more locations at a time, such as identifying the presence of a disease (e.g., influenza, coronavirus disease, etc.) among users located in a geographic region (e.g., a county) during a time interval (e.g., last day, last week, etc.). In one or more implementations, the identification logic 304 may be configured to process glucose measurements 114 along with temperature measurements 116 and location data 120 to identify disease in a population of users at one or more locations at a time. Moreover, the identification logic 304 may be further used to perform this identification multiple times for multiple locations (e.g., multiple counties). Based on this identification, the presence and / or severity of the disease (e.g., the number of cases of the disease or the percentage of the population with the disease) may be presented for different geographic regions (e.g., by county) and / or different times (e.g., by day or week).

[0067] The identification also allows the identification logic 304 to compare diseases across different geographic regions and / or across time periods, such as by determining one or more statistical measures related to the presence (e.g., differences) of disease between different geographic regions or different time periods. By triggering the presentation of information corresponding to the identification, the identification logic 304 allows a user to compare (e.g., visually) the presence of disease across different geographic regions and / or across time periods. For example, as discussed in more detail with respect to at least FIG. 4 , the presence and / or severity of disease in two different locations over the same time period (e.g., the last week) may be presented. Alternatively or additionally, the presence and / or severity of disease in a given location may be compared across different time periods, as discussed in more detail with respect to FIG. 5 . As discussed above, the identification logic 304 may be configured to identify diseases for various types of geographic regions in accordance with the described techniques. While counties are discussed above and below, for example, the identification logic 304 may alternatively or additionally identify diseases for countries, states, cities, zip codes, voting districts, and school districts, to name a few.

[0068] To identify illnesses among a population of users, the identification logic 304 may be configured in various manners without departing from the spirit or scope of the described techniques. For example, the identification logic 304 may include or be configured as a machine learning model or an ensemble of machine learning models, such as regression models (e.g., linear, polynomial, and / or logistic regression models), classifiers, neural networks, and reinforcement learning-based models, to name a few. Alternatively or additionally, the identification logic 304 may include or be configured as one or more hard-coded rules such that the identification logic 304 processes the temperature readings 116 and the location data 120 (and, in some implementations, additional data) to determine, for example, one or more statistical measures associated with illness identification. In this example, the identification logic 304 may then apply the above-described rules to the one or more statistical measures. Additionally or alternatively, the identification logic 304 may be configured to detect anomalies in the glucose readings 114 and / or the temperature readings 116 in conjunction with the location data 120. In particular, the identification logic 304 may identify deviations from a determined "normal" temperature or glucose for a location. The deviations and determined normal values ​​may correspond to the average temperature or glucose across a population of users at a given location. It should be understood that the identification logic 304 may be configured in other manners (e.g., based on various different algorithms and / or rules) to identify illnesses among a population of users at a location during a given period of time in accordance with the described techniques.

[0069] As described above, the identification logic 304 may include or be configured as a machine learning model in one or more implementations. In such implementations, the machine learning model may be generated according to one or more algorithms, such as training the model to learn the model's internal weights (e.g., a neural network approach) or learning the parameters of the model's predictive function (e.g., a regression approach), and using, for example, past temperature measurements 116 and location data 120 of the user population 108. In implementations where additional data is used to identify disease in the user population, such as glucose measurements 114, the machine learning model may be further trained using this additional data.

[0070] In addition to the past temperature measurements 116 and location data 120, the machine learning model may be generated using past data representing the presence and / or absence of one or more diseases. Before generating the machine learning model, for example, the past temperature measurements 116 and the past location data 120 may be associated with data representing the presence or absence of diseases at each location and each time. In other words, each past temperature measurement 116 may be matched with each location (e.g., using the location data 120) and information representing the presence (or absence) of at least one disease at each location at the time corresponding to the past temperature measurement 116. In a scenario where past glucose measurements 114 are also used by the identification logic 304 to identify diseases, each past temperature measurement 116 may be further matched with one or more respective glucose measurements 114.

[0071] This matched data is sometimes referred to herein as “training data.” When configured as a machine learning model, the identification logic 304 may be generated through a learning or training process performed in accordance with one or more algorithms configured to learn function parameters from the training data or train a model based on the training data. In connection with this training or learning process, past temperature measurements 116 (and optionally past glucose measurements 114) may correspond to inputs to the identification logic 304, while the presence or absence of disease at each location may correspond to a desired outcome that may be compared with the output of the identification logic 304 during the training or learning process. By using one or more of the learning or training algorithms described above, the identification logic 304 learns to substantially predict outcomes in the training data given the corresponding input training data. In particular, the function parameters and internal model weights of the machine learning model may be automatically adjusted during the learning process in response to the learning or training algorithm to more closely match the predicted values ​​output by the model during the process with the outcomes of the training data. It should be understood that a variety of learning approaches may be utilized in connection with the described techniques, including supervised approaches, unsupervised approaches, and reinforcement learning approaches.

[0072] Additionally, the identification logic 304 may be trained using various other contextual information relevant to identifying illnesses and may therefore be able to receive it during operation. By way of example, this contextual information may include the month, day of the week, and time of day, to name a few. The identification logic 304 may use this information, for example, to signal the detection of an anomaly from an expected temperature change associated with a nominal pattern. By way of example, the average temperature of an entire population may be lower at night, for example, because people in the population are sleeping and have lower body temperatures during sleep. Thus, a relatively higher average temperature of an entire population at night may not be significantly (statistically significantly) higher than the average temperature of the population during the day, but may still indicate the presence of illness in the population. Other examples of contextual information may include predicted weather by month for different locations. It should be understood that the identification logic 304 may be trained using a variety of contextual information and may also be able to utilize it during operation without departing from the spirit or scope of the described techniques.

[0073] Once trained, or the parameters of the underlying function are learned, the identification logic 304, configured as a machine learning model, is configured to operate to identify diseases among a population of users at a location. More specifically, the identification logic 304, configured as a machine learning model, identifies such diseases by generating a prediction, e.g., based on the training or learning, regarding whether the disease is present at a particular location and over a period of time. To do so, temperature measurements 116 and location data 120, and optionally glucose measurements 114, are provided as inputs to the identification logic 304. Data representative of other aspects of the user population may also be provided as inputs to the identification logic 304.

[0074] In one or more implementations, the disease identification system 122 preprocesses the location data 120 and the temperature measurements 116 to format them so that they can be received as input by the identification logic 304. By way of example, the disease identification system 122 may form vectors (e.g., feature vectors) of the location data 120 and the temperature measurements 116 and then provide those vectors as input to the identification logic 304. In one or more implementations, the preprocessing may include determining statistical characteristics of the location data 120 and the temperature measurements 116, including, for example, the average temperature, the average temperature over a period of time, the median temperature, the number of users with a temperature above a threshold temperature, and the percentage of users in a geographic area with a temperature above a threshold temperature, to name a few. In these implementations, the disease identification system 122 may be configured to generate input data representing the determined statistical characteristics in addition to or instead of directly representing the temperature measurements 116 and the location data 120. Based on patterns learned from past temperature measurements using the approaches discussed above, the identification logic 304 outputs a prediction regarding the presence of disease at a given location over a specific period of time based on the data input. The output may also be configured as a vector (eg, a feature vector) that indicates the presence of a disease.

[0075] As described above, the identification logic 304 may alternatively or additionally be configured as one or more hard-coded rules. Such rules may identify the presence or absence of disease based on meeting one or more criteria. By way of example, a rule may include a comparison to a threshold value, such that if a threshold percentage of users in a geographic region have a temperature (or average temperature) above a threshold temperature over a period of time, the identification logic 304 identifies the presence of disease in the geographic region for that period of time. It should be understood that this is just one example rule, and that the identification logic may encode a variety of rules for identifying disease among a population of users in a location in accordance with the described techniques.

[0076] Based on the data describing one or more identified diseases output by the identification logic 304, the disease identification system 122 can notify different entities. The illustrated example 300 includes notification 306 and notification 308. Notification 306 is shown communicated to a computing device 106, which, in one or more implementations, is associated with a person 102 that corresponds to a user of the user population 108. Specifically, the person 102 may correspond to one user of the user population 108 who wears a wearable glucose monitoring device 104 and / or has a user profile with the glucose monitoring platform 110. In contrast, notification 308 is shown communicated to a third party 310. The third party 310 may correspond to various entities that have an interest in the diseases identified in the user population by the disease identification system 122. By way of example and not limitation, third party 310 may represent a public health agency (e.g., the Centers for Disease Control and Prevention (CDC), the World Health Organization (WHO), and the National Institutes of Health (NIH)), a government agency, a school district, a medical facility (e.g., hospitals and clinics), a news source, a telemedicine service, or a data partner (e.g., an entity that has contracted with glucose monitoring platform 110 to receive notification of identified diseases), to name a few.

[0077] In one or more implementations, the notifications 306, 308 include information describing illnesses identified by the identification logic 304 in at least one geographic region for a period of time, e.g., one or more previous periods, a current time interval (e.g., today, this week, this month), or one or more periods following the identification (e.g., tomorrow, next week, next month). To this end, the notifications 306, 308 can include at least some of the same information. Alternatively, or additionally, the notifications 306, 308 can include different information. For example, the notification 306 can include an alert or warning directed to the person 102. Such an alert can include instructions recommending one or more actions for the user to take based on the identification of an illness in a location, such as a geographic region in which the user is located or selected by the user. By way of example, the alert can notify the user about the illness and / or include suggested actions to reduce the person 102's risk of contracting the illness, such as washing hands more frequently than usual, avoiding close contact with others, limiting travel from home, wearing a face covering when around others, etc. In at least one implementation, the notification 308 communicated to the third party 310 may not include an alert with such instructions, but in at least one different implementation, the notification 308 may include some form of alert and / or recommended action to mitigate the identified illness.

[0078] It should be understood that notifications 306, 308 may include the same or different information without departing from the spirit or scope of the techniques described herein. Nevertheless, notifications 306, 308 include information based on and / or representative of at least one disease identified by identification logic 304 for a population of users in at least one geographic region over a period of time. In the context of the different information that may be included in notifications 306, 308 and presented via computing device 106 or a computing device associated with a third party 310, consider the following discussion of FIGS. 4-6.

[0079] FIG. 4 depicts an example implementation 400 of a user interface that may be displayed to present information associated with identifying a population disease.

[0080] The illustrated example 400 includes a display device 402 displaying a user interface 404, which may be an example of notifications 306, 308 or may be generated based on these notifications. In this example 400, the user interface 404 includes a representation of a geographic region (e.g., a country) divided into further geographic regions (e.g., counties). Additionally, the user interface 404 includes graphical elements that visually indicate diseases identified in the further geographic regions. These visual elements are based on the diseases identified by the identification logic 304 as discussed above.

[0081] User interface 404 is an example of a "heat map" that may be generated over a period of time based on the diseases identified by identification logic 304 among user populations in different regions. As a heat map, user interface 404 is configured to show differences in disease presence from one location to another, such as by showing "hot spots." Hot spots correspond to locations identified as having a relatively greater disease severity than other locations. In this example 400, location 406 is displayed with a graphic element indicating that the disease severity is greater than the severity indicated by the graphic element at different location 408. In this manner, the presence or severity of disease at two different locations can be visually indicated over the same period of time. In other words, the heat map visually distinguishes the severity of disease across user populations at the different locations depicted in the heat map.

[0082] In this example 400, the time associated with one or more diseases in the displayed geographic region is shown by a graphical time element 410. The graphical time element 410 can represent various time periods according to the described techniques, such as the period from January 1 of the current year to the displayed date, the period from selected data (e.g., the start of a "disease" season or the first identified case of a disease) to the displayed date, a given day, a given week, a given month, a given year, etc.

[0083] FIG. 5 depicts an example embodiment 500 of information presented in connection with identifying a population disease via a user interface.

[0084] The illustrated example 500 depicts stages in which a geographic region (e.g., a country) is divided into further geographic regions (e.g., counties), and the stages include graphical elements that visually indicate diseases identified in the further geographic regions at different times in the stages. In particular, the illustrated example 500 includes a first stage 502, a second stage 504, and a third stage 506, which may correspond to a first time, a second time, and a third time, respectively. In this example, the second time may follow the first time, and the third time may follow the second time.

[0085] Stages 502, 504, and 506 may be presented via a user interface, such as user interface 404, and may be examples of notifications 306, 308 or may be generated based on those notifications. Each stage may correspond to a “heat map” showing the presence or severity of one or more diseases at different locations at a corresponding time, e.g., a first, second, or third time. In one or more implementations, user interface 404 may be configured to display the different stages 502, 504, and 506 in chronological and / or reverse chronological order and animate the transitions between the stages. In this manner, the described system may visually show a user how the presence and / or severity of one or more diseases changes over time. In this particular example 500, for example, the maps of the geographic region and the additional geographic region in the third stage 506 contain more hot spots than the maps in the first stage 502, indicating an increase in the presence or severity of one or more diseases from the first time to the third time. In this example, the map in the second stage 504 shows an intermediate increase in disease presence and / or severity between the first stage 502 and the third stage 506. Generally speaking, presenting the same geographic area or set of geographic areas at different times allows the presence and / or severity of disease at a given location to be compared across different times.

[0086] FIG. 6 depicts an example implementation 600 of a user interface displayed to present notifications associated with the identification of a population disease.

[0087] The illustrated example 600 depicts one example of a computing device 106 displaying a user interface 602. The user interface 602 may be an example of a notification 306 or may be generated by the computing device 106 based on the notification 306. In this example 600, the user interface displays information 604 describing a disease identified by the identification logic 304 as discussed above. Here, the user interface 602 also includes a recommended action 606. As discussed above, the recommended action 606 may be suggested to reduce the likelihood of the user of the computing device 106 contracting the identified disease.

[0088] In this example 600, the user interface 602 further includes selectable graphic elements 608, 610 that are selectable to display more information about one or more diseases identified by the identification logic 304, i.e., a map visually indicating the presence or severity of the disease (e.g., as in FIGS. 4 and 5 ) and additional information. The exemplary user interface 602 also includes an alert deadline 612. It should be understood that the user interface 602 is one example of an alert that may be displayed based on the notification 306. The alert may be configured to display in different manners to include different and / or additional information without departing from the spirit or scope of the described techniques. Alternatively or additionally, the alert may be displayed within a mobile app, as a notification from the mobile app, received and displayed as a text message, etc.

[0089] FIG. 7 depicts an example implementation 700 of a user interface that may be displayed to present information associated with identifying a population disease in a selected location.

[0090] The illustrated example 700 includes a computing device 106 in an exemplary implementation in which a user of the computing device 106 selects a location, the identification logic 304 identifies whether a disease has been detected at the selected location based on the temperature readings 116, and the computing device 106 displays an indication related to the identification, such as an indication that the disease is present at the location or an indication that the disease is not present at the location.

[0091] For example, in a first step 702, the computing device 106 presents a user interface that allows a user to provide input to select a geographic region. The depicted interface indicates that the user may begin typing the letters of the place name or may speak the place name. In a second step 704, the computing device 106 presents suggested geographic regions that match the portion of the search query entered by the user to select the geographic region. Although not depicted in the illustrated example 700, the user of the computing device 106 selects a location, namely, San Diego, California.

[0092] In step 706, the computing device 106 presents an indication of whether a disease has been identified by the identification logic 304 in the selected location. In particular, user interface configuration 708 corresponds to a scenario in which the identification logic 304 has identified a disease in the selected geographic region ("yes") and / or predicts that there is a risk of the disease in that region over a future time period. In contrast, user interface configuration 710 corresponds to a scenario in which the identification logic 304 has identified a disease in the selected geographic region ("no") and / or predicts that there is no risk of the disease in that region over a future time period.

[0093] Having discussed detailed examples of techniques for population disease identification using wearable glucose monitoring devices, we will now consider some example procedures to illustrate additional aspects of the techniques.

[0094] Exemplary Procedure This section describes an example population disease protocol using a wearable glucose monitoring device. Aspects of the protocol may be implemented in hardware, firmware, software, or a combination thereof. The protocol is illustrated as a set of blocks specifying operations to be performed by one or more devices and is not necessarily limited to the order shown for performing the operations by each block. In at least some implementations, the protocol is performed by a disease identification system, such as disease identification system 122, utilizing identification logic 304.

[0095] FIG. 8 depicts a procedure 800 of an example implementation in which the presence of illness in a user at one or more locations is identified based on temperature measurements obtained from a wearable glucose monitoring device.

[0096] Temperature measurements provided by wearable glucose monitoring devices worn by users of the user population are obtained (block 802). By way of example, the disease identification system 122 obtains temperature measurements 116 from the storage device 118 of the glucose monitoring platform 110. The temperature measurements 116 are provided by the wearable glucose monitoring devices 104 of the users of the user population 108.

[0097] Location data representing the user's location is obtained, and the temperature readings are associated with the respective locations according to the location data (block 804). By way of example, the disease identification system 122 obtains the location data 120. In one or more implementations, the computing devices 106 associated with the users of the user population 108 associate the location data 120 with each temperature reading 116 such that the disease identification system 122 can associate the location described by the location data 120 with each temperature reading 116. Alternatively or additionally, the storage device 118 maintains the location data 120 as part of the user profiles of the users of the user population 108. Here, the disease identification system 122 can associate the location described by the location data 120 in the user profiles of the users of the user population 108 with each temperature reading 116.

[0098] The presence of the illness in the user is identified at one or more locations based on the temperature measurements and the location data (block 806). By way of example, the identification logic 304 identifies the presence of the illness in the user at one or more of the locations based on the temperature measurements 116 and the location data 120. In one or more implementations, the identification logic 304 identifies the presence of the illness further based on the glucose measurements 114.

[0099] At least one of the users is notified of the presence of the disease (block 808). By way of example, the disease identification system 122 communicates a notification 306 to the computing device 106 to inform the person 102 of the presence of the disease identified in block 806. The notification 306 may include or otherwise enable the presentation, via the computing device 106, of one or more user interfaces for outputting information about the identified disease, such as one or more of the user interfaces depicted in FIGS.

[0100] In one or more implementations, at least one third party is notified of the presence of the disease. By way of example, the disease identification system 122 communicates a notification 308 to the third party 310 to inform at least one user associated with the third party 310 about the disease identified in block 806. The notification 308 may include or otherwise enable the presentation, via the computing device, of one or more user interfaces for outputting information about the identified disease, such as one or more of the user interfaces depicted in FIGS. 4-7.

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

[0102] Exemplary Systems and Devices FIG. 9 illustrates an exemplary system 900 including an exemplary computing device 902 embodying one or more computing systems and / or devices that may implement various techniques described herein. This is illustrated through the inclusion of a disease identification system 122, which is illustrated both at the computing device 902 level and at the service provider level. This indicates that some aspects of the disease identification system 122 may be implemented on the computing device 902 (e.g., computing device 106), such as in connection with a disease identification app. This also indicates that aspects of the disease identification system 122 may be implemented using one or more server-based or “cloud computing” resources. The computing device 902 may be, for example, a service provider server, a device associated with a client (e.g., a client device), an on-chip system, and / or any other suitable computing device or computing system.

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

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

[0105] The computer-readable medium 906 is shown as including memory / storage 912. The memory / storage 912 represents memory / storage capacity associated with one or more computer-readable media. The memory / storage 912 components may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks, etc.). The memory / storage 912 components may include fixed media (e.g., RAM, ROM, fixed hard drives, etc.) as well as removable media (e.g., flash memory, removable hard drives, optical disks, etc.). The computer-readable medium 906 may be configured in a variety of other manners, as described further below.

[0106] The input / output interface 908 embodies functionality that allows a user to input commands and information into the computing device 902 and to present information to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., a capacitive or other sensor configured to detect physical touch), a camera (e.g., which may use visible or invisible wavelengths such as infrared frequencies to recognize movements as gestures without touch), etc. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, a tactile response device, etc. Accordingly, the computing device 902 may be configured in various ways, described further below, to support user interaction.

[0107] Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, etc. that perform particular tasks or implement particular abstract data types. As used herein, the terms "module," "functionality," and "component" generally refer to software, firmware, hardware, or combinations thereof. Aspects of the techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.

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

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

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

[0111] As previously mentioned, the hardware elements 910 and the computer-readable medium 906 embody modules, programmable device logic, and / or fixed device logic implemented in hardware that may be used in some embodiments to implement at least some aspects of the techniques described herein, such as to execute one or more instructions. The hardware may include integrated circuits or components of on-chip systems, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations in silicon or other hardware. In this context, the hardware may operate as a processing device that executes program tasks defined by instructions and / or logic embodied by the hardware, as well as hardware utilized to store instructions for execution, such as the computer-readable storage medium described above.

[0112] A combination of the foregoing may be used to implement the various techniques described herein. Accordingly, software, hardware, or executable modules may be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage medium and / or by one or more hardware elements 910. Computing device 902 may be configured to implement specific instructions and / or functionality corresponding to the software and / or hardware modules. Thus, implementation aspects of modules executable by computing device 902 as software may be achieved at least partially in hardware, for example, through the use of computer-readable storage media and / or hardware elements 910 of processing system 904. The instructions and / or functionality may be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 902 and / or processing system 904) to implement the techniques, modules, and examples described herein.

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

[0114] The cloud 914 includes and / or embodies a platform 916 for resources 918. The platform 916 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of the cloud 914. The resources 918 may include applications and / or data that may be utilized while computer processing is running on a server remote from the computing device 902. The resources 918 may also include services provided over the Internet and / or through a subscriber network, such as a cellular or Wi-Fi network.

[0115] The platform 916 may abstract resources and functionality for connecting the computing device 902 with other computing devices. The platform 916 may also abstract resource scaling, functioning to provide a level of scale corresponding to the encountered demand of the resources 918 implemented via the platform 916. Thus, in embodiments of interconnected devices, implementation aspects of the functionality described herein may be distributed throughout the system 900. For example, functionality may be implemented partially on the computing device 902 as well as via the platform 916 that abstracts the functionality of the cloud 914.

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

[0117] 102 people 104 Wearable Glucose Monitoring Devices 106 Computing Devices 108 User Group 110 Glucose Monitoring Platform 112 Network 114 Glucose Measurements 116 Temperature Measurements 118 Storage Devices 120 Location Data 122 Disease Identification System

Claims

1. A method for use by a system having a processor, comprising: the system obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population; the system obtaining location data representing a location of the user and associating each of the temperature measurements with a respective location; the system identifying the presence of a disease in the user at one or more of the locations based on the temperature measurements, the location data, and glucose measurements provided by the wearable glucose monitoring device; the system notifying at least one of the users of the presence of the disease.

2. 10. The method of claim 1, wherein identifying the presence of the disease comprises processing the temperature measurements and the location data using, in part, one or more machine learning models, the one or more machine learning models generated based on past temperature measurements of the user population and past data representative of the presence of one or more diseases in the user population.

3. The method of claim 1 , wherein the wearable glucose monitoring device includes at least one continuous glucose monitoring (CGM) system.

4. 10. The method of claim 1, wherein identifying the presence of the disease comprises processing the temperature measurements, the glucose measurements, and the location data using, in part, one or more machine learning models, the one or more machine learning models generated based on past temperature and glucose measurements of the user population and past data representative of the presence of one or more diseases in the user population.

5. The method of claim 1 , further comprising notifying at least one third party of the presence of the disease.

6. 6. The method of claim 5, wherein the at least one third party includes at least one of a public health organization, a government organization, a school district, a medical facility, a news source, a telemedicine service, or a data partner having a glucose monitoring platform compatible with the wearable glucose monitoring device.

7. The method of claim 1 , wherein the users of the user population have a user profile with a glucose monitoring platform.

8. notifying at least one user of the presence of the disease; generating a heat map visually distinguishing the severity of the disease across a population of users at different locations; and causing a display of the heatmap on a display device of a computing device associated with the at least one user.

9. notifying at least one user of the presence of the disease; generating an alert with information about the presence of the disease; and triggering output of the alert via a computing device associated with the at least one user.

10. The method of claim 9 , wherein causing output of the alert comprises causing display of the alert via a display device of the computing device.

11. 1. A system comprising: at least one processor; a memory having stored thereon instructions executable by said at least one processor to perform operations, said operations comprising: obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population; obtaining location data representative of locations of the users and associating the temperature measurements with the respective locations; identifying the presence of a disease in the user at one or more of the locations based on the temperature measurements, the location data, and glucose measurements provided by the wearable glucose monitoring device; and notifying at least one of the users about the presence of the disease.

12. 12. The system of claim 11, further comprising one or more machine learning models configured to identify the presence of the disease by processing the temperature measurements and the location data, wherein the one or more machine learning models are generated based on past temperature measurements of the user population and past data representative of the presence of one or more diseases in the user population.

13. The system of claim 11 , wherein the wearable glucose monitoring device comprises at least one continuous glucose monitoring (CGM) system.

14. 12. The system of claim 11, further comprising one or more machine learning models configured to identify the presence of the disease by processing the temperature measurements, the glucose measurements, and the location data, wherein the one or more machine learning models are generated based on past temperature and glucose measurements of the user population and past data representative of the presence of one or more diseases in the user population.

15. The system of claim 11 , wherein the action further comprises notifying at least one third party about the presence of the disease.

16. 16. The system of claim 15, wherein the at least one third party includes at least one of a public health organization, a government organization, a school district, a medical facility, a news source, a telehealth service, or a data partner having a glucose monitoring platform compatible with the wearable glucose monitoring device.

17. The system of claim 11 , wherein the users of the user population have a user profile with a glucose monitoring platform.

18. notifying at least one user of the presence of the disease; generating a heat map visually distinguishing the severity of the disease across a population of users at different locations; and causing a display of the heat map on a display device of a computing device associated with the at least one user.

19. notifying at least one user of the presence of the disease; generating an alert with information about the presence of the disease; and triggering output of the alert via a computing device associated with the at least one user.

20. 20. The system of claim 19, wherein causing output of the alert comprises causing display of the alert via a display device of the computing device.

21. One or more non-transitory computer-readable storage media having stored thereon instructions executable by one or more processors of at least one computing device to cause the at least one computing device to perform operations, the operations including: obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population; obtaining location data representative of locations of the users and associating the temperature measurements with the respective locations; identifying the presence of a disease in the user at one or more of the locations based on the temperature measurements, the location data, and glucose measurements provided by the wearable glucose monitoring device; and notifying at least one of the users about the presence of the disease.

22. 22. The one or more computer-readable storage media of claim 21 , wherein identifying the presence of the disease includes processing the temperature measurements and the location data using, in part, one or more machine learning models, the one or more machine learning models generated based on past temperature measurements of the user population and past data representative of the presence of one or more diseases in the user population.

23. 22. The one or more computer-readable storage media of claim 21, wherein the wearable glucose monitoring device comprises at least one continuous glucose monitoring (CGM) system.

24. 22. The one or more computer-readable storage media of claim 21 , wherein identifying the presence of the disease comprises processing the temperature measurements, the glucose measurements, and the location data using, in part, one or more machine learning models, the one or more machine learning models generated based on past temperature and glucose measurements of the user population and past data representative of the presence of one or more diseases in the user population.

25. 22. The one or more computer-readable storage media of claim 21, wherein the actions further comprise notifying at least one third party about the presence of the disease.

26. 26. The one or more computer-readable storage media of claim 25, wherein the at least one third party includes at least one of a public health organization, a government organization, a school district, a medical facility, a news source, a telemedicine service, or a data partner having a glucose monitoring platform compatible with the wearable glucose monitoring device.

27. 22. The one or more computer-readable storage media of claim 21, wherein the users of the user population have user profiles with a glucose monitoring platform.

28. notifying at least one user of the presence of the disease; generating a heat map visually distinguishing the severity of the disease across a population of users at different locations; and causing a display of the heat map on a display device of a computing device associated with the at least one user.

29. notifying at least one user of the presence of the disease; generating an alert with information about the presence of the disease; and triggering output of the alert via a computing device associated with the at least one user.

30. 30. The one or more computer-readable storage media of claim 29, wherein causing output of the alert comprises causing display of the alert via a display device of the computing device.

31. 1. An apparatus comprising: means for obtaining temperature measurements provided by wearable glucose monitoring devices worn by users of a user population; means for obtaining location data representative of the user's location and associating each of the temperature measurements with a respective location; means for identifying the presence of disease in the user at one or more of the locations based on the temperature measurements, the location data, and glucose measurements provided by the wearable glucose monitoring device; means for notifying at least one of said users of said presence of said disease.

Images