Illness detection based on temperature data

Abstract

To provide a method, system, and device for illness detection.SOLUTION: A method may include identifying baseline temperature data associated with a user on the basis of temperature data collected from the user via a wearable device throughout a first time interval. The method may include receiving additional temperature data collected via the wearable device throughout a second time interval, and inputting the baseline temperature data and the additional temperature data into a classifier. The method may include identifying a satisfaction of deviation criteria between the baseline temperature data and the additional temperature data, and causing a graphical user interface (GUI) of a user device to display an illness risk metric for the user on the basis of the satisfaction of the deviation criteria, the illness risk metric associated with a relative probability that the user will transition from a healthy state to an unhealthy state.SELECTED DRAWING: Figure 16

Description

[Technical field]

[0001] [Cross reference] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 043,892, filed June 25, 2020, by RAI et al., entitled "DETECTING TRANSITIONS BETWEEN HEALTHY AND UNHEALTHY STATES," U.S. Provisional Patent Application No. 63 / 049,405, filed July 8, 2020, by Aschbacher et al., entitled "DETECTING TRANSITIONS BETWEEN HEALTHY AND UNHEALTHY STATES," and U.S. Provisional Patent Application No. 63 / 116,981, filed June 24, 2021, by RAI et al., entitled "DETECTING TRANSITIONS BETWEEN HEALTHY AND UNHEALTHY STATES." This application claims the benefit of U.S. Nonprovisional Patent Application No. 17 / 357,922 by PHO et al., entitled "METHOD WITH HYDROXY-BASED DATA," each of which is expressly incorporated herein by reference.

[0002] [Technical field to which the invention pertains] The following relates to wearable devices and data processing, including disease detection based on temperature data. [Background technology]

[0003] Some wearable devices may be configured to collect physiological data from the user, including temperature data, heart rate data, etc. Many users desire more insight into their physical health. [Brief description of the drawings]

[0004] [Figure 1] 1 illustrates an example of a system that supports disease detection techniques according to aspects of the present disclosure. [Diagram 2]1 illustrates an example of a system that supports disease detection based on temperature data, according to an aspect of the present disclosure. [Diagram 3] 1 illustrates an example of a neural tree supporting disease detection techniques in accordance with aspects of the present disclosure. [Figure 4] 1 illustrates an example of a neural tree supporting disease detection techniques in accordance with aspects of the present disclosure. [Diagram 5] 1 illustrates an example of a neural tree supporting disease detection techniques in accordance with aspects of the present disclosure. [Figure 6] 1 illustrates an example of a temperature data diagram supporting a disease detection technique according to an aspect of the present disclosure. [Figure 7] 1 illustrates an example of a temperature data diagram supporting a disease detection technique according to an aspect of the present disclosure. [Figure 8] 1 illustrates an example of a modifiable behavioral predictor diagram supporting illness detection techniques, according to aspects of the present disclosure. [Figure 9] 1 illustrates an example of a modifiable behavioral predictor diagram supporting illness detection techniques, according to aspects of the present disclosure. [Figure 10] 1 illustrates an example of a modifiable behavioral predictor diagram supporting illness detection techniques, according to aspects of the present disclosure. [Figure 11] 1 illustrates an example of a menstrual cycle model that supports disease detection techniques, according to aspects of the present disclosure. [Figure 12] 1 illustrates an example of a health management platform that supports disease detection techniques in accordance with aspects of the present disclosure. [Figure 13] 1 illustrates a block diagram of an apparatus supporting disease detection techniques according to an aspect of the present disclosure. [Figure 14] FIG. 1 illustrates a block diagram of a wearable application supporting disease detection techniques in accordance with an aspect of the present disclosure. [Figure 15] 1 illustrates a diagram of a system including a device supporting disease detection techniques, according to an aspect of the present disclosure. [Figure 16] 1 shows a flowchart illustrating a method for supporting disease detection techniques according to an aspect of the present disclosure. [Figure 17]1 shows a flowchart illustrating a method for supporting disease detection techniques according to an aspect of the present disclosure. [Figure 18] 1 shows a flowchart illustrating a method for supporting disease detection techniques according to an aspect of the present disclosure. [Figure 19] 1 shows a flowchart illustrating a method for supporting disease detection techniques according to an aspect of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] Some wearable devices may be configured to collect physiological data from a user, including temperature data, heart rate data, etc. The acquired physiological data may be used to analyze the user's movements and other activities, such as sleep patterns. Many users would like more insight into their physical health, including their sleep patterns, activities, and overall physical health.

[0006] Aspects of the present disclosure are directed to techniques for detecting and predicting illness. In particular, a computing device of the present disclosure may detect a user's transition from a healthy state to an unhealthy state. For example, aspects of the present disclosure may detect a transition from a healthy state to an unhealthy state at an early stage (e.g., before the onset of symptoms) and notify the user of a potential transition before the onset of symptoms and / or worsening of symptoms associated with the upcoming unhealthy state. From the user's perspective, early detection (e.g., detection of illness before the onset of symptoms) may appear as a prediction of the user's transition from a healthy state to an unhealthy state, or in other words, may indicate that the user is experiencing an immunological response. Thus, aspects of the present disclosure may detect and / or predict the onset of the user's unhealthy state. In some implementations, the computing device may also detect / predict the user's transition from an unhealthy state to a healthy state.

[0007] For purposes of this disclosure, the term "health condition" and similar terms may be used to refer to a user's physical state (e.g., a normal state) in the absence of symptoms of disease and / or a specific diagnosis. Conversely, the term "ill health condition" and similar terms may be used herein to refer to a user's physical state when the user is experiencing illness. For example, a user may be in an ill health condition when experiencing disease symptoms such as fever, chills, sore throat, headache, and other symptoms. Exemplary illnesses that may cause an ill health condition include, but are not limited to, influenza A / B and bacterial or viral infections such as COVID-19.

[0008] A transition from a healthy state to an unhealthy state may refer to a transition from a state that the user perceives as healthy to a state that the user perceives as unhealthy, whereby those subjective symptoms may reflect the presence of an underlying disease, infection, condition, or diagnosis. For example, a transition from a healthy state to an unhealthy state may include the onset of symptoms such as fever and / or other conditions (e.g., reduced physical capacity). Conversely, a transition from an unhealthy state to a healthy state may include the reduction, remission, or resolution of symptoms.

[0009] In some implementations, the healthy and unhealthy states may be referred to as pre-symptomatic and symptomatic states, respectively. For example, in a healthy state, the user may not be experiencing symptoms (e.g., symptoms of disease or infection). The user may not be experiencing symptoms (e.g., symptoms of disease / infection), but may be in a scenario where the user is transitioning to a state where symptoms may be experienced. For example, the user may be infectious during periods when they are not experiencing symptoms. In other words, the user may be experiencing a disease / infection but not yet experiencing symptoms (e.g., feeling healthy). The pre-symptomatic period may also be the time when an individual is most likely to spread the disease. Therefore, it is desirable to detect the disease during the pre-symptomatic state to allow for intervention to stop the spread of the disease.

[0010] After a period of time (e.g., an incubation period), the user may transition to a diseased state (e.g., an unhealthy state). The user may transition from a pre-symptomatic state to a diseased state, but in some cases, the user may not develop symptoms. Some aspects of the present disclosure are directed to detection of disease during the pre-symptomatic stage (e.g., before the user experiences symptoms of the disease). However, the techniques described herein may also be used to detect disease when the user does not develop symptoms or is unaware of their symptoms.

[0011] Thus, some techniques of the present disclosure may be used to identify illnesses at a pre-symptomatic stage based on physiological data (e.g., measured physiological data) collected from a user via a wearable device. Exemplary physiological parameters may include, but are not limited to, neural information (e.g., heart rate data, heart rate variability (HRV) data), temperature data, respiratory rate data, movement / activity data (e.g., actigraphy-based data related to sleep and movement), and the like. For example, in some cases, the techniques described herein may utilize changes in HRV data and other neural parameters to identify illnesses. In other cases, the techniques described herein may utilize changes in a user's temperature data (e.g., changes in high / low temperature readings during the day) in conjunction with the user's location to identify illnesses. In additional or alternative implementations, the techniques described herein may utilize data related to modifiable behavioral predictors (e.g., physical activity, sleep) to identify illnesses. In some aspects, the techniques described herein may utilize models (e.g., menstrual cycle models, weekly pattern adjustment models, annual pattern adjustment models, seasonal pattern adjustment models) to account for cyclical and predictable changes in a user's movements, activities, and physiological responses to improve prediction of disease onset.

[0012] In some aspects, the techniques described herein may detect illness using physiological data collected over multiple different time intervals (e.g., reference window, prediction window). Comparison of physiological data collected over the respective time intervals may be used to identify the fulfillment of deviation criteria, and the fulfillment of one or more deviation criteria may be used to identify possible illness. For example, the techniques described herein may determine a user's physiological parameter values ​​over a first time interval (e.g., reference window) while the user is in a healthy state to determine the user's ambulatory baseline parameters (e.g., baseline temperature data, baseline HRV data). The techniques described herein may further compare physiological data collected over a second subsequent time interval (e.g., prediction window) to the baseline parameters to determine a deviation from the baseline parameters, and this deviation (e.g., fulfillment of deviation criteria) may be indicative of illness.

[0013] In additional or alternative implementations, the systems described herein may determine personalized or group-derived "baseline" physiological parameter values ​​(e.g., within a reference window) for a user of a healthy state. The system may then detect / predict a transition to an unhealthy state based on these moving baseline physiological parameter values ​​and / or one or more deviations from a distribution of baseline physiological parameter values ​​(e.g., deviations that fall within one or more subsequent early detection / prediction windows).

[0014] In some implementations, to detect transitions from a healthy state to an unhealthy state, the systems and methods of the present disclosure may utilize one or more classifiers (e.g., machine learning classifiers, algorithms, etc.). For example, in some implementations, the systems and methods of the present disclosure may employ change-point or anomaly detection strategies in multivariate space utilizing Bayesian-inspired semi-supervised methodologies for performance evaluation. Hierarchical or mixture modeling techniques may be utilized to provide group-specific model parameters, thereby providing higher algorithm accuracy for specific user segments. In other implementations, to detect transitions back to a healthy state (e.g., recovery from COVID-19 or other illnesses), the systems and methods of the present disclosure may detect a return from a deviant parameter value to a previous baseline parameter value / range.

[0015] The techniques described herein may notify the user of a detected / predicted transition from a healthy state to an unhealthy state in various ways. For example, the system may cause a graphical user interface (GUI) of the user device to display a message or other notification to inform the user of the likelihood of a potential transition to an unhealthy state (e.g., illness risk metrics, illness prediction metrics) and provide recommendations to the user. In one example, the GUI may display a recommendation that the user prepare for the potential illness by resting, staying hydrated, and / or scheduling a doctor's appointment. The GUI may also include graphics / text that indicate the data used to make the detection / prediction of the upcoming unhealthy state. For example, the GUI may indicate that an upcoming illness has been predicted based on temperature deviation from a normal baseline. Based on the early warning (e.g., before noticeable symptoms), the user may take early steps that may help reduce the severity of the upcoming illness. Additionally, the user may modify / schedule daily activities (e.g., work hours and leisure time) based on the early warning.

[0016] In some implementations, the computing device may notify administrators (e.g., organizational administrators, or medical professionals overseeing patient cohorts) assigned to monitor groups of individuals to provide risk estimates or to assist in identifying individuals most likely to require follow-up action for further testing or screening on the part of the organization. Such devices may present model results as a tool to improve selection of subgroups of individuals to whom additional care should be provided, or to otherwise adopt safety protocols. In such situations, disease detection metrics and other disease scores are not definitive, absolute, or diagnostic, but are intended to assist the enterprise in a preliminary assessment of risk, screening, or resource allocation, and may be intended to be used in conjunction with additional tools for confirmatory diagnosis.

[0017] Aspects of the present disclosure are first described in the context of a system that supports collection of physiological data from a user via a wearable device. Additional aspects of the present disclosure are described in the context of an exemplary neurological diagram, a temperature data diagram, a modifiable behavioral predictor diagram, an exemplary menstrual cycle model, and an exemplary health management platform. Aspects of the present disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flow charts related to disease detection techniques.

[0018] 1 illustrates an example of a system 100 supporting disease detection techniques according to aspects of the present disclosure. The system 100 includes multiple electronic devices (e.g., wearable devices 104, user devices 106) that may be worn and / or operated by one or more users 102. The system 100 further includes a network 108 and one or more servers 110.

[0019] The electronic devices may include any electronic devices known in the art, including wearable devices 104 (e.g., ring-type wearable devices, wristwatch-type wearable devices, etc.), user devices 106 (e.g., smartphones, laptops, tablets). The electronic devices associated with each user 102 may include one or more of the following functionalities: 1) measuring physiological data, 2) storing the measured data, 3) processing data, 4) providing output to the user 102 (e.g., via a GUI) based on the processed data, 5) communicating data with each other and / or with other computing devices. Different electronic devices may perform one or more of the functionalities.

[0020] Exemplary wearable devices 104 may include wearable computing devices such as a ring-type computing device (hereinafter, "ring") configured to be worn on a finger of the user 102, a wrist computing device (e.g., a smart watch, fitness band, or bracelet) configured to be worn on the wrist of the user 102, and / or a head-mounted computing device (e.g., glasses / goggles). The wearable devices 104 may also include bands, straps (e.g., flexible or inflexible bands or straps), stick-on sensors, etc., which may be positioned in other locations such as head-wrapped bands (e.g., forearm bands and / or bicep bands), and / or leg-wrapped bands (e.g., thigh or calf bands), behind-the-ear bands, underarm bands, etc. The wearable devices 104 may also be attached to or included in an article of clothing. For example, the wearable devices 104 may be included in a pocket and / or pouch of a garment. As another example, the wearable device 104 may be clipped and / or pinned to clothing or otherwise maintained within proximity of the user 102. Examples of clothing items may include, but are not limited to, hats, shirts, gloves, pants, socks, outerwear (e.g., jackets), and underwear. In some implementations, the wearable device 104 may be included with other types of devices, such as training / sports devices used during physical activity. For example, the wearable device 104 may be attached to or included with a bicycle, skis, a tennis racket, a golf club, and / or training weights.

[0021] Much of the present disclosure may be described in the context of a ring-type wearable device 104. Thus, the terms "ring 104," "wearable device 104," and similar terms may be used interchangeably, unless otherwise noted herein. However, use of the term "ring 104" should not be considered limiting, as it is contemplated herein that aspects of the present disclosure may be implemented using other wearable devices (e.g., watch-type wearable devices, necklace-type wearable devices, bracelet-type wearable devices, earring-type wearable devices, anklet-type wearable devices, etc.).

[0022] In some aspects, the user devices 106 may include handheld mobile computing devices such as smartphones and tablet computing devices. The user devices 106 may also include personal computers such as laptops and desktop computing devices. Other exemplary user devices 106 may include server computing devices that may communicate with other electronic devices (e.g., via the Internet). In some implementations, the computing devices may include medical devices such as external wearable computing devices (e.g., Holter monitors). The medical devices may also include implantable medical devices such as pacemakers and defibrillators. Other exemplary user devices 106 may include home computing devices such as Internet of Things (IoT) devices (e.g., IoT devices), smart TVs, smart speakers, smart displays (e.g., video calling displays), hubs (e.g., wireless communication hubs), security systems, smart appliances (e.g., thermostats and refrigerators), and fitness equipment.

[0023] Some electronic devices (e.g., wearable device 104, user device 106) may measure physiological parameters of the respective user 102, such as photoplethysmography waveform, continuous skin temperature, pulse waveform, respiration rate, heart rate, heart rate variability (HRV), actigraphy, galvanic skin response, pulse oximetry, and / or other physiological parameters. Some electronic devices that measure physiological parameters may also perform some / all of the calculations described herein. Some electronic devices may not measure physiological parameters and perform some / all of the calculations described herein. For example, a ring (e.g., wearable device 104), a mobile device application, or a server computing device may process received physiological data measured by other devices.

[0024] In some implementations, the user 102 may operate or be associated with multiple electronic devices, some of which may measure physiological parameters and some of which may process the measured physiological parameters. In some implementations, the user 102 may have a ring (e.g., wearable device 104) that measures physiological parameters. The user 102 may also have or be associated with a user device 106 (e.g., a mobile device, smartphone), where the wearable device 104 and the user device 106 are communicatively coupled to each other. In some cases, the user device 106 may receive data from the wearable device 104 and perform some / all of the calculations described herein. In some implementations, the user device 106 may also measure physiological parameters described herein, such as movement / activity parameters.

[0025] For example, as shown in FIG. 1, a first user 102-a (user 1) may operate or be associated with a wearable device 104-a (e.g., ring 104-a) and a user device 106-a, which may operate as described herein. In this example, the user device 106-a associated with the user 102-a may process / store physiological parameters measured by the ring 104-a. In contrast, a second user 102-b (user 2) may be associated with a ring 104-b, a wristwatch-type wearable device 104-c (e.g., watch 104-c), and a user device 106-b, and the user device 106-b associated with the user 102-b may process / store physiological parameters measured by the ring 104-b and / or watch 104-c. Additionally, an nth user 102-n (user N) may be associated with the electronic devices described herein (e.g., ring 104-n, arrangement of user devices 106-n). In some aspects, the wearable devices 104 (e.g., ring 104, watch 104) and other electronic devices may be communicatively coupled to the user devices 106 of the respective user 102 via Bluetooth, Wi-Fi, and other wireless protocols.

[0026] The electronic devices (e.g., user device 106, wearable device 104) of the system 100 may be communicatively coupled to one or more servers 110 via wired or wireless communication protocols. For example, as shown in FIG. 1, the electronic devices (e.g., user device 106) may be communicatively coupled to one or more servers 110 via a network 108. The network 108 may implement a Transport Control Protocol and Internet Protocol (TCP / IP), such as the Internet, or may implement other network 108 protocols. The network connection between the network 108 and the respective electronic devices may facilitate the transport of data via e-mail, web, text message, mail, or any other suitable form of interaction with the computer network 108. For example, in some implementations, a ring 104-a associated with a first user 102-a may be communicatively coupled to a user device 106-a, which is communicatively coupled to the server 110 via the network 108. Additionally or alternatively, the wearable device 104 (e.g., ring 104, watch 104) may be communicatively coupled directly to the network 108.

[0027] The system 100 may provide on-demand database services between the user device 106 and one or more servers 110. In some cases, the servers 110 may receive data from the user device 106 over the network 108 and store and analyze the data. Similarly, the servers 110 may provide data to the user device 106 over the network 108. In some cases, the servers 110 may be located in one or more data centers. The servers 110 may be used for data storage, management, and processing. In some implementations, the servers 110 may provide a web-based interface to the user device 106 via a web browser.

[0028] In some aspects, the system 100 may support techniques for automatic sleep stage classification based on data collected by a wearable device. In particular, the system 100 detects periods during which the user 102 is asleep and classifies the periods during which the user 102 is asleep into one or more sleep stages. For example, as shown in FIG. 1, the user 102-a may be associated with a wearable device 104-a (e.g., a ring 104-a) and a user device 106-a. In this example, the ring 104-a may collect physiological data related to the user 102-a, including temperature, heart rate, HRV, respiration rate, etc. In some aspects, the data collected by the ring 104-a may be input to a machine learning classifier, which is configured to determine periods during which the user 102-a is asleep (or was asleep). Furthermore, the machine learning classifier may be configured to classify periods into different sleep stages, including a wakefulness sleep stage, a rapid eye movement (REM) sleep stage, a light sleep stage (non-rapid eye movement (NREM)), and a deep sleep stage (NREM).

[0029] In some aspects, the classified sleep stages may be displayed to the user 102-a via a GUI of the user device 106-a. In particular, the GUI may display time intervals during which the user 102-a is asleep, with segments of the time intervals labeled or otherwise indicated with corresponding sleep stages. In some implementations, the sleep stage classification techniques described herein may be used to provide the user 102-a with feedback regarding the user's sleep patterns, such as a recommended bedtime, a recommended wake-up time, etc. Additionally, in some implementations, the sleep stage classification techniques described herein may be used to calculate a score for each user, such as a sleep score, a readiness score, etc.

[0030] In some aspects, the system 100 may utilize circadian rhythm derived features to further improve physiological data collection, illness detection, and other techniques described herein. The term circadian rhythm may refer to a natural internal process that regulates an individual's sleep-wake cycle, which repeats approximately every 24 hours. In this regard, the techniques described herein may utilize a circadian rhythm adjustment model to improve sleep stage classification. For example, the circadian rhythm adjustment model may be input to a machine learning classifier along with physiological data collected from the user 102-a via the wearable device 104-a. In this example, the circadian rhythm adjustment model may be configured to "weight" or adjust the physiological data collected throughout the user's sleep to provide a more accurate sleep stage classification. In some implementations, the system may initially start with a "baseline" circadian rhythm adjustment model and may use physiological data collected from each user 102 to modify the baseline model and generate an adjusted individual circadian rhythm adjustment model specific to each respective user 102.

[0031] In some embodiments, the system 100 may utilize other biological rhythms to further improve the comparison of data with the phases of these other rhythms. For example, if a weekly rhythm is detected in the individual's baseline data, the model may be configured to adjust the "weight" of the data by day of the week. Biological rhythms that may require adjustment of the model in this manner include: 1) ultradian (rhythms faster than daily, including sleep cycles during sleep states and oscillations in the measured physiological variable with periodicity of less than an hour to several hours during wakefulness), 2) circadian rhythms, 3) non-endogenous diurnal rhythms that have been shown to be imposed on top of circadian rhythms, such as work schedules, 4) weekly rhythms or other exogenously imposed artificial time periodicities (e.g., a hypothetical culture with a 12-day "week" might use a 12-day rhythm), 5) daily ovarian rhythms in women and spermatogenic rhythms in men, 6) lunar rhythms (relevant to individuals living with low or no artificial light, 7) seasonal rhythms.

[0032] Biological rhythms are not necessarily stationary rhythms. For example, many women experience variability in ovarian cycle length from cycle to cycle, and ultradian rhythms are not thought to occur at exactly the same time or with exactly the same periodicity across days, even within an individual. Therefore, signal processing techniques sufficient to quantify the frequency composition of these rhythms while maintaining the time resolution in physiological data may be used to improve the detection of these rhythms and assign the phase of each rhythm to each moment of measured time, thereby modifying the adjustment model and comparison of time intervals.

[0033] The biological rhythms described are not always identical across physiological modalities. For example, after a move across time zones, alignment of some rhythms to the new time zone may occur more quickly than for other rhythms or variables (e.g., ultradian rhythms may recover more quickly than circadian rhythms, or heart rate may regain its normal rhythmic properties more quickly than respiratory rate). Loss of similarly stable relationships is a common feature of illness. Therefore, the classification of "healthy" and "unhealthy" time intervals may be further refined by including rhythm parameters such as amplitude and instantaneous frequency per variable, and by including parameters that describe rhythmic relationships between variables (as in the case of alignment of ultradian rhythms of temperature to ultradian rhythms of heart rate, co-information, coherence, etc.). The resulting relationship parameters must be generated in such a way that they maintain sufficient temporal resolution for the models to be compared.

[0034] Biorhythm adjustment models and parameters can be added in linear or non-linear combinations as needed to more accurately capture the dynamic baseline of an individual or group of individuals. The weights and models can then be used as features to improve the accuracy of the comparison between "healthy" and "unhealthy" time intervals. For example, to detect / predict illness, the user's temperature data through the user's natural circadian rhythm (e.g., "temperature rhythm") can be compared with other physiological parameters evaluated in relation to circadian rhythm (e.g., HRV rhythm, respiratory rate rhythm).

[0035] In some aspects, each device of the system 100 may support techniques for identifying the onset of illness. An embodiment of the system 100 may support techniques for identifying illness during a presymptomatic stage (e.g., illness detection before the onset of symptoms). In particular, the system 100 shown in FIG. 1 may support techniques for using a classifier (e.g., a machine learning classifier) ​​to identify the likelihood that a user will transition from a healthy state to an unhealthy state based on physiological data collected from the user. In some implementations, the techniques described herein may compare physiological data (and rhythm parameters thereof) collected over different time intervals (e.g., a first / reference time interval, a second / prediction time interval) to identify the fulfillment of deviation criteria, and the fulfillment of one or more deviation criteria may be used to predict an illness risk metric (e.g., a "risk score"), an illness prediction metric, an illness severity metric, an illness recovery metric, etc.

[0036] For example, as shown in FIG. 1, a user 102-a may be associated with a wearable device 104-a (e.g., ring 104-a) and a user device 106-a. In this example, the ring 104-a may collect physiological data related to the user 102-a, including temperature, heart rate, HRV, respiration rate, etc. In some aspects, the data collected by the ring 104-a is input to a classifier, which is configured to determine a disease risk metric (or other metric) related to the likelihood or probability that the user will transition from a healthy state to an unhealthy state. In some aspects, the data input to the classifier may be processed to determine rhythm parameters across biorhythms and physiological data types (e.g., ultradian and circadian rhythms in the relationship between temperature, heart rate, and those rhythms), and the resulting parameters are also input to the classifier. In some aspects, the classifier may be based on a non-machine learning, but other artificial intelligence techniques, or an empirically derived linear discriminator that does not rely on artificial intelligence or machine learning.

[0037] The system 100 may be configured to cause the user device 106-a to display an indication of the illness risk metric so that the user 102-a can take preventative measures and / or adjust sleep or activity routines to prevent illness, reduce the severity of the illness, reduce the duration of the illness, prevent the spread of the illness, or any combination thereof.

[0038] In some cases, system 100 may utilize nervous system metrics (e.g., metrics indicative of sympathetic / parasympathetic activity) to identify illness. For example, system 100 may compare HRV data collected over different time intervals (e.g., reference windows, prediction windows) to identify satisfaction of deviation criteria, which indicates an onset of illness. For example, changes in high frequency content of HRV data over time relative to changes in low frequency content of HRV data over time may be used to identify an onset of illness.

[0039] Additionally or alternatively, the system 100 may utilize temperature data to identify the onset of illness. In particular, the system 100 may utilize temperature data in conjunction with the geographic location of the user to determine the onset of illness. For example, a change in high and / or low temperature readings during the day of a first user 102 living in a colder climate (e.g., Finland) may be more indicative of illness compared to a change in high and / or low temperature readings during the day of a second user 102 living in a warmer climate (e.g., Miami). Similarly, seasonal variations in biological rhythms differ between northern regions (e.g., Finland) and southern regions (e.g., Miami). Thus, in some implementations, the system 100 may use location data (e.g., geographic location, latitude) to determine a "prediction weight" for the user's temperature data, the prediction weight being associated with the relative predictive accuracy of the temperature data for predicting illness. In such cases, the predictive weights may be used in conjunction with collected temperature data to determine how likely a given user 102 is to transition from a healthy state to an unhealthy state.

