Population disease identification using wearable blood glucose monitoring devices

Abstract

Identifying disease in a population using wearable blood glucose monitoring devices is described. A disease identification system obtains temperature measurements generated by wearable blood glucose monitoring devices worn by users of a population of users. The disease identification system also obtains location data describing locations of the users and associates each temperature measurement 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 of the users at one or more locations based on the temperature measurements and the location data. The disease identification system generates a communication for notifying at least one user about the presence of the disease.

Description

[0001] Related Applications

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

[0003] Diseases, such as influenza and coronaviruses, can have widespread and severe impacts on populations. For example, a disease may have health-related effects on a population, thus requiring at least some form of treatment for those who have it. Additionally, some diseases can have severe economic impacts, paralyzing global and local economic sectors due to various reasons, such as fear of the disease, rules and regulations implemented to combat its spread (e.g., quarantines, curfews, and / or business closures). However, the negative impacts of such diseases can be reduced by taking mitigating actions, such as maintaining social distancing, increasing handwashing or sanitizing, increasing cleaning of shared spaces, and wearing face coverings.

[0004] The effectiveness of these practical disease-mitigating behaviors depends not only on the extent to which they are adopted but also on the timeliness of their adoption. Widespread adoption of mitigation behaviors in the early stages of disease can significantly reduce its negative effects compared to adopting them later. Furthermore, some individuals may be more susceptible to severe adverse effects than others if they are infected. One example of someone who may be at higher risk is a diabetic patient—a particular disease can cause more severe, even life-threatening, adverse effects in diabetic patients compared to those without diabetes. Early mitigation behaviors in high-risk individuals enable them to limit exposure to the disease and / or take preventative measures to prevent disease contraction, even after exposure.

[0005] One indicator of many diseases is an elevated body temperature relative to a defined “normal” temperature (e.g., 98.6°F). However, in the real world, people don't typically “take their temperature” until they feel unwell. So, once a person begins to feel unwell, he, she, or her caregiver might obtain a thermometer to measure that person's temperature / or might go to a doctor's office to have their temperature taken. However, by this time, the person may have been infected long enough to unknowingly expose others to the disease. In the early stages of illness, due to the time delay between contracting the disease and feeling unwell enough to have their temperature measured, many people in a population can unknowingly become ill and expose others to the disease. At least in part due to this time delay, traditional methods of using temperature to identify illness may not be effective in preventing its spread, and thus, illness can have a significant impact on the population and those at higher risk of severe adverse effects. Summary of the Invention

[0006] To overcome these problems, wearable blood glucose monitoring devices are used to identify diseases in a population. The disease identification system acquires temperature measurements generated by wearable blood glucose monitoring devices worn by users within a user population. The system also acquires location data describing the user's location and associates the temperature measurements with the corresponding location. The system uses identification logic (e.g., one or more machine learning models) to identify the presence of a disease in users at one or more locations based on the temperature measurements and location data. The system generates communications to notify at least one user of the presence of a disease.

[0007] One aspect is a method that includes: acquiring temperature measurements generated by wearable blood glucose monitoring devices worn by users within a user population; acquiring location data describing the user's location and associating each temperature measurement with a corresponding location; identifying the presence of a disease in one or more users at one or more locations based on the temperature measurements and location data; and notifying at least one user of the presence of the disease.

[0008] In the above methods, identifying the presence of a disease involves partially using one or more machine learning models to process temperature measurements and location data, generated based on historical temperature measurements of the user population and historical data describing the presence of one or more diseases within the user population. In the above methods, the wearable blood glucose monitoring device includes at least one continuous glucose monitoring (CGM) system. In the above methods, identification is also based on blood glucose measurements generated by wearable blood glucose monitoring devices worn by users within the user population.

[0009] In the above method, identifying the presence of disease involves partially using one or more machine learning models to process temperature measurements, blood glucose measurements, and location data, which are generated based on historical temperature and blood glucose measurements of the user population and historical data describing one or more diseases present in the user population.

[0010] The above method also includes notifying at least one third party of the presence of the disease. In the above method, the at least one third party includes at least one of the following: a public health organization, a government organization, a school district, a healthcare institution, a news source, a telemedicine service, or a data partner with a blood glucose monitoring platform corresponding to the wearable blood glucose monitoring device. In the above method, the user population has user profiles on the blood glucose monitoring platform.

[0011] In the above methods, notifying at least one user of the existence of a disease includes: generating a heat map visually distinguishing the severity of the disease among user groups in different locations; and causing the heat map to be displayed on a display device of a computing device associated with at least one user. In the above methods, notifying at least one user of the existence of a disease includes: generating an alarm with disease presence information; and causing the alarm to be output via a computing device associated with at least one user. In the above methods, causing the alarm to be output includes causing the alarm to be displayed via a display device of the computing device.

[0012] On the other hand, it is a system comprising: at least one processor; and a memory storing instructions executable by the at least one processor to perform the following operations: acquiring temperature measurements generated by wearable blood glucose monitoring devices worn by users of a user population; acquiring location data describing user locations and associating temperature measurements with corresponding locations; identifying the presence of a disease in one or more users at one or more locations based on the temperature measurements and location data; and notifying at least one user of the presence of the disease.

[0013] The system also includes one or more machine learning models configured to identify the presence of diseases by processing temperature measurements and location data, generated based on historical temperature measurements of the user population and historical data describing the presence of one or more diseases in the user population.

[0014] In the aforementioned system, the wearable blood glucose monitoring device includes at least one continuous glucose monitoring (CGM) system. In the aforementioned system, identification is also based on blood glucose measurements generated by wearable blood glucose monitoring devices worn by users within a user population. The aforementioned system also includes one or more machine learning models configured to identify the presence of diseases by processing temperature measurements, blood glucose measurements, and location data, generated based on historical temperature and blood glucose measurements of the user population, and historical data describing the presence of one or more diseases within the user population.

[0015] In the aforementioned system, the operation further includes notifying at least one third party of the existence of the disease. In the aforementioned system, the at least one third party includes at least one of the following: a public health organization, a government organization, a school district, a medical institution, a news source, a telemedicine service, or a data partner with a blood glucose monitoring platform corresponding to the wearable blood glucose monitoring device. In the aforementioned system, users within the user population have user profiles on the blood glucose monitoring platform.

[0016] In the aforementioned system, notifying at least one user of the existence of a disease includes: generating a heat map visually distinguishing the severity of the disease among user groups at different locations; and causing the heat map to be displayed on a display device of a computing device associated with at least one user. In the aforementioned system, notifying at least one user of the existence of a disease includes: generating an alarm with disease presence information; and causing the alarm to be output via a computing device associated with at least one user. In the aforementioned system, causing the alarm to be output includes causing the alarm to be displayed via a display device of the computing device.

[0017] On the other hand, there is one or more non-transitory computer-readable storage media having instructions stored thereon, which can be executed by one or more processors of at least one computing device to cause the at least one computing device to perform operations including: acquiring temperature measurements generated by wearable blood glucose monitoring devices worn by users of a user population; acquiring location data describing the user's location and associating the temperature measurements with the corresponding location; identifying the presence of a disease in one or more users at one or more locations based on the temperature measurements and location data; and notifying at least one user of the presence of the disease.

[0018] In the aforementioned storage medium, identifying the presence of a disease involves, in part, using one or more machine learning models to process temperature measurements and location data, generated based on historical temperature measurements of the user population and historical data describing the presence of one or more diseases within the user population. In the aforementioned storage medium, the wearable blood glucose monitoring device includes at least one continuous glucose monitoring (CGM) system. In the aforementioned storage medium, identification is also based on blood glucose measurements generated by wearable blood glucose monitoring devices worn by users within the user population.

[0019] In the aforementioned storage medium, identifying the presence of a disease includes, in part, using one or more machine learning models to process temperature measurements, blood glucose measurements, and location data, generated based on historical temperature and blood glucose measurements of a user population and historical data describing the presence of one or more diseases within that user population. In the aforementioned storage medium, the operation also includes notifying at least one third party of the presence of the disease.