[0040] Additionally or alternatively, the system 100 may utilize physiological data associated with modifiable behavioral predictors (e.g., physical activity, sleep) to identify illness onset. For example, machine learning classifiers may be used to identify fulfillment of deviation criteria indicative of changes in the user's activity and / or sleep over time, which may be used to identify illness. Furthermore, in some implementations, the system 100 may utilize models (e.g., menstrual cycle models, weekly pattern adjustment models, annual pattern adjustment models, seasonal pattern adjustment models) to account for periodic and predictable changes in the user's movements, activities, and physiological responses to improve prediction of illness onset. For example, the system 100 may identify and / or generate a menstrual cycle model for the user 102-a, and use the menstrual cycle model to improve illness detection for the user 102-a. In this example, a menstrual cycle model may be used to account for natural cyclical changes in the user's physiological data based on the user's menstrual cycle (e.g., increased body temperature during menstruation), thereby reducing / eliminating false positive illness predictions.

[0041] The techniques described herein may provide improved illness detection using data collected by a wearable device. In particular, the techniques described herein may be used to predict whether the user 102 will transition from a healthy state to an unhealthy state (or vice versa) based on physiological data collected from the user 102 via the wearable device. The physiological data used to perform illness detection may include nervous system information (e.g., heart rate data, HRV data), temperature data, respiratory rate data, movement / activity data, sleep data, and the like. Additionally, the system 100 may utilize additional data, such as location data, to determine the predictive accuracy of various physiological parameters for identifying illness, thereby improving the accuracy of the illness detection techniques. Furthermore, by considering periodic and predictable changes in the user's activity, sleep, and / or physiological parameters (e.g., menstrual cycle models, weekly / seasonal / annual pattern adjustment models), the techniques described herein may further improve illness detection, thereby providing the user 102 with more valuable insight into the user's overall physical health.

[0042] It should be understood by those skilled in the art that one or more aspects of the present disclosure may be implemented in the system 100 to additionally or alternatively solve problems other than those described above. Furthermore, aspects of the present disclosure may provide technical improvements to "conventional" systems or processes as described herein. However, the description and accompanying drawings only include exemplary technical improvements resulting from the implementation of aspects of the present disclosure, and therefore do not represent all of the technical improvements provided within the scope of the claims.

[0043] 2 illustrates an example of a system 200 supporting disease detection techniques according to aspects of the present disclosure. System 200 may implement or be implemented by system 100. In particular, system 200 illustrates an example of a ring 104 (e.g., wearable device 104), a user device 106, and a server 110, as described with reference to FIG.

[0044] In some aspects, the ring 104 may be configured to be worn around a user's finger and may determine one or more user physiological parameters when worn around the user's finger. Exemplary measurements and determinations may include, but are not limited to, the user's skin temperature, pulse waveform, respiratory rate, heart rate, HRV, blood oxygen level, and the like.

[0045] The system 200 further includes a user device 106 (e.g., a smartphone) that communicates with the ring 104. For example, the ring 104 may be in wireless and / or wired communication with the user device 106. In some implementations, the ring 104 may transmit measured and processed data (e.g., temperature data, photoplethysmogram (PPG) data, motion / accelerometer data, ring input data, etc.) to the user device 106. The user device 106 may also transmit data, such as ring 104 firmware / configuration updates, to the ring 104. The user device 106 may process the data. In some implementations, the user device 106 may transmit the data to the server 110 for processing and / or storage.

[0046] The ring 104 may include a housing 205, which may include an inner housing 205-a and an outer housing 205-b. In some embodiments, the housing 205 of the ring 104 may store or otherwise contain various components of the ring, including, but not limited to, device electronics, a power source (e.g., battery 210 and / or capacitors), one or more boards (e.g., printable circuit boards) interconnecting the device electronics and / or power source, etc. The device electronics may include device modules (e.g., hardware / software) such as a processing module 230-a, memory 215, a communication module 220-a, a power module 225, etc. The device electronics may also include one or more sensors. Exemplary sensors may include one or more temperature sensors 240, a PPG sensor assembly (e.g., PPG system 235), and one or more motion sensors 245.

[0047] The sensors may include associated modules (not shown) configured to communicate with the respective components / modules of the ring 104 and generate signals associated with the respective sensors. In some aspects, each of the components / modules of the ring 104 may be communicatively coupled to one another via wired or wireless connections. Additionally, the ring 104 may include additional and / or alternative sensors or other components configured to collect physiological data from the user, including light sensors (e.g., LEDs), oximeters, etc.

[0048] The ring 104 shown and described with reference to FIG. 2 is provided for illustrative purposes only. As such, the ring 104 may include additional or alternative components as shown in FIG. 2. Other rings 104 may be manufactured that provide the functionality described herein. For example, rings 104 may be manufactured with fewer components (e.g., sensors). In a particular example, a ring 104 may be manufactured with a single temperature sensor 240 (or other sensor), a power source, and device electronics configured to read the single temperature sensor 240 (or other sensor). In another particular example, the temperature sensor 240 (or other sensor) may be attached to a user's finger (e.g., using a plastic / rubber band and / or tape). In this case, the sensor may be wired to another computing device, such as a wrist-worn computing device that reads the temperature sensor 240 (or other sensor). In other examples, rings 104 may be manufactured that include additional sensors and processing functionality.

[0049] The housing 205 may include one or more housing 205 components. The housing 205 may include an outer housing 205-b component (e.g., a shell) and an inner housing 205-a component (e.g., a molding). The housing 205 may include additional components (e.g., additional layers) not explicitly shown in FIG. 2. For example, in some implementations, the ring 104 may include one or more insulating layers that electrically insulate the device electronics and other conductive materials (e.g., electrical traces) from the outer housing 205-b (e.g., the metallic outer housing 205-b). The housing 205 may provide structural support for the device electronics, the battery 210, the substrate(s), and other components. For example, the housing 205 may protect the device electronics, the battery 210, and the substrate(s) from mechanical forces such as pressure and impact. The housing 205 may also protect the device electronics, the battery 210, and the substrate(s) from water and / or other chemicals.

[0050] The outer housing 205-b may be manufactured from one or more materials. In some implementations, the outer housing 205-b may include a metal such as titanium, which may provide strength and wear resistance at a relatively light weight. The outer housing 205-b may also be manufactured from other materials (e.g., polymers). In some implementations, the outer housing 205-b may be protective as well as decorative.

[0051] The inner housing 205-a may be configured to interface with a user's finger. The inner housing 205-a may be formed from a polymer (e.g., a medical grade polymer) or other material. In some implementations, the inner housing 205-a may be transparent. For example, the inner housing 205-a may be transparent to light emitted by a PPG light emitting diode (LED). In some implementations, the inner housing 205-a components may be molded onto the outer housing 205-a. For example, the inner housing 205-a may include a polymer molded (e.g., injection molded) to fit within the outer housing 205-b metal shell.

[0052] The ring 104 may include one or more substrates (not shown). The device electronics and battery 210 may be included on one or more substrates. For example, the device electronics and battery 210 may be mounted on one or more substrates. An exemplary substrate may include one or more PCBs, such as a flexible printed circuit board (PCB) (e.g., polyimide). In some implementations, the electronics / battery 210 may include a surface mounted device (e.g., a surface mount technology (SMT) device) on a flexible PCB. In some implementations, the one or more substrates (e.g., one or more flexible PCBs) may include electrical traces that provide electrical communication between the device electronics. The electrical traces may also connect the battery 210 to the device electronics.

[0053] The device electronics, battery 210, and substrate may be arranged within the ring 104 in a variety of ways. In some implementations, one substrate containing the device electronics may be mounted along the bottom (e.g., bottom half) of the ring 104 such that the sensors (e.g., PPG system 235, temperature sensor 240, motion sensor 245, and other sensors) interface with the inner surface of the user's finger. In these implementations, the battery 210 may be included (e.g., on a separate substrate) along the top of the ring 104.

[0054] The various components / modules of ring 104 represent functionality (e.g., circuits and other components) that may be included in ring 104. A module may include any discrete and / or integrated electronic circuit components implementing analog and / or digital circuitry capable of producing the functionality attributed to the module herein. For example, a module may include analog circuitry (e.g., amplification circuitry, filtering circuitry, analog-to-digital conversion circuitry, and / or other signal conditioning circuitry). A module may also include digital circuitry (e.g., combinational or sequential logic circuitry, memory circuitry, etc.).

[0055] The memory 215 (memory module) of the ring 104 may include any volatile, non-volatile, magnetic, or electrical media, such as random access memory (RAM), read only memory (ROM), non-volatile RAM (NVRAM), electrically erasable programmable ROM (EEPROM), flash memory, or any other memory device. The memory 215 may store any of the data described herein. For example, the memory 215 may be configured to store data (e.g., motion data, temperature data, PPG data) collected by the respective sensors and the PPG system 235. Additionally, the memory 215 may include instructions that, when executed by one or more processing circuits, cause the modules to perform various functions attributed to the modules herein. The device electronics of the ring 104 described herein are merely exemplary device electronics. As such, the types of electronic components used to implement the device electronics may vary based on design considerations.

[0056] The functionality attributed to the modules of the ring 104 described herein may be embodied as one or more processors, hardware, firmware, software, or any combination thereof. The depiction of different features as modules is intended to highlight different functional aspects and does not necessarily imply that such modules must be realized by separate hardware / software components. Rather, the functionality associated with one or more modules may be performed by separate hardware / software components or integrated within a common hardware / software component.

[0057] The processing module 230-a of the ring 104 may include one or more processors (e.g., processing units), microcontrollers, digital signal processors, systems on chips (SoCs), and / or other processing devices. The processing module 230-a communicates with the modules included in the ring 104. For example, the processing module 230-a may send / receive data to / from other components of the ring 104, such as modules and sensors. As described herein, the modules may be implemented by various circuit components. Thus, the modules may also be referred to as circuits (e.g., communication circuits and power circuits).

[0058] The processing module 230-a may be in communication with the memory 215. The memory 215 may include computer-readable instructions that, when executed by the processing module 230-a, cause the processing module 230-a to perform various functions attributed to the processing module 230-a herein. In some implementations, the processing module 230-a (e.g., a microcontroller) may include additional features associated with other modules, such as the communications functionality provided by the communications module 220-a (e.g., an integrated Bluetooth® Low Energy transceiver) and / or additional on-board memory 215.

[0059] The communication module 220-a may include circuitry to provide wireless and / or wired communication with the user device 106 (e.g., the communication module 220-b of the user device 106). In some implementations, the communication modules 220-a, 220-b may include wireless communication circuitry, such as Bluetooth circuitry and / or Wi-Fi circuitry. In some implementations, the communication modules 220-a, 220-b may include wired communication circuitry, such as Universal Serial Bus (USB) communication circuitry. Using the communication module 220-a, the ring 104 and the user device 106 may be configured to communicate with each other. The processing module 230-a of the ring may be configured to send / receive data to / from the user device 106 via the communication module 220-a. Exemplary data may include, but are not limited to, motion data, temperature data, pulse waveforms, heart rate data, HRV data, PPG data, and status updates (e.g., charging status, battery charge level, and / or ring 104 configuration settings). The ring processing module 230-a may also be configured to receive updates (eg, software / firmware updates) and data from the user device 106.

[0060] The ring 104 may include a battery 210 (e.g., a rechargeable battery 210). An exemplary battery 210 may include a lithium ion or lithium polymer type battery 210, although various battery 210 options are possible. The battery 210 may be wirelessly charged. In some implementations, the ring 104 may include a power source other than the battery 210, such as a capacitor. The power source (e.g., the battery 210 or capacitor) may have a curved geometry that matches the curvature of the ring 104. In some aspects, the charger or other power source may include additional sensors that may be used to collect data in addition to or supplemental to data collected by the ring 104 itself. Additionally, the charger or other power source for the ring 104 may function as a user device 106, in which case the charger or other power source for the ring 104 may be configured to receive data from the ring 104, store and / or process data received from the ring 104, and communicate data between the ring 104 and the server 110.

[0061] In some aspects, the ring 104 includes a power module 225 that may control charging of the battery 210. For example, the power module 225 may interface with an external wireless charger that charges the battery 210 when interfaced with the ring 104. The charger may include reference structures that mate with reference structures on the ring 104 to produce a specified orientation with the ring 104 during charging 104. The power module 225 may also regulate the voltage(s) of the device electronics, regulate the power output to the device electronics, and monitor the state of charge of the battery 210. In some implementations, the battery 210 may include a protection circuit module (PCM) that protects the battery 210 from high current discharge, over-voltage during charging 104, and under-voltage during discharging 104. The power module 225 may also include electrostatic discharge (ESD) protection.

[0062] One or more temperature sensors 240 may be electrically coupled to the processing module 230-a. The temperature sensor 240 may be configured to generate a temperature signal (e.g., temperature data) indicative of a temperature read or sensed by the temperature sensor 240. The processing module 230-a may determine the temperature of the user at the location of the temperature sensor 240. For example, in the ring 104, the temperature data generated by the temperature sensor 240 may indicate the user's temperature (e.g., skin temperature) at the user's finger. In some implementations, the temperature sensor 240 may contact the user's skin. In other implementations, a portion of the housing 205 (e.g., the inner housing 205-a) may form a barrier (e.g., a thin thermally conductive barrier) between the temperature sensor 240 and the user's skin. In some implementations, the portion of the ring 104 configured to contact the user's finger may have a thermally conductive portion and a thermally insulating portion. The thermally conductive portion may conduct heat from the user's finger to the temperature sensor 240. The thermally insulating portion may insulate portions of the ring 104 (eg, the temperature sensor 240) from the ambient temperature.

[0063] In some implementations, the temperature sensor 240 may generate a digital signal (e.g., temperature data) that the processing module 230-a may use to determine the temperature. As another example, if the temperature sensor 240 includes a passive sensor, the processing module 230-a (or the temperature sensor 240 module) may measure the current / voltage generated by the temperature sensor 240 and determine the temperature based on the measured current / voltage. An exemplary temperature sensor 240 may include a thermistor, such as a negative temperature coefficient (NTC) thermistor, or other types of sensors including resistors, transistors, diodes, and / or other electrical / electronic components.

[0064] The processing module 230-a may sample the user's temperature over time. For example, the processing module 230-a may sample the user's temperature according to a sampling rate. An exemplary sampling rate may include 1 sample / second, although the processing module 230-a may be configured to sample the temperature signal at other sampling rates higher / lower than 1 sample / second. In some implementations, the processing module 230-a may sample the user's temperature continuously throughout the day and night. Sampling at a sufficient rate (e.g., 1 sample / second) throughout the day may provide sufficient temperature data for the analysis described herein.

[0065] The processing module 230-a may store the sampled temperature data in the memory 215. In some implementations, the processing module 230-a may process the sampled temperature data. For example, the processing module 230-a may determine an average temperature value over a period of time. In one example, the processing module 230-a may determine an average temperature value every minute by summing all temperature values ​​collected in a minute and dividing by the number of samples in that minute. In a particular example where the temperature is sampled at 1 sample / second, the average temperature may be the sum of all sampled temperatures in a minute divided by 60 seconds. The memory 215 may store the average temperature values ​​over time. In some implementations, the memory 215 may store the average temperature instead of the sampled temperatures (e.g., 1 per minute) to conserve the memory 215.

[0066] The sampling rate, which may be stored in memory 215, may be configurable. In some implementations, the sampling rate may be the same throughout the day and night. In other implementations, the sampling rate may be changed throughout the day and night. In some implementations, the ring 104 may filter / reject temperature readings, such as large spikes in temperature that are not indicative of a physiological change (e.g., a temperature spike from a hot shower). In some implementations, the ring 104 may filter / reject temperature readings that may be unreliable due to other factors, such as excessive movement during 104 exercise (e.g., as indicated by the motion sensor 245).

[0067] The ring 104 (e.g., a communications module) may transmit the sampled and / or average temperature data to the user device 106 for storage and / or further processing. The user device 106 may forward the sampled and / or average temperature data to the server 110 for storage and / or further processing.

[0068] Although the ring 104 is shown as including a single temperature sensor 240, the ring 104 may include multiple temperature sensors 240 in one or more locations, such as disposed along the inner housing 205-a near the user's finger. In some implementations, the temperature sensor 240 may be a stand-alone temperature sensor 240. Additionally or alternatively, the one or more temperature sensors 240 may be included with other components (e.g., packaged with other components), such as with an accelerometer and / or a processor.

[0069] The processing module 230-a may obtain and process data from multiple temperature sensors 240 in a manner similar to that described with respect to a single temperature sensor 240. For example, the processing module 230 may sample, average, and store temperature data from each of the multiple temperature sensors 240 individually. In other examples, the processing module 230-a may sample the sensors at different rates and average / store different values ​​for the different sensors. In some implementations, the processing module 230-a may be configured to determine a single temperature based on an average of two or more temperatures determined by two or more temperature sensors 240 at different locations on the finger.

[0070] The temperature sensor 240 on the ring 104 may acquire a distal temperature at a user's finger (e.g., any finger). For example, one or more temperature sensors 240 on the ring 104 may acquire the user's temperature from the underside of the finger or at different locations on the finger. In some implementations, the ring 104 may continuously acquire the distal temperature (e.g., at a sampling rate). Although distal temperatures measured at the finger by the ring 104 are described herein, other devices may measure temperatures at the same / different locations. In some cases, the distal temperature measured at the user's finger may differ from the temperature measured at the user's wrist or other external body location. Additionally, the distal temperature measured at the user's finger (e.g., "shell" temperature) may differ from the user's core temperature. As such, the ring 104 may provide a useful temperature signal that may not be acquired at other internal / external locations on the body. In some cases, continuous temperature measurements at the finger may capture temperature fluctuations (e.g., small or large fluctuations) that may not be evident in the core temperature. For example, continuous temperature measurements at a finger can capture minute-by-minute or hour-by-hour temperature fluctuations, providing additional insight that may not be provided by other temperature measurements at other locations on the body.

[0071] The ring 104 may include a PPG system 235. The PPG system 235 may include one or more optical transmitters that transmit light. The PPG system 235 may also include one or more optical receivers that receive light transmitted by the one or more optical transmitters. The optical receiver may generate a signal (hereinafter, a "PPG" signal) that indicates the amount of light received by the optical receiver. The optical transmitter may illuminate an area of ​​the user's finger. The PPG signal generated by the PPG system 235 may indicate blood perfusion in the illuminated area. For example, the PPG signal may indicate changes in blood volume in the illuminated area caused by the user's pulse pressure. The processing module 230-a samples the PPG signal and determines the user's pulse waveform based on the PPG signal. The processing module 230-a may determine various physiological parameters, such as the user's respiration rate, heart rate, HRV, oxygen saturation, and other circulatory parameters, based on the user's pulse waveform.

[0072] In some implementations, the PPG system 235 may be configured as a reflective PPG system 235 in which the optical receiver(s) receive transmitted light reflected through a region of the user's finger. In some implementations, the PPG system 235 may be configured as a transmissive PPG system 235 in which the optical transmitter(s) and optical receiver(s) are arranged opposite one another such that light is transmitted directly through a portion of the user's finger to the optical receiver(s).

[0073] The number and ratio of transmitters and receivers included in the PPG system 235 may vary. Exemplary optical transmitters may include light emitting diodes (LEDs). The optical transmitters may transmit light in the infrared spectrum and / or other spectrums. Exemplary optical receivers may include, but are not limited to, optical sensors, phototransistors, and photodiodes. The optical receivers may be configured to generate PPG signals in response to wavelengths received from the optical transmitters. The locations of the transmitters and receivers may vary. Additionally, a single device may include reflective and / or transmissive PPG systems 235.

[0074] 2 may, in some implementations, include a reflective PPG system 235. In these implementations, the PPG system 235 may include a centrally located optical receiver (e.g., at the bottom of the ring 104) and two optical transmitters located on either side of the optical receiver. In this implementation, the PPG system 235 (e.g., the optical receiver) may generate a PPG signal based on light received from one or both of the optical transmitters.

[0075] The processing module 230-a may control one or both of the optical transmitters to transmit light while sampling the PPG signal generated by the optical receiver. In some implementations, the processing module 230-a may cause the optical transmitter with a stronger received signal to transmit light while sampling the PPG signal generated by the optical receiver. For example, the selected optical transmitter may emit light continuously while the PPG signal is sampled at a sampling rate (e.g., 250 Hz).

[0076] Sampling the PPG signal generated by the PPG system 235 may result in a pulse waveform, which may be referred to as a "PPG." The pulse waveform may indicate blood pressure versus time for multiple cardiac cycles. The pulse waveform may include peaks indicative of cardiac cycles. Additionally, the pulse waveform may include respiratory induced variations, which may be used to determine respiratory rate. The processing module 230-a, in some implementations, may store the pulse waveform in the memory 215. The processing module 230-a may process the pulse waveform as it is generated and / or from the memory 215 to determine user physiological parameters as described herein.

[0077] The processing module 230-a may determine the user's heart rate based on the pulse waveform. For example, the processing module 230-a may determine the heart rate (e.g., beats per minute) based on the time between peaks in the pulse waveform. The time between peaks may be referred to as the interbeat interval (IBI). The processing module 230-a may store the determined heart rate value and the IBI value in the memory 215.

[0078] The processing module 230-a may determine HRV over time. For example, the processing module 230-a may determine HRV based on the variation of IBl. The processing module 230-a may store the HRV values ​​over time in the memory 215. Additionally, the processing module 230-a may determine the user's respiration rate over time. For example, the processing module 230-a may determine the respiration rate based on frequency modulation, amplitude modulation, or baseline modulation of the user's IBI value over a period of time. Additionally or alternatively, the respiration rate may be determined based on the HRV data. The respiration rate may be calculated in breaths per minute or as another respiration rate (e.g., breaths per 30 seconds). The processing module 230-a may store the user's respiration values ​​over time in the memory 215.

[0079] The ring 104 may include one or more motion sensors 245, such as one or more accelerometers (e.g., 6D accelerometers) and / or one or more gyroscopes (gyros). The motion sensors 245 may generate motion signals indicative of the movement of the sensor. For example, the ring 104 may include one or more accelerometers that generate acceleration signals indicative of the acceleration of the accelerometer. As another example, the ring 104 may include one or more gyro sensors that generate gyro signals indicative of angular motion (e.g., angular velocity) and / or changes in orientation. The motion sensors 245 may be included in one or more sensor packages. An exemplary accelerometer / gyro sensor is a Bosch BM1160 inertial microelectromechanical system (MEMS) sensor that may measure angular velocity and acceleration in three perpendicular axes.

[0080] The processing module 230-a may sample the motion signals at a sampling rate (e.g., 50 Hz) and determine the movement of the ring 104 based on the sampled motion signals. For example, the processing module 230-a may sample the acceleration signals to determine the acceleration of the ring 104. As another example, the processing module 230-a may sample the gyro signals to determine the angular motion. In some implementations, the processing module 230-a may store the motion data in the memory 215. The motion data may include sampled motion data as well as motion data calculated based on the sampled motion signals (e.g., acceleration and angle values).

[0081] The ring 104 may store various data described herein. For example, the ring 104 may store temperature data, such as raw sampled temperature data and calculated temperature data (e.g., average temperature). As another example, the ring 104 may store PPG signal data, such as pulse waveforms and data calculated based on the pulse waveforms (e.g., heart rate values, IBI values, HRV values, and respiration values). The ring 104 may also store motion data, such as sampled motion data indicative of linear and angular motion.

[0082] The ring 104 or other computing device may calculate and store additional values ​​based on the sampled / calculated physiological data. For example, the processing module 230 may calculate and store various metrics such as sleep metrics (e.g., sleep score), activity metrics, and readiness metrics. In some implementations, the additional values / metrics may be referred to as "derived values." The ring 104 or other computing / wearable device may calculate various values / metrics regarding motion. Exemplary derived values ​​for motion data may include, but are not limited to, a motion count value, a regularity value, an intensity value, a metabolic equivalence of task (MET) value, and an orientation value. The motion count, regularity value, intensity value, and MET may indicate the amount (e.g., speed / acceleration) of the user's motion over time. The orientation value may indicate how the ring 104 is oriented on the user's finger and whether the ring 104 is worn on the left or right hand.

[0083] In some implementations, the motion count and regularity value may be determined by counting the number of acceleration peaks within one or more time periods (e.g., one or more time periods of 30 seconds to one minute). The intensity value may indicate the number of motions and the associated intensity of the motions (e.g., acceleration values). The intensity values ​​may be classified as low, medium, and high depending on the associated threshold acceleration value. The MET may be determined based on the intensity of the 104 motions for a period of time (e.g., 30 seconds), the regularity / irregularity of the motions, and the number of motions associated with different intensities.

[0084] In some implementations, the processing module 230-a may compress data stored in the memory 215. For example, the processing module 230-a may perform calculations based on the sampled data and then delete the sampled data. As another example, the processing module 230-a may average the data over a longer period of time to reduce the number of values ​​stored. In a particular example, if the average temperature of a user for one minute is stored in the memory 215, the processing module 230-a may calculate the average temperature over a five minute period for storage and then erase the one minute average temperature data. The processing module 230-a may compress the data based on various factors, such as the total amount of memory 215 used / available and / or the time since the ring 104 last transmitted data to the user device 106.

[0085] The user's physiological parameters may be measured by a sensor included on the ring 104, although other devices may measure the user's physiological parameters. For example, the user's temperature may be measured by a temperature sensor 240 included on the ring 104, or other devices may measure the user's temperature. In some examples, other wearable devices (e.g., wrist devices) may include sensors that measure the user's physiological parameters. Additionally, medical devices such as external medical devices (e.g., wearable medical devices) and / or implantable medical devices may measure the user's physiological parameters. One or more sensors on any type of computing device may be used to implement the techniques described herein.

[0086] Physiological measurements may be taken continuously throughout the day and / or night. For example, in some implementations, the ring 104 may be configured to continuously acquire physiological data (e.g., determine temperature readings, HRV readings, respiration rate readings) according to one or more measurement periodicities throughout each day / sleep day. In other words, the ring 104 may continuously acquire physiological data from the user regardless of "trigger conditions" for performing such measurements.

[0087] In additional or alternative implementations, physiological measurements may be taken during portions of the day and / or portions of the night 104. In some implementations, physiological measurements may be taken in response to a determination that the user is in a particular state, such as an active state, a resting state, and / or a sleeping state. For example, the ring 104 may take physiological measurements in a resting / sleeping state to obtain a cleaner physiological signal. In one example, the ring 104 or other device / system may detect when the user is resting and / or sleeping and obtain physiological parameters (e.g., temperature) for the detected state. The device / system may use the resting / sleeping physiological data and / or other data when the user is in other states to implement the techniques of this disclosure.

[0088] In some implementations, the ring 104 may be configured to collect, store, and / or process data as previously described herein, and may forward any of the data described herein to the user device 106 for storage and / or processing. In some aspects, the user device 106 includes a wearable application 250, an operating system (OS), a web browser application (e.g., web browser 280), one or more additional applications, and a GUI 275. The user device 106 may further include other modules and components, including sensors, audio devices, haptic feedback devices, and the like. The wearable application 250 may include examples of applications (e.g., “apps”) that may be installed on the user device 106. The wearable application 250 may be configured to obtain data from the ring 104, store the obtained data, and process the obtained data, as described herein. For example, the wearable application 250 includes a user interface (UI) module 255, an acquisition module 260, a processing module 230-b, a communication module 220-b, and a storage module (e.g., a database 265) configured to store application data.