[0020] In the aforementioned storage medium, the at least one third party includes at least one of the following: public health organizations, government organizations, school districts, healthcare institutions, news sources, telemedicine services, or data partners with a blood glucose monitoring platform corresponding to the wearable blood glucose monitoring device. In the aforementioned storage medium, users within the user population have user profiles on the blood glucose monitoring platform. In the aforementioned storage medium, notifying at least one user of the presence of a disease includes: generating a heatmap visually distinguishing the severity of the disease among user populations in different locations; and causing the heatmap to be displayed on a display device of a computing device associated with at least one user.

[0021] In the aforementioned storage medium, notifying at least one user of the presence of a disease includes: generating an alarm with disease presence information; and causing the alarm to be output via a computing device associated with at least one user. In the aforementioned storage medium, causing the alarm to be output includes displaying the alarm via a display device of the computing device.

[0022] On the other hand, there is an apparatus comprising: for acquiring temperature measurements generated by wearable blood glucose monitoring devices worn by users of a user population; for acquiring location data describing the user's location and associating each temperature measurement with a corresponding location; for identifying the presence of a disease in a user at one or more locations based on the temperature measurements and location data; and for notifying at least one user of the presence of the disease.

[0023] This overview presents some concepts in a simplified form, which will also be described in the detailed description below. Therefore, this summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Attached Figure Description

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

[0025] Figure 1 This is an illustration of an environment operable in an exemplary implementation of the techniques described herein.

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

[0027] Figure 3 An exemplary implementation is described, in which data collected from a wearable blood glucose monitoring device, including temperature measurements, is routed to different systems associated with population disease identification.

[0028] Figure 4 An exemplary implementation of a user interface for displaying information associated with the identification of diseases in a population is described.

[0029] Figure 5 An exemplary implementation of information displayed in association with population disease identification via a user interface is described.

[0030] Figure 6 An exemplary implementation of a user interface for displaying notifications associated with population disease identification is described.

[0031] Figure 7 An exemplary implementation of a user interface for displaying information associated with population disease identification at a selected location is described.

[0032] Figure 8 A process in an exemplary implementation is described, wherein the presence of a disease is identified in one or more users at one or more locations based on temperature measurements obtained from a wearable blood glucose monitoring device.

[0033] Figure 9 An embodiment system is shown, including various components of the embodiment apparatus, which can be implemented as any type of computing device, as referenced. Figure 1-8 The described and / or utilized implementations of the techniques described herein. Detailed Implementation

[0034] Overview

[0035] One indicator of many diseases is an elevated body temperature relative to a defined “normal” temperature (e.g., 98.6°F). However, in the real world, people don’t typically “take their temperature” until they feel unwell—they don’t usually monitor their temperature continuously in real time. By the time a patient’s temperature is actually measured, they may have been infected long enough to unknowingly expose others to the disease. In the early stages of an illness, due to the time delay between contracting the disease and feeling unwell enough to have their temperature measured, many people in a population can unknowingly become ill and expose others to the disease. At least partly because of this time delay, traditional methods of using temperature to identify disease may not be effective in preventing the spread of disease, which can have a significant impact on the population and on those at higher risk of serious adverse effects. Furthermore, several factors can affect an individual’s body temperature. For example, exercise and weather can affect an individual’s body temperature, so an individual’s temperature may correspond to a temperature that typically indicates the presence or absence of disease—even if the exercise or weather is the cause of the temperature rather than the disease. Therefore, there can be too much interference in an individual’s temperature measurement, making the temperature unsuitable for disease identification at the individual level.

[0036] To overcome these problems, wearable blood glucose monitoring devices are used to identify population diseases. Unlike traditional temperature measurement methods, wearable blood glucose monitoring devices equipped with temperature sensors can continuously (e.g., at predetermined time intervals) and in real time generate a person's temperature measurements because the device is configured to be worn continuously by the person over a period of time. By generating real-time temperature measurements, without the need for intentional temperature measurement by the person or others, the wearable blood glucose monitoring device can capture temperature changes as they occur. Assuming that a majority of the population in a geographic area can wear wearable blood glucose monitoring devices configured with temperature sensors, the wearable blood glucose monitoring devices worn by this subset can generate temperature measurements in real time, allowing temperature changes to be identified, for example, through recognition logic such as machine learning models, across the subset of measurements.

[0037] In one or more embodiments, the disease identification system acquires temperature measurements generated by wearable blood glucose monitoring devices worn by users within a user population. The disease identification system also acquires location data describing the user's location and associates each temperature measurement with a corresponding location. For example, the identification system acquires location data from the user's user profile or from location data (e.g., GPS coordinates) packaged together with temperature measurements from, for example, the user's mobile device.

[0038] Disease identification systems utilize identification logic (e.g., one or more machine learning models) to identify the presence of a disease in users at one or more locations based on temperature measurements and location data. It should be understood that the number of temperature measurements obtained for a user population is excessive for a human to process practically; for example, it may be impossible to identify meaningful patterns within those temperature measurements (e.g., an average temperature rise at one location exceeding a threshold temperature for the entire population and / or a specific location). However, the identification logic is configured to process the sheer volume and time of temperature measurements, which is practically impossible for any human.

[0039] Once the identification logic determines the presence or absence of a disease, the disease identification system can generate communications to notify at least one user of its presence. Additionally or alternatively, the disease identification system can generate communications to notify third parties, such as public health organizations, government agencies, school districts, etc. By measuring population-level temperature in real time and notifying of the disease's presence, the disease identification system can provide information about the disease's existence much earlier than traditional methods. Therefore, people can be able to take mitigation actions earlier, which can effectively avoid or at least reduce many of the disease's negative effects.

[0040] In the following discussion, an embodiment environment in which the techniques described herein may be employed is first described. Then, details and processes of exemplary implementations that may be performed in exemplary environments as well as in other environments are described. The execution of the exemplary processes is not limited to the exemplary environment, and the exemplary environment is not limited to the execution of the exemplary processes.

[0041] Example Environment

[0042] Figure 1 This is a schematic diagram of an exemplary embodiment of an environment 100, which can be used for population disease identification using the wearable blood glucose monitoring device described herein. The illustrated environment 100 includes a person 102 wearing a wearable blood glucose monitoring device 104 and a computing device 106. The illustrated environment 100 also includes other users in a user population 108 wearing the wearable blood glucose monitoring device 104 and a blood glucose monitoring platform 110. The wearable blood glucose monitoring device 104, the computing device 106, the user population 108, and the blood glucose monitoring platform 110 are communicatively connected, including via a network 112.

[0043] Alternatively or additionally, the wearable blood glucose monitoring device 104 and the computing device 106 may communicate in other ways, such as using one or more wireless communication protocols or technologies. For example, the wearable blood glucose monitoring device 104 and the computing device 106 may communicate with each other using one or more Bluetooth (e.g., Bluetooth Low Energy link), Near Field Communication (NFC), 5G, etc.

[0044] According to the described technology, a wearable blood glucose monitoring device 104 is configured to provide measurements of blood glucose levels and temperature of a person 102. The wearable blood glucose monitoring device 104 may be configured to have a blood glucose sensor, for example, which continuously detects analytes indicating blood glucose levels in the person 102 and is capable of generating blood glucose measurements. In the illustrated environment 100 and throughout the detailed description, these measurements are referred to as blood glucose measurement 114. The wearable blood glucose monitoring device 104 may also be configured to have a temperature sensor, for example, a thermocouple that continuously measures a temperature-related voltage due to the thermoelectric effect. The measured voltage can be interpreted as (e.g., the temperature of the person 102). In the illustrated environment 100 and throughout the detailed description, these measurements are referred to as temperature measurement 116.