[0089] Various data processing operations described herein may be performed by the ring 104, the user device 106, the server 110, or any combination thereof. For example, in some cases, data collected by the ring 104 may be pre-processed and transmitted to the user device 106. In this example, the user device 106 may perform some data processing operations on the received data, transmit the data to the server 110 for data processing, or both. For example, in some cases, the user device 106 may perform processing operations that require relatively low processing power and / or operations that require relatively low latency, while the user device 106 may transmit data to the server 110 for processing operations that require relatively high processing power and / or operations that can tolerate relatively high latency.

[0090] In some aspects, the ring 104, the user device 106, and the server 110 of the system 200 may be configured to evaluate a user's sleep patterns. In particular, each component of the system 200 may be used to collect data from the user via the ring 104 and generate one or more scores (e.g., sleep score, readiness score) for the user based on the collected data. For example, as previously described herein, the ring 104 of the system 200 may be worn by the user to collect data from the user including temperature, heart rate, HRV, etc. The data collected by the ring 104 may be used to determine when the user is asleep to evaluate the user's sleep for a given "sleep day." In some aspects, a score may be calculated for the user for each sleep day such that a first sleep day is associated with a first set of scores and a second sleep day is associated with a second set of scores. A score may be calculated for each sleep day based on the data collected by the ring 104 during each sleep day. The scores may include, but are not limited to, a sleep score, a readiness score, etc.

[0091] In some cases, the "sleep days" may coincide with traditional calendar days, such that a given sleep day is from midnight to midnight on the respective calendar day. In other cases, the sleep days may be offset relative to the calendar days. For example, a sleep day may be from 6:00pm (18:00) on a calendar day to 6:00pm (18:00) on the next calendar day. In this example, 6:00pm may serve as a "cutoff time" such that data collected from the user before 6:00pm is counted into the current sleep day and data collected from the user after 6:00pm is counted into the next sleep day. Due to the fact that most individuals sleep best at night, offsetting the sleep days relative to the calendar days allows the system 200 to evaluate the user's sleep patterns in a manner that is consistent with the user's sleep schedule. In some cases, the user may be able to selectively adjust the timing of the sleep days relative to the calendar days (e.g., via a GUI) to align the sleep days with the duration that the respective user typically sleeps.

[0092] In some implementations, the user's respective overall score (e.g., sleep score, readiness score) for each day may be determined / calculated based on one or more "contributors," "factors," or "contributing factors." For example, the user's overall sleep score may be calculated for a set of incentives including total sleep, efficiency, restfulness, rapid eye movement (REM) sleep, deep sleep, latency, timing, or any combination thereof. A sleep score may include any number of incentives. A "total sleep" incentive may refer to the sum of all sleep periods of a sleep day. An "efficiency" incentive may reflect the proportion of time asleep compared to awake time while in bed and may be calculated using an efficiency average of long sleep periods (e.g., main sleep periods) of a sleep day, weighted by the duration of each sleep period. A "restfulness" incentive may indicate how restful the user's sleep is and may be calculated using an average of all sleep periods of a sleep day, weighted by the duration of each period. The restfulness triggers may be based on "wake count" (e.g., the sum of all arousals (when the user wakes up) detected during different sleep periods), excessive movement, and "wake count" (e.g., the sum of all arousals (when the user gets out of bed) detected during different sleep periods).

[0093] The "REM sleep" trigger may refer to the sum of REM sleep duration over all sleep periods of a sleep day, including REM sleep. Similarly, the "deep sleep" trigger may refer to the sum of deep sleep duration over all sleep periods of a sleep day, including deep sleep. The "latency" trigger may represent the time it takes the user to fall asleep (e.g., average, median, longest) and may be calculated using an average of long sleep periods throughout the sleep day, weighted by the duration of each period and the number of such periods (e.g., the integration of a given sleep stage or stages may be a trigger in itself or may weight other triggers). Finally, the "timing" trigger may refer to the relative timing of sleep periods within a sleep day and / or calendar day, and may be calculated using an average of all sleep periods of a sleep day, weighted by the duration of each period.

[0094] As another example, a user's overall readiness score may be calculated based on a set of incentives including sleep, sleep balance, heart rate, HRV balance, recovery index, temperature, activity, activity balance, or any combination thereof. A readiness score may include any number of incentives. A "sleep" incentive may refer to the combined sleep score of all sleep periods within a sleep day. A "sleep balance" incentive may refer to the cumulative duration of all sleep periods within a sleep day. In particular, sleep balance may indicate to a user whether the sleep a user has had over a period of time (e.g., the past two weeks) is balanced with the user's needs. Typically, an adult requires 7-9 hours of sleep per night to be healthy, alert, and performing at their best mentally and physically. However, it is normal to have occasional bad sleep days, and therefore the sleep balance incentive takes into account long-term sleep patterns to determine whether each user's sleep needs are being met. The "resting heart rate" trigger may indicate the lowest heart rate from the longest sleep period (eg, the main sleep period) of the sleep day and / or the lowest heart rate from a nap occurring after the main sleep period.

[0095] Continuing with reference to the "triggers" (e.g., contributing factors) of the readiness score, the "HRV balance" trigger may indicate the highest HRV average from the main sleep period and the sleep that occurs after the main sleep period. The HRV balance trigger may help the user track their recovery state by comparing the user's HRV trend over a first period (e.g., 2 weeks) to the average HRV over some second longer period (e.g., 3 months). The "Recovery Index" trigger may be calculated based on the longest sleep period. The recovery index measures how long it takes for the user's resting heart rate to stabilize during the night. A sign of very good recovery is that the user's resting heart rate stabilizes during the first half of the night, at least 6 hours before the user wakes up, leaving time for the body to recover for the next day. The "Temperature" trigger may be calculated based on the longest sleep period (e.g., main sleep period) or based on the sleep that occurs after the longest sleep period if the user's highest body temperature during the sleep is at least 0.5°C higher than the highest body temperature during the longest period. In some aspects, the ring may measure the user's temperature while the user is asleep, and the system 200 may display the user's average temperature against the user's baseline temperature. If the user's temperature is outside of the normal range (e.g., significantly above or below 0.0), the temperature trigger may be highlighted (e.g., go to a "Pay attention" state) or otherwise generate an alert to the user.

[0096] In some implementations, various devices of the system 200 may support techniques for illness detection. In particular, the system 200 may support illness detection based on physiological data indicative of the user's neuroimmune and nervous system responses during the pre-symptomatic period of infection or illness. The early incubation period of infection, before one realizes one has symptoms, is a key window of opportunity for early detection. Wearable-derived markers of nervous system balance may help detect the onset of infection and the transition to symptomatic illness during the "incubation period" before one realizes one is sick. For example, in the context of COVID-19, one may be infectious without experiencing any symptoms for up to 14 days before actually developing a fever or feeling unwell. This 14-day period may be referred to as the "pre-symptomatic period" of COVID-19. Influenza has a shorter incubation time or pre-symptomatic period, which may be typically up to 4 days. The pre-symptomatic period is also the period during which an individual is most likely to spread the virus. Therefore, it is desirable to detect illness during the pre-symptomatic state to allow for intervention to stop the spread of the disease.

[0097] For many types of influenza-like illnesses, including COVID-19 and other viral or bacterial infections, the body's immune response to the invading pathogen modulates the autonomic nervous system, thereby transmitting signals (e.g., inflammatory cytokines) to the brain that may result in "sickness symptoms." Physiological data collected by a wearable device (e.g., ring 104) may detect these early nervous system changes by building markers or "features" that are fed into a classifier / algorithm (e.g., machine learning classifier). These markers may be derived from continuous heart rate monitoring, PPG data, derived IBI series, or any combination thereof. Because PPG and other physiological data measured at the finger are based on arterial blood flow (as compared to capillary blood flow), physiological data collected from the finger via ring 104 may be more sensitive and accurate as compared to physiological data collected from the wrist, thereby providing highly sensitive signals to nervous system balance markers for detecting illness during the incubation period (or pre-symptomatic period).

[0098] A user's nervous system balance may involve the relative antagonism (e.g., push and pull) of a user's sympathetic and parasympathetic nervous system responses. In particular, upon exposure to stress (e.g., exposure to illness / infection or attack from a pathogen), the parasympathetic nervous system (e.g., the part of the nervous system associated with "rest and digest" or recovery) may shut down some of its tonic, inhibitory input to the heart, immune cells, and other body tissues. In essence, by "taking your foot off the break," the nervous system may allow greater sympathetic input to engage the "fight or flight" system. This favors the immune system in the earliest stages of infection by recruiting immune cells such as monocytes / macrophages from the bone marrow to the bloodstream and tissues where they seek out virus-infected cells. Thus, nervous system changes may occur near the time of infection or prior to the onset of symptoms (e.g., in the case of COVID-19, 2-14 days prior to the onset of symptoms).

[0099] The antagonism between sympathetic and parasympathetic responses results in a "nervous system balance," which may explain the combination of coordinated adrenergic and cholinergic inputs that affect heart rate and the vasculature, manifest as changes in PPG-derived markers, and influence the user's immune response to infection / disease. Essentially, both counterregulatory aspects of the nervous system (sympathetic / adrenergic and parasympathetic / cholinergic) are necessary and do not always operate in a counterregulatory fashion as traditionally presented in some textbooks and other literature.

[0100] In response to infection / illness, the brain sends signals through the nervous system to peripheral immune organs such as the bone marrow and spleen. These signals release more immune cells, such as monocytes / macrophages, into the bloodstream, which may hunt down and help fight infected cells. Nervous system balance is needed to control this immune response to infection and direct recovery from illness. Nervous system balance is a function of both parasympathetic and sympathetic nervous system inputs to the heart and immune cells. Furthermore, sleep is unique in the context of nervous system balance, which has different activation patterns during the day and at night (or when awake and asleep). Thus, it is contemplated herein that the wearable device 104 (e.g., ring 104) of system 200 may be configured to capture physiological data indicative of sleep and other nervous system responses, which may provide a unique measurement of nighttime nervous system balance before (and during) infection / illness.

[0101] The user's nervous system mediates connections between the immune system and the brain to fight disease / infection, providing a critical signaling pathway that allows the brain to "learn" that the body has been infected with a disease (e.g., influenza-like respiratory virus) and coordinate a systemic response to the infection, resulting in the development of "sickness symptoms" such as fatigue, pain, etc., to help the body fight the infection. For example, upon identifying an infection, the nervous system may transmit inflammatory signals to the brain's hypothalamic center, which regulates body temperature, thereby causing the body to generate a fever and inhibiting viral replication, thereby enhancing survival.

[0102] Nevertheless, since the nervous system responds to many other stimuli besides illness / infection, the system 200 may be configured to combine subtle changes across many markers to detect larger patterns of response to illness. Indeed, an individual feature associated with collected physiological data may not be strongly indicative of illness on its own. However, when multiple features are combined together and used with many features / markers, the machine learning classifier of the system 200 may be highly accurate in detecting illness. Thus, the system 200 may utilize multiple aspects such as the balance of the nervous system between parasympathetic and sympathetic nervous systems and the behavioral outcomes caused by infection (e.g., sleeping earlier or longer, etc.) to identify illness. In other words, the techniques described herein may determine / predict illness based on learned patterns of deviations in the user's activity, sleep, and / or physiological data, rather than individual "anomalies" in a single parameter or feature.

[0103] Thus, the system 200 may support techniques for identifying onset of illness using physiological data indicative of nervous system responses (e.g., HRV, respiration rate). In particular, the techniques described herein may compare HRV data collected from a user over a first time interval (reference window) and a second time interval (prediction window) and may determine fulfilment of a deviation criterion based on a change in the HRV data from the first time interval to the second time interval. The fulfilment of the deviation criterion may then be used to determine an "illness risk score", "illness prediction metric", or some other metric indicative of the user's illness, and may report the determined metric to the user via the GUI 275 of the user device 106. In other words, the system 200 may collect HRV data from a user and compare the collected HRV data to baseline HRV data of that same user to determine a deviation from the user's baseline HRV data, which deviation may be indicative of illness. Additionally or alternatively, the system 200 may determine the user's respiration rate (e.g., based on the HRV data) and may determine the deviation from the user's baseline respiration rate to identify onset of illness.

[0104] In some implementations, the collected HRV data may be input to a classifier, which is configured to identify the fulfillment of one or more deviation criteria over a respective time interval (e.g., reference window, prediction window) to detect illness. In some implementations, the frequency content of the HRV data collected from the user may be used to identify the onset of illness. For example, the ring 104, the user device 106, and / or the server 110 of the system 200 may determine HRV frequency bands and time domain metrics associated with the HRV data collected from the user. The time domain content / metrics of the HRV data may include the root mean square of successive differences (RMSSD). Additionally, frequency domain content / metrics for HRV data may include high frequency (HF: 0.15-0.40 Hz; minimum duration = 30 s; rolling window = 1 min) and low frequency (LF: 0.04-0.15 Hz; minimum duration = 90 s; rolling window = 2-5 min) ranges, respiratory rate, and very low frequency (VLF: 0.015-0.04 Hz; minimum duration 270 s). These frequency features may be calculated on a rolling basis over a 1-10 min window depending on the length of the frequency of interest after removing movement and other artifacts as well as ectopic beats from the signal.

[0105] Various components of the system 200 may determine the raw spectral power in each frequency band and / or the peak frequency for each frequency band. These frequency extractions at high resolution granularity may be fed into a feature engineering pipeline configured to extract various statistical parameters from various points during the sleep period. These may include, but are not limited to, quantiles of the distribution (e.g., 1%, 50%, 99%, etc.) or metrics that examine shifts in the overall distribution, such as the Wasserstein metric. In other words, the feature engineering pipeline may be configured to compute features for specific time windows (e.g., rolling 1-10 minute time windows) as well as compute statistics over the time windows (e.g., median values ​​over the night), and the computed features and statistics may be fed into a classifier (e.g., a machine learning classifier) ​​to perform various illness detection techniques described herein. In some implementations, the changes in the distribution may be framed using Bayesian statistics to reflect the influence of prior knowledge of a given user's range of values ​​in a personalized manner over various "baseline periods."

[0106] In some implementations, features related to physiological data associated with nervous system responses (e.g., HRV data) may be extracted in a "sleep intelligent" manner, such as separating respiration rates during REM and non-REM sleep. Features may be extracted from the early, middle, or late portions of the evening, where different physiological influences may predominate. For example, the circadian rhythm of the immune system suggests that between approximately 9:00 pm and 2:00 am, the immune system may be poised to launch a strong attack and secrete more cytokines, but later in the evening, sympathetically mediated visceral nerve signals may initiate signals that entrain the circadian rhythm of the next day, thereby significantly influencing this signal. Thus, the system 200 may be configured to perform sickness detection based on physiological data collected over an entire night of sleep, based on physiological data collected over multiple sleep periods, and / or based on "sleep stage intelligent" or time-informed features based on physiological data collected within time intervals determined according to known circadian rhythms and physiology.

[0107] In some embodiments, the system 200 may determine the frequency content of the HRV data throughout each time interval (e.g., first / reference time interval, second / prediction time interval). For example, the feature engineering pipeline of the system 200 (and / or the machine learning classifier) ​​may determine the frequency and amplitude (e.g., raw spectral power) of high and low frequency signals in a rolling time window (e.g., rolling 2-minute time interval) across a night of collected physiological data. The system 200 may then calculate statistics on the determined features (e.g., 50% quantile of high frequency amplitude across the entire night of rolling 2-minute intervals) to determine a single set of parameters / values ​​for each night of physiological data.

[0108] The frequency content associated with the acquired HRV data may be further shown and explained with reference to FIG.

[0109] 3 illustrates an example of a neurological tree 300 that supports disease detection techniques according to aspects of the present disclosure. In particular, the neurological tree 300 includes an HRV frequency content diagram 305-a and a neurological metric diagram 305-b.

[0110] HRV frequency content diagram 305-a illustrates how analysis of HRV frequency bands can be used to capture divergence between sympathetic and parasympathetic indices prior to illness in order to detect illness at a pre-symptomatic stage. In particular, HRV frequency content diagram 305-a illustrates low frequency content (low frequency curve 310-a) and high frequency content (high frequency curve 310-b) for over 10,000 individuals who experienced flu-like symptoms, including symptoms associated with COVID-19. The x-axis of HRV frequency content diagram 305-a illustrates the time (e.g., days) before and after the onset of symptoms, with time=0 illustrating the onset of symptoms (e.g., first onset of symptoms) for the respective user. The x-axis of HRV frequency content diagram 305-a is normalized to graph two different metrics together (e.g., low frequency curve 310-a and high frequency curve 310-b).

[0111] The low frequency curve 310-a represents the 99th percentile of peak frequencies in the low frequency band, an HRV metric derived from the IBI series during nighttime sleep periods. The high frequency curve 310-b represents the 1st percentile of peak frequencies in the high frequency band, another HRV metric derived from the IBI series during nighttime sleep periods. In some aspects, the low frequency curve 310-a may represent a sympathetic nervous system response and the high frequency curve 310-b may represent a parasympathetic nervous system response.

[0112] As shown in the HRV frequency content diagram 305-a, there may be a coordinated shift within the two frequency ranges prior to the onset of symptoms. That is, there is a separation between the low frequency curve 310-a and the high frequency curve 310-b prior to the onset of symptoms. Since the low frequency curve 310-a and the high frequency curve 310-b are associated with sympathetic and parasympathetic activity, respectively, the degree of separation of the respective curves 310 prior to the onset of symptoms may make the respective responses (e.g., sympathetic response, parasympathetic response) more evident. This degree of separation between the low frequency curve 310-a and the high frequency curve 310-b may reflect a change in input to immune organs, such as the bone marrow, to stimulate the release of immune cells into the bloodstream to fight infection.

[0113] In some embodiments, the system 200 may identify illness at a presymptomatic stage (e.g., before the onset of illness at time=0) based on the low frequency content (e.g., low frequency curve 310-a) and / or high frequency content (e.g., high frequency curve 310-b) of the user's HRV data. In some cases, the system 200 (e.g., ring 104, user device 106, server 110, machine learning classifier) ​​may identify the degree of divergence of the low frequency curve 310-a and the high frequency curve 310-b to identify illness. For example, during a first interval (e.g., reference window), the normalized low frequency curve 310-a may be larger than the normalized high frequency curve 310-b. In contrast, during a second time interval (e.g., prediction window), the normalized high frequency curve 310-b may be larger than the normalized low frequency curve 310-a. Thus, the system 200 may detect an onset of disease based on the deviation between the respective curves 310 between the first and second time intervals.

[0114] The system 200 may utilize additional physiological parameters related to nervous system response to determine the onset of illness. For example, the nervous system metric diagram 305-b shows three different metrics derived from a user's IBI series that may be used for illness detection: resting heart rate (curve 310-c), HRV averaged score (curve 310-d), and recovery metric (curve 310-e). In some implementations, as previously described herein, the resting heart rate, HRV averaged score (e.g., "HRV Balance"), and recovery metric (e.g., "Recovery Index") may include "contributing factors" or "contributing factors" used to determine the user's readiness score.

[0115] The x-axis of nervous system metric diagram 305-b indicates the time (e.g., days) before and after the onset of symptoms, with time=0 indicating the onset of symptoms (e.g., first onset of symptoms) for the respective user. Each curve 310-c, 310-d, and 310-e of nervous system metric diagram 305-b may be calculated by comparing recent data to the user's long-term average, normalized from 0 to 100 (y-axis). As shown in FIG. 3, each nervous system metric shown in nervous system metric diagram 305-b may provide valuable insight for illness detection in the pre-onset period.

[0116] In particular, the curve 310-d relating to the user's HRV averaged score, or "HRV balance," declines substantially prior to the onset of symptoms. The curve 310-d reflecting the user's HRV averaged score (e.g., HRV balance) compares the recent nighttime HRV (e.g., a 14-day weighted average of log-transformed RMSSD, with more weight given to more recent data) to the user's long-term HRV over the past few months. Additionally, the curve 310-c reflecting resting heart rate (comparing the previous night's lowest 10-minute heart rate to the user's long-term average of heart rate) also declines prior to the onset of symptoms. Finally, the curve 310-e reflecting the recovery index (e.g., recovery metric data) for the readiness score also exhibits an increase in the number of days leading up to the onset of symptoms. The recovery metric data, or recovery index, may refer to the time it takes for the user's resting heart rate to stabilize overnight. The increase in the curve 310-e may reflect an increase in the percentage of the night dedicated to recovery after the heart rate reaches its lowest point. A longer than normal recovery time may be a weak predictor of slight illness. In summary, a decrease in curve 310-c (e.g., a decrease in resting heart rate), a decrease in curve 310-d (e.g., a decrease in HRV averaged score), an increase in curve 310-e (e.g., an increase in recovery metric data), or any combination thereof may be used for illness prediction.

[0117] 4 illustrates an example of a neurological tree 400 supporting illness detection techniques according to aspects of the present disclosure. In particular, the neurological tree 400 includes an HRV frequency content plot 405-a, a bedtime plot 405-b, an RMSSD plot 405-c, and a REM sleep plot 405-d.

[0118] The x-axis of each diagram 405-a-405-d indicates the dates (e.g., month-day) before and after the onset of the symptom, where a vertical reference line in each diagram 405 indicates the onset of the user's illness symptom. The y-axis of HRV frequency content diagram 405-a indicates the correlation between high and low frequency content of HRV data from the user. The y-axis of bedtime diagram 405-b indicates the user's bedtime measured as a duration (in minutes) after midnight on the respective date. The y-axis of RMSSD diagram 405-c indicates an RMSSD measurement of the user's longest sleep duration in milliseconds, and the y-axis of REM sleep diagram 405-d indicates the user's total REM sleep duration in seconds.

[0119] As seen in HRV frequency content diagram 405-a, there is a noticeable increase in the correlation between high and low frequency HRV peak frequencies approximately 5-7 days prior to symptom onset. Additionally, bedtime diagram 405-b indicates that the user may be going to bed earlier in the days leading up to symptom onset (e.g., the decrease in the curve in bedtime diagram 405-b), and RMSSD diagram 405-c indicates that the RMSSD of the HRV data is lower in the days leading up to symptom onset. The decrease in RMSSD (and / or other HRV metrics) may indicate the withdrawal of parasympathetic symptoms, which may indicate oncoming illness. Finally, REM sleep diagram 405-d shows an increase in REM sleep leading up to symptom onset.

[0120] While the individual neural characteristics / parameters shown in Figure 4 may be somewhat noisy individually, these respective parameters, when used in conjunction or in combination, may be used to effectively predict illness. For example, increased correlation between high and low frequency HRV content, along with earlier bedtime and increased REM sleep, may be used to identify that a user may transition from a healthy to an unhealthy state.

[0121] 5 illustrates an example of a neurological tree 500 supporting illness detection techniques according to aspects of the present disclosure. In particular, the neurological tree 500 includes a first diagram 505-a illustrating the longest sleep durations of deep and REM sleep stages, and a second diagram 505-b illustrating the relative percentages of total sleep classified as deep and REM sleep.

[0122] The x-axis of each diagram 505-a and 505-b is the time (e.g., days) before and after the onset of symptoms, with time=0 indicating the date of onset of the respective user's symptoms. The y-axis of each diagram 505-a and 505-b is z-normalized to show the respective curves on the same graph, with the first diagram 505-a showing the amount of time the respective user spent in REM sleep stages (curve 510-a) and deep sleep stages (curve 510-b), and the second diagram 505-b showing the relative percentage of the user's total sleep classified as REM sleep (curve 510-c) or deep sleep (curve 510-d).

[0123] During sleep, the user exhibits different sleep stages / phases (e.g., deep sleep stage, light sleep stage, REM sleep stage, wakefulness sleep stage). REM and non-REM sleep stages have characteristically different patterns of nervous system balance, and changes in each sleep stage can be used to predict the onset of illness. In particular, the system 200 can be configured to input physiological data collected from the ring 104 (e.g., HRV data, respiration rate data, temperature data, etc.) into a classifier (e.g., machine learning classifier), which classifies the physiological data into each sleep stage. The sleep stage data (e.g., data indicating the duration the user spent in each sleep stage) can then be used to predict illness. In this regard, the classifier / algorithm can create or "learn" the complex interactions that occur between these sleep stages and metrics of nervous system balance or HRV. By looking at these features together, the machine learning classifier can develop a more accurate understanding of the complexities of how the nervous system responds to illness during sleep.

[0124] For example, as shown in the first diagram 505-a, an increase in the amount of time the user spends in REM sleep (e.g., an increase in curve 510-a), as well as a decrease in the amount of time the user spends in deep sleep (e.g., a decrease in curve 510-b) may be used to predict the user's transition from a healthy state to an unhealthy state. Further, as shown in the second diagram 505-b, an increase in the relative proportion of the user's sleep spent in REM sleep (e.g., curve 510-c) and a decrease in the relative proportion of the user's sleep spent in deep sleep (e.g., curve 510-d) may additionally or alternatively be used to predict the onset of a condition.

[0125] In some cases, physiological data obtained from the user may be used in a "sleep intelligent" manner to predict illness. That is, the system 200 may only utilize physiological data collected during certain periods of the night and / or certain sleep stages when predicting illness. For example, chronologically informed features may be determined based on the user's known circadian rhythm and physiology, and features may be extracted from the early evening, late night, or night, when different physiological influences may predominate.

[0126] For example, HRV data collected during periods of REM sleep may be more useful in detecting illness compared to HRV data collected during other sleep stages (e.g., deep sleep stages, light sleep stages). As such, in some implementations, the system 200 may utilize physiological data collected during defined sleep stages, nighttime duration, and / or type of sleep stage when predicting illness. For example, the system 200 may utilize HRV data collected during REM sleep stages within a first time interval (e.g., a reference window) and HRV data collected during REM sleep stages within a second time interval (e.g., a prediction window) to identify the fulfillment of deviation criteria and predict the onset of illness.

[0127] Similarly, the system 200 may utilize physiological data collected at defined time intervals throughout the cycle of the user's natural circadian rhythm to determine illness. For example, according to the user's natural circadian rhythm, physiological changes between approximately 2:00am and 4:00am may be more indicative of illness, as this time interval may correspond to a time when the body naturally tends to increase biological responses to combat illness. As another example, according to the user's natural circadian rhythm, physiological changes within the first 180 minutes after the user's normal bedtime (e.g., the first 180 minutes of expected sleep) and the last 180 minutes before the user's normal wake-up time (e.g., the last 180 minutes of expected sleep) may be more indicative of illness. In other words, the user's natural circadian rhythm may be used to identify absolute and relative time windows that may be of particular interest when determining / predicting illness. Thus, system 200 may identify a user's circadian rhythm and compare physiological data collected within a particular time interval of the circadian rhythm with physiological data collected within the same time interval of the circadian rhythm to detect illness. For example, system 200 may compare HRV data collected between 2:00am and 4:00am with the user's baseline HRV data collected between 2:00am and 4:00am on previous days to determine deviations from the baseline HRV data and detect illness.

[0128] An example for determining / predicting a user's transition from a healthy state to an unhealthy state may be illustrative. In this example, the ring 104 may acquire physiological data from the user over time. For example, the ring 104 may acquire / determine at least one of the user's HRV data, temperature data, pulse waveform data, respiratory rate, heart rate, blood oxygen level, or any combination thereof. Each data stream (e.g., temperature data, heart rate data, HRV data, etc.) may be referred to as a "parameter" of the physiological data. The ring 104 may transmit the acquired / determined physiological data to the user device 106. Additionally, in some aspects, the user device 106 may transmit the acquired physiological data to the server 110.

[0129] The user device 106 and / or server 110 may determine a healthy baseline value / range based on data acquired during a first time interval, which may be referred to herein as a “baseline determination window” or “reference window.” The user device 106 may determine a value used for deviation determination during a second time interval, which may be referred to herein as an “early detection window” or “prediction window.” The prediction window may be a window of time that occurs after the reference window. In some implementations, the reference window may be adjacent to the early detection window such that the two time windows form a continuous time window. In some implementations, the two time windows may be separated from each other by a period of time. In some implementations, the same time window may be used to calculate different baselines / deviations. In some implementations, different time windows may be used to calculate different baselines / deviations. The time windows for the reference window, prediction window, unhealthy time window, and recovery time window may be of any duration. For example, the time windows may be in minutes, hours, days, or weeks.

[0130] The user device 106 and / or server 110 may determine a healthy baseline value / range for each parameter of the physiological data. The healthy baseline value / range may indicate a value and / or a range of values ​​for the user's physiological parameters when the user is in a healthy state. For example, the healthy baseline value / range may indicate a healthy temperature characteristic, a respiration rate characteristic, a HR characteristic, and / or an HRV characteristic. The user device 106 may determine one or more healthy baseline values / ranges for each of the measured physiological parameters. For example, the user device 106 and / or server 110 may determine a healthy baseline HRV range, a healthy baseline respiration rate range, a healthy baseline temperature range, etc. The user device 106 and / or server 110 may determine a healthy baseline value / range for each parameter based on the acquired physiological data within a baseline reference window (e.g., a first time interval). In some implementations, the baseline value / range may be a value / range in the time domain, the frequency domain, or both.

[0131] For purposes of this disclosure, the terms "physiological data," "baseline physiological data," and similar terms may be used to refer not only to collected physiological readings (e.g., temperature readings, heart rate readings, etc.), but also other parameters / characteristics associated with the collected physiological readings, such as frequency, amplitude, phase, etc. For example, the term "baseline temperature data" may refer to the raw / processed temperature readings collected from a user, as well as the frequency content of the temperature data. In this regard, the term "physiological data" and similar terms may be used interchangeably with "physiological parameters," "dynamic physiological parameters," "physiological characteristics," etc. For example, the term "temperature data" may be used interchangeably with the terms "dynamic temperature parameters" or "temperature characteristics" to refer to the raw / processed temperature readings, as well as other rhythmic temperature parameters, such as frequency, amplitude, phase, stability, etc.

[0132] In some cases, the user device 106 and / or server 110 may select a first time interval (e.g., a reference window) and a second time interval (e.g., a prediction window) to be used for disease detection. In some implementations, Bayesian statistical methods may be utilized, where the reference window constitutes the prior distribution and the prediction window constitutes the posterior distribution. In other implementations, Bayesian methods may be used to select an appropriate discrimination threshold at which the model output probability of disease may be classified as actionable or non-actionable from the perspective of a user or employer-based product. For example, the incidence of COVID-19 in a province or employment center or similar demographic may provide a prior distribution for assessing the statistical likelihood of a posterior data-driven distribution.

[0133] Continuing with the same example, the user device 106 and / or server 110 may determine whether one or more parameters of the user's recent (e.g., current) physiological data deviate from one or more of the corresponding healthy baseline values / ranges (e.g., identify the fulfillment of one or more deviation criteria). In some cases, the identification of the fulfillment of the deviation criteria may be performed by a machine learning classifier. The deviation from one or more of the healthy baseline values / ranges may indicate that the user may transition from a healthy state to an unhealthy state. For example, the user device 106 may determine that the user's temperature readings deviate from a determined healthy baseline temperature range and that the user's HRV readings deviate from a determined healthy baseline HRV range. As another example, the user device 106 may determine whether temperature data within an early detection window deviates from one or more of the healthy temperature baseline values / ranges.

[0134] The user device 106 and / or server 110 may then determine whether there may be a transition from a healthy state to an unhealthy state based on a healthy-to-unhealthy transition criterion (e.g., deviation criterion). The deviation criterion may indicate one or more deviations (e.g., temperature deviation criterion, HRV deviation criterion, respiration rate deviation criterion) that, if met, indicate that the user may be transitioning from a healthy state to an unhealthy state. Each healthy baseline value / range may be associated with one or more deviation criteria. In some implementations, a single deviation from a healthy baseline range / value may satisfy the deviation criterion. In some implementations, the deviation criterion may require multiple deviations to occur within a given time interval for one or more physiological parameters, such as one or more HRV deviations, temperature deviations, one or more respiration rate deviations, etc.

[0135] If one or more deviation criteria are met, the user device 106 may notify the user that a transition from a healthy state to an unhealthy state has been detected / predicted. For example, the wearable application 250 may notify the user on the user device 106 within the application GUI 275 or in another manner (e.g., push notification). As another example, if the server 110 makes the decision, the server 110 may notify the user via the web-based GUI 275 or in another manner (e.g., push notification). In some implementations, the GUI 275 may present (e.g., in a dashboard) baseline data and / or physiological data related to the deviation. In some implementations, the GUI 275 may provide summary values ​​(e.g., summary prediction values) that summarize the deviation and / or the decision. In some implementations, the GUI 275 may provide a text notification to the user indicating why there is a prediction that the user may transition to an unhealthy state in the near future.

[0136] In some implementations, the user device 106 and / or server 110 may report one or more risk and / or predictive values ​​(e.g., disease risk value, disease predictive value) to the user. The risk / predictive values, other physiological data / values, and techniques described herein may be used for a variety of purposes in addition to disease detection / prediction. For example, the data / values ​​may be used for diagnosis, prognosis (e.g., who is more likely to need hospitalization or respiratory support), risk stratification (e.g., who is at highest risk), resource allocation decision-making (e.g., who should be tested for COVID-19 and how often individuals should be tested), precision medicine (e.g., which treatment works best on whom), monitoring of treatment effectiveness (e.g., a given treatment resulting in day-to-day improvement), emergency treatment triage, pharmacodynamic / response purposes, and other purposes. Such digital biomarkers could be highly impactful for patients with suspected COVID-19 or influenza-like illness to prevent the spread of the disease, facilitate return to work, and provide early detection in pre-symptomatic or asymptomatic individuals, as well as potentially identifying early prognostic biomarkers of possible subsequent exacerbations.

[0137] In some implementations, the system 200 may be configured to provide some information or other insight regarding the determined illness assessment metric (e.g., illness risk metric, illness prediction metric). The personalized insight may indicate aspects of the collected physiological data used to generate the illness assessment score. For example, if a user does not experience high temperatures (e.g., no fever) but still exhibits a relatively high illness assessment score (e.g., high probability of illness), providing personalized insight may provide additional information that is causing the high illness assessment score. Furthermore, providing personalized insight may promote greater user engagement. Furthermore, personalized insight may provide answers to questions such as "What is causing a high illness assessment score?", "Why is my body temperature normal, so why is my illness assessment score high?", "Why does my illness risk metric (e.g., Health Risk Management (HRM) score) sometimes vary greatly from day to day?", "Why do the readiness score and the HRM score refer to different things?", "I have asthma; is my score high because of my respiratory rate or because I am sensing something else?", etc. In this regard, the insights may explain contributing factors to the sickness assessment score without exposing the raw physiological data, the user's privacy, or details of the algorithms / models used to generate the sickness assessment score.

[0138] For example, the user device 106 may display, via the GUI 275, one or more parameters of the collected physiological data that are the primary contributors to the generated sickness assessment score. For example, if a high sickness assessment score was determined primarily due to a high temperature reading, the GUI 275 may indicate that changes in temperature are the primary reason for the high sickness assessment score. As another example, if a user exhibits an increased respiration rate and elevated resting heart rate, but not an increased temperature, the GUI 275 may indicate that the respiration rate and resting heart rate are the primary reasons for the high sickness assessment score. In other cases, the insight may show a trend of all or the top contributors over time for a given user.

[0139] In some implementations, the system 200 may be configured to receive user inputs regarding detected / predicted illnesses to train a classifier (e.g., supervised learning for machine learning classifiers) and improve illness detection techniques. For example, the user device 106 may display an illness risk metric indicating the relative likelihood of the user becoming unwell. The user may then input one or more user inputs, such as the onset of symptoms, a positive illness test, etc. These user inputs may then be input to the classifier to train it. In other words, the user inputs may be used to validate or confirm the determined illness risk metric.

[0140] While much of the present disclosure has been described in the context of determining / predicting a transition from a healthy state to an unhealthy state based on acquired physiological data (e.g., HRV data, temperature data), aspects of the present disclosure may also be used to determine / predict a transition from an unhealthy state to a healthy state based on acquired physiological data. For example, the user device 106 and / or server 110 may detect a transition based on a temperature biomarker along with other physiological parameters (e.g., pulse waveform data, respiration rate data, heart rate data, HRV data, actigraphy data, galvanic skin response data, oxygen saturation data) to determine / predict when a user will transition (or is currently transitioning) from an unhealthy state to a healthy state. Similar notifications and alerts may be provided to the user (e.g., via the GUI 275) indicating the detected transition.

[0141] Similar techniques using the respective user's baseline temperature range may be used to determine / predict the user's illness at the pre-symptomatic stage. For example, the ring 104 may acquire physiological data (e.g., temperature data) from the user over a first time interval (e.g., a reference window). The temperature data may include skin temperature measured at the user's finger. The temperature data may be sampled at a sampling rate (e.g., 1 sample / minute, etc.) or temperature collection period. In some implementations, the temperature data may be sampled continuously throughout the day and night. While the skin temperature measured at the finger may be used, other temperature measurements (e.g., skin temperature and / or core temperature) may be acquired from different user locations. The ring 104 may transmit the acquired / determined data to the user device 106 or other computing devices (e.g., server 110). Similarly, the user device 106 may transmit the acquired physiological data to the server 110. The user device 106 and / or server 110 may acquire one or more days of temperature data of the user. Additionally, the user device 106 and / or the server 110 may continue to obtain the user's temperature data over time from the ring 104 (eg, via the user device 106).

[0142] In some implementations, the user device 106 and / or the server 110 may filter the received temperature data. For example, the server 110 may apply a low-pass filter to the temperature data. In some implementations, the user device 106 and / or the server 110 may implement one or more transforms when processing the temperature data. For example, the server 110 may implement a discrete wavelet transform (DWT) in combination with a low-pass filter. Filtering the temperature data may reduce the amount of noise and some extreme fluctuations in the temperature data. For example, initial filtering / processing of the temperature data may remove false anomalies, which may allow each device of the system 200 to more clearly identify true anomalies / patterns that may be more indicative of early disease onset. Additionally, the ring 104, the user device 106, the server 110, or other computing devices may perform processing to remove erroneous data readings. For example, temperature or other physiological readings associated with large amounts of activity (e.g., as indicated by a motion sensor) may be removed from the data or otherwise mathematically adjusted by an algorithm. Additionally, temperatures that are not indicative of user temperature, such as a hot shower, may be removed or mathematically adjusted. Removal of erroneous or unreliable data may help ensure more reliable predictions.

[0143] The user device 106 and / or server 110 may then determine baseline temperature data associated with the user based on the temperature data collected throughout the first time interval (e.g., reference window). The baseline temperature data may include linear statistical metrics of the temperature data (e.g., minimum / maximum / average / median temperature readings), as well as dynamic descriptions of the temperature readings, such as temperature periodicity, frequency content (e.g., frequency composition, baseline frequency content), stability of frequency over time (e.g., stability of temperature readings with respect to menstrual phases, ultradian rhythms, circadian rhythms), or any combination thereof, and relationships of these dynamics with other physiological variables.

[0144] In some aspects, the user device 106 and / or server 110 may receive additional temperature data collected by the ring 104 throughout a second time interval (e.g., a prediction window). In this example, the user device 106 and / or server 110 may compare the additional temperature data to the baseline temperature data to identify whether one or more deviation criteria are met. For example, the server 110 may input the baseline temperature data and the additional temperature data into a classifier, which is configured to identify the fulfillment (or lack thereof) of one or more deviation criteria. In some cases, the classifier may compare the temperature data to the baseline temperature data to determine whether the deviation or change between the temperature data and the baseline temperature data meets (e.g., is greater than or equal to) some temperature change threshold. In other words, the classifier may identify the fulfillment of the deviation criteria when the change between the temperature reading / range relative to the user's baseline temperature reading / range exceeds the temperature change threshold.

[0145] The system 200 may then notify the user of the detected / predicted illness based on satisfaction of the deviation criteria. For example, the user device 106 may display, via the GUI 275, an indication of an illness risk metric, which is associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0146] In some cases, the user device 106 and / or server 110 may identify the fulfillment of a deviation criterion (e.g., predict illness) based on a deviation between high and / or low daytime temperature readings (e.g., maximum and / or minimum daytime temperature readings) between the baseline temperature data and the additional temperature data. For example, a change between a user's typical high daytime temperature readings between the baseline temperature data and the additional temperature data that meets a temperature change threshold (e.g., a change above some threshold) may indicate illness. As another example, a change between a user's typical low daytime temperature readings between the baseline temperature data and the additional temperature data that meets a temperature change threshold (e.g., a change above some threshold) may indicate illness. In some cases, a user may deviate in both high and low temperatures prior to the onset of symptoms. Additionally, while large deviations in temperature may indicate the onset of illness, in some implementations, smaller deviations may also indicate the onset of illness. Additionally, determining / predicting illness based on a user's own baseline temperature data may provide a level of personalized detection that may not be available with other illness detection techniques, such as techniques that rely on an increase in absolute temperature values ​​above a typical general temperature threshold (e.g., 37°C).

[0147] In some implementations, the frequency content of the temperature data may also be used to predict illness. For example, the user device 106 and / or the server 110 may receive temperature data from the ring 104 and determine frequency domain physiological data (e.g., frequency domain temperature data). For example, the user device 106 may determine one or more ranges of frequency content over one or more time periods (e.g., night / day). The user device 106 and / or the server 110 may input the calculated frequency domain physiological data values ​​into one or more models / classifiers. The one or more models / classifiers may include any machine learning model, machine learning classifier, or other algorithms known in the art (e.g., random forest classifier, gradient boosted classification tree, neural network algorithm).

[0148] In some implementations, the frequency domain features may be approximated by peak-finding algorithms tuned to similar frequency ranges. These peak (or trough) finding features may quantify the prominence of the peaks, the number of peaks, the distance between adjacent peaks, and the width of the peaks. Such approximation of frequency domain features may enable the algorithm to function in a real-time generative environment while capturing normal circadian and ultradian rhythmic patterns, as well as disruptions to these rhythms that illness may cause. One example of this approximation may be approximating the 22-26 hour circadian rhythm in temperature by including a daily feature that quantifies the daytime minimum and nighttime maximum temperature values. In combination, such features may effectively capture illness-induced changes in the prominence or amplitude of the 22-26 hour circadian rhythm.

[0149] Continuing with the same example, the user device 106 and / or server may determine a healthy temperature baseline value / range based on frequency domain temperature data. For example, the user device 106 may determine a healthy temperature baseline value / range based on temperature data within a temperature baseline determination window. As another example, the user device 106 may determine a healthy temperature baseline value / range based on frequency domain temperature data within a 22-26 hour range that corresponds to the user's circadian rhythm.

[0150] The user device 106 and / or server 110 may determine whether the user's recent (e.g., current) temperature data deviates from one or more of the healthy temperature baseline values / ranges. For example, the user device 106 may determine whether the low frequency signal strength deviates from a healthy range during a second time interval (e.g., a prediction window). As another example, the user device 106 may determine whether the low frequency signal strength for a particular duration within the user's natural circadian rhythm deviates from a healthy baseline for a corresponding duration of the circadian rhythm during a first time interval (e.g., a reference window).

[0151] The user device 106 and / or server 110 may then determine whether there may be a transition from a healthy state to an unhealthy state based on the deviation criteria (e.g., healthy / unhealthy transition criteria). The deviation criteria may include one or more temperature deviation criteria, such as deviations in frequency domain and / or time domain temperature signals. In other words, the user device 106 and / or server may determine whether output from one or more models (e.g., machine learning classifiers) indicates that the user is transitioning from a healthy state to an unhealthy state based on frequency domain features of the temperature data.

[0152] It is noted herein that frequency domain temperature data may provide insight into a user's health state that may not be visually apparent in time domain data. For example, while time domain temperature data may not necessarily indicate a fever or other temperature change, the frequency domain may provide relevant information regarding the user's health state and possible transitions using techniques described herein. Additionally, techniques described herein may analyze data according to a 22-26 hour range that roughly corresponds to circadian rhythms. Additionally, ranges other than time ranges corresponding to circadian rhythms may be used. For example, frequency domain content associated with an 8-12 hour range (e.g., ultradian rhythms), a 2-5 hour range (e.g., ultradian rhythms), and / or a 1-2 hour range (e.g., sleep-related rhythms) may be used. Ranges other than those described herein may also be used in analyzing temperature deviations as well as detecting / predicting a user's transitions between healthy / unhealthy states.

[0153] In some implementations, the frequency analysis of the temperature data may be shown as a heat map or spectrogram. For example, a spectrogram may graphically show the frequency content of a temperature versus time signal (e.g., showing low to high frequency content of the acquired temperature data over time). A spectrogram of frequency domain temperature data may show deviations in low frequency signal strength (e.g., deviations in a range of low frequency power) and may be generated / calculated using various techniques. For example, spectrogram data may be calculated using continuous wavelet transform (CWT) techniques, Fourier transform techniques (e.g., fast Fourier transform), or other techniques.

[0154] The y-axis of the spectrogram of the frequency domain temperature data may indicate units of cycle length in time (e.g., cycle=1 / frequency). In other words, the y-axis may represent the frequency content of the signal in terms of cycle length (e.g., in time units). In some cases, the spectrogram of the frequency domain temperature data may indicate high signal strength corresponding to an approximate circadian rhythm (e.g., within a 22-26 hour period range centered around the 24 hour), which may indicate that the user is transitioning from a healthy state to an unhealthy state, as described above. In some implementations, the user device 106 and / or server 110 may detect / predict a transition to an unhealthy state according to one or more deviation criteria with respect to low frequency signal strength corresponding to the user's approximate circadian rhythm (e.g., a pattern in low frequency signal strength within a 22-26 hour range).

[0155] In some aspects, other "rhythm parameters" of the acquired temperature data (in addition to the frequency content of the temperature data) may be used to identify / predict illness. In general, frequency content is just one component of a user's natural physiological / biorhythm (e.g., circadian rhythm, ultradian rhythm, etc.). Other rhythm-derived parameters (or rhythm evaluation parameters) related to physiological rhythm may include amplitude, stability, phase, etc.

[0156] The deviation criteria (e.g., healthy / unhealthy transition criteria) may include one or more of the deviation and transition criteria described herein, including deviation of low-frequency signal strength (e.g., deviation of low-frequency power / signal strength range). The deviation criteria may be met when a user's frequency-domain temperature data deviates outside a healthy range of low-frequency signal strength (e.g., based on baseline temperature data). In some implementations, a healthy range of frequency-domain temperature data may be defined for each respective user in terms of a range of values ​​above and below a central healthy low-frequency signal strength. For example, the healthy range may be defined as approximately one standard deviation around the center of this range, as determined based on baseline temperature data. As another example, the healthy range may be defined as approximately two standard deviations around the center of the range.

[0157] In additional or alternative implementations, the deviation criteria may be met when the user's low frequency signal strength within the second time interval is outside of a healthy range (determined based on the baseline temperature data) for some threshold period of time. For example, a transition from a healthy state to an unhealthy state may be detected / predicted in response to a deviation above or below the healthy range lasting longer than a threshold period of time. In some implementations, the deviation / transition criteria may include a magnitude condition. For example, a transition from a healthy state to an unhealthy state may be detected / predicted in response to a deviation above or below the healthy range by a threshold magnitude.

[0158] In some implementations, the deviation criteria (e.g., transition criteria) may include a required number of deviations from a healthy range. For example, a transition from a healthy state to an unhealthy state may be detected / predicted in response to a threshold number of deviation criteria (e.g., two or more) being met. In some implementations, a deviation may be required to remain for a threshold period and / or have a threshold magnitude to satisfy the deviation criteria. In some implementations, the deviation criteria may include several deviation polarities. For example, a transition from a healthy state to an unhealthy state may be detected / predicted in response to detecting a low deviation followed by a high deviation. The deviation criteria may include one or more deviations for any of the physiological parameters, such as temperature, respiration rate, heart rate, and HRV. In some implementations, the deviation criteria may be based on deviations in the time domain, the frequency domain, or both.

[0159] In some implementations, a transition from a healthy state to an unhealthy state may be detected / predicted in response to a threshold number of deviation criteria being satisfied, such as satisfaction of a temperature deviation criterion and one or more other deviation criteria. In some implementations, the deviation criteria may include a composite decision in which multiple different deviation criteria are taken into account. For example, different weights may be assigned to different deviations (e.g., heavier weighting for stronger deviation criteria), and a transition from a healthy state to an unhealthy state may be detected / predicted when the sum of the different weighted criteria is greater than a threshold. In some implementations, the deviation criteria may require satisfaction of a defined set of indicators, such as satisfaction of a temperature criterion followed by satisfaction of another transition criterion.

[0160] It has been found that the low frequency signal strength of temperature data may deviate from a healthy baseline range prior to the onset of flu and fever. Deviation of the low frequency signal strength outside the healthy baseline range may indicate that the user may enter an unhealthy state. Additionally, the low frequency signal strength may return to the healthy baseline range prior to recovery. Re-entering the low frequency signal strength into the healthy range may indicate that the user may re-enter a healthy state.

[0161] As described herein, the ring 104 (or other device) may obtain temperature data (e.g., skin temperature data) of the user throughout the day and night. The frequency domain analysis techniques described herein may use any combination of daytime and / or nighttime data for detection / prediction of the user's transitions between healthy / unhealthy states. For example, in some implementations, the computing device (e.g., the ring 104, the user device 106, the server 110) may perform frequency domain analysis on nighttime data, such as consecutive nighttime data (e.g., while the user is asleep). As another example, in some implementations, the computing device may perform frequency domain analysis on data throughout the day and night such that the data includes consecutive days of data during which the user alternates between awake and asleep times. In yet another example, the computing device may perform frequency domain analysis on daytime data such that the data includes consecutive days of data obtained while the user is awake / active.

[0162] The frequency domain analysis techniques described herein may monitor deviations in one or more frequency ranges for one or more different sets of data, such as one or more signal deviations in frequency ranges associated with nighttime data, daytime data, and / or full-day data (e.g., continuous 24-hour data). For example, a computing device may detect / predict a user's transition based on deviations in a single frequency range associated with nighttime data (e.g., data from consecutive nights). As another example, a computing device may detect / predict a user's transition based on deviations in multiple frequency ranges associated with nighttime data. As another example, a computing device may detect / predict a user's transition based on deviations in one or more nighttime frequency ranges and deviations in one or more daytime frequency ranges. In some implementations, a computing device (e.g., user device 106, server 110) may use rules to detect / predict when a user is transitioning between healthy / unhealthy states. For example, the rule(s) may indicate that a transition may occur based on specified deviations in one or more frequency bands for one or more data sets.

[0163] In some implementations, a computing device (e.g., user device 106, server 110) may use one or more models to detect / predict when a user is transitioning between healthy and unhealthy states. The models may use any of the spectrogram data described herein as input. For example, the models may use any of the baseline and deviation values ​​as input. In a particular example, the models may use baseline and deviation values ​​associated with one or more frequency bands in one or more different data sets (e.g., nighttime, daytime, all day). The models may also receive inputs associated with other user physiological parameters (e.g., heart rate, HRV, respiration rate, etc.). The inputs may be formatted in various ways depending on the model. For example, the inputs may include decimal and / or binary values ​​(e.g., deviation yes / no) based on the frequency spectrogram data.

[0164] In some implementations, the model may output a value (e.g., a decimal value between 0 and 1) indicating the likelihood that the user is transitioning between states. The user device 106 and / or server 110 may compare the model output value to a threshold to determine whether a transition to an unhealthy state is likely. In some implementations, various components of the system 200 (e.g., the ring 104, the user device 106, the server 110) may implement one or more machine learning models (e.g., supervised learning models) that are configured to receive inputs and generate output values.

[0165] In some implementations, components of the system 200 (e.g., user device 106, server 110) may select the time intervals (e.g., first time interval / reference window, second time interval / prediction window) to be used for illness detection. In particular, the system 200 may select / identify different time intervals (e.g., different windows) such that physiological data acquired during each of the respective time intervals may be compared to one another. By comparing the physiological data acquired during the different time intervals, the system 200 may determine whether a deviation criterion (e.g., deviation meeting some threshold) is met between the physiological data acquired during the respective time intervals, and fulfillment of the deviation criterion may indicate illness.

[0166] For example, the user device 106 and / or server 110 may select a reference window and a prediction window for the acquired physiological data (e.g., temperature data, HRV data, etc.). In some embodiments, the user device 106 and / or server 110 may define a reference window and a subsequent prediction window for the acquired physiological data. The physiological data acquired during the reference window (e.g., a first time interval) may be used to determine baseline physiological data (e.g., baseline temperature data, baseline HRV data, etc.). In contrast, the physiological data acquired during the prediction window (e.g., a second time interval) may be compared to the baseline physiological data to determine whether a deviation criterion during the respective time interval is met. In some cases, the prediction window may include the most recently acquired temperature data (e.g., temperature data for the most recent 1-5 days).

[0167] In some implementations, the reference window and the prediction window may be defined on a daily basis. For example, the reference window may include one or more days of physiological data (e.g., one week of temperature data). Similarly, the prediction window may include one or more days of temperature data (e.g., employing an autoregressive strategy for feature specification within the prediction window). The size of the reference window and the prediction window may vary depending on the amount of available physiological data. For example, when a minimum amount of physiological data is available, the reference window and the prediction window may have a minimum size or may draw from prior knowledge of demographically / medically similar users. In a particular example, if the server 110 operates with a minimum of two days of physiological data and currently has two days of user physiological data, the server 110 may select the reference window as one day's data and then select the prediction window as the next day's data. Using the minimum amount of available data may enable the server 110 to detect transitions between healthy and unhealthy states sooner than if the server 110 waits to obtain a larger data set for calculation.

[0168] As the user device 106 and / or server 110 obtains more physiological data from the ring 104, the user device 106 and / or server 110 may lengthen the reference window and / or prediction window. For example, the server 110 may lengthen the reference window to establish a more robust set of physiological data for analysis. In a particular example, obtaining a third day of data may cause the reference window to extend to the first two days of data. In this particular example, the prediction window may occupy the most recent day of data (e.g., the third day of data). The server 110 may lengthen the reference window and prediction window to any length. In some implementations, the server 110 may require that the physiological data for a day include a minimum portion of valid data (e.g., within a significant temperature threshold) throughout the day (e.g., for 90% or more of the day). Each of the windows may include one or more days of data, although reference windows and prediction windows including physiological data of other durations may be implemented.