[0045] In one or more embodiments, the wearable blood glucose monitoring device 104 is a continuous glucose monitoring (CGM) system. As used herein, the term “continuous” when used in conjunction with associated blood glucose monitoring can refer to the ability of the device to generate measurements substantially continuously, such that the device can be configured to generate blood glucose measurements 114 at time intervals (e.g., every hour, every 30 minutes, every 5 minutes, etc.), in response to establishing a communication connection with different devices (e.g., when a computing device establishes a wireless connection with the wearable blood glucose monitoring device 104 to retrieve one or more measurements), etc.

[0046] Similarly, the wearable blood glucose monitoring device 104 can be configured to generate temperature measurements 116 substantially continuously, for example, enabling the generation of temperature measurements 116 at time intervals (e.g., every 5 minutes, every minute, every 30 seconds, etc.), in response to establishing a communication connection with different devices, etc. In one or more embodiments, the rate of generation of temperature measurements 116 is more frequent than the rate of generation of blood glucose measurements 114, for example, generating temperature measurements 116 every 30 seconds and blood glucose measurements 114 every 5 minutes. Regarding Figure 2 It discusses this feature and other aspects of the configuration of the wearable blood glucose monitoring device 104 in more detail.

[0047] Additionally, the wearable blood glucose monitoring device 104 transmits blood glucose measurements 114 and temperature measurements 116 to the computing device 106 via a wireless connection or similar means. The wearable blood glucose monitoring device 104 can communicate these measurements in real time, for example, since they are generated using a blood glucose sensor and a temperature sensor. Alternatively or additionally, the wearable blood glucose monitoring device 104 can communicate blood glucose measurements 114 and temperature measurements 116 to the computing device 106 at set time intervals. For example, the wearable blood glucose monitoring device 104 can be configured to communicate blood glucose measurements 114 to the computing device 106 every five minutes (when they are generated) and temperature measurements 116 every 30 seconds (when they are generated) or once a day (as part of a "data dump" at predetermined time intervals).

[0048] Of course, without departing from the spirit or scope of the described technology, the intervals for transmitting blood glucose measurements 114 and the communication intervals with temperature measurements 116 may differ from the embodiments described above. According to the described technology, for example, based on a request from computing device 106, wearable blood glucose monitoring device 104 communicates measurements to computing device 106 on other grounds. In any case, computing device 106 may at least temporarily store the blood glucose measurements 114 and / or temperature measurements 116 of person 102 in a computer-readable storage medium of computing device 106.

[0049] Without departing from the spirit or scope of the described technology, although shown as a wearable device (e.g., a smartwatch), computing device 106 can be configured in multiple ways. For example, and not as a limitation, computing device 106 can be configured as different types of mobile devices (e.g., mobile phones or tablet devices). In one or more embodiments, computing device 106 can be configured as a dedicated device associated with blood glucose monitoring platform 110, for example, having the ability to acquire blood glucose measurement values ​​114 from wearable blood glucose monitoring device 104, perform various calculations related to blood glucose measurement values ​​114, display information related to blood glucose measurement values ​​114 and blood glucose monitoring platform 110, communicate blood glucose measurement values ​​114 to blood glucose monitoring platform 110, etc. However, unlike the embodiment where computing device 106 is configured as a mobile phone, computing device 106, when configured as a dedicated device, may not include certain functions available on mobile phones or wearable configurations, such as the ability to make phone calls, camera functions, the ability to utilize social networking applications, etc.

[0050] Additionally, according to the described technology, computing device 106 may represent more than one device. For example, in one or more cases, computing device 106 may correspond to a wearable device (e.g., a smartwatch) and a mobile phone. In this case, both devices can perform at least some of the same operations, such as receiving blood glucose measurement values ​​114 and temperature measurement values ​​116 from wearable blood glucose monitoring device 104, communicating them to blood glucose monitoring platform 110 via network 112, displaying information related to blood glucose measurement 114 and temperature measurement 116, and so on. Alternatively or additionally, different devices may have different functions that other devices do not have or that are limited by the computing instructions of a particular device.

[0051] For example, in the case where computing device 106 corresponds to a separate smartwatch and mobile phone, the smartwatch can be configured with various sensors and functions to measure various physiological markers (e.g., heart rate, respiration, blood flow rate, etc.) and activities (e.g., steps) of person 102. In this scenario, the mobile phone may not be configured to have these sensors and functions, or it may include a limited number of functions—although in other cases, the mobile phone may be able to provide the same functionality. Continuing with this particular case, the mobile phone may have functions that the smartwatch does not have, such as a camera for capturing dietary images for predicting future blood glucose levels and a amount of computing resources (e.g., battery and processing speed), which allows the mobile phone to perform calculations associated with blood glucose measurements 114 and temperature measurements 116 more efficiently. Even when the smartwatch is capable of performing such calculations, the computational instructions can limit the performance of these calculations on the mobile phone to avoid burdening both devices and to efficiently utilize available resources. In this regard, without departing from the spirit or scope of the described technology, computing device 106 can be configured in different ways and represent different numbers of devices than those discussed herein.

[0052] As described above, the computing device 106 communicates the blood glucose measurement 114 and the temperature measurement 116 to the blood glucose monitoring platform 110. In the illustrated environment 100, the blood glucose measurement 114 and the temperature measurement 116 are stored together with location data 120 in the storage device 118 of the blood glucose monitoring platform 110. The storage device 118 may represent one or more databases and other types of storage capable of storing the blood glucose measurement 114, the temperature measurement 116, and the location data 120.

[0053] Storage device 118 may also store various other data. According to the technology, for example, person 102 corresponds at least to a user of blood glucose monitoring platform 110 and may also be a user of one or more other third-party service providers. For this purpose, user 102 may be associated with a username, sometimes requiring authentication information (e.g., password or biometric data) to access blood glucose monitoring platform 110 using the username. This information, along with other information about the user, may be stored in storage device 118, including, for example, demographic information describing person 102, information about healthcare providers, payment information, prescription information, identified health indicators, user preferences, account information for other service provider systems (e.g., service providers associated with wearable devices, social networking systems, telemedicine services, etc.), and so on.

[0054] Storage device 118 also maintains data of other users in user population 108. Therefore, the blood glucose measurements 114 and temperature measurements 116 in storage device 118 include blood glucose and temperature measurements from the blood glucose sensor and temperature sensor of the wearable blood glucose monitoring device 104 worn by person 102, and also include blood glucose and temperature measurements from the blood glucose and temperature sensors of blood glucose monitoring devices worn by other users in user population 108. Similarly, the blood glucose measurements 114 and temperature measurements 116 of these other users are communicated to the blood glucose monitoring platform 110 via network 112 by their respective devices, and these other users have user profiles corresponding to the blood glucose monitoring platform 110.

[0055] In the illustrated embodiment, the blood glucose monitoring platform 110 includes a disease identification system 122. The disease identification system 122 is configured to process at least temperature measurements 116 and location data 120 to identify the presence of a disease in a user population at a location, such as identifying an outbreak of coronavirus disease in a geographic area, for example, by country, state, county, city, zip code, voting district, or school district, to name just a few. Based on the identification of a disease in the population, the disease identification system 122 can provide notifications related to the identification, such as alerts, suggestions, “heat” maps, or other information based on predictions. For example, the disease identification system 122 can provide notifications to person 102 (e.g., via computing device 106), public health organizations, etc.

[0056] Although described as part of a device independent of computing device 106, part or all of the disease identification system 122 may be implemented alternatively or additionally at computing device 106, for example, as a disease identification application. The disease identification system 122 may also use additional data, such as blood glucose measurements 114, to identify diseases in a user population at a location. Consider, for example, continuously measuring blood glucose and temperature and acquiring data describing such measurements. Figure 2 The following discussion will follow.

[0057] Figure 2 A more detailed description Figure 1 Embodiment 200 illustrates a method for implementing the wearable blood glucose monitoring device 104. Specifically, Embodiment 200 includes a top view and a corresponding side view of the wearable blood glucose monitoring device 104. It is worth noting that embodiments of the wearable blood glucose monitoring device 104 may differ from those discussed below without departing from the spirit or scope of the technology.

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