[0169] The reference and prediction windows used for illness detection may be of any length (e.g., amount of time, number of days, etc.). In some cases, the reference window may include seven days of data and the prediction window may include two days of data (e.g., the last two days of data). The reference and prediction windows may be rolling windows that move over time. For example, the windows may move by one day or other units. In some implementations, the windows may be moved by one day such that the prediction calculations are performed by morning (e.g., the user's wake-up time) so that a prediction may be provided to the user before the day begins (e.g., before work).

[0170] Although a single prediction window may be defined, in some implementations, the user device 106 and / or the server 110 may define multiple prediction windows. For example, the multiple prediction windows may occur consecutively after the reference window. Each of the multiple prediction windows may include one or more days of data. In some implementations, the server 110 may initially extend the reference window as new data is received. After extending the reference window to a desired length (e.g., seven days), the server may add one or more additional prediction windows for each day of additional physiological data.

[0171] While the user device 106 and / or the server 110 may use a reference window and a prediction window, in some implementations, aspects of the present disclosure may detect a user's transition between a healthy state and an unhealthy state based on a prediction window without using a reference window. For example, the server 110 may use data from one or more other users (e.g., users with similar demographics, similar physiological data, etc.) to determine whether the user is transitioning between a healthy state and an unhealthy state. The server 110 may only use the prediction window if sufficient data is not available to form a reference window. For example, if only the current day of physiological data is available, the server 110 may use day 1 as the prediction window. The server 110 may then obtain additional data (e.g., additional days) and define both the reference window and the prediction window. If a reference window is unavailable, the server 110 may select detection / prediction parameters (e.g., scoring features) based on similar other users (e.g., similar age, gender, underlying conditions, etc.).

[0172] In some aspects, the user device 106 and / or server 110 may generate a physiological parameter distribution or histogram (e.g., temperature distribution, HRV distribution, etc.) for each window (e.g., reference window, prediction window). For example, in the context of temperature data, the distribution may indicate the number of temperature values ​​that fall within a specified probability range. For example, for a 7-day reference window, the distribution may indicate the number of temperature values ​​in this 7-day window that fall within a specified range. As another example, for a multi-day prediction window, the distribution may indicate the number of temperature values ​​in the multi-day window that fall within a specified range. In implementations where multiple windows are used, the distribution may be done for each of the reference window and / or prediction window. For example, the first and second windows may have corresponding first and second reference / prediction window distributions.

[0173] The user device 106 and / or server 110 may determine one or more physiological parameter distribution values ​​(e.g., temperature distribution value, HRV distribution value) for each of the distributions. The distribution values ​​may be values ​​that indicate how the temperature and other signal values ​​are distributed within a window. For example, the distribution value for a window may indicate the central tendency, variance, kurtosis, and skew of the values ​​within that window.

[0174] The user device 106 and / or the server 110 may determine one or more distributions for each window. In some implementations, each distribution may be associated with a minimum or maximum value associated with the distribution value, and / or a threshold that defines the non-parametric quantiles of the distribution on the lower (e.g., 0.001, 0.01) and upper (e.g., 0.95, 0.975, 0.99) ends of the spectrum. For example, for high temperature deviations, a high percentile temperature value may be used to determine the distribution value. In this example, temperature values ​​above this high percentile temperature value may be defined as high temperature deviations. Stated differently, any temperature above this high threshold temperature value may be considered as high temperature deviations or anomalous. For low temperature deviations, the distribution value may be determined using a low percentile temperature value. In this example, temperature values ​​below a minimum temperature value may be defined as low temperature deviations. Stated differently, any temperature below a minimum temperature threshold may be defined as low temperature deviations or potentially anomalous.

[0175] The thresholds may be defined in various ways. In some implementations, the thresholds may be defined based on values ​​contained in the distribution of the window. For example, the thresholds may be defined as upper / lower quantiles of the distribution. In a particular example, the threshold for a high temperature deviation may be defined as a temperature higher than 95% of the temperatures in the distribution. In another particular example, the threshold for a low temperature deviation may be defined as a temperature that is less than the minimum 5% of the temperatures in the distribution. In some implementations, the distribution and / or thresholds may be determined in other ways. For example, the distribution values ​​and / or thresholds may be determined based on the maximum / minimum temperatures in the distribution, the range of temperatures in the distribution, the mean / median temperatures in the distribution, and / or other factors related to the distribution. The distribution values ​​may also be determined using other processing techniques.

[0176] In some cases, the distribution may be multivariate. For example, given the inherent physiological relationship between activity (or MET units) and temperature, the server may evaluate anomalies or changes to the multivariate distribution. Similarly, distributions of heart rate, HRV, respiration rate, and temperature may be understood within a multivariate context. Coherence, or lack thereof, across several signals and their multivariate time series at several times (e.g., sleep onset) may provide useful features for prediction, detection, or prognosis algorithms.

[0177] The user device 106 and / or server 110 may calculate one or more distribution values ​​for each window. In some implementations, the user device 106 and / or server 110 may calculate a single distribution value for both windows. For example, the server 110 may determine a high temperature distribution value for both windows. A high temperature distribution value may indicate a percentage of temperature values ​​greater than a threshold. For the reference window, the server 110 may calculate a high temperature distribution value by first determining the number of temperature values ​​greater than a threshold. The server 110 may then divide the number of temperature values ​​greater than the threshold by the number of temperature values ​​in the reference window.

[0178] The server 110 may determine high temperature distribution values ​​in the prediction window in a manner similar to that in the reference window. In some implementations, the server 110 may use values ​​from the reference window to define thresholds used in the prediction window. For example, the server 110 may use thresholds (e.g., temperature thresholds) from the reference window as thresholds in the calculations for the prediction window.

[0179] In some implementations, the comparison across the reference window and the prediction window may incorporate reference windows derived from multiple time scales. For example, human behavior may vary significantly on a 7-day cycle due to weekday-weekend changes, resulting in significant physiological changes, while human hormonal cycles (especially in women) vary on an approximately monthly basis, which also specifically results in physiological changes and changes in skin temperature. External temperature may vary on an annual cycle, thereby affecting the anomalies in skin temperature observed in daily life. Thus, an appropriate reference window may incorporate a set of weighted inputs from different information scales, or weight a given current distribution against multiple previous reference distributions measured over a variety of behaviorally and biologically relevant time scales.

[0180] In some implementations, the user device 106 and / or the server 110 may determine multiple distribution values ​​within each window. For example, the server 110 may determine multiple high temperature (or multivariate temperature / activity) distribution values ​​within each window. As another example, the server 110 may determine multiple low temperature distribution values ​​within each window. As another example, the server 110 may determine one or more distribution values ​​for high and low temperatures within a window. In a particular example, the server 110 may determine high temperature distribution values ​​for threshold quantiles of 0.999, 0.995, and 0.975. The server 110 may also determine low temperature distribution values ​​for threshold quantiles of 0.025, 0.01, and 0.001. In implementations in which multiple high / low temperature distribution values ​​are determined, some temperature values ​​above multiple thresholds may be counted twice (e.g., once per distribution value calculation). Alternatively, the distribution values ​​may be calculated based on the number of temperature values ​​between the thresholds. In several iterations, this comparison between the reference window and the early detection / prediction window may be calculated using the Kullback-Leibler (KL) divergence method, or direct density ratio estimation.

[0181] In some aspects, the user device 106 and / or server 110 may analyze the distribution of physiological data (e.g., temperature values, HRV values) within a prediction window compared to a reference window to determine whether the physiological data (e.g., univariate or multivariate distribution values) deviates within the prediction window relative to the reference window. In other words, the user device 106 and / or server 110 may compare physiological data collected within the respective windows to identify the fulfillment (or lack thereof) of deviation criteria that may be used to identify illness.

[0182] For example, the server 110 may determine a relative distribution value (e.g., a relative distribution ratio) indicating the amount of deviation between the temperature values ​​in the prediction window and the temperature values ​​in the reference window. In one example, the server 110 may determine the relative distribution value by dividing the distribution value in the prediction window by the corresponding distribution value in the reference window. In an example where each window has multiple distribution values, the server 110 may determine the relative distribution value for each of the multiple pairs of distribution values.

[0183] The magnitude of the relative distribution value (e.g., relative risk ratio) may indicate the amount of deviation from the reference window to the prediction window. For high temperature deviation, the greater the ratio of high temperature values ​​in the prediction window to the reference window, the greater the relative distribution value for high temperature. For low temperature deviation, the greater the ratio of low temperature values ​​in the prediction window to the reference window, the greater the relative distribution value for low temperature. Thus, a larger relative distribution value may indicate a larger deviation of high / low temperatures between windows. In some implementations, the server 110 may determine whether a user is transitioning from a healthy state to an unhealthy state based on the relative distribution value. For example, the server 110 may include one or more thresholds / models that use the relative distribution value to determine whether a user is transitioning.

[0184] The peaks of the relative distribution values ​​within each window may be used to identify illness. The occurrence of peaks (e.g., 0.999, 0.975, 0.005, 0.001 thresholds) in the relative distribution values ​​may indicate the onset of illness. For example, the number of peaks over time and / or the values ​​of the peaks may indicate the onset of illness. The server 110 may determine whether the user is transitioning from a healthy state to an unhealthy state based on the number of peaks, the values ​​of the peaks, the placement of the peaks, and additional data described herein.

[0185] The user device 106 and / or server 110 may then determine whether the user is transitioning from a healthy state to an unhealthy state based on an analysis of the physiological data distribution (e.g., temperature distribution) within the prediction window and the reference window. For example, the user device 106 and / or server 110 may determine whether the user is transitioning from a healthy state to an unhealthy state based on one or more deviations of the temperature values ​​represented by the determined relative distribution values. In some aspects, the user device 106 and / or server 110 may determine a deviation in the distribution (e.g., temperature distribution) between the early prediction window and the reference window and determine whether the user is transitioning to an unhealthy state based on the determined deviation (e.g., satisfaction of a deviation criterion). In some implementations, the user device 106 and / or server 110 may implement a classifier or other machine learning model to make the state transition decision.

[0186] In some implementations, the server 110 may output a disease risk metric or a disease prediction metric indicating the relative probability that the user will transition from a healthy state to an unhealthy state. For example, the server 110 may determine a disease prediction metric based on one or more of the calculated relative distribution values. In some implementations, the server 110 may generate a single prediction value or multiple prediction values ​​associated with one or more meanings described herein. In some implementations, the prediction value may be a decimal value that may have various meanings depending on how the server 110 is configured. In other implementations, the prediction value may be a binary value, such as a 0 value or a 1 value, that may have various meanings. In some implementations, the disease prediction metric may indicate the likelihood of disease. For example, a decimal value may indicate the probability that the user is transitioning to an unhealthy state. As another example, a binary value of 1 may indicate that the user is transitioning to an unhealthy state. In this example, a binary value of 0 may indicate that the user is in a healthy state and is likely not transitioning.

[0187] The user device 106 and / or the server 110 may determine the disease risk metric (e.g., disease prediction metric) in a variety of different ways. The meaning of the predicted value may depend on how the predicted value is calculated. In some implementations, the server 110 may use a function (e.g., a formula) that receives the relative distribution values ​​and calculates the predicted value based on the relative distribution values. In some implementations, the function may include weightings applied to different relative distribution values. In some implementations, the server 110 may use a rule-based calculation to calculate the predicted value. Exemplary rules may define the predicted value based on the number of relative distribution values ​​above / below a threshold, the magnitude of the relative distribution values, the timing of spikes in the relative distribution values, or any other data related to the magnitude / timing / placement of the relative distribution values ​​and / or other distribution parameters.

[0188] In some implementations, the user device 106 and / or the server 110 may use a machine learning model (e.g., a supervised learning model) to determine a disease risk metric (e.g., a disease prediction metric). The model used to determine the prediction value may be referred to herein as an “early detection / prediction model” or “prediction model.” The prediction model may be trained with training data. The training data may include data from a set of users labeled according to when the users developed disease symptoms. In some implementations, the predictive model may receive the relative distribution value as an input. The predictive model may generate one or more disease prediction values ​​based on the received input. The interpretation of the prediction value(s) may depend on how the model is generated. In some implementations, as described herein, the disease risk metric output by the model may indicate the likelihood of disease if the model is trained using data labeled according to the onset of symptoms.

[0189] In some implementations, the user device 106 and / or the server 110 may implement an autoregressive function (e.g., in the modeling). For example, the server 110 may define multiple prediction windows. In implementations in which the server 110 defines multiple prediction windows, the server 110 may calculate a relative distribution value for each prediction window. In these implementations, the server 110 may generate one or more prediction values ​​based on the relative distribution value for each prediction window. For example, if a prediction model takes the relative distribution value as input, the model may receive twice as many inputs as if two prediction windows were used instead of a single prediction window. Using multiple prediction windows may more closely model diseases that exhibit different behaviors in terms of incubation period, period of viral replication, or expected days to onset of symptoms. For example, using prediction windows on multiple separate days may better capture disease incubation than a single larger prediction window. In some implementations, the autoregressive component may detect phase transitions defined by multiple overshoots in the frequency of diurnal or circadian rhythms superimposed on a multi-day baseline increasing slope reflecting a fever state and / or a set point shift in thermoregulation associated with mediators and / or other sterile or pathogen associated immune stimuli (DAMPs and PAMPs) approaching the date of symptom onset, with the theoretical potential to affect thermoregulation.

[0190] In some implementations, the system 200 may leverage location information associated with each user (e.g., the user's geographic location) to further improve the user's illness detection techniques. The body's ability to maintain internal body temperature within a comfortable range (e.g., not too hot, not too cold) is important for healthy functioning. Changes in environmental temperature (e.g., ambient temperature) are one of the major factors to which the human body must constantly adapt, thus necessitating the human body's "thermostat" setting, or how the body dynamically raises and lowers its body temperature throughout the day in response to various perturbations (e.g., infection, exercise-induced fever, going outside and experiencing rapid changes in temperature, etc.).

[0191] Users living at more extreme latitudes (e.g., near the poles) experience colder climates with greater seasonal variations in light. Thus, users at higher latitudes must adapt to extremes of cold and light. For example, in Helsinki, Finland (approximately 60 degrees north latitude), the monthly mean temperature may range from about -7°C to about 21°C, and the average hours of sunlight may range from about 6 to 19 hours. In contrast, in Crete, Greece (approximately 35 degrees north latitude), the monthly mean temperature may range from about 12°C to 30°C, and the average hours of sunlight may range from about 10 to 14.5 hours. Light exposure is an important regulator of the daily circadian rhythm of temperature.

[0192] Exposure to hot or cold climates affects distal skin temperature, especially during the day, which may result in "ceiling" and "floor" effects that affect illness detection. For example, on average, the 99th percentile of skin temperature readings for a first user living in a colder climate may be slightly lower compared to the 99th percentile of skin temperature readings for a second user living in a warmer climate. This difference may make illness-induced increases in the 99th percentile of skin temperature readings more evident for users living in colder climates. In contrast, in warmer climates, the influence of the external environment on the temporary rise in the 99th percentile skin temperature readings may add more "noise" or partially mask the effects of illness. Therefore, when a larger temperature gradient exists between the body's internal temperature and the ambient temperature (such as in colder climates), a wearable device (e.g., ring 104) may have an advantage in detecting small increases in temperature and heart rate, or decreases in HRV, due to the vasoconstriction response used to prevent excessive heat loss and facilitate core temperature increase.

[0193] In other words, temperature deviations may be more evident for users living in colder climates compared to users living in warmer climates. Thus, skin temperature deviations may be more indicative of illness (e.g., have a higher predictive value) for users in colder climates compared to skin temperature deviations for users in warmer climates. This concept is further illustrated and explained with reference to Figures 6 and 7.

[0194] 6 illustrates an example of a temperature data diagram 600 supporting illness detection techniques according to aspects of the disclosure. In particular, the temperature data diagram 600 includes a first diagram 605-a illustrating high daytime temperature readings / ranges for a user in a colder climate and a second diagram 605-b illustrating high daytime temperature readings / ranges for a user in a warmer climate.

[0195] The x-axis of diagrams 605-a and 605-b shows the time (e.g., days) before and after the onset of symptoms, with time=0 showing the onset of symptoms (e.g., first onset of symptoms) for users in colder climates (e.g., higher latitudes; 55°N) and warmer climates (e.g., lower latitudes; 35°N), respectively. The onset of illness at time=0 in diagrams 605-a and 605-b may encompass a variety of respiratory or influenza-like illnesses, including COVID-19, influenza, and other illnesses with similar symptoms. The y-axis of diagrams 605-a and 605-b shows the high daytime temperature (in degrees Celsius) for users in colder and warmer climates, respectively. Specifically, the y-axis of diagrams 605-a and 605-b shows the 99th percentile (99%ile) of the users' temperature readings during the day, which may be considered the respective users' maximum daytime temperature after filtering outliers.

[0196] As shown in FIG. 605-a, which shows high daytime temperature readings / ranges for users at high latitudes (e.g., near Finland) and / or in colder climates, the maximum daytime temperature measured via the wearable device may be elevated in the days and weeks leading up to the onset of symptoms. Due to the fact that skin temperature at the periphery (e.g., hands, fingers) during the day tends to be lower in colder climates, it may be easier to detect the body's attempt to increase core temperature by vasoconstriction at the periphery. This may also be particularly evident during the day as opposed to sleep, since skin temperature and core temperature are less correlated and more counterregulatory during the day.

[0197] In contrast, referring to FIG. 605-b showing high daytime temperature readings / ranges for users at lower latitudes (e.g., the southern United States) and / or in warmer climates, users may experience less pronounced increases in high daytime temperatures leading to the onset of illness compared to users in colder climates. In other words, for users in warmer climates, an increase in maximum daytime temperatures may not result in a definitive illness. In summary, it has been found that users in colder climates may experience more pronounced increases in high daytime temperatures compared to users in warmer climates.

[0198] 7 illustrates an example of a temperature data diagram 700 supporting illness detection techniques according to aspects of the disclosure. In particular, the temperature data diagram 700 includes a first diagram 705-a illustrating low daytime temperature readings for a user in a colder climate and a second diagram 705-b illustrating low daytime temperature readings for a user in a warmer climate.

[0199] The x-axis of diagrams 705-a and 705-b shows the time (e.g., days) before and after the onset of symptoms, with time=0 showing the onset of symptoms (e.g., first onset of symptoms) for users in colder climates (e.g., higher latitudes; 55°N) and warmer climates (e.g., lower latitudes; 35°N), respectively. The onset of illness at time=0 in diagrams 705-a and 705-b may encompass a variety of respiratory or influenza-like illnesses, including COVID-19, influenza, and other illnesses with similar symptoms. The y-axis of diagrams 705-a and 705-b shows the low daytime temperature (in degrees Celsius) for users in colder and warmer climates, respectively. Specifically, the y-axis of diagrams 705-a and 705-b shows the 1%ile of the user's temperature readings during the day, which may be considered the minimum daytime temperature for the respective user after filtering outliers. Note herein that the absolute values ​​of the y-axis are significantly different across the first diagram 705-a (22-23° C.) compared to the second diagram 705-b (25-28° C.).

[0200] Infection / disease can cause an increase in core temperature. One way for the body to achieve this increase can be to conserve heat by preventing heat loss through the body's shell. The skin achieves this in part by vasoconstriction (narrowing the tiny blood vessels at the skin's surface). This vasoconstriction can be most evident as an increase in the minimum daytime temperature value, as shown in FIG. 7. This phenomenon can be identified and / or characterized for various machine learning algorithms as the 1%ile of the distribution of daytime temperatures taken from one day of a user compared to the previous day or baseline period for the same user.

[0201] For example, as shown in Figures 705-a and 705-b, the 1%ile daytime temperature readings / ranges may rise for users during periods of illness, regardless of latitude or climate. Further, a comparison of Figures 705-a and 705-b shows that users living in colder climates may experience a greater increase in low daytime temperature readings / ranges in the days and weeks leading up to the onset of illness (e.g., a greater pre-onset rise in low daytime temperatures for users in colder climates).

[0202] Thus, in some implementations, the system 200 may utilize location information and other factors (e.g., latitude, season, environmental exposure) to improve the illness prediction techniques described herein. For example, an algorithm or machine learning classifier may utilize a user's latitude or longitude, month, or seasonally corrected time series to make the resulting temperature signal "stationary" for climate-related changes. An algorithm / classifier, such as a tree-based algorithm or other machine learning model, may learn to model the interactions between exposure and environmental factors and an individual user's unique physiological time series. In some cases, the classifier may combine multiple signals that are sensitive to environmental, climate, and seasonal effects to improve the signal-to-noise ratio to better detect illness. Additionally, the classifier may be configured to predict illness differently for a pool of users grouped based on certain similar characteristics, which may include location, climate, and environmental exposure factors.

[0203] Stated differently, latitude and / or other location information may act as a rough proxy for the general range of temperatures in an area, especially when combined with time-based features such as season or month. These features may act as "moderators" or factors that influence the relative predictive value of statistical daytime temperature readings for predicting illness. These moderators may determine the conditions under which a given daytime temperature feature is particularly useful as a predictor of illness or not. In some implementations, the system 200 may use more complex weather and regional information in combination with the user's geolocation from the user device 106 to derive more accurate estimates of environmental exposure and identify when an individual is indoors or outdoors. Such location information may be used to determine the relative predictive accuracy of temperature data for identifying illness.

[0204] For example, the user device 106 and / or server 110 of the system 100 may receive temperature data associated with the user acquired by the ring 104. The user device 106 and / or server 110 may additionally receive / identify location information associated with the user. The location information may include the user's geographic location, the user's latitude, or both. In some cases, the user device 106 and / or server 110 may receive the user's location information based on a user input received via the GUI 275. For example, the user may input a home address or an approximate home location into the wearable application 250. Additionally or alternatively, the user device 106 and / or server 110 may determine the location information based on a global positioning module of the user device 106 (e.g., a global positioning satellite (GPS) module, a global navigation satellite system (GNSS) module), or any combination thereof.

[0205] In this example, the user device 106 and / or server 110 may input temperature data and location data into a machine learning classifier that is configured to identify satisfaction of one or more deviation criteria in the temperature data (e.g., deviation of a temperature reading from baseline temperature data for the user) based on the location information.

[0206] In particular, the location information may be used by the machine learning classifier to identify / generate one or more "predictive weights" associated with the acquired temperature data. The predictive weights may be associated with relative predictive accuracy for detecting illness. For example, as shown and described in FIGS. 6 and 7, a user in a colder climate may experience more significant temperature changes leading up to the onset of illness compared to a user in a warmer climate. Thus, a user's temperature changes (and temperature readings) in a colder climate may have a higher relative "predictive weight" compared to a user's temperature changes / temperature readings in a warmer climate. In some cases, the location data may be used to determine a user's geographic location and / or climate data (e.g., ambient temperature data) that may be used to generate the predictive weights. The ambient temperature data may be based on data acquired from the user device 106, the time of year, climate data for the determined geographic location, or any combination thereof.

[0207] Thus, in some cases, the machine learning classifier may assign a relatively high predictive weight to temperature data collected from users in colder climates and a relatively low predictive weight to temperature data collected from users in warmer climates. Then, upon identifying the predictive weights for the temperature data collected from the user, the machine learning classifier may "weight" the collected temperature data based on (e.g., using) the predictive weights to generate weighted temperature data. The weighted temperature data may then be used by the machine learning classifier to identify fulfillment of deviation criteria and predict illness.

[0208] By determining location information of a user and determining a predictive weight of the temperature data based on the location information (and / or ambient temperature data), the techniques described herein may be configured to compensate for skin temperature responses among users in various climates. In other words, the location information (e.g., latitude) may be used as a rough proxy for the external climate / ambient temperature that may be used to determine the relative predictive accuracy of the temperature data for identifying illness. As such, the techniques described herein may support more accurate and efficient illness detection techniques on an international scale.

[0209] Location may also affect seasonal changes present in biorhythm parameters (e.g., day length, which may be affected by latitude throughout the calendar year, may affect the circadian rhythm parameter of temperature). In this manner, location information may be used in some embodiments to weight or modify classifications of "healthy" and "unhealthy" time intervals where seasonality or seasonal phase is a factor.

[0210] Additionally, in some aspects, if information about disease rates is available in a user's location, individual or group disease detection thresholds or classifiers may be modified. For example, if influenza rates have increased significantly in Miami and the user's location information indicates that the user is located in Miami, the detection threshold may be lowered to reflect the increased local risk.

[0211] In additional or alternative implementations, instead of generating predictive weights for the temperature data, the system 200 may simply input both the temperature data and the location information into a classifier and let the classifier learn which combinations of temperature data and location information predict illness. In other words, the system 200 may input the temperature data and the location information into a classifier (e.g., a machine learning classifier) ​​and train the classifier to determine / predict illness based on the received temperature data and location information. In such a case, the classifier may be trained to recognize that temperature variations across users may exhibit varying predictive accuracy when predicting illness depending on the relative location (and / or climate / ambient temperature) of each respective user.

[0212] In some implementations, the system 200 may additionally or alternatively use data related to modifiable behavioral predictors, such as sleep and activity, to perform illness detection. Scientific evidence has shown that healthy behaviors, such as being more active or sleeping better, can minimize the risk of getting sick with influenza-like illnesses (including COVID-19) and can even modify the strength of antibody responses. However, conventional wearable devices have not effectively identified metrics related to sleep and activity that can be collected via a wearable device to detect illness at a pre-symptomatic stage.

[0213] Some aspects of the predictive algorithms / classifiers used to identify illnesses, such as the user's age, sex, physiology, or existing medical conditions, are generally not modifiable by the user. In contrast, activity and sleep are both health behaviors that can be modified by the user ("modifiable behavioral predictors"). Furthermore, these modifiable behavioral predictors may exhibit changes as the user becomes unwell. As such, the techniques described herein may utilize data collected via the ring 104 related to modifiable behavioral predictors to further refine illness detection techniques during pre-symptomatic conditions. Modifiable behavioral predictors that may be used to perform illness detection may include, but are not limited to, daytime activity, sleep duration, and timing of sleep (e.g., bedtime, wake-up time), adherence associated with wearing the ring 104 (e.g., frequency / consistency with which the user wears the ring 104), and the like.

[0214] A key behavioral sign of the disease is the feeling that one tires easily and has little energy to exercise. This feeling of fatigue is caused by inflammatory proteins (e.g., cytokines) secreted by the immune system upon recognition of virus-infected cells. These inflammatory cytokines signal the brain to conserve energy, and the brain accomplishes this by altering behavior to reduce energy expenditure.

[0215] In some aspects, the ring 104 may be configured to measure activity (e.g., movement) using an actigraphy sensor and / or an accelerometer. The ring 104, the user device 106, and / or the server 110 may be configured to convert actigraphy data and / or other data related to activity (e.g., accelerometer data) and convert these data streams into estimates of METs, which are a measure of energy expended during activity. This may be further shown and described with reference to FIG. 8.

[0216] 8 illustrates an example of a modifiable behavioral predictor diagram 800 supporting illness detection techniques according to aspects of the disclosure. In particular, the modifiable behavioral predictor diagram 800 includes a first diagram 805-a illustrating three activity-related metrics (normalized for comparison) for several days before and after the onset of symptoms, and a second diagram 805-b illustrating sleep-timing-related metrics (e.g., bedtime, wake-up time) for several days before and after the onset of symptoms.

[0217] The x-axis of diagrams 805-a and 805-b shows the time (e.g., days) before and after the onset of symptoms, with time=0 showing the onset of the user's symptoms (e.g., first onset of symptoms). The y-axis of diagram 805-a is z-normalized to show the relative increase and decrease of activity-related metrics over time in the same graph. The y-axis of diagram 805-b shows the change in bedtime and wake-up time in normalized units.

[0218] With reference to diagram 805-a shown in FIG. 8, curve 810-a shows the daily inactivity duration of a user over time, curve 810-b shows the average daily MET (e.g., energy expenditure) of a user over time, and curve 810-c shows the total MET minutes accumulated during moderate or high intensity activity over time. As can be seen in diagram 805-a, the user tends to be inactive for several days before the onset of symptoms (e.g., increase in curve 810-a before the onset of illness). Furthermore, for several days before the onset of symptoms, the average daily MET (energy expenditure) decreases (e.g., decrease in curve 810-b) and the total MET minutes accumulated during moderate or high intensity activity declines (e.g., decrease in curve 810-c). All three curves 810-a, 810-b, 810-c may exhibit the most significant changes after the onset of symptoms, although there is an accelerated predicted change in the direction of decreased activity just prior to the onset of symptoms. As such, in some implementations, the system 200 may utilize these characteristics / parameters (e.g., inactivity, average METs per day, total METs accumulated during activity) to predict illness.

[0219] While a decrease in activity (decrease in curve 810-a) or a decrease in average daily MET (decrease in curve 810-b) may be a useful metric for illness detection, these changes may be slight and activity may change for many reasons other than illness. Furthermore, activity or MET-based metrics may be less meaningful than raw or absolute numbers and more meaningful when constructed to detect declines relative to a person's normal activity level. Thus, in some implementations, each component of the system 200 (e.g., ring 104, user device 106, server 110) may be configured to determine a user's average daily MET as a change relative to the same user's previous median daily MET over a representative prior baseline (e.g., 14 days). In other words, the system 200 may compare the activity and / or daily MET from a second time interval (e.g., a prediction window prior to the onset of symptoms) to the activity and / or daily MET determined from a previous first time interval (e.g., a reference window) to determine the user's expected activity and / or daily MET change. In this regard, changes in activity and daily METs during different time intervals (e.g., changes in daily METs relative to a user's baseline daily METs) may be used to identify fulfillment of deviation criteria and predict the onset of disease.

[0220] In some implementations, the system 200 may utilize a given user's raw absolute average daily MET score as a feature for illness detection, as well as a rolling average of the average daily MET score over the past 30 days (which may be weighted equally or given progressively decreasing weights backwards in time). Including both of these features as inputs to the machine learning classifier / algorithm for illness detection may enable the machine learning classifier to learn a within-user normalization strategy. In other words, by providing the machine learning classifier with the user's past activity and daily MET values, the machine learning classifier may be able to determine recent changes in activity / daily MET relative to the typical level of activity / daily MET for that user over a reference time interval (e.g., over the past month).

[0221] Furthermore, exercise strengthens the immune system, making highly active users less susceptible to infection / disease. Therefore, by using rolling average features of activity and METs per day over some reference window (e.g., the past month), a machine learning classifier may be able to identify individuals with "stronger" immune systems who are less likely to get sick.

[0222] In some implementations, the system 200 may additionally or alternatively include the standard deviation of the average MET per day over some reference window (e.g., the past month) as a feature input in the machine learning classifier to improve disease detection. The standard deviation of the average MET per day may capture how consistently a user engages in high levels of activity. In contrast, the mean (e.g., average) may be large if an individual engages in a lot of exercise one day per week. However, optimal immune system benefits may be associated with a more consistent exercise regimen. Thus, including both the mean and standard deviation of activity over a representative time window (e.g., the past month) may enable the machine learning classifier to learn whether highly active and consistently active users are less likely to get sick.

[0223] Furthermore, a "drop" in average MET due to illness may not be detectable for users who are not active to begin with. In other words, for very inactive users, it may be difficult to detect a decrease in activity relative to the user's usual low activity baseline. Thus, the inclusion of features that capture a user's longer term "trait" or "baseline" activity levels, the consistency of those levels, and even sudden or "state" changes may be most useful when combined together in one model (e.g., a tree or neural network type algorithm) that can learn interactions.

[0224] 9 illustrates an example of a modifiable behavioral predictor diagram 900 that supports illness detection techniques, according to an embodiment of the present disclosure. In particular, the modifiable behavioral predictor diagram 900 includes an activity duration diagram 905-a, an activity consistency diagram 905-b, a MET diagram 905-c, and a weekly pattern diagram 905-d.

[0225] The x-axis of each diagram 905-a-905-d indicates the dates (e.g., month-day) before and after the onset of the symptom, and the baseline between May 11th (05-11) and May 18th (05-18) in each of the diagrams 905 indicates the user's respective onset of the illness symptom (e.g., onset of dry / wet breath, allergic reaction, gastrointestinal symptoms, fever symptoms, etc.). The y-axis of the active duration diagram 905-a indicates the rolling average of active duration (in minutes) over a 30-day window. The y-axis of the active consistency diagram 905-b indicates the standard deviation of active duration (in minutes) over a 30-day window (e.g., more or less active consistency). The y-axis of the MET diagram 905-c represents the MET expenditure per day (e.g., overall performance in terms of effort). Finally, the y-axis of the weekly pattern diagram 905-d shows a true / false indication as to whether a given day on the x-axis includes a weekend day (e.g., 0=weekday, 1=weekend). In general, the weekly pattern diagram 905-d (e.g., weekly pattern adjustment model) may be used to adjust a user's activity expectations based on cyclical weekly patterns, since user activity may generally be higher on weekends.

[0226] As can be seen in FIG. 9, the user may exhibit a decrease in activity duration (e.g., decrease in activity duration diagram 905-a) and decrease in activity consistency (e.g., decrease in activity consistency diagram 905-b) prior to the onset of symptoms. These patterns in activity duration and activity consistency may generally occur at approximately the same time and may be used as features to identify / predict illness. Furthermore, comparing diagram 905 with weekly pattern diagram 905-d, it can be seen that the user generally exhibits higher activity on weekends compared to weekdays. Finally, an increase in activity duration (e.g., increase in activity duration diagram 905-a), increase in activity consistency (e.g., increase in activity consistency diagram 905-b), and increase in MET consumption (e.g., increase in MET diagram 905-c) several days after the onset of symptoms may be indicative of the user returning from an unhealthy state to a healthy state (e.g., recovery from illness).

[0227] In general, the system 200 may input physiological data associated with the activity features shown in FIG. 9 (e.g., activity duration, activity consistency, MET) into a machine learning classifier, which may then learn how to combine multiple activity features to determine a pattern that best describes each user in the pre-symptomatic period. Because each user may respond differently to illness, training a machine learning algorithm using data from each user may enable the machine learning classifier to identify each user's individual response to illness. Thus, the activity features shown in FIG. 9 may be used to identify / predict that a user will transition from an unhealthy state to a healthy state or vice versa.

[0228] In general, activity metrics exhibit "seasonality" or predictable patterns aligned with weekdays and weekends or specific days of the week. For example, as shown in FIG. 9, users may generally be more active on weekends compared to weekdays. Similar periodic patterns may be identified on a monthly, yearly, etc. For example, users may generally be more active in warmer months compared to colder months. This may be either an effect of warmer weather and less rain / snow, or an effect of pandemic lockdowns changing activity lifestyles.

[0229] Thus, in some implementations, the system 200 may utilize one or more models (e.g., pattern adjustment models) that describe relatively periodic activity, behavior, or other physiological parameters over a time interval. The models may include weekly activity models, annual activity models, menstrual cycle models, etc. By considering periodic and predictable changes in activity or other physiological parameters, the techniques described herein may be able to more effectively identify which changes in activity / physiological data are due to illness and which changes are based on predictable periodic user behavior (e.g., being more active on weekends) and / or predictable physiological responses (e.g., monthly menstrual phases).

[0230] For example, in some cases, components of the system 200 (e.g., user device, server 110) may generate features or models (e.g., weekly pattern adjustment models) that represent weekdays as "0" and weekends as "1" (e.g., weekly models: M-0, T-0, W-0, Th-0, F-0, S-1, Su-1). In this example, the weekly pattern adjustment models representing weekdays / weekends may be included with activity features in a machine learning classifier or algorithm (e.g., tree algorithm, gradient boosting classification tree) to improve illness detection. In such a case, the machine learning classifier may build or "learn" feature interactions to account for differences in user activity between weekends and weekdays to improve illness detection. For example, by inputting the weekly pattern adjustment models into the machine learning classifier, the machine learning classifier may be configured to determine that the user is less active on weekdays, and therefore may be less likely to identify low activity metrics (e.g., low MET) on weekdays as indicative of illness. In some cases, the features may be each day of the week, which may be dummy coded as six different days of the week and one reference day.

[0231] In some implementations, the system 200 may apply a seasonal autoregressive moving integral average (SARIMA) model to the historical time series for 30 or more days during which the user was known to be healthy. The seasonal order parameter may be fixed at 7 to capture weekly seasonality. Such a model may be trained for each respective user and output parameters reflecting the degree to which a given user exhibits weekly patterns in activity. These personalized SARIMA coefficients may then be input as features for a larger machine learning classifier based on a rolling window spanning the past N days. Additionally or alternatively, a time series classification model (e.g., a random convolution kernel transform (ROCKET) model or a MiniROCKET model) may be used, which may essentially model autoregressive or other time-dependent patterns.

[0232] In some cases, a user's adherence to wearing a wearable device may include additional modifiable behavioral predictors when performing illness detection / analysis. Borrowing a term from the field of behavioral medicine, "adherence" may refer to whether or not a user wears the ring 104, or how often the user wears the ring (e.g., how often / consistency the user wears the ring 104). It has been found that users generally wear the ring 104 more frequently (e.g., increased adherence in illness) when they become ill. Furthermore, increased adherence has been found to indicate recovery from illness for some users. Indeed, users generally exhibit increased adherence (e.g., more consistent wear time, decreased non-wear time) immediately after the onset of symptoms and during recovery from illness. This may be due to an increased interest in viewing physiological data when the user is ill, or the fact that users may be less likely to remove their ring 104 due to illness or various activities.

[0233] In this regard, the term "adherence data" may refer to data related to the frequency or consistency with which a user wears the ring 104. In some aspects, the ring 104 may determine whether the user is wearing the ring based on the duration the ring 104 is charged, through the presence (or absence) of detected user temperature readings, respiratory rate, heart rate data, and the like. In this regard, the ring 104 may determine and transmit "adherence data" to the user device 106 and / or the server 110, which may be used to determine the adherence with which the user wears the ring 104. Additionally, the adherence data (e.g., changes in the adherence data) may be used by the system 200 to identify the onset of an illness, recovery from an illness, or both. For example, the user device 106 may identify changes in the user's adherence data (e.g., more frequent / consistent wearing of the ring 104, less frequent / less consistent wearing of the ring 104). In this example, the user device 106 may determine a disease risk metric, predict disease onset / disease recovery, or any combination thereof based on changes in adherence data.

[0234] Symptoms of fatigue may include another important behavioral sign of illness. When the body senses an infection, the immune system signals the brain to direct energy to fighting the infection. Sleep timing features for machine learning algorithms may include falling asleep earlier than normal ("earlier bedtime"), falling asleep faster (lower "latency"), sleeping for a longer duration than normal sleep time, waking later than normal, etc. In some implementations, the sickness detection classifier / algorithm described herein may include absolute values ​​in conjunction with features representing previous representative averages or medians over a representative period such as 14 days. In other implementations, the sickness detection algorithm may represent the current day metric as the difference between today's measurements and the median of the past 14 days (or a representative baseline of a reasonable length). Such features may be input into a tree or neural network algorithm, with or without day of week or weekend / weekday binary features.

[0235] For example, refer again to diagram 805-b shown in FIG. 8. The x-axis of diagram 805-b shows the time (e.g., days) before and after the onset of symptoms, where time=0 shows the onset of the user's symptoms (e.g., first onset of symptoms), and the y-axis of diagram 805-b shows the change in bedtime and wake-up time in normalized units. Curve 810-d shows the user's bedtime, quantified as the number of minutes since the previous midnight and calculated as the delta relative to the user's median bedtime over the previous representative baseline period (e.g., the previous 7-14 days). Similarly, curve 810-e shows the user's wake-up time, quantified as the number of minutes since the previous midnight and calculated as the delta relative to the user's median wake-up time over the previous representative baseline period (e.g., the previous 7-14 days).

[0236] As can be seen in diagram 805-b, users generally go to bed earlier (e.g., the decrease in curve 810-d) and wake up later (e.g., the increase in curve 810-e) prior to the onset of illness symptoms. As such, in some implementations, the system 200 may determine the user's sleep data (e.g., bedtime, wake-up time) to determine the onset of illness. In particular, changes in the sleep data (e.g., changes in bedtime and / or wake-up time) may be used to identify the fulfillment (or lack thereof) of deviation criteria, which is then used to identify / predict illness.

[0237] Not all users respond to illness in the same way. Furthermore, viruses and infections may affect users in different ways. Thus, different users may exhibit different sleep patterns across a set of sleep timing variables in response to illness. A classifier (e.g., a machine learning classifier, a machine learning algorithm, a tree-based algorithm) may be configured to automatically detect different sleep data patterns and thresholds across a collection of features, which may improve the illness prediction techniques described herein. Furthermore, by utilizing each user's own sleep data as reference data, the classifier may be trained individually for each user, which allows the classifier to more accurately detect changes in each user's sleep data, thereby predicting illness based on each user's sleep data.

[0238] 10 illustrates an example of a modifiable behavioral predictor diagram 1000 that supports illness detection techniques, according to an aspect of the present disclosure. In particular, the modifiable behavioral predictor diagram 1000 includes a bedtime diagram 1005-a, a wake-up time diagram 1005-b, a sleep duration diagram 1005-c, and a weekly pattern diagram 1005-d.

[0239] The x-axis of each diagram 1005-a-d indicates the dates (e.g., month-day) before and after the onset of the symptom, and the baseline between May 11 (05-11) and May 18 (05-18) in each of the diagrams 1005 indicates the onset of the user's respective illness symptom (e.g., onset of dry / wet breath, allergic reactions, gastrointestinal symptoms, fever symptoms, etc.). The y-axis of bedtime diagram 1005-a indicates the user's bedtime quantified as the minutes since the prior midnight and calculated as a rolling average over a 30-day window. The y-axis of wake time diagram 1005-b indicates the user's wake time quantified as the minutes since the prior midnight and calculated as a rolling average over a 30-day window. The y-axis of sleep duration diagram 1005-c indicates the duration of the user's sleep in seconds per night. Finally, the y-axis of the weekly pattern diagram 1005-d shows a true / false indication as to whether a given day on the x-axis includes a weekend day (e.g., 0=weekday, 1=weekend). In general, the weekly pattern diagram 1005-d can be used to adjust a user's sleep expectations based on cyclical weekly patterns. For example, a user can generally sleep more on weekends when they do not have to be up for work.

[0240] As can be seen in FIG. 9, it has been found that the user may begin to go to bed earlier (e.g., increase in bedtime diagram 1005-a) and wake up later (e.g., increase in awakening diagram 1005-b) in the days leading up to the onset of symptoms. Additionally, the user may sleep longer (e.g., increase in sleep duration diagram 1005-c) in the days leading up to the onset of symptoms. In this regard, these features of the user's sleep data (e.g., bedtime, awakening time, sleep duration) may be input into a classifier (e.g., a machine learning classifier) ​​to identify deviation criteria that may be used to predict the onset of illness.

[0241] The relative consistency of various parameters (e.g., consistency of bedtime, consistency of wake-up time) may also be used to perform the disease detection techniques described herein. Humans generally have consistent sleep habits (e.g., a user typically goes to bed and wakes up at similar times each day). Consistent sleep habits allow cells in the human body to tune to the environment and optimize energy efficiency by knowing the best time to mobilize energy into the bloodstream or fight infection. Thus, consistent sleep habits may help prevent disease.

[0242] Thus, sleep timing parameters / features related to the "consistency" of a user's sleep habits (e.g., bedtime and wake-up time) can be used to predict the onset of illness. Bedtime consistency and wake-up time consistency can be measured as the standard deviation over some reference time interval (e.g., the past 30 days) of the number of minutes since the last midnight that an individual went to sleep or woke up, respectively. In particular, it has been found that both bedtime and wake-up times become more inconsistent (or fluctuate) in the days prior to the onset of symptoms. This may be due to behavioral changes during the incubation period of the illness. Therefore, in some implementations, features / parameters related to the consistency of sleep data (e.g., bedtime consistency, wake-up time consistency, sleep duration consistency) can be used to predict or identify illness, as described herein.

[0243] In some implementations, the system 200 may utilize one or more "pattern adjustment models" to improve the illness detection techniques described herein. The pattern adjustment models may be used to account for predictable changes in a user's behavior, activity, sleep patterns, and / or physiological data. In some implementations, the pattern adjustment models may be used to account for recurring cyclical patterns. The pattern adjustment models may include a weekly pattern adjustment model, a seasonal pattern adjustment model, an annual pattern adjustment model, or any combination thereof.

[0244] For example, as previously described herein with respect to diagram 905-d of FIG. 9 and diagram 1005-d of FIG. 10, the weekly pattern adjustment model may include a series of "0"s and "1"s representing weekdays and weekends, respectively. In this example, the weekly pattern adjustment model may be used (e.g., input into a classifier) ​​to account for changes in the user's sleep and / or activity patterns between weekdays and weekends. Thus, by inputting the weekly pattern adjustment model into the classifier, the system 200 may be able to more effectively distinguish between changes in sleep / activity patterns indicative of an oncoming illness and changes due to normal cyclical changes in behavior throughout the week.

[0245] Similarly, the annual and / or seasonal pattern adjustment models may help the system 200 distinguish between changes in sleep / activity patterns that indicate an oncoming illness and changes due to normal cyclical changes in behavior throughout the year (e.g., users are typically less active during the winter months compared to the summer months). In some implementations, the system 200 may generate a pattern adjustment model for each respective user for each user. In particular, the system 200 may acquire physiological data of the user and generate the pattern adjustment model for the user based on the acquired physiological data.

[0246] For example, by collecting a user's physiological data over a period of several weeks, the system 200 may determine that the user goes to bed later, wakes up later, and is generally more active on weekends compared to weekdays (which may be expressed as a "user activeness metric"). In this regard, the system 200 may generate a weekly pattern adjustment model that captures this information. Thus, by generating a weekly pattern adjustment model for the user, the system 200 may be able to more effectively distinguish between changes in the user's behavior (e.g., sleep patterns, activity patterns) and / or physiological data that are due to illness and those that are simply due to the user's normal weekly routine. For example, inputting the weekly pattern adjustment model into a classifier may reduce the likelihood that the classifier will interpret later bedtimes and later wake-up times on weekends as due to illness.

[0247] In some aspects, the pattern adjustment model may be used to generate "prediction weights" that may improve the disease detection techniques described herein. As previously described herein, a prediction weight may refer to some weighting metric or other metric related to the relative predictive accuracy for detecting a disease. For example, a higher prediction weight may be associated with a higher relative accuracy for predicting a disease (e.g., more accuracy in identifying a disease) and a lower prediction weight may be associated with a lower relative accuracy for predicting a disease (e.g., less accuracy in identifying a disease).

[0248] For example, a user may generally go to bed later, wake up later, and be more active on weekends compared to weekdays. In this example, sleep data indicating later bedtimes and later waketimes on weekends may be associated with a lower "prediction weight" in that these parameters are more likely to be attributable to the user's normal weekly sleep habits rather than indicative of illness. In this regard, the system 200 may utilize the determined pattern adjustment model (e.g., weekly pattern adjustment model, seasonal pattern adjustment model, annual pattern adjustment model) to generate one or more "prediction weights" of the physiological data, sleep data, activity data, etc., which are used to improve the illness detection techniques described herein. In particular, the prediction weights and / or pattern adjustment models may be input into a classifier to determine the fulfillment (or lack thereof) of deviation criteria used to identify illness. In particular, higher user activeness metrics on weekends and lower user activeness metrics on weekdays may be used to determine different "prediction weights" for weekends and weekdays, respectively, and changes in the sleep data, activity data, or both are evaluated against the respective prediction weights.

[0249] In some implementations, the system 200 may utilize a pattern adjustment model (e.g., a menstrual cycle model) configured to account for predictable cyclical changes in physiological data due to normal menstrual cycles. For example, it has been found that naturally cycling users exhibit changes in physiological data based on where each user is in their menstrual cycle. Such temperature deviations may be due to progesterone, a hormone that regulates the menstrual cycle. For example, a user's temperature may vary throughout the user's menstrual cycle, and users may generally exhibit maximum temperature readings during the luteal phase of the menstrual cycle. In this regard, by utilizing a menstrual cycle model, the system 200 may more efficiently determine which changes in physiological data and other parameters (e.g., sleep data, activity data) are due to illness and which changes are simply due to the user's natural menstrual cycle. In particular, the use of a menstrual cycle model may reduce or eliminate the frequency with which the system 200 erroneously interprets natural temperature increases throughout the menstrual cycle as indicative of illness.

[0250] In some implementations, the system 200 may generate a menstrual cycle model for each respective user. In other words, the system 200 may utilize each respective user's physiological data to generate a menstrual cycle model tailored to each respective user. This may be further shown and described with reference to FIG. 11 .

[0251] 11 illustrates an example of a menstrual cycle model 1100 that supports disease detection techniques according to an aspect of the present disclosure. In particular, the menstrual cycle model 1100 illustrates a raw temperature data plot 1105-a, a filtered temperature data plot 1105-b, a square wave temperature data plot 1105-c, and a cycle phase plot 1105-d.

[0252] The x-axis of each of the respective diagrams indicates the time (e.g., date) at which the user's menstrual cycle is evaluated. Raw temperature data diagram 1105-a and filtered temperature data diagram 1105-b show the deviation of the user's daily high temperature reading (in degrees Celsius) measured against the user's average daily high temperature reading over a reference period (e.g., the past 60 days). In other words, the y-axis of diagrams 1105-a and 1105-b shows the intra-user temperature deviation. The y-axis of square wave temperature data diagram 1105-c shows the predicted phase of the cycle, with 1 indicating the luteal phase and 0 indicating the follicular phase. The y-axis of cycle phase diagram 1105-d shows the phase of the user's menstrual cycle from 0 to 1, with 0 indicating the start of a new menstrual phase and 1 indicating the end of a menstrual phase.

[0253] In some aspects, the system 200 may obtain physiological data (e.g., temperature data) from a user over time. In some cases, the user device 106 and / or server 110 may determine a single daily temperature for each day, which typically represents a high nighttime temperature reading for each day. The single high temperature reading is shown in the raw temperature data diagram 1105-a. The user device 106 and / or server 110 may then filter (e.g., apply a bandpass filter) the raw temperature data to generate the filtered temperature data diagram 1105-b. Filtering the temperature data may remove abnormally high or low temperature readings from the raw temperature data diagram 1105-a, which may be due to a hot shower, being in the sun, etc.

[0254] As shown in each diagram 1105, a peak finding algorithm may be used on each diagram 1105 to identify peaks in temperature readings (e.g., temperature readings that are equal to or greater than some temperature threshold). In general, the peak finding algorithm may find peaks in temperature readings that may generally correspond to a particular phase within the menstrual cycle (e.g., the luteal phase). In other words, in some implementations, the peak finding algorithm may be used to identify temperature spikes that may correspond to the end of a menstrual phase during which a user typically experiences a naturally elevated temperature.

[0255] In some cases, the system 200 may implement a peak finding algorithm according to commonly understood knowledge regarding menstrual phases. For example, the menstrual cycle of most women with a natural cycle typically lasts between 20-40 days. As such, in some cases, the peak finding algorithm may be configured to identify peaks that are at least 15 days apart from each other, such that the peak finding algorithm does not identify temperature peaks (and thus menstrual phases) that are less than 15 days apart from each other. In this regard, the system 200 may implement a menstrual cycle duration threshold to generate the menstrual cycle model. The term "menstrual cycle duration threshold" may refer to an estimated timing of a menstrual phase relative to a preceding menstrual phase (e.g., duration during a menstrual phase), an estimated duration timing during a luteal phase relative to a preceding luteal phase, an estimated timing of a follicular phase relative to a preceding follicular phase, or any combination thereof. The use of a menstrual cycle duration threshold may enable the system to more efficiently identify a particular phase within a menstrual cycle in the presence of noisy temperature readings that may be due to birth control and / or menopause. Further, in some implementations, the peak finding algorithm may be configured to identify temperature peaks only if a user's temperature readings have been elevated (eg, meeting some temperature threshold) for a certain number of days.

[0256] The user device 106 and / or server 110 may then identify characteristics of the user's menstrual cycle (e.g., menstrual phase). In some cases, the system 200 may identify the menstrual phase based on peaks identified via a peak-finding algorithm (e.g., based on a menstrual cycle duration threshold). Additionally or alternatively, the system 200 may identify the menstrual phase of the respective user's menstrual cycle based on user input received via the user device 106. For example, the user may enter one or more user inputs via the GUI 275 of the user device 106, the user inputs being associated with the user's menstrual cycle. The user inputs may indicate the start / end of a menstrual phase of the menstrual cycle, an ovulation phase of the menstrual cycle, etc. In some cases, the system 200 may cause the user device 106 (e.g., the GUI 275) to display a prompt for user input related to the user's menstrual cycle, the user input being received in response to the prompt.

[0257] In this regard, the system 200 may be configured to utilize acquired physiological data, user input, or both, to determine characteristics of the user's menstrual cycle (e.g., start / end of menstrual phase, start / end of ovulation phase, start / end of follicular phase, start / end of luteal phase, temperature readings throughout the menstrual cycle, etc.) In some cases, the system 200 may cause the user device 106 to display one or more characteristics of the menstrual cycle to the user (e.g., via the GUI 275).

[0258] The system 200 may then generate a menstrual cycle model for the user based on the identified characteristics of the respective user's menstrual cycle (e.g., based on the identified start / end of the menstrual phase, the identified start / end of the follicular / luteal phase, etc.). For example, as shown in cycle phase diagram 1105-d, the menstrual cycle model may indicate the user's cycle phase. The cycle phase may be measured from 0 to 1 to indicate how far into the entire menstrual phase the user is over time (e.g., percentage of progression). For example, if a user's menstrual phase typically lasts 25 days, then each day will occupy 1 / 25=0.04 of the menstrual cycle. For example, the first day of a new menstrual phase may be represented by 0.04 (1 / 25=0.04) in cycle phase diagram 1105-d, and the second day of a menstrual phase may be represented by 0.08 (2 / 25=0.08) in cycle phase diagram 1105-d. Similarly, the 25th day of the menstrual phase (e.g., the estimated last day) may be represented in the cycle phase diagram 1105-d as a 1 (25 / 25=1), indicating that the menstrual phase is likely at or near the end.

[0259] Upon generating the user's menstrual cycle model, the system 200 may utilize the menstrual cycle model to more efficiently determine the user's scores (e.g., sleep score, readiness score). For example, based on the menstrual cycle model, the classifier may be configured to identify that the user generally exhibits an increased temperature toward the end of each menstrual phase. In this regard, the classifier may be configured to take into account the expected higher temperature during the latter part of the menstrual phase when determining the sleep score and readiness score.

[0260] Additionally, system 200 may be configured to utilize a menstrual cycle model for each respective user to improve the illness detection / prediction techniques described herein. By inputting the user's menstrual cycle model along with the user's physiological data into the classifier, the classifier may be configured to more efficiently identify whether a change in the physiological data (e.g., an increase in temperature reading) is due to an approaching illness or simply due to the user's natural menstrual cycle.

[0261] For example, in some implementations, the system 200 may determine one or more predictive weights for temperature data obtained from the user based on the determined menstrual cycle model. As previously described herein, the predictive weights may be associated with a relative predictive accuracy of the temperature data for predicting illness. In particular, temperature data having a higher predictive weight may be more indicative of illness (e.g., higher predictive accuracy) and temperature data having a lower predictive weight may be less indicative of illness (e.g., lower predictive accuracy). For example, with reference to the cycle phase diagram 1105-d, the system 200 may determine that a higher temperature reading obtained during an earlier portion of the menstrual phase (e.g., days closer to 0 on a scale of 0 to 1) is associated with a higher predictive weight and a higher temperature reading obtained during a later portion of the menstrual phase (e.g., days closer to 1 on a scale of 0 to 1) is associated with a lower predictive weight. These predictive weights may take into account the fact that users naturally exhibit elevated temperature readings near the end of each menstrual phase, and therefore elevated temperature readings toward the end of each menstrual phase are natural, expected, and therefore unlikely to indicate illness.

[0262] As another example, a user's temperature readings taken during the menstrual, luteal, and / or follicular phases may be associated with a relatively low predictive weight (e.g., a lower relative predictive accuracy for detecting illness), whereas a user's temperature readings taken outside the menstrual, luteal, and / or follicular phases may be associated with a relatively high predictive weight (e.g., a higher relative predictive accuracy for detecting illness).

[0263] The user device 106 and / or server 110 may be configured to weight temperature data acquired from the user over time using one or more predictive weights to generate weighted temperature data. By weighting the acquired temperature data, the system 200 (e.g., a classifier implemented by the system 200) may be configured to take into account the fact that elevated temperature readings throughout a natural menstrual cycle may be more or less indicative of illness depending on when throughout the menstrual cycle the respective temperature readings were collected. The weighted temperature readings may then be used to identify fulfillment of deviation criteria used to determine / predict illness.

[0264] In some implementations, the system 200 may be configured to test and validate a classifier, algorithm, or model used to determine / predict illness based on data collected from multiple users. For example, the server 110 of the system 200 may receive training data from a set of user devices 106. Each of the user devices 106 may be associated (e.g., communicatively coupled) with a ring 104 or other wearable device 104 configured to collect physiological data from the respective user. The training data may include collected physiological data (e.g., temperature data, HRV data, etc.) and / or user status data collected from the set of users. Additionally, the server 110 may be configured to generate and transmit illness assessment metrics (e.g., illness risk metrics, illness prediction metrics) to the user devices 106.

[0265] Continuing with the same example, the server 110 may collect physiological data (e.g., temperature data) and user status data from a set of user devices 106. The user status data may include various types of data. For example, the user status data may include symptom data, such as symptom description and timing. The user status data may also include diagnostic conditions. In some implementations, the user status data may include self-reported data that a user may report to the server 110. In other implementations, the user status data may be reported to the server 110 by another party. In some implementations, the self-reported data may be verified by an external source (e.g., a physician's diagnosis and test results). In some implementations, the user status data may include conclusions derived from user physiological data, such as a symptom / illness (e.g., fever) that is determined based on temperature data or other user physiological data.

[0266] Exemplary self-reported data may include symptoms indicative of illness, such as influenza A / B or COVID-19. In other implementations, the symptoms may be more generally associated with cognitive or mental health issues, such as depression and anxiety, as these concerns may also arise in the context of infection or immune dysregulation. In some implementations, the server 110 and / or the user device 106 may provide a list of symptoms / illnesses for the user to select from the web-based GUI 275 and / or application GUI 275. The user status data may be reported at various times. For example, the user status data may be reported once (e.g., at the onset of illness) or multiple times (e.g., daily). In this regard, the illness detection model may be semi-supervised by user feedback in response to receiving an algorithmically generated prediction of the likelihood of illness. For example, the user may be provided with a menu or checklist of options of possible recent behavioral or environmental or health-related changes that may alternatively explain the phase transition detected by the ring or other device. The user's responses to such prompts may then be used (e.g., in a Bayesian fashion) to adjust future predictions for that user.

[0267] Additional exemplary user status data and training data may include, without limitation, 1) blood / swab / biological or medical tests to confirm a diagnosis or to quantify infection / immunity / vaccination response; 2) medical record data; 3) derivation of symptom recall bias based on timing of self-report relative to the time the user reports experiencing symptoms (e.g., a feature in the model to calibrate confidence in self-reports for recall bias that affects subjective symptom reporting); 4) COVID-19 incidence by region (city, zip code, etc.) over time; 5) incidence specific to particular employment centers (e.g., hospital facilities or meatpacking plants or sports teams) and / or occupational roles (e.g., nurses or hospital administrators); 6) census-based data on rural / urban population density, SES, and demographics; 7) weather data on outside temperature, humidity, etc.; and 8) transportation data (e.g., used to derive a metric of whether a user utilizes public transportation and to quantify local population mobility).

[0268] In some implementations, the user status data may include other data, such as user geolocation (e.g., latitude / longitude) associated with the acquired temperature data. Such geolocation data may be used to generate geolocation-specific predictive models. Additionally, the geolocation data may be used to evaluate whether the user is likely to transition to an unhealthy state. The user status data may also indicate the user's place and type of employment, user demographic data (e.g., age and gender), other health conditions, or other data describing the user and / or the user's environment. Any of the user status data described herein may be used to make more targeted predictive models and predictive decisions.

[0269] The server 110 (e.g., a model generation module) may use a training set of data including physiological data (e.g., temperature data) and associated user status data to train one or more illness prediction models (e.g., classifiers, algorithms, or other models used to detect / predict illness). The server 110 may use a variety of differently labeled training data to generate the illness prediction models (e.g., classifiers) described herein. In some implementations, the server 110 may use training data including relative distribution values ​​divided into per-day values. The server 110 may also include a label for each day of the relative distribution data indicating whether the user was healthy or unhealthy. For example, the label may be 1 for unhealthy (e.g., onset of symptoms) and 0 for healthy. In this example, the illness prediction model may generate an illness risk metric for the user. In some cases, the illness risk metric may include an illness prediction value between 0 and 1 indicating the likelihood that the user is transitioning to an unhealthy state. The server 110 may generate the illness prediction model using multiple days (e.g., weeks) of data for each user.