[0059] In operation, the blood glucose sensor 202, adhesive pad 212, and attachment mechanism 214 can be assembled into an application component configured for application to skin 208 for subcutaneous insertion of the blood glucose sensor 202, as shown. In this case, the transmitter 210 can be attached to the component via the attachment mechanism 214 after application to skin 208. Alternatively or additionally, the transmitter 210 can be incorporated as part of the application component, such that the blood glucose sensor 202, adhesive pad 212, attachment mechanism 214, and transmitter 210 (with temperature sensor 204 and sensor module 206) can all be applied to skin 208 in a single step. Alternatively or additionally, the temperature sensor 204 can be provided together with the blood glucose sensor 202 such that it is included in the application component, which may include the transmitter 210 in some configurations and may not include the transmitter 210 in others (e.g., the transmitter 210 may be attached to the application component after application). In one or more embodiments, the application component is applied to skin 208 using a separate sensor applicator (not shown). In one or more embodiments, the application components can be removed by peeling the adhesive pad 212 off the skin 208. It should be understood that the wearable blood glucose monitoring device 104 and its various components shown are merely one embodiment of form without departing from the spirit or scope of the described technology, and the wearable blood glucose monitoring device 104 and its components may have different form factors.

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

[0061] The blood glucose sensor 202 can be a device, molecule, and / or chemical that changes or causes a change in response to an event at least partially independent of the blood glucose sensor 202. The sensor module 206 is configured to receive indications of changes in the blood glucose sensor 202 or indications of changes caused by the blood glucose sensor 202. For example, the blood glucose sensor 202 may include a glucose oxidase that reacts with blood glucose and oxygen to form hydrogen peroxide, which may be electrochemically detected by the sensor module 206, which may include electrodes. In this embodiment, the blood glucose sensor 202 may be configured as or include a blood glucose sensor configured to detect analytes in blood or interstitial fluid that indicate blood glucose levels using one or more measurement techniques. In one or more embodiments, the blood glucose sensor 202 may also be configured to detect analytes in blood or interstitial fluid that indicate other markers (e.g., lactate levels). Additionally or alternatively, the wearable blood glucose monitoring device 104 may include additional sensors to the blood glucose sensor 202 to detect those analytes indicating other markers.

[0062] Temperature sensor 204 is configured to detect conditions that can be used to determine, for example, a temperature measurement of person 102. For example, temperature sensor 204 may be configured as a thermocouple that continuously measures a temperature-related voltage due to the thermoelectric effect. Sensor module 206 may be configured to interpret the measured voltage as (e.g., of person 102) temperature and generate a temperature measurement value 116. Alternatively or additionally, temperature sensor 204 may include or utilize first and second electrical conductors, and sensor module 206 may electrically detect potential changes across the first and second electrical conductors of temperature sensor 204. In this embodiment, sensor module 206 and temperature sensor 204 are configured as thermocouples such that a change in potential corresponds to a change in temperature, and sensor module 206 may be configured to generate a temperature measurement value 116. It should be understood that temperature sensor 204 and sensor module 206 may be configured in multiple ways to detect the temperature of person 102 and generate a temperature measurement value 116 to indicate the temperature of person 102.

[0063] In some embodiments, the sensors of sensor module 206 and wearable blood glucose monitoring device 104 are configured to detect a single analyte, such as blood glucose. In other embodiments, the sensors of sensor module 206 and wearable blood glucose monitoring device 104 are configured to detect multiple analytes, such as sodium, potassium, carbon dioxide, testosterone, lactate, insulin, and blood glucose. Alternatively or additionally, wearable blood 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 blood glucose), but also one or more environmental conditions (e.g., the temperature of person 102, the temperature of the environment in which person 102 is located). Thus, sensor module 206, blood glucose sensor 202, and temperature sensor 204 (and any additional sensors) can detect the presence of one or more analytes, the absence of one or more analytes, the temperature of person 102, and / or changes in more than one environmental condition.

[0064] In one or more embodiments, sensor module 206 may include a processor and memory (not shown). Sensor module 206, utilizing the processor, can generate a temperature measurement value 116 based on communication with temperature sensor 204, for example, indicating the above-described interpretation. Similarly, sensor module 206, utilizing the processor, can generate a blood glucose measurement value 114 based on communication with blood glucose sensor 202, for example, indicating the above-described change. Based on these communications with blood glucose sensor 202 and temperature sensor 204, sensor module 206 may also be configured to generate data streams of temperature measurement value 116 and blood glucose measurement 114. These data streams may include communicable data packets including at least one blood glucose measurement value 114 or at least one temperature measurement value 116.

[0065] As described above, sensor module 206 and the sensor can operate to generate blood glucose measurement values ​​114 and temperature measurement values ​​116 at different time intervals. For example, sensor module 206 and temperature sensor 204 can be used to generate (e.g., for person 102) temperature measurement values ​​116 at a first time interval (e.g., every 30 seconds). In contrast, sensor module 206 and blood glucose sensor 202 can be used to generate blood glucose measurement values ​​114 at a second time interval different from the first time interval, such as every 5 minutes. Of course, according to the described technology, the time intervals at which blood glucose sensor 202 and temperature sensor 204 generate blood glucose measurement values ​​114 and temperature measurement values ​​116 can be different from those discussed above. For example, blood glucose measurement values ​​114 and temperature measurement values ​​116 can be generated at the same time interval in at least one embodiment, such that there is a one-to-one relationship between blood glucose measurement values ​​114 and temperature measurement values ​​116.

[0066] In addition to being generated at different time intervals, blood glucose measurements 114 and temperature measurements 116 can also be communicated to one or more computing devices at different time intervals. For example, transmitter 210 can be configured to transmit blood glucose measurements 114 to the computing device at a first transmission interval (e.g., every 5 minutes). In one or more embodiments, the transmission interval of blood glucose measurements 114 is the same as the interval at which blood glucose measurements 114 are generated, for example, every 5 minutes. In this way, each time a separate blood glucose measurement 114 is generated, transmitter 210 can communicate that separate blood glucose measurement 114 to the computing device. Alternatively or additionally, multiple blood glucose measurements 114 can be stored in the memory of wearable blood glucose monitoring device 104, and transmitter 210 can communicate multiple blood glucose measurements 114 (or subsets thereof) to the computing device.

[0067] Regarding temperature measurements 116, transmitter 210 can be configured to communicate them to a computing device at a second transmission interval (e.g., once daily) different from the first transmission interval. For this purpose, multiple temperature measurements 116 can be stored, at least temporarily, in the memory of the wearable blood glucose monitoring device 104. Those temperature measurements 116 can be communicated by transmitter 210 to the computing device at a rate different from the rate at which these measurements are generated (e.g., every 30 seconds) (e.g., once daily). By communicating the temperature measurements 116 at a lower frequency than those measurements are generated, wearable blood glucose monitoring device 104 can conserve resources (e.g., battery life and computer processing cycles) that would otherwise be available for more frequent communication of generating and communicating the temperature measurements 116 to a computing device. Instead, transmitter 210 can communicate them substantially as blood glucose measurements 114 are generated, because a person 102 or a healthcare provider can use the blood glucose measurements 114 to make treatment decisions for a health condition (e.g., diabetes). Furthermore, such decisions may require the blood glucose measurements 114 to be timely (i.e., substantially real-time) to avoid adverse effects related to the health condition, such as abnormal blood glucose levels. Although the above discussion has discussed transmission intervals at a lower frequency than the generation frequency of temperature measurement 116, in one or more embodiments, transmitter 210 may transmit temperature measurement 116 to computing device at the same or similar rate at which these measurements are generated.

[0068] Transmitter 210 can also cause additional data, either packaged together or separate from the blood glucose measurement 114 and temperature measurement 116, to be transmitted to the computing device. For example, this additional data may include measurements of other analytes, one or more sensor identifiers (e.g., information that uniquely identifies a particular blood glucose sensor 202 from other blood glucose sensors), identifiers of other components of the wearable blood glucose monitoring device 104 (e.g., one or more antennas of transmitter 210), and sensor status indicating the state of a given sensor (e.g., describing the operational state of a given sensor).