[0270] The server 110 may then test / validate the performance of one or more disease prediction models (e.g., classifiers). In some implementations, the server 110 may test / validate the performance of one or more disease prediction models by comparing the output from the one or more disease prediction models with the training data. In other words, the server 110 may use supervised learning techniques to test / validate the performance of the one or more disease prediction models. The server 110 may then generate a disease assessment metric (e.g., disease risk metric, disease prediction value) for the user using the one or more disease prediction models as described herein, and the disease assessment metric is associated with the probability or likelihood that the respective user will transition from a healthy state to an unhealthy state.

[0271] In some implementations, the user device 106 and / or the server 110 may generate and / or interpret illness assessment metrics (e.g., illness risk metrics, illness predictors) based on the characteristics of the respective users. For example, the server 110 may generate and / or interpret illness risk metrics based on the user's location. In one example, a user in a geolocation where the disease is more prevalent at the time may be alerted to illness with a lower probability of display than a user in a geolocation where the disease is not prevalent (e.g., using Bayesian statistics or other methods). Similarly, the server 110 may generate / interpret illness risk metrics based on similarity to other users, such as users in the same location / employment type (e.g., same office, same frontline work, etc.), including cluster or mixture modeling techniques. In this case, the server 110 may alert the user to a possible illness with a lower probability if others in the workplace were feeling unwell. In some implementations, the thresholds may be set by the manager / employer. One or more predictive models may be trained and / or used based on the user characteristics.

[0272] 12 illustrates an example of a health management platform 1200 that supports disease detection techniques according to aspects of the present disclosure. The health management platform 1200 may implement or be implemented by aspects of the system 100, the system 200, or both.

[0273] The health management platform 1200 may be configured to perform health monitoring (e.g., HRM services) of one or more users 102. In particular, the health management platform 1200 may be configured to monitor (e.g., continuously monitor) physiological data of one or more users 102 to provide physiological data, disease risk metrics, and the like to some administrator (e.g., administrator user device 106-d) associated with the one or more users 102. In some implementations, the administrator user device 106-d may be operated by or associated with a medical professional (e.g., doctor, nurse), an organizational administrator (e.g., business owner, business manager), a personal trainer, a coach (e.g., sports team coach), and the like. In this regard, the health management platform 1200 may be configured to provide health-related information (e.g., disease risk scores) associated with the one or more users 102 to some administrator (administrator user device 106-d).

[0274] The administrator user device 106-d may include an example of the user device 106 shown in FIG. 2. In some implementations, the administrator user device 106-d may include one of the user devices 106-a, 106-b, and / or 106-c. In other words, in some cases, one of the users 102-a, 102-b, 102-c may include an administrator that receives health-related information of each of the respective users 102-a, 102-b, 102-c. In other cases, the administrator user device 106-d may include another device such that the administrator is not one of the users 102-a, 102-b, 102-c.

[0275] For example, the health management platform 1200 may include a first user 102-a, a second user 102-b, and a third user 102-c. The users 102-a, 102-b, 102-c may be associated with corresponding wearable devices (e.g., rings 104-a, 104-b, 104-c, respectively) and corresponding user devices 106-a, 106-b, 106-c. As described herein with reference to FIG. 2, each of the rings 104-a, 104-b, 104-c may be configured to continuously acquire physiological data (e.g., temperature information, HRV information, respiration rate information) associated with the respective user 102-a, 102-b, 102-c. The ring 104 may be configured to continuously acquire physiological data at regular or irregular intervals and transmit the acquired physiological data to the corresponding user device 106-a, 106-b, 106-c.

[0276] The user devices 106-a, 106-b, 106-c may then be configured to perform processing operations on the physiological data received from their respective rings 104-a, 104-b, 104-c. Additionally or alternatively, the user devices 106-a, 106-b, 106-c may transmit (e.g., relay, forward) the received physiological data to one or more servers 110 (e.g., via the network 108), which are configured to perform the processing operations described herein.

[0277] In some implementations, the health management platform 1200 may cause the GUI of the administrator user device 106-d to display all or a portion of the physiological data acquired from each user and / or the parameters calculated / identified based on the acquired physiological data. For example, if the administrator user device 106-d is associated with a clinic administrator for users 102-a, 102-b, 102-c, the administrator user device 106-d may receive and display physiological data associated with each user 102, sleep data (e.g., sleep stages, sleep duration) of each user 102, etc. In this regard, the health management platform 1200 may enable health-related data for each of the respective users to be continuously reported to applicable medical professionals or other users, which may enable more accurate and comprehensive medical decisions for each user 102.

[0278] In some implementations, the health management platform 1200 may report disease-related metrics (e.g., disease risk metrics, disease prediction metrics) to the administrator user device 106-d. For example, the user devices 106-a, 106-b, 106-c and / or the server 110 may be configured to determine a disease risk metric (e.g., disease prediction metric, disease evaluation metric) for each of the respective users 102-a, 102-b, 102-c. Each component may be configured to determine the disease risk metric according to the techniques described herein, such as using one or more classifiers (e.g., machine learning classifiers). The user devices 106-a, 106-b, 106-c and / or the server 110 may then report the disease risk metric to the administrator user device 106-d. In this regard, the user devices 106-a, 106-b, 106-c and / or the server 110 cause the GUI of the administrator user device 106-d to display at least one disease risk metric for at least one of the users 102.

[0279] In some implementations, the health management platform 1200 may display the physiological data and / or the disease risk metric on the administrator user device 106-d based on a comparison of the respective disease risk metrics. For example, the administrator user device 106-d may display the disease risk metric of each user in order from the user 102 with the highest risk of disease (e.g., highest disease risk score) to the user 102 with the lowest risk of disease (e.g., lowest disease risk score). In other cases, the disease risk scores may be displayed on the administrator user device 106-d in some other order.

[0280] In some aspects, the health management platform 1200 may report (via the administrator user device 106-d) physiological data and / or disease risk metrics based on one or more user inputs received via the administrator user device 106-d and / or other user devices 106. The user inputs may be associated with identifying disease risk metrics, reporting disease risk metrics, or both. In other words, the user inputs may be used to adjust how disease risk metrics are reported, which disease risk metrics are reported, etc. The user inputs may be associated with thresholds for identifying disease risk metrics, thresholds for reporting disease risk metrics, or both.

[0281] For example, an administrator may input (e.g., via the administrator user device 106-d) thresholds for reporting illness risk metrics. In this example, the health management platform 1200 may be configured to report illness risk metrics to the administrator user device 106-d only if the respective illness risk metric meets (e.g., is equal to or greater than) the threshold. In this regard, the health management platform 1200 may be adjusted such that an illness alert is generated only if the health management platform 1200 predicts, with some threshold confidence, that the user 102 will become ill. Such techniques may reduce the volume of alerts sent to the administrator user device 106-d.

[0282] In some aspects, the health management platform 1200 (e.g., server 110, user devices 106-a, 106-b, 106-c) may cause the administrator user device 106-d to display one or more recommendations. The recommendations may be associated with the determined illness risk metric of each user 102-a, 102-b, 102-c. For example, the administrator user device 106-d may display a recommendation for the user 102 to schedule a doctor's appointment, a recommendation for the user 102 to stay home and take time off work or some other activity, a recommendation for the user to quarantine, a recommendation for the user 102 to prepare for a potential illness (e.g., stay hydrated, rest), etc. Thus, the health management platform 1200 may help prevent the spread of illness and may prevent a potential outbreak of illness.

[0283] In some cases, the health management platform 1200 may generate recommendations (via the administrator user device 106-d) for users 102 other than the user 102 predicted to be ill. For example, if the server 110 predicts that a first user 102-a is likely to be ill (e.g., high illness risk metric) and the first user 102-a shares a cubicle with a second user 102-b, the server 110 may cause the administrator user device 106-c to display a recommendation for the second user 102-b to schedule a doctor's appointment or stay home from work based on the illness risk metric of the first user 102-a and potential contact between the first user and the second user 102.

[0284] Further, the health management platform 1200 may be configured to modify the illness risk metric of one user 102 based on the illness risk metric of another user 102. For example, continuing with the above example, the first user 102-a and the second user 102-b may share a cubicle. This information may be entered into the health management platform 1200 via the administrator user device 106-d and used to determine potential contact between the users 102-a and 102-b and / or potential proximity between the users 102-a and 102-b. In this example, the server 110 may determine a first illness risk metric of the first user 102-a and a second illness risk metric of the second user 102-b. The first illness risk metric may indicate that the first user 102-a is unwell or is highly likely to become unwell. As such, the server 110 may be configured to selectively modify (e.g., selectively increase) a second disease risk metric of a second user 102-b based on the first disease risk metric of the first user 102-a and / or potential contact / potential proximity between the respective users 102-a and 102-b.

[0285] 13 shows a block diagram 1300 of a device 1305 supporting illness detection techniques according to an aspect of the disclosure. The device 1305 may include an input module 1310, an output module 1315, and a wearable application 1320. The device 1305 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0286] The input module 1310 may provide a means for receiving information, such as packets, user data, control information, or any combination thereof, associated with various information channels (e.g., control channels, data channels, information channels associated with disease detection techniques). The information may be passed to other components of the device 1305. The input module 1310 may utilize a single antenna or a set of multiple antennas.

[0287] The output module 1315 may provide a means for transmitting signals generated by other components of the device 1305. For example, the output module 1315 may transmit information such as packets, user data, control information, or any combination thereof, associated with various information channels (e.g., control channels, data channels, information channels associated with disease detection techniques). In some examples, the output module 1315 may be co-located with the input module 1310 in a transceiver module. The output module 1315 may utilize a single antenna or a set of multiple antennas.

[0288] For example, the wearable application 1320 may include a data acquisition component 1325, a temperature data component 1330, a classifier component 1335, a user interface component 1340, or any combination thereof. In some examples, the wearable application 1320 or its various components may be configured to perform various operations (e.g., receiving, monitoring, transmitting) using or otherwise cooperating with the input module 1310, the output module 1315, or both. For example, the wearable application 1320 may receive information from the input module 1310, transmit information to the output module 1315, or be integrated in combination with the input module 1310, the output module 1315, or both to receive information, transmit information, or perform various other operations as described herein.

[0289] The wearable application 1320 may support automatically detecting illness according to examples disclosed herein. The data acquisition component 1325 may be configured or otherwise support as a means for receiving temperature data associated with the user from the wearable device, the temperature data being collected via the wearable device through a first time interval. The temperature data component 1330 may be configured or otherwise support as a means for identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. The data acquisition component 1325 may be configured or otherwise support as a means for receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The classifier component 1335 may be configured or otherwise support as a means for inputting the baseline temperature data and the additional temperature data into a classifier. The classifier component 1335 may be configured or otherwise support as a means for using the classifier to identify fulfillment of one or more deviation criteria between the baseline temperature data and the additional temperature data. The user interface component 1340 may be configured as or otherwise support a means for causing a GUI of a user device to display a disease risk metric associated with a user based at least in part on the satisfaction of one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0290] FIG. 14 illustrates a block diagram 1400 of a wearable application 1420 supporting illness detection techniques according to aspects of the disclosure. The wearable application 1420 may be an example of a wearable application or an aspect of the wearable application 1320, or both, as described herein. The wearable application 1420, or various components thereof, may be examples of means for performing various aspects of the illness detection techniques described herein. For example, the wearable application 1420 may include a data acquisition component 1425, a temperature data component 1430, a classifier component 1435, a user interface component 1440, a frequency content component 1445, a location information component 1450, a user input component 1455, or any combination thereof. Each of these components may communicate directly or indirectly with one another (e.g., via one or more buses).

[0291] The wearable application 1420 may support automatically detecting illness according to examples disclosed herein. The data acquisition component 1425 may be configured or otherwise support as a means for receiving temperature data associated with the user from the wearable device, the temperature data being collected via the wearable device through a first time interval. The temperature data component 1430 may be configured or otherwise support as a means for identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. In some examples, the data acquisition component 1425 may be configured or otherwise support as a means for receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The classifier component 1435 may be configured or otherwise support as a means for inputting the baseline temperature data and the additional temperature data into a classifier. In some examples, the classifier component 1435 may be configured as or otherwise support a means for using a classifier to identify fulfillment of one or more deviation criteria between the baseline temperature data and the additional temperature data. The user interface component 1440 may be configured as or otherwise support a means for causing a GUI of the user device to display a disease risk metric associated with the user based at least in part on the fulfillment of one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0292] In some examples, the frequency content component 1445 may be configured or otherwise support a means for identifying baseline frequency content of baseline temperature data associated with a user. In some examples, the frequency content component 1445 may be configured or otherwise support a means for identifying additional frequency content of additional temperature data. In some examples, the classifier component 1435 may be configured or otherwise support a means for inputting the baseline frequency content and the additional frequency content into a classifier, where identifying satisfaction of one or more deviation criteria is based at least in part on the baseline frequency content and the additional frequency content.

[0293] In some examples, the temperature data component 1430 may be configured or otherwise support a means for identifying a first high daytime temperature range within the baseline temperature data for at least a first day within a first time interval. In some examples, the temperature data component 1430 may be configured or otherwise support a means for identifying a second high daytime temperature range within additional temperature data for at least a second day within a second time interval, the first high daytime temperature range and the second high daytime temperature range being equal to or greater than a percentile threshold of temperature readings collected from the user within the first day and the second day, respectively, and identifying a fulfillment of the one or more deviation criteria based at least in part on the first high daytime temperature range, the second high daytime temperature range, or both.

[0294] In some examples, to support identifying satisfaction of one or more deviation criteria, the temperature data component 1430 may be configured as or otherwise support a means for identifying that a change between a first high daytime temperature range and a second high daytime temperature range exceeds a temperature change threshold.

[0295] In some examples, the temperature data component 1430 may be configured or otherwise support a means for identifying a first low daytime temperature range within the baseline temperature data for at least a first day within a first time interval. In some examples, the temperature data component 1430 may be configured or otherwise support a means for identifying a second low daytime temperature range within additional temperature data for at least a second day within a second time interval, the first low daytime temperature range and the second low daytime temperature range being below a percentile threshold of temperature readings collected from the user within the first day and the second day, respectively, and identifying fulfillment of the one or more deviation criteria based at least in part on the first low daytime temperature range, the second low daytime temperature range, or both.

[0296] In some examples, to support identifying satisfaction of one or more deviation criteria, the temperature data component 1430 may be configured as or otherwise support a means for identifying that a change between a first low daytime temperature range and a second low daytime temperature range exceeds a temperature change threshold.

[0297] In some examples, the temperature data component 1430 may be configured or otherwise support a means for identifying a first subset of baseline temperature data collected by the wearable device within a diurnal interval for each day in the first time interval. In some examples, the temperature data component 1430 may be configured or otherwise support a means for identifying a second subset of additional temperature data collected by the wearable device within a diurnal interval for each day in the second time interval, and inputting the temperature data into the classifier includes inputting the first subset of baseline temperature data and the second subset of additional temperature data into the classifier.

[0298] In some examples, the temperature data component 1430 may be configured as or otherwise support a means for identifying a daytime interval based at least in part on location information associated with a user, a sunrise-sunset calendar, an identified bedtime associated with a user, an identified wake-up time associated with a user, or any combination thereof.

[0299] In some examples, the location information component 1450 may be configured or otherwise support a means for identifying location information associated with a user for at least a portion of the first time interval and at least a portion of the second time interval. In some examples, the classifier component 1435 may be configured or otherwise support a means for inputting the location information into a classifier, the classifier being configured to identify fulfillment of one or more deviation criteria based at least in part on the location information.

[0300] In some examples, the location information component 1450 may be configured or otherwise support a means for identifying ambient temperature data associated with a user's geographic location based at least in part on the location information. In some examples, the classifier component 1435 may be configured or otherwise support a means for inputting ambient temperature data into a classifier, where identifying satisfaction of one or more deviation criteria is based at least in part on the ambient temperature data.

[0301] In some examples, the location information component 1450 may be configured with or otherwise support a means for identifying climate data, time of year, or both, and identifying the ambient temperature data is based at least in part on the climate data, time of year, or both.

[0302] In some examples, to support identifying location information, the user input component 1455 may be configured as or otherwise support a means for receiving an indication of location information from a user device.

[0303] In some examples, the location information includes the geographic location of the user, the latitude of the user, or both.

[0304] In some examples, the classifier component 1435 may be configured with or otherwise support a means for using the classifier to identify one or more predictive weights associated with the additional temperature data based at least in part on the location information, the one or more predictive weights being associated with a relative predictive accuracy for detecting illness, and identifying fulfillment of one or more deviation criteria being based at least in part on the one or more predictive weights.

[0305] In some examples, the classifier component 1435 may be configured as or otherwise support a means for using the classifier to weight the additional temperature data based at least in part on the one or more predictive weights to generate weighted temperature data. In some examples, the data acquisition component 1425 may be configured as or otherwise support a means for receiving additional physiological data associated with the user from the wearable device, the additional physiological data being collected via the wearable device throughout the first and second time intervals. In some examples, the classifier component 1435 may be configured as or otherwise support a means for inputting the additional physiological data into the classifier, and identifying fulfillment of the one or more deviation criteria is based at least in part on the weighted temperature data, the additional physiological data, or a combination thereof.

[0306] In some examples, to support receiving temperature data throughout the first time interval, the data acquisition component 1425 may be configured as or otherwise support a means for receiving multiple temperature readings associated with a user in accordance with a temperature collection periodicity throughout each of the multiple days of the first time interval.

[0307] In some examples, the wearable device includes a wearable ring device.

[0308] In some examples, the wearable device collects physiological data from the user based on arterial blood flow.

[0309] In some examples, the user device includes a user device associated with the user, a user device associated with an administrator associated with a group of users that includes the user, or both.

[0310] In some examples, the temperature data and the additional temperature data are associated with a plurality of users including the user, and the temperature data component 1430 may be configured as or otherwise support a means for identifying baseline temperature data associated with each user of the plurality of users based at least in part on the received temperature data. In some examples, the temperature data and the additional temperature data are associated with a plurality of users including the user, and the classifier component 1435 may be configured as or otherwise support a means for inputting the baseline temperature data of each user of the plurality of users into a classifier. In some examples, the temperature data and the additional temperature data are associated with a plurality of users including the user, and the classifier component 1435 may be configured as or otherwise support a means for using a classifier to identify a disease risk metric associated with each user of the plurality of users based at least in part on the baseline temperature data of each respective user. In some examples, the temperature data and the additional temperature data are associated with a plurality of users including the user, and the user interface component 1440 may be configured as or otherwise support a means for causing a GUI of the administrator user device to display at least one disease risk metric associated with at least one user of the plurality of users.

[0311] FIG. 15 illustrates a diagram of a system 1500 including a device 1505 supporting disease detection techniques according to an aspect of the disclosure. The device 1505 may be or include an example of a component of the device 1305 as described herein. In some implementations, the device 1505 may include an example of a user device 106 as described herein. The device 1505 may include components for bidirectional communication with the wearable device (e.g., the ring 104) and the server 110, such as a communication module 1510, an antenna 1515, a wearable application 1520, a user interface component 1525, a database 1530, a memory 1535, and a processor 1540. These components may be in electronic communication via one or more buses (e.g., a bus 1545) or may be otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically).

[0312] The communication module 1510 may manage input and output signals for the device 1505 via the antenna 1515. The communication module 1510 may include an example of the communication module 220-b of the user device 106 shown and described in FIG. 2. In this regard, the communication module 1510 may manage communications with the ring 104 and the server 110 as shown in FIG. 2. The communication module 1510 may also manage peripherals that are not integrated into the device 1505. In some cases, the communication module 1510 may represent a physical connection or port to an external peripheral. In some cases, the communication module 1510 may utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or another known operating system. In other cases, the communications module 1510 may represent or interact with a wearable device (e.g., the ring 104), a modem, a keyboard, a mouse, a touch screen, or similar devices. In some cases, the communications module 1510 may be implemented as part of the processor 1540. In some examples, a user may interact with the device 1505 via the communications module 1510, a user interface component 1525, or via hardware components controlled by the communications module 1510.

[0313] In some cases, the device 1505 may include a single antenna 1515. However, in some other cases, the device 1505 may have two or more antennas 1515 that may be capable of simultaneously transmitting or receiving multiple wireless transmissions. The communications module 1510 may communicate bidirectionally via one or more antennas 1515, wired links, or wireless links as described herein. For example, the communications module 1510 may represent a wireless transceiver and may communicate bidirectionally with another wireless transceiver. The communications module 1510 may also include a modem for modulating packets and providing the modulated packets to one or more antennas 1515 for transmission and demodulating packets received from the one or more antennas 1515.

[0314] The user interface component 1525 may manage data storage and processing in the database 1530. In some cases, a user may interact with the user interface component 1525. In other cases, the user interface component 1525 may operate automatically without user interaction. The database 1530 may be an example of a single database, a distributed database, multiple distributed databases, a data store, a data lake, or an emergency backup database.

[0315] The memory 1535 may include RAM and ROM. The memory 1535 may store computer-readable, computer-executable software that includes instructions that, when executed, cause the processor 1540 to perform various functions described herein. In some cases, the memory 1535 may include a basic I / O system (BIOS), which may control basic hardware or software operations such as interaction with peripheral components or devices, among other things.

[0316] The processor 1540 may include intelligent hardware devices (e.g., a general purpose processor, a digital signal processor (DSP), a central processing unit (CPU), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, the processor 1540 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into the processor 1540. The processor 1540 may be configured to execute computer readable instructions stored in the memory 1535 to perform various functions (e.g., functions or tasks supporting the methods and systems for sleep staging algorithms).

[0317] The wearable application 1520 may support automatically detecting illness according to examples disclosed herein. For example, the wearable application 1520 may be configured as or otherwise support a means for receiving temperature data associated with a user from a wearable device, the temperature data being collected via the wearable device through a first time interval. The wearable application 1520 may be configured as or otherwise support a means for identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. The wearable application 1520 may be configured as or otherwise support a means for receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The wearable application 1520 may be configured as or otherwise support a means for inputting the baseline temperature data and the additional temperature data into a classifier. The wearable application 1520 may be configured or otherwise support a means for using a classifier to identify fulfillment of one or more deviation criteria between the baseline temperature data and the additional temperature data. The wearable application 1520 may be configured or otherwise support a means for causing a GUI of the user device to display a disease risk metric associated with the user based at least in part on the fulfillment of the one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0318] By including or configuring the wearable application 1520 according to examples described herein, the device 1505 may support techniques for improved disease detection / prediction. In particular, the techniques described herein may enable disease detection at a pre-symptomatic stage based on temperature data that may be acquired via the wearable device 104. Additionally, the techniques described herein may utilize location data in conjunction with temperature data to improve disease detection techniques. Thus, by enabling disease detection at a pre-symptomatic stage, the techniques described herein may limit the spread of disease and reduce the severity of the disease.

[0319] FIG. 16 illustrates a flowchart illustrating a method 1600 for supporting illness detection techniques according to aspects of the disclosure. The operations of the method 1600 may be implemented by the user device 106 or components thereof as described herein. For example, the operations of the method 1600 may be performed by the user device 106 as described with reference to FIGS. 1-15. In some examples, the user device 106 may execute a set of instructions to control functional elements of the user device 106 to perform the described functions. Additionally or alternatively, the user device 106 may use dedicated hardware to perform aspects of the described functions.

[0320] At 1605, the method may include receiving temperature data associated with the user from the wearable device, the temperature data being collected via the wearable device throughout a first time interval. The operations of 1605 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1605 may be performed by a data acquisition component 1425, as described with reference to FIG.

[0321] At 1610, the method may include identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. The operations of 1610 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1610 may be performed by temperature data component 1430, as described with reference to FIG.

[0322] At 1615, the method may include receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The operations of 1615 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1615 may be performed by a data acquisition component 1425, as described with reference to FIG.

[0323] At 1620, the method may include inputting the baseline temperature data and the additional temperature data into a classifier. The operations of 1620 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1620 may be performed by the classifier component 1435, as described with reference to FIG.

[0324] At 1625, the method may include using a classifier to identify satisfaction of one or more deviation criteria between the baseline temperature data and the additional temperature data. The operations of 1625 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1625 may be performed by a classifier component 1435, as described with reference to FIG.

[0325] At 1630, the method may include causing a GUI of the user device to display a disease risk metric associated with the user based at least in part on satisfaction of one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state. The operations of 1630 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1630 may be performed by a user interface component 1440, as described with reference to FIG.

[0326] FIG. 17 illustrates a flowchart illustrating a method 1700 for supporting illness detection techniques according to aspects of the disclosure. The operations of method 1700 may be implemented by user device 106 or components thereof as described herein. For example, the operations of method 1700 may be performed by user device 106 as described with reference to FIGS. 1-15. In some examples, user device 106 may execute a set of instructions to control functional elements of user device 106 to perform the described functions. Additionally or alternatively, user device 106 may use dedicated hardware to perform aspects of the described functions.

[0327] At 1705, the method may include receiving temperature data associated with the user from the wearable device, the temperature data being collected via the wearable device throughout a first time interval. The operations of 1705 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1705 may be performed by a data acquisition component 1425, as described with reference to FIG.

[0328] At 1710, the method may include identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. The operations of 1710 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1710 may be performed by temperature data component 1430, as described with reference to FIG.

[0329] At 1715, the method may include receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The operations of 1715 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1715 may be performed by the data acquisition component 1425, as described with reference to FIG.

[0330] At 1720, the method may include identifying baseline frequency content of baseline temperature data associated with the user. The operations of 1720 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1720 may be performed by frequency content component 1445, as described with reference to FIG.

[0331] At 1725, the method may include identifying additional frequency content of the additional temperature data. The operations of 1725 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1725 may be performed by frequency content component 1445, as described with reference to FIG.

[0332] At 1730, the method may include inputting the baseline frequency content and the additional frequency content into a classifier. The operations of 1730 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1730 may be performed by the classifier component 1430, as described with reference to FIG.

[0333] At 1735, the method may include using a classifier to identify satisfaction of one or more deviation criteria between the baseline frequency content and the additional frequency content. The operations of 1735 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1735 may be performed by a classifier component 1435, as described with reference to FIG.

[0334] At 1740, the method may include causing a GUI of the user device to display a disease risk metric associated with the user based at least in part on satisfaction of one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state. The operations of 1740 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1740 may be performed by a user interface component 1440, as described with reference to FIG.

[0335] FIG. 18 illustrates a flowchart illustrating a method 1800 for supporting illness detection techniques according to aspects of the disclosure. The operations of the method 1800 may be implemented by the user device 106 or components thereof as described herein. For example, the operations of the method 1800 may be performed by the user device 106 as described with reference to FIGS. 1-15. In some examples, the user device 106 may execute a set of instructions to control functional elements of the user device 106 to perform the described functions. Additionally or alternatively, the user device 106 may use dedicated hardware to perform aspects of the described functions.

[0336] At 1805, the method may include receiving temperature data associated with the user from the wearable device, the temperature data being collected via the wearable device throughout a first time interval. The operations of 1805 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1805 may be performed by the data acquisition component 1425, as described with reference to FIG.

[0337] At 1810, the method may include identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. The operations of 1810 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1810 may be performed by temperature data component 1430, as described with reference to FIG.

[0338] At 1815, the method may include receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The operations of 1815 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1815 may be performed by a data acquisition component 1425, as described with reference to FIG.

[0339] At 1820, the method may include inputting the baseline temperature data and the additional temperature data into a classifier. The operations of 1820 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1820 may be performed by the classifier component 1435, as described with reference to FIG.

[0340] At 1825, the method may include identifying a first high daytime temperature range within the baseline temperature data for at least a first day within the first time interval. The operations of 1825 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1825 may be performed by temperature data component 1430, as described with reference to FIG.

[0341] At 1830, the method may include identifying a second high daytime temperature range within the additional temperature data for at least a second day within the second time interval, the first high daytime temperature range and the second high daytime temperature range being equal to or greater than a percentile threshold of temperature readings collected from the user within the first day and the second day, respectively. The operations of 1830 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1830 may be performed by temperature data component 1430, as described with reference to FIG.

[0342] At 1835, the method may include using a classifier to identify a fulfillment of one or more deviation criteria between the baseline temperature data and the additional temperature data, where identifying the fulfillment of the one or more deviation criteria is based at least in part on a first high daytime temperature range, a second high daytime temperature range, or both. The operations of 1835 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1835 may be performed by a classifier component 1435, as described with reference to FIG. 14.

[0343] At 1840, the method may include causing a GUI of the user device to display a disease risk metric associated with the user based at least in part on satisfaction of one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state. The operations of 1840 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1840 may be performed by a user interface component 1440, as described with reference to FIG.

[0344] FIG. 19 illustrates a flowchart illustrating a method 1900 for supporting illness detection techniques according to aspects of the disclosure. The operations of the method 1900 may be implemented by the user device 106 or components thereof as described herein. For example, the operations of the method 1900 may be performed by the user device 106 as described with reference to FIGS. 1-15. In some examples, the user device 106 may execute a set of instructions to control functional elements of the user device 106 to perform the described functions. Additionally or alternatively, the user device 106 may use dedicated hardware to perform aspects of the described functions.

[0345] At 1905, the method may include receiving temperature data associated with the user from the wearable device, the temperature data being collected via the wearable device throughout a first time interval. The operations of 1905 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1905 may be performed by the data acquisition component 1425, as described with reference to FIG.

[0346] At 1910, the method may include identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval. The operations of 1910 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1910 may be performed by temperature data component 1430, as described with reference to FIG.

[0347] At 1915, the method may include receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval. The operations of 1915 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1915 may be performed by the data acquisition component 1425, as described with reference to FIG.

[0348] At 1920, the method may include identifying location information associated with the user for at least a portion of the first time interval and at least a portion of the second time interval. The operations of 1920 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1920 may be performed by location information component 1450, as described with reference to FIG.

[0349] At 1925, the method may include inputting the baseline temperature data, the additional temperature data, and the location information into a classifier. The operations of 1925 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1925 may be performed by a classifier component 1435, as described with reference to FIG.

[0350] At 1930, the method may include identifying a fulfillment of one or more deviation criteria between the baseline temperature data and the additional temperature data using a classifier, the classifier configured to identify the fulfillment of the one or more deviation criteria based at least in part on the location information. The operations of 1930 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1930 may be performed by a classifier component 1435, as described with reference to FIG.

[0351] At 1935, the method may include causing a GUI of the user device to display a disease risk metric associated with the user based at least in part on satisfaction of one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state. The operations of 1935 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1935 may be performed by a user interface component 1440, as described with reference to FIG.

[0352] A method for automatically detecting illness is described. The method may include receiving HRV data associated with a user from a wearable device, the HRV data collected via the wearable device over a first time interval and a second time interval subsequent to the first time interval, inputting the HRV data into a classifier, using the classifier to identify fulfillment of one or more deviation criteria between a first subset of the HRV data collected over the first time interval and a second subset of the HRV data collected over the second time interval, and causing a GUI of the user device to display an illness risk metric associated with the user based at least in part on the fulfillment of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0353] An apparatus for automatically detecting illness is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to receive HRV data associated with a user from a wearable device, the HRV data collected via the wearable device over a first time interval and a second time interval subsequent to the first time interval, input the HRV data to a classifier, use the classifier to identify a fulfillment of one or more deviation criteria between a first subset of the HRV data collected over the first time interval and a second subset of the HRV data collected over the second time interval, and cause a GUI of the user device to display an illness risk metric associated with the user based at least in part on the fulfillment of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0354] Another apparatus for automatically detecting illness is described. The apparatus may include means for receiving HRV data associated with a user from a wearable device, the HRV data collected via the wearable device over a first time interval and a second time interval subsequent to the first time interval, means for inputting the HRV data to a classifier, means for using the classifier to identify fulfillment of one or more deviation criteria between a first subset of the HRV data collected over the first time interval and a second subset of the HRV data collected over the second time interval, and means for causing a GUI of the user device to display an illness risk metric associated with the user based at least in part on the fulfillment of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0355] A non-transitory computer-readable medium storing code for automatically detecting illness is described. The code may include instructions executable by a processor to receive HRV data associated with a user from a wearable device, the HRV data collected via the wearable device through a first time interval and a second time interval subsequent to the first time interval, input the HRV data to a classifier, use the classifier to identify fulfillment of one or more deviation criteria between a first subset of the HRV data collected through the first time interval and a second subset of the HRV data collected through the second time interval, and cause a GUI of the user device to display an illness risk metric associated with the user based at least in part on the fulfillment of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0356] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for determining frequency content of the HRV data throughout at least a portion of the first time interval and at least a portion of the second time interval, and identifying satisfaction of the one or more deviation criteria may be based at least in part on the frequency content.

[0357] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, determining the frequency content of the HRV data may include operations, features, means, or instructions for determining low frequency content of the HRV data and determining high frequency content of the HRV data, and identifying satisfaction of one or more deviation criteria may be based at least in part on the low frequency content, the high frequency content, or both.

[0358] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a discrepancy between low frequency content of the HRV data and high frequency content of the HRV data between the first time interval and the second time interval, and identifying satisfaction of one or more deviation criteria may be based at least in part on identifying the discrepancy.

[0359] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for receiving physiological data associated with a user from a wearable device, where the physiological data is collected via the wearable device through a first time interval and a second time interval, identifying a plurality of sleep stages associated with the user based at least in part on the physiological data, and identifying a first portion of the HRV data corresponding to a first sleep stage of the plurality of sleep stages in the first time interval and a second portion of the HRV data corresponding to a second sleep stage of the plurality of sleep stages in the second time interval, where the first sleep stage and the second sleep stage comprise a same type of sleep stage, and inputting the HRV data to the classifier includes inputting the first portion of the HRV data and the second portion of the HRV data.

[0360] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying at least a first portion of the first time interval and a second portion of the second time interval based at least in part on a circadian rhythm associated with the user, and identifying a first portion of the HRV data corresponding to the first portion of the first time interval and a second portion of the HRV data corresponding to the second portion of the second time interval, wherein inputting the HRV data to the classifier includes inputting the first portion of the HRV data and the second portion of the HRV data.

[0361] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying an RMSSD metric associated with the HRV data, and identifying satisfaction of one or more deviation criteria may be based at least in part on the RMSSD metric.

[0362] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for receiving physiological data associated with a user from a wearable device, where the physiological data is collected via the wearable device through a first time interval and a second time interval, identifying resting heart rate data, HRV averaged score data, recovery metric data, or any combination thereof based at least in part on the physiological data, and inputting the resting heart rate data, HRV averaged score data, recovery metric data, or any combination thereof into a classifier, where identifying satisfaction of one or more deviation criteria may be based at least in part on the resting heart rate data, HRV averaged score data, recovery metric data, or any combination thereof.

[0363] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a decrease in resting heart rate data between the first and second time intervals, a decrease in HRV averaged score data between the first and second time intervals, an increase in recovery metric data between the first and second time intervals, or any combination thereof, and identifying satisfaction of the one or more deviation criteria may be based at least in part on a decrease in resting heart rate data, a decrease in HRV averaged score data, an increase in recovery metric data, or any combination thereof.

[0364] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for receiving physiological data associated with a user from a wearable device, where the physiological data is collected via the wearable device through a first time interval and a second time interval, inputting the physiological data into a classifier and classifying the physiological data collected through the first time interval and the second time interval into a plurality of sleep intervals within the first time interval and the second time interval, where each sleep interval of the plurality of sleep intervals is associated with one of a wake sleep stage, a light sleep stage, a REM sleep stage, or a deep sleep stage, and identifying satisfaction of the one or more deviation criteria may be based at least in part on classifying the physiological data.

[0365] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a first change in a first duration of a sleep stage associated with a REM sleep stage between the first time interval and the second time interval, a second change in a second duration of a sleep stage associated with a deep sleep stage between the first time interval and the second time interval, or both, and identifying satisfaction of the one or more deviation criteria may be based at least in part on the first change, the second change, or both.

[0366] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for receiving user input via the user device and in response to causing the GUI to display the disease risk metric, and using the user input to train a classifier.

[0367] In some examples of the methods, devices, and non-transitory computer-readable media described herein, the user input indicates a positive disease test, the onset of disease symptoms, or both.

[0368] Some examples of the methods, devices, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying respiration rate data associated with a user based at least in part on the HRV data and inputting the respiration rate data into a classifier, and identifying satisfaction of one or more deviation criteria may be based at least in part on the respiration rate data.

[0369] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the wearable device includes a wearable ring device.

[0370] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the wearable device collects HRV data from the user using arterial blood flow as a basis.

[0371] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the user device includes a user device associated with a user, a user device associated with an administrator associated with a group of users that includes the user, or both.

[0372] In some examples of the methods, apparatus, and non-transitory computer-readable medium described herein, the HRV data may be associated with a plurality of users including the user, and the methods, apparatus, and non-transitory computer-readable medium may include further operations, features, means, or instructions for using the classifier to identify a disease risk metric associated with each user of the plurality of users based at least in part on the HRV data of each respective user, and causing a GUI of the administrator user device to display at least one disease risk metric associated with at least one user of the plurality of users.

[0373] A method for automatically detecting illness is described. The method may include receiving temperature data associated with a user from a wearable device, the temperature data being collected via the wearable device through a first time interval, identifying baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval, receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval, inputting the baseline temperature data and the additional temperature data into a classifier, using the classifier to identify satisfaction of one or more deviation criteria between the baseline temperature data and the additional temperature data, and causing a GUI of the user device to display an illness risk metric associated with the user based at least in part on the satisfaction of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0374] An apparatus for automatically detecting illness is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to receive temperature data associated with a user from a wearable device, the temperature data being collected via the wearable device through a first time interval, identify baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval, receive additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device through a second time interval after the first time interval, input the baseline temperature data and the additional temperature data into a classifier, use the classifier to identify satisfaction of one or more deviation criteria between the baseline temperature data and the additional temperature data, and cause a GUI of the user device to display an illness risk metric associated with the user based at least in part on the satisfaction of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0375] Another apparatus for automatically detecting illness is described. The apparatus may include means for receiving temperature data associated with a user from a wearable device, the temperature data collected via the wearable device over a first time interval, means for identifying baseline temperature data associated with the user based at least in part on the temperature data collected over the first time interval, means for receiving additional temperature data associated with the user from the wearable device, the additional temperature data collected via the wearable device over a second time interval after the first time interval, means for inputting the baseline temperature data and the additional temperature data to a classifier, means for using the classifier to identify satisfaction of one or more deviation criteria between the baseline temperature data and the additional temperature data, and means for causing a GUI of the user device to display an illness risk metric associated with the user based at least in part on the satisfaction of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0376] A non-transitory computer readable medium storing code for automatically detecting illness is described. The code may include instructions executable by a processor to receive temperature data associated with a user from a wearable device, the temperature data collected via the wearable device through a first time interval, identify baseline temperature data associated with the user based at least in part on the temperature data collected through the first time interval, receive additional temperature data associated with the user from the wearable device, the additional temperature data collected via the wearable device through a second time interval after the first time interval, input the baseline temperature data and the additional temperature data to a classifier, use the classifier to identify satisfaction of one or more deviation criteria between the baseline temperature data and the additional temperature data, and cause a GUI of the user device to display an illness risk metric associated with the user based at least in part on the satisfaction of the one or more deviation criteria, the illness risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

[0377] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying baseline frequency content of baseline temperature data associated with the user, identifying additional frequency content of the additional temperature data, and inputting the baseline frequency content and the additional frequency content into a classifier, where identifying satisfaction of one or more deviation criteria may be based at least in part on the baseline frequency content and the additional frequency content.

[0378] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a first high daytime temperature range within the baseline temperature data for at least a first day within a first time interval and identifying a second high daytime temperature range within additional temperature data for at least a second day within a second time interval, where the first high daytime temperature range and the second high daytime temperature range may be equal to or greater than a percentile threshold of temperature readings collected from the user within the first day and the second day, respectively, and identifying satisfaction of the one or more deviation criteria may be based at least in part on the first high daytime temperature range, the second high daytime temperature range, or both.

[0379] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, identifying satisfaction of the one or more deviation criteria may include an operation, feature, means, or instruction for identifying that a change between a first high daytime temperature range and a second high d...

Claims

1. 1. A method for automatically detecting a disease, comprising: Identifying a menstrual cycle model associated with a menstrual cycle of a user; receiving physiological data associated with the user from a wearable device, the physiological data including at least temperature data collected via the wearable device over a first time interval and a second time interval subsequent to the first time interval; inputting the physiological data and the menstrual cycle model into a classifier; using the classifier to identify satisfaction of one or more deviation criteria between a first subset of the temperature data collected over the first time interval and a second subset of the temperature data collected over the second time interval based on at least the menstrual cycle model; and displaying, on a graphical user interface of a user device, a disease risk metric associated with the user based on at least the satisfaction of the one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

2. Identifying the satisfaction of one or more deviation criteria between the first subset of the temperature data collected over the first time interval and the second subset of the temperature data collected over the second time interval includes:

2. The method of claim 1, further comprising identifying whether a deviation between the first subset of temperature data and the second subset of temperature data is based at least on the menstrual cycle of the user or at least on an approaching illness.

3. 2. The method of claim 1, further comprising: using the classifier to identify one or more prediction weights associated with the temperature data based at least on the menstrual cycle model, the one or more prediction weights being associated with a relative predictive accuracy for detecting disease, and identifying the satisfaction of the one or more deviation criteria is based at least on the one or more prediction weights.

4. 4. The method of claim 3, further comprising: weighting the temperature data using the classifier based at least on the one or more predictive weights to generate weighted temperature data, wherein identifying the fulfillment of the one or more deviation criteria is based at least on the weighted temperature data.

5. 4. The method of claim 3, wherein a first predictive weight associated with a first portion of temperature data collected during a menstrual phase of the menstrual cycle, a luteal phase of the menstrual cycle, a follicular phase of the menstrual cycle, or any combination thereof, is associated with a lower relative predictive accuracy for detecting illness, and a second predictive weight associated with a second portion of temperature data collected outside the menstrual phase of the menstrual cycle, the luteal phase of the menstrual cycle, the follicular phase of the menstrual cycle, or any combination thereof, is associated with a higher relative predictive accuracy for detecting illness.

6. 2. The method of claim 1, wherein the first subset of temperature data is associated with a time period of the user's menstrual cycle during the first time interval, and the second subset of temperature data is associated with the same time period of the user's menstrual cycle during the second time interval.

7. receiving, via the user device, one or more user inputs related to a start of a menstrual phase of the menstrual cycle, an end of the menstrual phase of the menstrual cycle, an ovulation phase of the menstrual cycle, or any combination thereof; The method of claim 1 , further comprising: generating the menstrual cycle model based on at least the one or more user inputs.

8. receiving additional physiological data associated with the user from the wearable device, the additional physiological data being collected via the wearable device over a third time interval preceding at least a portion of the first time interval; identifying one or more characteristics associated with the menstrual cycle of the user based on at least the additional physiological data; The method of claim 1 , further comprising: generating the menstrual cycle model based on at least one or more identified characteristics.

9. causing the graphical user interface of the user device to display a prompt related to the menstrual cycle of the user based at least on identifying the one or more characteristics; 10. The method of claim 8, further comprising receiving, via the user device, one or more user inputs in response to the prompt, wherein generating the menstrual cycle model is based at least on the one or more user inputs.

10. 9. The method of claim 8, wherein the one or more characteristics include a start of a menstrual phase of the menstrual cycle, an end of the menstrual phase of the menstrual cycle, an ovulation phase of the menstrual cycle, temperature readings throughout the menstrual cycle, or any combination thereof.

11. Identifying the one or more characteristics associated with the menstrual cycle may further comprise:

9. The method of claim 8, comprising identifying a plurality of temperature readings that meet a temperature threshold based on at least the additional physiological data, wherein each temperature reading of the plurality of temperature readings corresponds to a menstrual phase of the menstrual cycle, a luteal phase of the menstrual cycle, a follicular phase of the menstrual cycle, or any combination thereof.

12. 12. The method of claim 11, further comprising identifying a menstrual cycle duration threshold associated with the menstrual cycle, the menstrual cycle duration threshold being associated with an estimated timing of the menstrual phase relative to a preceding menstrual phase, an estimated timing of the luteal phase relative to a preceding luteal phase, an estimated timing of the follicular phase relative to a preceding follicular phase, or any combination thereof, wherein each menstrual phase of a plurality of menstrual phases is identified based on at least the menstrual cycle duration threshold.

13. 2. The method of claim 1, further comprising: using the classifier to generate one or more scores associated with the user based on at least the physiological data and the menstrual cycle model, the one or more scores including a sleep score, a readiness score, or both.

14. The method of claim 1 , further comprising causing the graphical user interface of the user device to display one or more characteristics of the menstrual cycle model.

15. The physiological data is associated with a plurality of users including the user, the physiological data being collected via a plurality of wearable devices associated with the plurality of users, and the method further comprising: identifying a menstrual cycle model associated with each user of the plurality of users; inputting the menstrual cycle model for each user of the plurality of users into the classifier; identifying a disease risk metric associated with each of the plurality of users based on at least the physiological data and the menstrual cycle model for each respective user using the classifier; The method of claim 1 , further comprising: causing a graphical user interface of an administrator user device to display at least one disease risk metric associated with at least one user of the plurality of users.

16. The method of claim 1 , wherein the wearable device comprises a wearable ring device.

17. The method of claim 1 , wherein the wearable device collects the physiological data from the user based on arterial blood flow.

18. The method of claim 1 , wherein the user devices include a user device associated with the user, a user device associated with an administrator associated with a group of users that includes the user, or both.

19. 1. An apparatus for automatically detecting a disease, comprising: A processor; a memory coupled to the processor; instructions stored in the memory; The instructions cause the device to: Identifying a menstrual cycle model associated with a menstrual cycle of a user; receiving physiological data associated with the user from a wearable device, the physiological data including at least temperature data collected via the wearable device over a first time interval and a second time interval subsequent to the first time interval; inputting the physiological data and the menstrual cycle model into a classifier; using the classifier to identify satisfaction of one or more deviation criteria between a first subset of the temperature data collected over the first time interval and a second subset of the temperature data collected over the second time interval based on at least the menstrual cycle model; The apparatus is executable by the processor to cause a graphical user interface of a user device to display a disease risk metric associated with the user based on at least the satisfaction of the one or more deviation criteria, the disease risk metric being associated with a relative probability that the user will transition from a healthy state to an unhealthy state.

20. to identify the satisfaction of one or more deviation criteria between the first subset of the temperature data collected over the first time interval and the second subset of the temperature data collected over the second time interval. The instructions further include causing the device to:

20. The apparatus of claim 19, wherein the apparatus is executable by the processor to identify whether a deviation between the first subset of temperature data and the second subset of temperature data is based at least on the menstrual cycle of the user or at least on an approaching illness.

Images