[0069] Having considered the implementation environment and exemplary wearable blood glucose monitoring devices, we now consider discussing some implementation details of techniques for identifying population diseases using wearable blood glucose monitoring devices in a digital media environment, according to one or more embodiments.

[0070] Population disease identification

[0071] Figure 3 Example 300 of the implementation is described, in which data collected from a wearable blood glucose monitoring device, including temperature measurements, is routed to different systems related to population disease identification.

[0072] The illustrated embodiment 300 includes from Figure 1 An embodiment of a wearable blood glucose monitoring device 104 and a computing device 106 is described. The illustrated embodiment 300 also includes the disease recognition system 122 and a storage device 118 as described above, storing blood glucose measurements 114 and temperature measurements 116. In this embodiment 300, it is described that the wearable blood glucose monitoring device 104 transmits the blood glucose measurements 114 and temperature measurements 116 to the computing device 106. The wearable blood glucose monitoring device 104 can transmit the blood glucose measurements 114 and temperature measurements 116 to the computing device 106 in multiple ways.

[0073] The illustrated embodiment 300 also includes a data packet 302. Here, the data packet 302 includes temperature measurement 116 and location data 120. The location data 120 is shown in a hash to indicate that it is optional—in one or more embodiments, the location data is not communicated to the blood glucose monitoring platform 110 along with the temperature measurement 116. In the case where the location data 120 is not communicating with the temperature measurement 116, the location data 120 can simply be stored in the storage device 118 of the blood glucose monitoring platform 110, for example, as a profile of a person 102 using the blood glucose monitoring platform 110 for establishing or updating user-related input locations. This is one embodiment of how the temperature measurement 116 of person 102 is associated with location.

[0074] In one or more embodiments, location data 120 may be generated by computing device 106 and packaged together with temperature measurement 116 in data packet 302 (as shown) to describe the location of person 102, for example, when blood glucose measurement 114 is generated or when blood glucose measurement 114 is communicated to blood glucose monitoring platform 110. For example, computing device 106 may be configured with suitable hardware and processing resources to determine location using Global Positioning System (GPS) coordinates, triangulation methods involving communication with wireless access points (e.g., wireless routers or cellular phone towers), combinations of GPS and other wirelessly received data, etc. In this way, the temperature measurement 116 of person 102 at a given time may be associated with the location of person 102 or with the physical location of the computing device 106 of person 102.

[0075] Data packet 302 may include data different from or additional to the data illustrated, such as one or more of the blood glucose measurements 114, any other data generated by the wearable blood glucose monitoring device 104 and communicated to the computing device 106, and supplementary data generated by computation. Device 106 describes one or more events (e.g., in time) corresponding to one or more blood glucose measurements 114 and / or temperature measurements 116 (e.g., application usage data, device interaction data, etc.), to name just a few. In this embodiment 300, data packet 302 is described as being routed from computing device 106 to storage device 118 of blood glucose monitoring platform 110. Therefore, computing device 106 can act as an intermediary between wearable blood glucose monitoring device 104 and blood glucose monitoring platform 110, and computing device 106 can be configured, for example, as a user's mobile phone or smartwatch.

[0076] Although not described in the illustrated embodiment 300, the blood glucose monitoring platform 110 can process these data packets 302, resulting in at least some temperature measurements 116 and location data 120 (when included in data packets 302) being stored in the storage device 118. The blood glucose monitoring platform 110 can also process blood glucose measurements 114 received from the computing device 106 and result in at least some of them also being stored in the storage device 118. This data can be provided to or otherwise accessed from the storage device 118 to the disease identification system 122, for example, for identifying diseases in a user population at a particular location, as described below.

[0077] In the illustrated embodiment 300, the disease identification system 122 is described as receiving location data 120 and temperature measurement values ​​116 from a storage device 118. The disease identification system 122 is configured to use the location data 120 and temperature measurement values ​​116 to identify diseases at different locations. The illustrated embodiment 300 also describes the disease identification system 122 receiving blood glucose measurement values ​​114. However, compared to the location data 120 and temperature measurement values ​​116, the blood glucose measurement values ​​114, described as being communicated to the disease identification system 122, are shown in a hash. This indicates that in one or more embodiments, the disease identification system 122 identifies diseases in a user population at locations where there is no blood glucose measurement value 114, and in other embodiments, the disease identification system 122 does indeed use the blood glucose measurement value 114 to identify a user population at a location where a disease exists. According to the technology, the blood glucose measurement value 114, location data 120, and temperature measurement value 116 processed by the disease identification system 122 may correspond to one or more users in a user population 108, which may include person 102.

[0078] In the illustrated embodiment 300, the disease identification system 122 is described as including identification logic 304. Typically, the identification logic 304 is configured to process temperature measurements 116 and location data 120 to identify diseases in a population of users at one or more locations at a given time, such as identifying the presence of a disease (e.g., influenza, coronavirus, etc., among users located in a geographic area (e.g., county) within a certain time interval (e.g., the last day, last week, etc.). In one or more embodiments, the identification logic 304 may be configured to process blood glucose measurements 114, along with temperature measurements 116 and location data 120, to identify diseases in a population of users at one or more locations at a given time. Furthermore, the identification logic 304 can also be used for multiple locations (e.g., multiple counties) and to perform the identification multiple times. Based on this identification, the presence and / or severity of a disease (e.g., the number of disease cases or the percentage of the population with the disease) can be displayed for different geographic areas (e.g., between counties) and / or for different times (e.g., daily or weekly).

[0079] This identification also enables identification logic 304 to compare diseases across different geographic regions and / or time periods, for example, by determining one or more statistical measures related to the presence (e.g., differences) of diseases between different geographic regions or time periods. By causing the display of information corresponding to the identification, identification logic 304 enables the user to compare (e.g., visually) the presence of diseases across different geographic regions and / or time periods. For example, the presence and / or severity of diseases at two different locations within the same time period (e.g., last week) can be displayed, as at least regarding... Figure 4This will be discussed in more detail. Alternatively or additionally, the presence and / or severity of disease at a given location can be compared over different time periods, such as regarding Figure 5 This will be discussed in more detail. As mentioned above, identification logic 304 can be configured to identify diseases in various types of geographic areas according to the technology described. Although counties have been discussed above and below, identification logic 304 can, for example, alternatively or additionally identify diseases by country, state, city, zip code, voting district, and school district, to name just a few.

[0080] To identify diseases within a user population, identification logic 304 can be configured in various ways without departing from the spirit or scope of the technology. For example, identification logic 304 may include or be configured as a machine learning model or a collection of machine learning models, such as regression models (e.g., linear, multinomial, and / or logistic regression models), classifiers, neural networks, and reinforcement learning-based models, to name just a few. Alternatively or additionally, identification logic 304 may include or be configured as one or more hard-coded rules that cause identification logic 304 to process temperature measurements 116 and location data 120 (and additional data in some embodiments) to, for example, determine one or more statistical measurements relevant to disease identification. In this embodiment, identification logic 304 may then apply the aforementioned rules to one or more statistical measurements. Additionally or alternatively, identification logic 304 may be configured to detect anomalies in blood glucose measurements 114 and / or temperature measurements 116 that are relevant to location data 120. In particular, identification logic 304 may identify deviations from a determined “normal” temperature or blood glucose level at a given location. The deviations and determined normal values ​​may correspond to the average temperature or blood glucose levels of a user population at a given location. It should be understood that the identification logic 304 can be configured in other ways (e.g., based on various different algorithms and / or rules) to identify diseases in a user population at a given location within a given time period, according to the described techniques.

[0081] As described above, the identification logic 304 may include or be configured as a machine learning model in one or more embodiments. In such an embodiment, the machine learning model may be generated according to one or more algorithms—training the model to learn its internal weights (e.g., a neural network method) or learning the parameters of the model's prediction function (e.g., a regression method)—and using historical temperature measurements 116 and location data 120, such as user population 108. In embodiments that use additional data to identify diseases in the user population, such as blood glucose measurements 114, the machine learning model may also be trained using this additional data.

[0082] Along with historical temperature measurements 116 and location data 120, historical data describing the presence and / or absence of one or more diseases can also be used to generate machine learning models. For example, before generating a machine learning model, historical temperature measurements 116 and historical location data 120 can be associated with data describing the presence or absence of a disease at the corresponding location and at the corresponding time. In other words, each historical temperature measurement 116 can be matched with a corresponding location (e.g., using location data 120) and information describing the presence (or absence) of at least one disease at the corresponding location at the time corresponding to the historical temperature measurement 116. Where identification logic 304 also uses historical blood glucose measurements 114 to identify diseases, each historical temperature measurement 116 can also be matched with one or more corresponding blood glucose measurements 114.

[0083] This matching data may be referred to herein as "training data". When configured as a machine learning model, identification logic 304 can be generated through a learning or training process performed according to one or more algorithms configured to learn function parameters from the training data or train a model based on the training data. In conjunction with this training or learning process, historical temperature measurements 116 (and optionally historical blood glucose measurements 114) can correspond to the inputs of identification logic 304, and the presence or absence of disease at the corresponding location can correspond to the expected result, which can be compared with the output of identification logic 304 during the training or learning process. By using one or more learning or training algorithms mentioned above, identification logic 304 learns to substantially predict the results in the training data given the corresponding input training data. In particular, the function parameters or internal model weights of the machine learning model are automatically adjusted during training according to the learning or training algorithm employed, so that the predictions output by the model during the process are closer to the results of the training data. It should be understood that multiple learning methods related to the aforementioned techniques can be combined, including supervised methods, unsupervised methods, and reinforcement learning methods.

[0084] Furthermore, the identification logic 304 can be trained using various other contextual information related to disease identification, and thus can also receive this contextual information during operation. For example, this contextual information may include the month, day of the week, and time of day, to name a few. The identification logic 304 can use this information, for example, to notify the detection of anomalies based on expected temperature changes associated with a nominal pattern. For example, the average temperature of the entire population may be lower at night, for example, because people in the population are sleeping and their body temperature is lower during sleep. In this way, a relatively higher average temperature for the entire population at night—which may not be significantly (e.g., statistically significant) higher than the average temperature of the population during the day—can indicate the presence of disease in the population. Other embodiments of the contextual information may include the expected monthly climate for different locations. It should be understood that the identification logic 304 can be used and can also be trained using various contextual information during operation without departing from the spirit or scope of the described technology.

[0085] Once trained or learned of the parameters of the basic functions, the recognition logic 304, configured as a machine learning model, is configured to operate to identify diseases in a user population at a location. More specifically, the recognition logic 304, configured as a machine learning model, identifies a disease by, for example, generating predictions about the presence of the disease at a specific location and over a period of time based on training or learning. For this purpose, temperature measurements 116, location data 120, and optional blood glucose measurements 114 are provided as inputs to the recognition logic 304. Data describing other aspects of the user population can also be provided as inputs to the recognition logic 304.

[0086] In one or more embodiments, the disease identification system 122 preprocesses the location data 120 and temperature measurements 116 to format them so that they can be received as input to the identification logic 304. For example, the disease identification system 122 may form vectors (e.g., feature vectors) of the location data 120 and temperature measurements 116, and then provide those vectors as input to the identification logic 304. In one or more embodiments, preprocessing may include determining statistical characteristics of the location data 120 and temperature measurements 116, including, for example, average temperature, average temperature over a period of time, median temperature, number of users with temperatures above a threshold temperature, and the percentage of users in a geographic area with temperatures above a threshold temperature, to name a few. In these embodiments, the disease identification system 122 may be configured to generate input data that describes, in addition to directly describing, the determined statistical characteristics of the temperature measurements 116 and location data 120. Based on patterns learned from historical temperature measurements using the methods described above, the identification logic 304 outputs a prediction about the presence of a disease at a given location within a specific time period based on the data input. The output may also be configured as a vector (e.g., feature vector) indicating the presence of a disease.

[0087] As described above, the identification logic 304 can be alternatively or additionally configured as one or more hard-coded rules. Such rules can identify the presence or absence of a disease based on the satisfaction of one or more criteria. For example, a rule could involve a comparison with a threshold, such that if a threshold percentage of users in a geographic area have a temperature (or average temperature) exceeding a threshold temperature over a period of time, then the identification logic 304 identifies the presence of a disease in the geographic area during that time period. It should be understood that this is merely one example rule, and the identification logic can encode multiple rules to identify diseases in a user population at a location according to the described technology.

[0088] Based on data describing one or more identified diseases output by identification logic 304, disease identification system 122 can notify different entities. The illustrated embodiment 300 includes notifications 306 and 308. Notification 306 is shown as being communicated to computing device 106, and in one or more embodiments, it is associated with person 102 corresponding to a user in user population 108. Specifically, person 102 may correspond to a user in user population 108 wearing wearable blood glucose monitoring device 104 and / or having a user profile with blood glucose monitoring platform 110. Conversely, notification 308 is shown as being communicated to a third party 310. Third party 310 may correspond to various entities interested in diseases identified by disease identification system 122 in the user population. For example, rather than limiting, a third party 310 can represent public health organizations (e.g., the Centers for Disease Control and Prevention (CDC), the World Health Organization (WHO), and the National Institutes of Health (NIH)), government organizations, school districts, healthcare institutions (e.g., hospitals and doctors' offices), news sources, telehealth services, or data partners (e.g., entities that have an agreement with the blood glucose monitoring platform 110 to receive notifications of identified diseases), to name just a few.

[0089] In one or more embodiments, notifications 306, 308 include information describing a disease identified by identification logic 304 over a period of time in at least one geographic area, such as one or more previous time periods, current time intervals (e.g., today, this week, this month), and one or more time periods after identification (e.g., tomorrow, next week, next month). For this purpose, notifications 306, 308 may include at least some of the same information. Alternatively or additionally, notifications 306, 308 may include different information. For example, notification 306 may include an alert or warning for person 102. Such an alert may include instructions to recommend one or more actions for the user based on the identification of a disease at a location such as the geographic area where the user is located or a geographic area selected by the user. For example, an alert may inform the user of a disease and / or include behavioral suggestions to mitigate the risk of person 102 contracting the disease, such as washing hands more frequently than usual, avoiding close interaction with others, limiting travel to home, wearing a face mask when around others, etc. In at least one implementation, the notification 308 communicated to the third party 310 may not include an alarm with this instruction, although in at least one different implementation, the notification 308 may include some form of alarm and / or recommended behavior for alleviating the identified disease.

[0090] It should be understood that notifications 306 and 308 may include the same or different information without departing from the spirit or scope of the technology described herein. In any case, notifications 306 and 308 include information based on and / or describing at least one disease identified by identification logic 304 for a user population in at least one geographic area over a period of time. Consideration should be given to the context of the different information that may be included in notifications 306 and 308 and then displayed via computing device 106 or a computing device associated with a third party 310. Figure 4-6 The following discussion will follow.

[0091] Figure 4 Example 400 describes an implementation of a user interface for displaying information associated with the identification of diseases in a population.

[0092] The illustrated embodiment 400 includes a display device 402 that displays a user interface 404, which may be an embodiment of or based on notifications 306, 308. In this embodiment 400, the user interface 404 includes the display of a geographic region (e.g., a country) that is further subdivided into other geographic regions (e.g., counties). Furthermore, the user interface 404 includes graphic elements that visually indicate diseases identified in additional geographic regions. These visual elements are based on diseases identified by identification logic 304, as described above.

[0093] User interface 404 is an embodiment of a "heatmap" that can be generated based on diseases identified by identification logic 304 in user populations in different areas over a period of time. As a heatmap, user interface 404 is configured to display differences in the presence of disease between one location and another, for example, displaying "hot spots." Hot spots correspond to locations where the severity of the disease is identified as relatively greater than other locations. In this embodiment 400, location 406 is displayed along with graphical elements indicating a greater severity of disease than that indicated by graphical elements at different locations 408. In this way, the presence or severity of disease at two different locations can be visually indicated within the same time period. In other words, the heatmap visually distinguishes the severity of disease among user populations in different locations described on the heatmap.

[0094] In this embodiment 400, the time associated with one or more diseases in the displayed geographic area is indicated by the graphical time element 410. The graphical time element 410 may represent various time periods according to the described technology, such as a time period from January 1st of the year to a specified date, a time period from selected data (e.g., start time), a "disease" season (or the first identified disease case) to a specified date, a given date, a given weekday, a given month, a given year, etc.

[0095] Figure 5 Example 500 describes an implementation of displaying information associated with population disease identification via a user interface.

[0096] The illustrated embodiment 500 describes multiple stages of a geographic region (e.g., a country) that is divided into other geographic regions (e.g., counties), wherein the multiple stages include multiple stages of graphical elements that visually indicate diseases identified at different times in the other geographic regions. Specifically, the illustrated embodiment 500 includes a first stage 502, a second stage 504, and a third stage 506 that may correspond to a first time, a second time, and a third time, respectively. In this embodiment, the second time may be after the first time, and the third time may be after the second time.

[0097] Stages 502, 504, and 506 can be displayed via a user interface such as user interface 404, and are embodiments of or generated based on notifications 306 and 308. Each stage may correspond to a "heatmap" indicating the presence or severity of one or more diseases at different locations at a given time (e.g., at a first, second, or third time). In one or more embodiments, user interface 404 may be configured to display the different stages 502, 504, and 506 in chronological order and / or reverse chronological order, and also to animate the transitions between these stages. In this way, the system can visually indicate to the user how the presence and / or severity of one or more diseases changes over time. In this particular embodiment 500, for example, the map of the geographic area and other geographic areas in the third stage 506 includes more hotspots than the map 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 embodiment, the graph of the second stage 504 represents an intermediate increase in the presence and / or severity of diseases between the first stage 502 and the third stage 506. Generally speaking, the display of the same geographic area or a set of geographic areas at different times makes it possible to compare the presence and / or severity of disease at a given location between different times.

[0098] Figure 6 Example 600 describes an implementation of a user interface for displaying notifications associated with population disease identification.

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

[0100] In this embodiment 600, the user interface 602 also includes selectable graphical elements 608, 610, which can be selected to display more information about one or more diseases identified by the identification logic 304, i.e., maps visually indicating the presence or severity of the diseases (e.g., such as...). Figure 4 and 5(As shown) and additional information. The exemplary user interface 602 also includes a warning expiration 612. It should be understood that user interface 602 is one embodiment of an alert that can be displayed based on notification 306. Without departing from the spirit or scope of the described technology, alerts can be configured to be displayed in different ways to include different and / or additional information. Alternatively or additionally, alerts can be displayed as notifications from a mobile application, within a mobile application, received and displayed as a text message, etc.

[0101] Figure 7 Example 700 describes an implementation of a user interface for displaying information associated with population disease identification at a selected location.

[0102] The illustrated embodiment 700 includes a computing device 106 in an exemplary embodiment, wherein the user selects a location, identification logic 304 identifies whether a disease is detected at the selected location based on a temperature measurement 116, and the computing device 106 displays an indication related to the identification, such as whether a disease exists at the location or not.

[0103] For example, in the first stage 702, computing device 106 displays a user interface that allows the user to provide input to select a geographic region. The described interface instructs the user to begin typing characters of a place name or speaking the place name. In the second stage 704, computing device 106 displays suggested geographic regions that match a portion of the search query entered by the user for selecting a geographic region. Although not described in illustrated embodiment 700, the user selects a location on computing device 106, namely, San Diego, California.

[0104] At stage 706, the computing device 106 displays an indication of whether the identification logic 304 has identified a disease at the selected location. Specifically, user interface configuration 708 corresponds to the case where the identification logic 304 has indeed identified a disease at the selected geographic area (“Yes”) and / or predicts a disease risk in the area during the upcoming time period. In contrast, user interface configuration 710 corresponds to the case where the identification logic 304 has not identified a disease at the selected geographic area (“No”) and / or predicts no disease risk in the area during the upcoming time period.

[0105] Detailed embodiments of techniques for identifying diseases in populations using wearable blood glucose monitoring devices have been discussed; now, some embodiment procedures are considered to illustrate other aspects of these techniques.

[0106] Implementation process

[0107] This section describes an embodiment process for identifying diseases in a population using a wearable blood glucose monitoring device. Aspects of the process may be implemented in hardware, firmware, or software, or a combination thereof. These processes are shown as a set of boxes specifying operations performed by one or more devices, and are not necessarily limited to the order in which the operations for each box are performed. In at least some embodiments, the process is performed by a disease identification system, such as disease identification system 122 utilizing identification logic 304.

[0108] Figure 8 A process 800 in an exemplary embodiment is described, wherein the presence of a disease is identified in a user at one or more locations based on temperature measurements obtained from a wearable blood glucose monitoring device.

[0109] Temperature measurements are acquired from wearable blood glucose monitoring devices worn by users within the user population (box 802). For example, disease identification system 122 acquires temperature measurement 116 from storage device 118 of blood glucose monitoring platform 110. Temperature measurement 116 is generated by wearable blood glucose monitoring devices 104 of users within user population 108.

[0110] Location data describing a user's location is acquired, and temperature measurements are associated with the corresponding locations based on the location data (box 804). For example, disease identification system 122 acquires location data 120. In one or more embodiments, computing device 106 associated with users of user group 108 associates location data 120 with corresponding temperature measurements 116, enabling disease identification system 122 to associate the location described by location data 120 with each temperature measurement 116. Alternatively or additionally, storage device 118 maintains location data 120 as part of the user profiles of users of user group 108. Here, disease identification system 122 is able to associate the location described by location data 120 in the user profiles of users of user group 108 with each of the temperature measurements 116.

[0111] Based on temperature measurements and location data, the presence of a disease is identified in users at one or more locations (box 806). For example, identification logic 304 identifies the presence of a disease in users at one or more locations based on temperature measurement 116 and location data 120. In one or more embodiments, identification logic 304 also identifies the presence of a disease based on blood glucose measurement 114.

[0112] At least one user is notified of the presence of a disease (box 808). For example, disease identification system 122 communicates notification 306 to computing device 106 to notify person 102 of the presence of a disease identified in box 806. Notification 306 may include or otherwise enable the display of one or more user interfaces via computing device 106 to output information about the identified disease, such as... Figure 4-7 One or more user interfaces as described in the document.

[0113] In one or more embodiments, at least one third party is notified of the presence of a disease. For example, disease identification system 122 communicates notification 308 to third party 310 to notify at least one user associated with third party 310 about the disease identified in box 806. Notification 308 may include or otherwise enable the display of one or more user interfaces via a computing device to output information about the identified disease, such as... Figure 4-7 One or more user interfaces as described in the document.

[0114] Having described the process of one or more implementations, we now consider the systems and apparatus of embodiments that may be used to implement the various techniques described herein.

[0115] Implementation Examples: Systems and Apparatus

[0116] Figure 9 An embodiment system, typically located at 900, is illustrated, comprising an embodiment computing device 902, representing one or more computing systems and / or devices capable of implementing the various techniques described herein. This is illustrated by the inclusion of a disease identification system 122. Here, the disease identification system 122 is illustrated at both the computing device 902 level and the service provider level. This indicates that some aspects of the disease identification system 122 can be implemented at the computing device 902 (e.g., computing device 106), for example, in relation to a disease identification application. This also indicates that various aspects of the disease identification system 122 are implemented using one or more server-based or “cloud computing” resources. For example, the computing device 902 could be a service provider’s server, a device associated with a client (e.g., a client device), a system-on-a-chip, and / or any other suitable computing device or computing system.

[0117] The computing device 902 shown in the figure includes a processing system 904, one or more computer-readable media 906, and one or more interconnected I / O interfaces 908. Although not shown, the computing device 902 may also include a system bus or other data and command transmission system interconnecting the various components. The system bus may include any one or a combination of different bus architectures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of a plurality of bus architectures. Several other embodiments are also contemplated, such as control lines and data lines.

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

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

[0120] Input / output interface 908 represents a function that allows a user to input commands and information to computing device 902 and also allows information to be displayed to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, cursor control device (e.g., mouse), microphone, scanner, touch functionality (e.g., capacitive or other sensors configured to detect physical touch), camera (e.g., capable of recognizing gestures as non-touch gestures using visible or invisible wavelengths such as infrared frequencies), and so on. Examples of output devices include display devices (e.g., monitors or projectors), speakers, printers, network interface cards, haptic response devices, and so on. Therefore, computing device 902 can be configured to support user interaction in several ways, as further described below.

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

[0122] Implementations of the described modules and techniques may be stored on or transmitted via a computer-readable medium of some form. The computer-readable medium may include a plurality of media accessible by the computing device 902. For example, and not as a limitation, the computer-readable medium may include a “computer-readable storage medium” and a “computer-readable signal medium.”

[0123] "Computer-readable storage medium" can refer to a medium and / or device that enables persistent and / or non-transitory storage of information, compared to simple signal transmission, carrier waves, or signals themselves. Therefore, 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 employing methods or techniques suitable for storing information thereon, such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Embodiments of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital universal disk (DVD) or other optical storage, hard disk, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or other storage devices, tangible media, or articles of art suitable for storing desired information and accessible by a computer.

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

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

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

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

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

[0129] Platform 916 can extract resources and functions to connect computing device 902 to other computing devices. Platform 916 can also be used to extract resource scaling to provide an appropriate level of scaling to any demand on resource 918 implemented via platform 916. Therefore, in the interconnect device implementation, the implementation of the functions described herein can be distributed throughout system 900. For example, the function can be implemented partially on computing device 902 or through platform 916, which extracts functions from cloud 914.

[0130] in conclusion

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

Claims

1. A system comprising: At least one processor; as well as A memory storing instructions executable by the at least one processor to perform operations, including: Acquire blood glucose measurements from multiple wearable continuous glucose monitoring (CGM) systems worn by multiple users; Acquire temperature measurements generated by temperature sensors from multiple wearable CGM systems worn by the multiple users; Acquire location data describing the locations of the multiple users and associate each temperature and blood glucose measurement with the corresponding location; Detect anomalies related to location data in the blood glucose and temperature measurements of the multiple users; Based on the detected anomalies, the temperature measurements, the location data, and the blood glucose measurements, the severity of the infectious disease in a user population of multiple users at one or more locations is identified; and Notifications regarding the severity of the infection at one or more locations are transmitted to the computing device associated with at least one of the plurality of users.

2. The system according to claim 1, wherein the operation further includes: Selection of receiving location; Based on the obtained temperature measurements and location data, identify whether the infectious disease has been detected at the selected location; as well as In response to the identification, an indication is provided as to whether the infectious disease has been detected at the selected location.

3. The system according to claim 1, wherein, The location data includes Global Positioning System (GPS) data generated by multiple computing devices associated with the multiple users.

4. The system according to claim 1, wherein, The location data includes stored profile data associated with the plurality of users.

5. The system of claim 1, wherein the identification is further based on historical temperature and blood glucose measurements of the user population, and historical data describing the severity of one or more infectious diseases in the user population.

6. The system according to claim 1, wherein, The operation also includes notifying at least one third party of the severity of the infection.

7. The system according to claim 6, wherein, The at least one third party includes at least one of the following: public health organizations, government organizations, school districts, healthcare institutions, news sources, telemedicine services, or data partners with blood glucose monitoring platforms corresponding to the plurality of wearable CGM systems.

8. The system according to claim 1, wherein, The multiple users have user profiles on the blood glucose monitoring platform.

9. The system according to claim 1, wherein, The transmission of notifications regarding the severity of the infection includes: Generate a heatmap that visually distinguishes the severity of the disease among user groups in different locations; and The heat map is displayed on the display device of the computing device associated with the at least one user.

10. The system according to claim 1, wherein, The transmission of notifications regarding the severity of the infection includes: Generate an alert containing information about the severity of the infection; and The alarm is output by the computing device associated with the at least one user.

11. The system according to claim 10, wherein, Outputting the alarm includes displaying the alarm via a display device of the computing device.

12. One or more non-transitory computer-readable storage media having instructions stored thereon, executable by one or more processors of at least one computing device to cause said at least one computing device to perform the following operations: Acquire blood glucose measurements from multiple wearable continuous glucose monitoring (CGM) systems worn by multiple users; Acquire temperature measurements generated by the temperature sensors of the wearable CGM system worn by the multiple users; Acquire location data describing the locations of the multiple users and associate each temperature and blood glucose measurement with the corresponding location; Detect anomalies related to location data in the blood glucose and temperature measurements of the multiple users; Based on the detected anomalies, the temperature measurements, the location data, and the blood glucose measurements, the severity of the disease infection in a user population of multiple users at one or more locations is identified; as well as The notification regarding the severity of the infection at one or more locations is transmitted to the computing device associated with at least one of the multiple users.

13. The computer-readable storage medium of claim 12, wherein the operation further comprises: Selection of receiving location; Based on the obtained temperature measurements and location data, identify whether the infectious disease has been detected at the selected location; as well as In response to the identification, an indication is provided as to whether the infectious disease has been detected at the selected location.

14. The computer-readable storage medium of claim 12, wherein, The location data includes Global Positioning System (GPS) data generated by multiple computing devices associated with the multiple users.

15. One or more computer-readable storage media according to claim 12, wherein, The location data includes stored profile data associated with the plurality of users.

16. The one or more computer-readable storage media according to claim 12, wherein, The identification is also based on historical temperature and blood glucose measurements of the user population, as well as historical data describing the severity of one or more infectious diseases present in the user population.

17. One or more computer-readable storage media according to claim 12, wherein, The operation also includes notifying at least one third party of the severity of the infection.

18. One or more computer-readable storage media according to claim 17, wherein, The at least one third party includes at least one of the following: public health organizations, government organizations, school districts, healthcare institutions, news sources, telemedicine services, or data partners with blood glucose monitoring platforms corresponding to the plurality of wearable CGM systems.

19. One or more computer-readable storage media according to claim 12, wherein, The multiple users have user profiles on the blood glucose monitoring platform.

20. One or more computer-readable storage media according to claim 12, wherein, The transmission of notifications regarding the severity of the infection includes: Generate a heatmap that visually distinguishes the severity of the disease among user groups in different locations; and The heat map is displayed on the display device of the computing device associated with the at least one user.

21. One or more computer-readable storage media according to claim 12, wherein, The transmission of notifications regarding the severity of the infection includes: Generate an alert containing information about the severity of the infection; and The alarm is output by the computing device associated with the at least one user.

22. The one or more computer-readable storage media according to claim 21, wherein, Outputting the alarm includes displaying the alarm via a display device of the computing device.

23. An apparatus comprising: A device for acquiring blood glucose measurements from multiple wearable continuous glucose monitoring (CGM) systems worn by multiple users; A means for acquiring temperature measurements generated by temperature sensors of multiple wearable CGM systems worn by the multiple users; A means for acquiring location data describing the locations of the plurality of users and associating each of the temperature and blood glucose measurements with the corresponding location; A device for detecting location-related anomalies in the blood glucose and temperature measurements of the multiple users; A device for identifying the severity of disease infection in a user population of said multiple users at one or more locations based on detected anomalies, said temperature measurements, said location data and said blood glucose measurements; as well as A means for transmitting notifications about the severity of the infection at one or more locations to a computing device associated with at least one of the plurality of users.

Images