Disease detection based on neurological metrics

Abstract

Methods, systems, and apparatus for disease detection are described. The methods may include receiving heart rate variability (HRV) data associated with a user from a wearable device, the HRV data being collected via the wearable device over a first time interval and a second time interval following the first time interval. The method may include feeding the HRV data into a classifier and identifying a deviation criterion between a first subset of the HRV data collected during the first time interval and a second subset of the HRV data collected during the second time interval. The method may include causing a graphical user interface (GUI) of the user device to display a disease risk measure for the user based on the satisfaction of the deviation criterion, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

Description

[0001] CROSS-REFERENCE

[0002] This Patent Application claims the benefit of U.S. Nonprovisional Patent Application No. 17 / 357,562 by PHO et al., entitled “ILLNESS DETECTION BASED ON NERVOUS SYSTEM METRICS,” filed June 24, 2021, which claims priority to the following applications: U.S. Provisional Patent Application No. 63 / 043,892 by RAI et al., entitled “DETECTING TRANSITIONS BETWEEN HEALTHY AND UNHEALTHY STATES,” filed June 25, 2020, U.S. Provisional Patent Application No. 63 / 049,405 by Aschbacher et al., entitled “DETECTING TRANSITIONS BETWEEN HEALTHY AND UNHEALTHY STATES,” filed July 8, 2020, and U.S. Provisional Patent Application No. 63 / 116,981 by RAI et al., entitled “DETECTING TRANSITIONS BETWEEN HEALTHY AND UNHEALTHY STATES,” filed November 23, 2020, each of which is expressly incorporated by reference herein. TECHNICAL FIELD

[0003] The following relates to wearable devices and data processing, including illness detection based on nervous system metrics. BACKGROUND

[0004] Some wearable devices can be configured to collect physiological data from a user, including temperature data, heart rate data, and the like. Many users desire more insight into their physical health. BRIEF DESCRIPTION OF DRAWINGS

[0005] FIG. 1 An example of a system that supports illness detection techniques is shown in accordance with various aspects of the present disclosure.

[0006] FIG. 2 An example of a system that supports illness detection techniques is shown in accordance with various aspects of the present disclosure.

[0007] FIG. 3 An example of a nervous system graph that supports illness detection techniques is shown in accordance with various aspects of the present disclosure.

[0008] FIG. 4 An example of a neurological system graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0009] FIG. 5 An example of a neurological system graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0010] FIG. 6 An example of a temperature data graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0011] FIG. 7 An example of a temperature data graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0012] FIG. 8 An example of a modifiable behavior predictor graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0013] FIG. 9 An example of a modifiable behavior predictor graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0014] FIG. 10 An example of a modifiable behavior predictor graph that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0015] FIG. 11 An example of a menstrual cycle model that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0016] FIG. 12 An example of a health management platform that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0017] FIG. 13 A block diagram of an apparatus that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0018] FIG. 14 A block diagram of a wearable application that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0019] FIG. 15 A diagram of a system including a device that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure.

[0020] FIG. 16 to FIG. 18 A flow diagram illustrating a method that supports disease detection techniques is shown, in accordance with various aspects of the present disclosure. DETAILED DESCRIPTION

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

[0022] Various aspects of the present disclosure relate to techniques for detecting and predicting illness. Specifically, computing devices of the present disclosure can detect a transition of a user from a healthy state to an unhealthy state. For example, various aspects of the present disclosure can 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 the potential transition before the onset of symptoms and / or an exacerbation of symptoms associated with the upcoming unhealthy state. From the user's perspective, early detection (e.g., detecting illness before the onset of symptoms) can manifest as a prediction of a transition of the user from a healthy state to an unhealthy state, or in other words, can indicate that the user is experiencing an immune response. As such, various aspects of the present disclosure can detect and / or predict the onset of an unhealthy state in a user. In some implementations, the computing devices can also detect / predict a transition of the user from an unhealthy state to a healthy state.

[0023] For purposes of the present disclosure, the term "healthy state," and like terms, can be used to refer to a physical state of a user (e.g., a normal state) in which there is an absence of symptoms of illness and / or a particular diagnosis. Conversely, the term "unhealthy state," and like terms, can be used herein to refer to a physical state of a user when the user is experiencing illness. For example, a user can be in an unhealthy state when experiencing symptoms of illness, such as fever, chills, sore throat, headache, and other symptoms. Example illnesses that can cause an unhealthy state include, but are not limited to, bacterial or viral infections, such as influenza A / B and coronavirus disease 2019 (COVID-19).

[0024] A transition from a healthy state to an unhealthy state can refer to a transition from a state in which a user feels healthy to a state in which the user feels unhealthy, whereby those subjective symptoms can reflect the presence of an underlying illness, infection, condition, or diagnosis. For example, a transition from a healthy state to an unhealthy state can include the onset of symptoms, such as fever and / or other conditions (e.g., reduced physical ability). Conversely, a transition from an unhealthy state to a healthy state can include a reduction, alleviation, or elimination of symptoms.

[0025] In some implementations, the healthy state and the unhealthy state can be referred to as a pre-symptomatic state and a symptomatic state, respectively. For example, in the healthy state, the user can not be experiencing symptoms (e.g., of a disease or infection). While the user can not be experiencing symptoms (e.g., of a disease / infection), the user can be in a scenario where they are transitioning to a state where they can experience symptoms. For example, the user can have been infected for some time without experiencing symptoms. In other words, the user can be experiencing a disease / infection but can still be pre-symptomatic (e.g., feel healthy). The pre-symptomatic period can also be when the individual is most likely to spread the disease. Thus, it is desirable to detect the disease during the pre-symptomatic state to enable interventions that can stop the spread of the disease.

[0026] After a period of time (e.g., a latent period), the user can transition to a symptomatic state (e.g., an unhealthy state). While the user can transition from the pre-symptomatic state to the symptomatic state, in some cases, the user can not become symptomatic. Some aspects of the present disclosure are directed to detecting a disease during the pre-symptomatic phase (e.g., before the user experiences symptoms of the disease). However, the techniques described herein can also be used to detect a disease without the user becoming symptomatic or becoming aware of their symptoms.

[0027] Thus, some techniques of the present disclosure can be used to identify a pre-symptomatic phase of a disease based on physiological data (e.g., measured physiological data) collected from a user via a wearable device. Example physiological parameters can include, but are not limited to: nervous system information (e.g., heart rate data, heart rate variability (HRV) data), temperature data, respiratory rate data, motion / activity data (e.g., activity log-based data associated with sleep and motion), etc. For example, in some cases, the techniques described herein can utilize changes in HRV data and other nervous system parameters to identify a disease. In other cases, the techniques described herein can utilize changes in temperature data of a user (e.g., changes in high / low temperature readings during the day) in conjunction with a location of the user to identify a disease. In additional or alternative implementations, the techniques described herein can utilize data associated with modifiable behavior predictors (e.g., physical activity, sleep) to identify a disease. In some aspects, the techniques described herein can utilize models (e.g., a menstrual cycle model, a weekly pattern adjustment model, an annual pattern adjustment model, a seasonal pattern adjustment model) to account for periodic, predictable changes in a user’s motion, activity, and physiological responses in order to improve predictions of disease onset.

[0028] In some aspects, the technology described herein can use physiological data collected over multiple different time intervals (e.g., reference window, prediction window) to detect illness. Comparison of physiological data collected over respective time intervals can be used to identify satisfaction of deviation criteria, where satisfaction of one or more deviation criteria can be used to identify likelihood of illness. For example, the technology described herein can determine physiological parameter values of a user over a first time interval (e.g., reference window) when the user is in a healthy state to determine motion baseline parameters (e.g., baseline temperature data, baseline HRV data) of the user. The technology described herein can further compare physiological data collected over a second time interval (e.g., prediction window) later in time to the baseline parameters in order to determine a deviation from the baseline parameters, where the deviation (e.g., satisfaction of deviation criteria) can be indicative of illness.

[0029] In additional or alternative implementations, the systems described herein can determine individualized or group-derived “baseline” physiological parameter values (e.g., in a reference window) for a user in a healthy state. The systems can then detect / predict a transition to a non-healthy state based on one or more deviations from these moving baseline physiological parameter values and / or distribution of baseline physiological parameter values (e.g., including deviations in one or more subsequent early detection / prediction windows).

[0030] In some implementations, to detect a transition from a healthy state to a non-healthy state, the systems and methods of the present disclosure can 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 can employ a change point or anomaly detection strategy in a multivariate space of physical assessments utilizing a semi-supervised approach with Bayesian influence. Hierarchical or hybrid modeling approaches can be used to provide group-specific model parameters, providing greater algorithmic precision for specific user segments. In other implementations, to detect a transition back to a healthy state (e.g., recovery from COVID-19 or other illness), the systems and methods of the present disclosure can detect a return to earlier baseline parameter values / ranges from deviated parameter values.

[0031] The techniques described herein can inform users of a detected / predicted transition from a healthy state to a non-healthy state in various ways. For example, the system can cause a graphical user interface (GUI) of a user device to display a message or other notification to inform the user of the likelihood of a potential transition to a non-healthy state (e.g., a disease risk metric, a disease prediction metric), and make a recommendation to the user. In one example, the GUI can display a recommendation for the user to prepare for a potential disease by resting, moisturizing, and / or scheduling a doctor’s appointment. The GUI can also include graphics / text indicating data used to make the detection / prediction of the upcoming non-healthy state. For example, the GUI can indicate that an upcoming disease has been predicted based on a temperature deviation from a normal baseline. Based on the early warning (e.g., before perceivable symptoms), the user can take early steps that can help reduce the severity of the upcoming disease. Further, the user can modify / schedule their daily activities (e.g., work and leisure time) based on the early warning.

[0032] In some implementations, the computing device can inform an administrator (e.g., an administrator of an organization or a medical professional supervising a group of patients) that is assigned to monitor a group of individuals in order to provide risk estimates or help identify individuals with the highest likelihood of needing follow-up action for further testing or screening on a portion of the organization. Such a device can present model results as a tool for improving selection of a subset of individuals to be provided additional care or for otherwise employing safety protocols. In such settings, disease detection metrics and other disease scores can not be intended to be deterministic, absolute, or diagnostic, but rather to help a company make preliminary assessments of risk, screening, or resource allocation that are intended to be used in conjunction with additional tools for confirming a diagnosis.

[0033] Various aspects of the disclosure are initially described in the context of a system that supports collecting physiological data from a user via a wearable device. Additional aspects of the disclosure are described in the context of an example nervous system graph, a temperature data graph, a modifiable behavior predictor graph, an example menstrual cycle model, and an example health management platform. Various aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts related to disease detection techniques.

[0034] FIG. 1 An example of a system 100 that supports disease detection techniques in accordance with various aspects of the disclosure is shown. The system 100 includes a plurality of electronic devices (e.g., wearable devices 104, user devices 106) that can 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.

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

[0036] The example wearable devices 104 can include wearable computing devices such as ring computing devices configured to be worn on a finger of the user 102 (hereinafter referred to as "rings"), wrist computing devices configured to be worn on a wrist of the user 102 (e.g., smartwatches, fitness bands, or wristbands), and / or head-mounted computing devices (e.g., eyeglasses / goggles). The wearable devices 104 can also include bands, straps (e.g., flexible or inflexible bands or straps), hook-and-loop sensors, etc., positionable in other locations such as around the head (e.g., forehead headbands), arms (e.g., forearm bands and / or double headbands), and / or legs (e.g., thigh or calf bands), behind the ears, under the armpits, etc. The wearable devices 104 can also be attached to or included in articles of clothing. For example, the wearable devices 104 can be included in pockets and / or pouches on clothing. As another example, the wearable devices 104 can be clipped to and / or pinned to clothing, or can otherwise be held in proximity to the user 102. Example articles of clothing can include, but are not limited to, hats, shirts, gloves, pants, socks, outerwear (e.g., jackets), and undergarments. In some implementations, the wearable devices 104 can be included in other types of devices such as training / sports devices used during physical activity. For example, the wearable devices 104 can be attached to or included in bicycles, snowboards, tennis rackets, golf clubs, and / or training weights.

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

[0038] In some aspects, user devices 106 can include handheld mobile computing devices, such as smartphones and tablet computing devices. User devices 106 can also include personal computers, such as laptop and desktop computing devices. Other example user devices 106 can include server computing devices that can communicate with other electronic devices (e.g., via the Internet). In some implementations, computing devices can include medical devices, such as external wearable computing devices (e.g., a Holter monitor). Medical devices can also include implantable medical devices, such as pacemakers and implantable cardioverter-defibrillators. Other example user devices 106 can include home computing devices, such as Internet of Things (IoT) devices (e.g., an IoT device), a smart television, a smart speaker, a smart display (e.g., a video call display), a hub (e.g., a wireless communication hub), a security system, a smart appliance (e.g., a thermostat and a refrigerator), and fitness equipment.

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

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

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

[0042] The electronic devices (e.g., user devices 106, wearable devices 104) of the system 100 can be communicatively coupled to one or more servers 110 via wired or wireless communication protocols. For example, as shown, the electronic devices (e.g., user devices 106) can be communicatively coupled to one or more servers 110 via a network 108. The network 108 can implement the Transmission Control Protocol and Internet Protocol (TCP / IP), or can implement other network 108 protocols. The network connections between the network 108 and the respective electronic devices can facilitate data transmission via email, the web, text messaging, mail, or any other suitable form of data transmission that interacts with the computer network 108. For example, in some implementations, the ring 104-a associated with the first user 102-a can be communicatively coupled to the user device 106-a, where the user device 106-a is communicatively coupled to the server 110 via the network 108. Additionally or alternatively, the wearable devices 104 (e.g., rings 104, watches 104) can be directly communicatively coupled to the network 108. FIG. 1

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

[0044] In some aspects, the system 100 can support techniques for automatic sleep stage classification based on data collected by a wearable device. Specifically, the system 100 detects a time period in which a user 102 is sleeping and classifies the time period in which the user 102 is sleeping into one or more sleep stages. For example, as shown in FIG. 1, a user 102-a can 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 can collect physiological data associated with the user 102-a, including temperature, heart rate, HRV, respiratory rate, etc. In some aspects, the data collected by the ring 104-a can be input to a machine learning classifier, where the machine learning classifier is configured to determine a time period in which the user 102-a is sleeping (or asleep). Further, the machine learning classifier can be configured to classify the time period into different sleep stages, including a wakeful sleep stage, a REM sleep stage, a light sleep stage (non-REM (NREM)), and a deep sleep stage (NREM). FIG. 1

[0045] In some aspects, the classified sleep stages can be displayed to the user 102-a via a GUI of the user device 106-a. Specifically, the GUI can display a time interval in which the user 102-a is asleep, where sections of the time interval are labeled or otherwise indicated with corresponding sleep stages. In some implementations, the sleep stage classification techniques described herein can be used to provide feedback to the user 102-a regarding the user’s sleep patterns, such as a recommended sleep time, a recommended wake-up time, etc. Further, in some implementations, the sleep stage classification techniques described herein can be used to calculate scores for respective users, such as a sleep score, a readiness score, etc.

[0046] ​In some aspects, the system 100 can utilize features derived from circadian rhythms to further improve physiological data collection, disease detection, and other techniques described herein. The term circadian rhythm can refer to a natural, internal process that regulates the sleep-wake cycle of an individual that repeats approximately every 24 hours. In this regard, the techniques described herein can utilize a circadian regulation model to improve sleep stage classification. For example, the circadian regulation model, along with physiological data collected from a user 102-a via the wearable device 104-a, can be input into a machine learning classifier. In this example, the circadian regulation model can be configured to "weight" or regulate physiological data collected during a user's sleep to provide more accurate sleep stage classification. In some implementations, the system can initially start with a "baseline" circadian regulation model, and can modify the baseline model using physiological data collected from each user 102 to generate a customized, individualized circadian regulation model specific to each respective user 102.

[0047] In some aspects, the system 100 can utilize other biological rhythms to further improve comparison of data through the phase of these other rhythms. For example, if a weekly rhythm is detected within the baseline data of an individual, the model can be configured to regulate the "weighting" of data by the day of the week. Biological rhythms that can require regulation of the model through this approach include: 1) ultradian (faster than the diurnal rhythm, including sleep cycles during sleep states, and oscillations in measured physiological variables from less than an hour to several hour periodicities during wake states; 2) circadian; 3) exogenous daily rhythm shown to impose on the circadian rhythm, such as in work schedules; 4) weekly rhythm, or other artificial time periodicities imposed exogenously (e.g., a 12-day rhythm can be used in a hypothetical culture with 12-day "weeks"); 5) female multi-day ovarian rhythm and male spermogenesis rhythm; 6) lunar rhythm (relevant to individuals living in low or no artificial light); and 7) seasonal rhythm.

[0048] Biological rhythms are not always stationary rhythms. For example, many women experience variability in the length of the ovarian cycle from cycle to cycle, and even within an individual, the ultradian rhythm is not expected to occur at exactly the same time or periodicity within a few days. As such, signal processing techniques sufficient to quantify the frequency composition while maintaining the time resolution of these rhythms in the physiological data can be used to improve detection of these rhythms, assignment of the phase of each rhythm to each instant in time, and modification of the regulation model and comparison of time intervals therefrom.

[0049] The described biological rhythms are not always perfectly identical across physiological modalities. For example, after traveling across time zones, some rhythms can align to the new time zone faster than others or variables (e.g., ultradian rhythms can recover faster than circadian rhythms, or heart rate can recover its normal rhythmic features faster than respiratory rate). Similar loss of stable relationships is a common hallmark of disease. As such, the classification of “healthy” and “unhealthy” time intervals can be further refined by including rhythmic parameters such as amplitude and instantaneous frequency per variable, and can be further refined by including parameters that describe the rhythmic relationships between variables (e.g., in the alignment of the ultradian rhythms of temperature and heart rate, co-information, concordance, etc.). The resulting relationship parameters must be generated in a way that preserves the temporal resolution sufficient for the models being compared.

[0050] The biological rhythm regulation models and parameters can be added in linear or non-linear combinations as appropriate in order to more accurately capture the dynamic baseline of an individual or group of individuals. The weights and models can then be used as features for improving the accuracy of comparisons between “healthy” time intervals and “unhealthy” time intervals. For example, a user’s temperature data during their natural circadian rhythm (e.g., “temperature rhythm”) can be compared to other physiological parameters assessed relative to the circadian rhythm (e.g., HRV rhythm, respiratory rate rhythm) to detect / predict disease.

[0051] In some aspects, respective devices of system 100 can support techniques for identifying an onset of a disease. Aspects of system 100 can support techniques for identifying a disease during a pre-symptomatic stage (e.g., disease detection prior to onset of symptoms). In particular, FIG. 1 System 100 illustrated in FIG. 1 can support techniques for identifying, using a classifier (e.g., a machine learning classifier), a 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 can compare physiological data (and rhythmic parameters thereof) collected over different time intervals (e.g., a first / reference time interval, a second / prediction time interval) to identify satisfaction of deviation criteria, where satisfaction of one or more deviation criteria can be used to predict a disease risk metric (e.g., a “risk score”), a disease prediction metric, a disease severity metric, a disease recovery metric, etc.

[0052] For example, as FIG. 1As shown, user 102-a can be associated with wearable device 104-a (e.g., ring 104-a) and user device 106-a. In this example, ring 104-a can collect physiological data associated with user 102-a, including temperature, heart rate, HRV, respiratory rate, etc. In some aspects, the data collected by ring 104-a can be input to a classifier, where the classifier is configured to determine a disease risk metric (or other metric) associated with a 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 can be processed to determine rhythm parameters across biological rhythms and physiological data types (e.g., ultradian and circadian rhythms of temperature, heart rate, and relationships of those rhythms), which are also input to the classifier. In some aspects, the classifier can not be machine learning, but rather be based on other artificial intelligence methods, or an empirically derived linear discriminator that does not rely on artificial intelligence or machine learning.

[0053] System 100 can be configured to cause user device 106-a to display an indication of the disease risk metric, which can enable user 102-a to take preventative measures and / or adjust a sleep or activity routine in order to prevent a disease, reduce a severity of a disease, reduce a duration of a disease, prevent a spread of a disease, or any combination thereof.

[0054] In some cases, system 100 can utilize nervous system metrics (e.g., metrics indicative of sympathetic / parasympathetic activity) to identify a disease. For example, system 100 can compare HRV data collected over different time intervals (e.g., a reference window, a prediction window) to identify a deviation criterion being met, where the deviation criterion being met is indicative of a disease onset. For example, a change in high frequency content of HRV data over time relative to a change in low frequency content of HRV data over time can be used to identify a disease onset.

[0055] In addition or alternatively, the system 100 can utilize temperature data to identify an onset of illness. Specifically, the system 100 can utilize temperature data in conjunction with a user’s geographic location to determine an onset of illness. For example, changes in daytime high and / or low temperature readings for a first user 102 living in a colder climate (e.g., Finland) can be more indicative of illness than changes in daytime high and / or low temperature readings for a second user 102 living in a warmer climate (e.g., Miami). Similarly, seasonal changes in circadian rhythms will differ between northern (e.g., Finland) and southern (e.g., Miami) regions. Accordingly, in some implementations, the system 100 can use location data (e.g., geographic location, latitude) to determine a “prediction weight” for a user’s temperature data, where the prediction weight is associated with a relative prediction accuracy of the temperature data for predicting illness. In such cases, the prediction weight can be used in conjunction with collected temperature data to determine a likelihood that a given user 102 will transition from a healthy state to an unhealthy state.

[0056] In addition or alternatively, the system 100 can utilize physiological data associated with modifiable behavior predictors (e.g., physical activity, sleep) to identify an onset of illness. For example, a machine learning classifier can be used to identify deviations that satisfy criteria indicative of changes in a user’s activity and / or sleep over time, where the changes in the user’s activity and / or sleep over time can be used to identify illness. Further, in some implementations, the system 100 can utilize models (e.g., menstrual cycle model, weekly pattern adjustment model, yearly pattern adjustment model, seasonal pattern adjustment model) to account for periodic, predictable changes in a user’s motion, activity, and physiological responses in order to improve predictions of an onset of illness. For example, the system 100 can identify and / or generate a menstrual cycle model for a user 102-a, and can use the menstrual cycle model to improve illness detection for the user 102-a. In this example, the menstrual cycle model can be used to account for natural periodic changes in a user’s physiological data based on the user’s menstrual cycle (e.g., increased temperature during menstruation), thereby reducing / eliminating false positive illness predictions.

[0057] The techniques described herein can use data collected by a wearable device to provide improved illness detection. In particular, the techniques described herein can be used to predict whether a 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. Physiological data used to perform illness detection can include nervous system information (e.g., heart rate data, HRV data), temperature data, respiratory rate data, motion / activity data, sleep data, etc. Furthermore, the system 100 can utilize additional data, such as location data, to determine the predictive accuracy of different physiological parameters used to identify illness, which can improve the accuracy of the illness detection techniques. Further, by taking into account periodic, predictable changes in a user’s activity, sleep, and / or physiological parameters (e.g., menstrual cycle models, weekly / seasonal / yearly pattern adjustment models), the techniques described herein can further improve illness detection, providing the user 102 with a more valuable understanding of their overall physical health.

[0058] Those skilled in the art will appreciate that one or more aspects of the disclosure can be implemented in system 100 to additionally or alternatively address other problems other than those noted above. In addition, various aspects of the disclosure can provide technical improvements to “conventional” systems or processes as described herein. However, the specification and drawings only include example technical improvements resulting from implementing aspects of the disclosure, and thus do not represent all technical improvements provided within the scope of the claims.

[0059] FIG. 2 An example of a system 200 that supports illness detection techniques is shown in accordance with various aspects of the disclosure. The system 200 can implement or be implemented by the system 100. In particular, the system 200 shows examples of the ring 104 (e.g., wearable device 104), the user device 106, and the server 110, as described with reference to FIG. 1

[0060] In some aspects, the ring 104 can be configured to be worn on a user’s finger and can determine one or more user physiological parameters when worn on the user’s finger. Example measurements and determinations can include, but are not limited to, user skin temperature, pulse waveform, respiratory rate, heart rate, HRV, blood oxygen level, etc.

[0061] ​System 200 further includes a user device 106 (e.g., a smartphone) that communicates with the ring 104. For example, the ring 104 may communicate wirelessly and / or via a wired connection with the user device 106. In some implementations, the ring 104 may transmit measured and processed data (e.g., temperature data, photoplethysmography (PPG) data, motion / accelerometer data, ring input data, etc.) to the user device 106. The user device 106 may also send data to the ring 104, such as firmware / configuration updates for the ring 104. The user device 106 may process the data. In some implementations, the user device 106 may transmit data to a server 110 for processing and / or storage.

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

[0063] These sensors may include association modules (not shown) configured to communicate with corresponding components / modules of the ring 104 and generate signals associated with the corresponding sensors. In some aspects, each of the components / modules of the ring 104 may be communicatively coupled to each other via a wired or wireless connection. Furthermore, 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), pulse oximeters, etc.

[0064] Reference FIG. 2 The ring 104 shown and described is provided for illustrative purposes only. Therefore, the ring 104 may include, for example... FIG. 2Additional or alternative components as shown herein. Other rings 104 providing the functionality described herein may be manufactured. For example, rings 104 with fewer components (e.g., sensors) may be manufactured. In a particular example, a ring 104 may be manufactured having a single temperature sensor 240 (or other sensor), a power supply, 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 strap). 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 including additional sensors and processing functionality may be manufactured.

[0065] Housing 205 may include one or more housing 205 assemblies. Housing 205 may include an outer housing 205-b assembly (e.g., a housing) and an inner housing 205-a assembly (e.g., a molded part). Housing 205 may be included in... FIG. 2 Additional components not explicitly shown (e.g., additional layers). For example, in some implementations, ring 104 may include one or more insulating layers that electrically insulate device electronics and other conductive materials (e.g., electrical traces) from housing 205-b (e.g., metal housing 205-b). Housing 205 may provide structural support for device electronics, battery 210, substrate, and other components. For example, housing 205 may protect device electronics, battery 210, and substrate from mechanical forces such as pressure and shock. Housing 205 may also protect device electronics, battery 210, and substrate from water and / or other chemicals.

[0066] The housing 205-b can be made of one or more materials. In some implementations, the housing 205-b may include a metal, such as titanium, which provides strength and abrasion resistance at a relatively light weight. The housing 205-b may also be made of other materials, such as polymers. In some implementations, the housing 205-b can be both protective and decorative.

[0067] The inner housing 205-a can be configured to engage with a user's finger. The inner housing 205-a can be formed of a polymer (e.g., a medical-grade polymer) or other materials. In some implementations, the inner housing 205-a can be transparent. For example, the inner housing 205-a can be transparent to light emitted by a PPG light-emitting diode (LED). In some implementations, the inner housing 205-a assembly can be molded onto the outer housing 205-b. For example, the inner housing 205-a can include a polymer molded (e.g., injection molded) to fit into the metal casing of the outer housing 205-b.

[0068] Ring 104 may include one or more substrates (not shown). Device electronics and battery 210 may be included on one or more substrates. For example, device electronics and battery 210 may be mounted on one or more substrates. Example substrates may include one or more printed circuit boards (PCBs), such as flexible PCBs (e.g., polyimide). In some implementations, electronics / battery 210 may include surface mount devices (e.g., surface mount technology (SMT) devices) on a flexible PCB. In some implementations, one or more substrates (e.g., one or more flexible PCBs) may include electrical traces providing electrical communication between device electronics. The electrical traces may also connect battery 210 to device electronics.

[0069] Device electronics, battery 210, and substrate can be arranged in various ways within the ring 104. In some implementations, a substrate including the device electronics may be mounted along the bottom (e.g., lower half) of the ring 104, such that sensors (e.g., PPG system 235, temperature sensor 240, motion sensor 245, and other sensors) engage with the underside of the user's finger. In these implementations, the battery 210 may be included along the top portion of the ring 104 (e.g., on another substrate).

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

[0071] The memory 215 (memory module) of ring 104 may include any volatile, non-volatile, magnetic, or electrical medium, 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. Memory 215 may store any data described herein. For example, memory 215 may be configured to store data collected by the corresponding sensors and PPG system 235 (e.g., motion data, temperature data, PPG data). Furthermore, memory 215 may include instructions that, when executed by one or more processing circuits, cause the module to perform various functions belonging to the modules herein. The device electronics of ring 104 described herein are merely example device electronics. Therefore, the type of electronic components used to implement the device electronics may vary based on design considerations.

[0072] The functionality of the modules belonging to the Ring 104 described herein can be embodied in one or more processors, hardware, firmware, software, or any combination thereof. Describing different features as modules is intended to highlight different functional aspects and does not necessarily imply that these modules must be implemented by separate hardware / software components. Rather, the functionality associated with one or more modules can be performed by separate hardware / software components or integrated within common hardware / software components.

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

[0074] Processing module 230-a can communicate with memory 215. Memory 215 may include computer-readable instructions that, when executed by processing module 230-a, cause processing module 230-a to perform various functions belonging to processing module 230-a herein. In some implementations, processing module 230-a (e.g., a microcontroller) may include additional features associated with other modules, such as communication functions provided by communication module 220-a (e.g., an integrated Bluetooth Low Energy transceiver) and / or additional onboard memory 215.

[0075] Communication module 220-a may include circuitry providing wireless and / or wired communication with user equipment 106 (e.g., communication module 220-b of user equipment 106). In some implementations, communication modules 220-a and 220-b may include wireless communication circuitry, such as Bluetooth circuitry and / or Wi-Fi circuitry. In some implementations, communication modules 220-a and 220-b may include wired communication circuitry, such as Universal Serial Bus (USB) communication circuitry. Using communication module 220-a, ring 104 and user equipment 106 may be configured to communicate with each other. The ring's processing module 230-a may be configured to send / receive data to / from user equipment 106 via communication module 220-a. Example data may include, but is not limited to, motion data, temperature data, pulse waveform, 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's processing module 230-a can also be configured to receive updates (e.g., software / firmware updates) and data from the user equipment 106.

[0076] Ring 104 may include a battery 210 (e.g., a rechargeable battery 210). Example battery 210 may include a lithium-ion or lithium-polymer type battery 210, but various battery options are possible. Battery 210 can be wirelessly charged. In some implementations, ring 104 may include a power source other than battery 210, such as a capacitor. The power source (e.g., battery 210 or capacitor) may have a curved geometry that matches the curves of ring 104. In some aspects, the charger or other power source may include additional sensors that can be used to collect data in addition to or supplement the data collected by ring 104 itself. Furthermore, the charger or other power source of ring 104 may act as user equipment 106, in which case the charger or other power source of ring 104 may be configured to receive data from ring 104, store and / or process data received from ring 104, and communicate data between ring 104 and server 110.

[0077] In some aspects, the ring 104 includes a power module 225 that controls the charging of the battery 210. For example, the power module 225 may engage with an external wireless charger that charges the battery 210 when engaged with the ring 104. The charger may include a reference structure that mates with a reference structure of the ring 104 to create a specified orientation with the ring 104 during charging. The power module 225 may also regulate the voltage 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, overvoltage during charging of the ring 104, and undervoltage during discharging of the ring 104. The power module 225 may also include electrostatic discharge (ESD) protection.

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

[0079] In some implementations, temperature sensor 240 can generate a digital signal (e.g., temperature data), which processing module 230-a can use to determine the temperature. As another example, if temperature sensor 240 includes a passive sensor, processing module 230-a (or temperature sensor 240 module) can measure the current / voltage generated by temperature sensor 240 and determine the temperature based on the measured current / voltage. Example 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.

[0080] Processing module 230-a can sample the user's temperature over time. For example, processing module 230-a can sample the user's temperature according to a sampling rate. Example sampling rates may include one sample per second, but processing module 230-a can be configured to sample the temperature signal at other sampling rates higher or lower than one sample per second. In some implementations, processing module 230-a can continuously sample the user's temperature throughout the day and night. Sampling at a sufficient rate (e.g., one sample per second) throughout the day can provide sufficient temperature data for the analysis described herein.

[0081] Processing module 230-a can store the sampled temperature data in memory 215. In some implementations, processing module 230-a can process the sampled temperature data. For example, processing module 230-a can determine the average temperature value over a period of time. In one example, processing module 230-a can determine the average temperature value for a minute by summing all temperature values ​​collected per minute and dividing by the number of samples in that minute. In a specific example of sampling the temperature at one sample per second, the average temperature could be the sum of all sampled temperatures for one minute divided by sixty seconds. Memory 215 can store the average temperature value over time. In some implementations, memory 215 can store the average temperature (e.g., one per minute) instead of the sampled temperatures to save memory 215.

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

[0083] The ring 104 (e.g., a communication module) can transmit sampled temperature data and / or average temperature data to the user equipment 106 for storage and / or further processing. The user equipment 106 can transmit the sampled temperature data and / or average temperature data to the server 110 for storage and / or further processing.

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

[0085] Processing module 230-a can acquire 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, processing module 230 can individually sample, average, and store temperature data from each of the multiple temperature sensors 240. In other examples, processing module 230-a can sample the sensors at different rates and average / store different values ​​for different sensors. In some implementations, processing module 230-a can be configured to determine a single temperature based on the average of two or more temperatures determined by two or more temperature sensors 240 at different locations on the finger.

[0086] Temperature sensors 240 on ring 104 can acquire the distal temperature at a user's finger (e.g., any finger). For example, one or more temperature sensors 240 on ring 104 can acquire the user's temperature from the underside of the finger or different locations on the finger. In some implementations, ring 104 can continuously acquire distal temperatures (e.g., at a sampling rate). While distal temperatures measured by ring 104 at a finger are described herein, other devices can measure temperatures at the same / different locations. In some cases, the distal temperature measured at a user's finger may differ from the temperature measured at the user's wrist or other external body locations. Furthermore, the distal temperature measured at a user's finger (e.g., "shell" temperature) may differ from the user's core temperature. Thus, ring 104 can provide a useful temperature signal that may not have been acquired at other internal / external locations of the body. In some cases, continuous temperature measurements at the finger can capture temperature fluctuations (e.g., small or large fluctuations) that may not be apparent in the core temperature. For example, continuous temperature measurements at the fingertips can capture minute-to-minute or hour-to-hour temperature fluctuations that provide additional insights that may not be provided by other temperature measurements elsewhere in the body.

[0087] Ring 104 may include a PPG system 235. The PPG system 235 may include one or more light emitters that emit light. The PPG system 235 may also include one or more light receivers that receive light emitted by the one or more light emitters. The light receivers may generate a signal indicating the amount of light received by the light receivers (hereinafter referred to as a "PPG" signal). The light emitters 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. Processing module 230-a may sample the PPG signal and determine the user's pulse waveform based on the PPG signal. Processing module 230-a may determine various physiological parameters, such as the user's respiratory rate, heart rate, HRV, oxygen saturation, and other circulatory parameters, based on the user's pulse waveform.

[0088] In some implementations, the PPG system 235 can be configured as a reflective PPG system 235, wherein one or more light receivers receive transmitted light reflected from an area passing through the user's finger. In some implementations, the PPG system 235 can be configured as a transmissive PPG system 235, wherein one or more light emitters and one or more light receivers are arranged opposite each other such that light passing through a portion of the user's finger is directly transmitted to one or more light receivers.

[0089] The number and ratio of transmitters and receivers included in the PPG system 235 can vary. Example light transmitters may include light-emitting diodes (LEDs). Light transmitters may emit light in the infrared spectrum and / or other spectra. Example light receivers may include, but are not limited to, photoelectric sensors, phototransistors, and photodiodes. Light receivers can be configured to generate PPG signals in response to wavelengths received from the light transmitter. The positions of the transmitters and receivers can be changed. Furthermore, a single device may include a reflective and / or transmissive PPG system 235.

[0090] In some implementations, FIG. 3 The PPG system 235 shown may include a reflective PPG system 235. In these implementations, the PPG system 235 may include a centrally located light receiver (e.g., at the bottom of ring 104) and two light emitters located on each side of the light receiver. In this implementation, the PPG system 235 (e.g., the light receiver) may generate a PPG signal based on light received from one or both of these light emitters.

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

[0092] Sampling the PPG signal generated by the PPG system 235 can produce a pulse waveform, which may be referred to as "PPG". The pulse waveform can indicate blood pressure versus time over multiple cardiac cycles. The pulse waveform may include peak values ​​indicating cardiac cycles. Furthermore, the pulse waveform may include respiratory-induced changes that can be used to determine respiratory rate. In some implementations, the processing module 230-a may store the pulse waveform in memory 215. The processing module 230-a may process the pulse waveform when it is generated and / or when it is retrieved from memory 215 to determine the user physiological parameters described herein.

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

[0094] Processing module 230-a can determine the HRV over time. For example, processing module 230-a can determine the HRV based on changes in the IBI. Processing module 230-a can store the HRV value over time in memory 215. Furthermore, processing module 230-a can determine the user's respiratory rate over time. For example, processing module 230-a can determine the respiratory rate based on the user's IBI value over a period of time using frequency modulation, amplitude modulation, or baseline modulation. Additionally or alternatively, the respiratory rate can be determined based on HRV data. The respiratory rate can be calculated as breaths per minute or as another respiratory rate (e.g., breaths per 30 seconds). Processing module 230-a can store the user's respiratory rate value over time in memory 215.

[0095] Ring 104 may include one or more motion sensors 245, such as one or more accelerometers (e.g., 6-D accelerometers) and / or one or more gyroscopes. Motion sensors 245 may generate motion signals indicating the motion of the sensors. For example, ring 104 may include one or more accelerometers that generate acceleration signals indicating the acceleration of the accelerometers. As another example, ring 104 may include one or more gyroscope sensors that generate gyroscope signals indicating angular motion (e.g., angular velocity) and / or orientation changes. Motion sensors 245 may be included in one or more sensor packages. An example accelerometer / gyroscope sensor is the Bosch BM1160 inertial microelectromechanical system (MEMS) sensor, which can measure angular rate and acceleration on three vertical axes.

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

[0097] The ring 104 can store various types of data described herein. For example, the ring 104 can store temperature data, such as raw sampled temperature data and calculated temperature data (e.g., average temperature). As another example, the ring 104 can 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 respiratory rate values). The ring 104 can also store motion data, such as sampled motion data indicating linear and angular motion.

[0098] The ring 104 or other computing device can calculate and store additional values ​​based on the sampled / computed physiological data. For example, the processing module 230 can 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 can calculate various values / metrics related to movement. Example derived values ​​of movement data may include, but are not limited to, movement count values, regularity values, intensity values, metabolic equivalence (MET) of task values, and orientation values. Movement counts, regularity values, intensity values, and MET can indicate the amount of user movement over time (e.g., speed / acceleration). Orientation values ​​can 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.

[0099] In some implementations, motion counts and regularity values ​​can be determined by counting the number of acceleration peaks over one or more time periods (e.g., one or more time periods of 30 seconds to 1 minute). Intensity values ​​can indicate the number of motions and the associated intensity of the motions (e.g., acceleration values). Depending on the associated threshold acceleration value, intensity values ​​can be categorized as low, medium, and high. MET can be determined based on the intensity of motion of the ring 104 during a time period (e.g., 30 seconds), the regularity / irregularity of the motion, and the number of motions associated with different intensities.

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

[0101] While a user's physiological parameters can be measured by sensors included on the ring 104, other devices can also measure these parameters. For example, while a user's temperature can be measured by a temperature sensor 240 included in the ring 104, other devices can also measure it. In some examples, other wearable devices (e.g., wrist devices) may include sensors for measuring a user's physiological parameters. Furthermore, medical devices such as external medical devices (e.g., wearable medical devices) and / or implantable medical devices can measure a user's physiological parameters. The techniques described herein can be implemented using one or more sensors on any type of computing device.

[0102] Physiological measurements can be acquired continuously throughout the day and / or night. For example, in some implementations, the ring 104 can be configured to continuously acquire physiological data (e.g., determine temperature readings, HRV readings, respiratory rate readings) based on one or more measurement cycles throughout the entire day / sleep day. In other words, the ring 104 can continuously acquire physiological data from the user, regardless of the “triggering conditions” used to perform these measurements.

[0103] In additional or alternative implementations, physiological measurements can be acquired during various periods of daytime and / or nighttime (104). In some implementations, physiological measurements can be acquired in response to determining that the user is in a specific state (e.g., active, resting, and / or sleeping). For example, the ring 104 can perform physiological measurements during rest / sleep to obtain a cleaner physiological signal. In one example, the ring 104 or other device / system can detect when the user is resting and / or sleeping and acquire physiological parameters (e.g., temperature) of the detected state. When the user is in other states, the device / system can use rest / sleep physiological data and / or other data to implement the techniques of this disclosure.

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

[0105] The various data processing operations described herein can be performed by ring 104, user equipment 106, server 110, or any combination thereof. For example, in some cases, data collected by ring 104 may be preprocessed and transmitted to user equipment 106. In this example, user equipment 106 may perform some data processing operations on the received data, transmit the data to server 110 for data processing, or both. For example, in some cases, user equipment 106 may perform processing operations requiring relatively low processing power and / or requiring relatively low latency, while user equipment 106 may transmit data to server 110 for processing operations requiring relatively high processing power and / or allowing relatively high latency.

[0106] In some aspects, the ring 104 of system 200, user device 106, and server 110 can be configured to assess a user's sleep patterns. Specifically, corresponding components of system 200 can be used to collect data from the user via 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 noted herein, the ring 104 of system 200 can be worn by the user to collect data from the user, including temperature, heart rate, HRV, etc. The data collected by ring 104 can be used to determine when the user fell asleep to assess the user's sleep for a given "sleep day." In some aspects, a score can be calculated for each corresponding 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. The score for each corresponding sleep day can be calculated based on data collected by ring 104 during the corresponding sleep day. The scores can include, but are not limited to, sleep scores, readiness scores, etc.

[0107] In some cases, a "sleep day" can be aligned with a traditional calendar day, allowing a given sleep day to run from midnight to midnight on the corresponding calendar day. In other cases, the sleep day can be offset relative to the calendar day. For example, a sleep day can run from 6:00 PM (6:00 PM) on a calendar day to 6:00 PM (6:00 PM) on a subsequent calendar day. In this example, 6:00 PM can serve as a "deadline," where data collected from the user before 6:00 PM is counted for the current sleep day pair, and data collected from the user after 6:00 PM is counted for the subsequent sleep day pair. Offsetting the sleep day relative to the calendar day allows System 200 to assess the user's sleep patterns in a manner consistent with their sleep schedule. In some cases, users may be able to selectively adjust (e.g., via a GUI) the timing of their sleep day relative to the calendar day, aligning the sleep day with the duration of the corresponding user's typical sleep.

[0108] In some implementations, a user's total score for each corresponding day (e.g., sleep score, readiness score) can be determined / calculated based on one or more "contributors," "factors," or "contribution factors." For example, a user's total sleep score can be calculated for a set of contributors, including: total sleep, efficiency, restlessness, REM sleep, deep sleep, wait time, timing, or any combination thereof. Sleep scores can include any number of contributors. A "total sleep" contributor can refer to the sum of all sleep periods on a sleep day. An "efficiency" contributor can reflect the percentage of time spent asleep compared to the time spent waking up while sleeping, and can be calculated using the efficiency average of the long sleep periods (e.g., the main sleep period) of the sleep day, weighted by the duration of each sleep period. A "restfulness" contributor can indicate how restful a user's sleep is, and can be calculated using the average of all sleep periods of the sleep day, weighted by the duration of each period. Tranquility contributors can be based on “wake-up counts” (e.g., the sum of all wake-ups detected during different sleep periods when the user wakes up), excessive movement, and “get-out counts” (e.g., the sum of all get-outs detected during different sleep periods when the user gets out of bed).

[0109] A “REM sleep” contributor can refer to the sum of REM sleep durations across all sleep segments on a sleep day that includes REM sleep. Similarly, a “deep sleep” contributor can refer to the sum of deep sleep durations across all sleep segments on a sleep day that includes deep sleep. A “waiting time” contributor can represent how long it takes a user to fall asleep (e.g., average, median, longest) and can be calculated using the average of long sleep segments between sleep days, weighted by the duration of each segment and the number of such segments (e.g., combining one or more given sleep stages can be its own contributor or can be weighted by other contributors). Finally, a “timed” contributor can refer to the relative timed sleep segments within a sleep day and / or calendar day and can be calculated using the average of all sleep segments on a sleep day weighted by the duration of each segment.

[0110] As another example, a user's overall readiness score can be calculated based on a set of contributors, including: sleep, sleep balance, heart rate, HRV balance, recovery index, temperature, activity, activity balance, or any combination thereof. The readiness score can include any number of contributors. A "sleep" contributor can refer to the combined sleep score of all sleep periods within a sleep day. A "sleep balance" contributor can refer to the cumulative duration of all sleep periods within a sleep day. Specifically, sleep balance can indicate to a user whether the sleep a user has taken over a certain period (e.g., the past two weeks) is in line with the user's needs. Typically, adults need 7-9 hours of sleep each night to maintain health, alertness, and optimal mental and physical performance. However, occasional nights with poor sleep are normal, so sleep balance contributors consider long-term sleep patterns to determine whether each user's sleep needs are being met. A "resting heart rate" contributor can indicate the lowest heart rate from the longest sleep period (e.g., the main sleep period) and / or the lowest heart rate from a nap that occurs after the main sleep period.

[0111] Continuing to reference the "contributors" (e.g., factors, contributing factors) of the readiness score, the "HRV balance" contributor can indicate the highest average HRV from the main sleep period and naps occurring after the main sleep period. The HRV balance contributor helps users track their recovery status by comparing their HRV trend over a first time period (e.g., two weeks) with the average HRV over a second, longer time period (e.g., three months). The "recovery index" contributor can be calculated based on the longest sleep period. The recovery index measures how long it takes for a user's resting heart rate to stabilize during the night. A very good sign of recovery is that the user's resting heart rate stabilizes during the first half of the night, and the user does not wake up for at least six hours, leaving time for the body to recover the next day. If the user's highest temperature during a nap is at least 0.5°C higher than the highest temperature during the longest sleep period, the "body temperature" contributor can be calculated based on the longest sleep period (e.g., the main sleep period) or based on naps occurring after the longest sleep period. In some aspects, the ring can measure the user's body temperature while the user is asleep, and the system 200 can display the user's average temperature relative to the user's baseline temperature. If a user's body temperature is outside their normal range (e.g., clearly above or below 0.0), the body temperature contributor can be highlighted (e.g., put into "attention" status) or an alert can be generated for the user in other ways.

[0112] In some implementations, the various devices of System 200 can support technologies for disease detection. Specifically, System 200 can support disease detection based on physiological data indicating a user's neuroimmune and nervous system responses during the pre-symptomatic period of infection or disease. The early incubation period of infection is a critical window of opportunity for early detection, before people know they are symptomatic. Tagging of the nervous system balance derived from wearable devices can help us detect the onset of infection and the transition to symptomatic illness during the "incubation period" before people know they are sick. For example, in the context of COVID-19, people may be infected and experience no symptoms for up to 14 days before they actually develop a fever or feel sick. For COVID-19, this 14-day period can be referred to as the "pre-symptomatic period." Influenza can have a shorter incubation period, or pre-symptomatic period, typically up to 4 days. The pre-symptomatic period is also when an individual is most likely to transmit the virus. Therefore, it is desirable to detect disease during the pre-symptomatic state so that interventions can stop the spread of the disease.

[0113] For many types of flu-like illnesses, including COVID-19 and other viral or bacterial infections, the body's immune response to invading pathogens modulates the autonomic nervous system, which in turn sends signals to the brain (e.g., inflammatory cytokines) that contribute to "disease symptoms." Physiological data collected by wearable devices (e.g., ring 104) can be used to detect these early neurological changes by constructing tags or "features" that are fed to a classifier / algorithm (e.g., a machine learning classifier). These tags can 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 (compared to capillary blood flow), physiological data collected from the finger via ring 104 may be more sensitive and accurate than data collected from the wrist, thus providing a uniquely sensitive signal for neurological balance tagging to detect disease during the incubation period (or pre-symptomatic period).

[0114] A user's nervous system balance can involve the relative antagonism (e.g., push-and-pull) of their sympathetic and parasympathetic nervous system responses. Specifically, when exposed to stress (e.g., exposure to illness / infection, or an attack from a pathogen), the parasympathetic nervous system (e.g., the part of the nervous system associated with "rest and digestion" or recovery) can withdraw some of its tonic inhibitory input to the heart, immune cells, and other body tissues. By essentially "taking the foot off the brakes," the nervous system can allow greater sympathetic input, thus engaging the "fight or flight" system. This is advantageous to the immune system in the earliest stages of infection by mobilizing immune cells such as monocytes / macrophages from the bone marrow into the bloodstream and tissues from which they seek out virus-infected cells. Therefore, changes in the nervous system can occur close to the time of infection or before the onset of symptoms (e.g., 2–14 days before the onset of symptoms in the case of COVID-19).

[0115] The antagonistic interaction between sympathetic and parasympathetic responses results in "nervous homeostasis," which can describe the coordinated combination of adrenergic and cholinergic inputs affecting heart rate and blood vessels, manifested as changes in PPG-derived markers, and influencing the user's immune response to infection / disease. Essentially, two counter-regulatory aspects of the nervous system (sympathetic / adrenergic and parasympathetic / cholinergic) are required, and they do not always move in a counter-regulatory manner as traditionally presented in some textbooks and other literature.

[0116] In response to infection / disease, the brain sends signals via the nervous system to peripheral immune organs such as the bone marrow and spleen. These signals release more immune cells (e.g., monocytes / macrophages) into the bloodstream, where they can help hunt down and fight infected cells. Neurological homeostasis is required to control this immune response to infection and guide recovery from disease. Neurological homeostasis 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 neurological homeostasis: neurological homeostasis exhibits different activation patterns during day versus night (or wakefulness versus sleep). Therefore, it is envisioned herein that a wearable device 104 of system 200 (e.g., a ring 104) could be configured to capture physiological data indicative of sleep and other neurological responses, providing a unique measurement of nighttime neurological homeostasis prior to (and during) infection / disease.

[0117] The user's nervous system mediates the connection between the immune system and the brain to fight disease / infection. This provides a key signaling pathway through which the brain "learns" when the body is infected with a disease (e.g., influenza-like respiratory virus), coordinates the body's overall response to the infection, and manifests "disease symptoms" such as fatigue and pain to help the body fight the infection. For example, after recognizing an infection, the nervous system can transmit inflammatory signals to the hypothalamus center of the brain, which regulates body temperature, causing the body to develop a fever, which can enhance survival by inhibiting viral replication.

[0118] Nevertheless, since the nervous system responds to many other stimuli besides disease / infection, system 200 can be configured to combine subtle variations on numerous labels to detect larger patterns indicative of a response to disease. In reality, individual characteristics associated with the collected physiological data may not be highly indicative of disease on their own. However, when multiple features are combined and combined with numerous features / labels, the machine learning classifier of system 200 can be highly accurate in detecting disease. Therefore, system 200 can leverage multiple aspects of the nervous system balance between the parasympathetic and sympathetic nervous systems, as well as infection-driven behavioral consequences (e.g., such as sleeping earlier or longer), to identify disease. In other words, the techniques described herein can determine / predict disease based on learned bias patterns within a user's activity, sleep, and / or physiological data, rather than individual "abnormalities" within a single parameter or feature.

[0119] Therefore, system 200 can support techniques for identifying disease episodes using physiological data (e.g., HRV, respiratory rate) indicative of nervous system responses. Specifically, the techniques described herein compare HRV data collected from a user during a first time interval (reference window) and a second time interval (prediction window), and can determine a deviation criterion based on the change in HRV data from the first time interval to the second time interval. The satisfaction of the deviation criterion can then be used to determine a “disease risk score,” a “disease prediction metric,” or some other metric indicative of the user’s disease, and the determined metric can be reported to the user via the GUI 275 of user device 106. In other words, system 200 can collect HRV data from the user and compare the collected HRV data with the user’s baseline HRV data to determine a deviation from the user’s baseline HRV data, where such deviation may indicate disease. Additionally or alternatively, system 200 can (e.g., based on HRV data) determine the user’s respiratory rate, and can determine a deviation from the user’s baseline respiratory rate to identify a disease episode.

[0120] In some implementations, the collected HRV data can be fed into a classifier configured to identify conditions that meet one or more deviation criteria across corresponding time intervals (e.g., reference window, prediction window) for disease detection. In some implementations, the frequency content of the HRV data collected from the user can be used to identify disease onset. For example, the ring 104 of system 200, user device 106, and / or server 110 can determine the HRV bands and time-domain measures associated with the HRV data collected from the user. The time-domain content / measure of the HRV data may include the root mean square (RMSSD) of continuous differences. Further, the frequency-domain content / measure of the HRV data may include high-frequency (HF: 0.15–0.40 Hz; min period = 30 seconds; rolling window = 1 min) and low-frequency (LF: 0.04–0.15 Hz; min period = 90 seconds; rolling window = 2–5 minutes) ranges, respiratory rate, and very low frequencies (VLF: 0.015–0.04 Hz; min period = 270 seconds). After removing motion and other artifacts and ectopic pulsations from the signal, these frequency characteristics can be calculated in a rolling 1-10 minute window, depending on the length of the frequency in question.

[0121] The various components of system 200 can determine the raw spectral power in the corresponding frequency band and / or the peak frequency of each corresponding frequency band. These frequency extractions at a high-resolution granularity can be fed into a feature engineering pipeline configured to extract different statistical parameters from different points during sleep periods. These can include, but are not limited to, quantiles of the distribution (e.g., 1%, 50%, 99%, etc.) or measures examining the offset across the entire distribution, such as the Wasserstein metric. In other words, the feature engineering pipeline can be configured to compute features for certain time windows (e.g., rolling 1–10 minute time windows) and to compute statistics over those time windows (e.g., the median during the night), wherein the computed features and statistics can be fed into a classifier (e.g., a machine learning classifier) ​​to perform the various disease detection techniques described herein. In some implementations, Bayesian statistics can be used to frame variations in the distribution to reflect the impact of prior knowledge about the range of values ​​for a given user in a personalized manner across different “baseline periods.”

[0122] In some implementations, features associated with physiological data (e.g., HRV data) related to nervous system responses can be extracted in a “sleep intelligence” manner, such as the separation of respiratory rates during REM and non-REM sleep. Features can be extracted from the early, middle, or late parts of the night, where different physiological influences may be dominant. For example, the circadian rhythm of the immune system suggests that between approximately 9:00 PM and 2:00 AM, the immune system may maintain a strong attack and secrete more cytokines, while in the later part of the night, sympathetic-mediated visceral neural signals can initiate signals carrying the circadian rhythm for the next day and thus influence these signals in a critical manner. Therefore, system 200 can be configured to perform disease detection based on “sleep stage intelligence” or chronologically notified features of physiological data collected throughout the night, based on physiological data collected across multiple sleep periods, and / or based on physiological data collected at time intervals determined according to known circadian rhythms and physiology.

[0123] In some aspects, system 200 can determine the frequency content of HRV data within various time intervals (e.g., a first / reference time interval, a second / prediction time interval). For example, the feature engineering pipeline of system 200 (and / or a machine learning classifier) ​​can determine the frequency and amplitude (e.g., raw spectral power) of high-frequency and low-frequency signals in a rolling time window (e.g., a rolling two-minute time interval) during the nighttime period of the collected physiological data. System 200 can then calculate statistics on the determined features (e.g., the 50th percentile of the high-frequency amplitude for the entire nighttime during the rolling two-minute interval) to determine the individual parameter / value set for the corresponding nighttime of the physiological data.

[0124] Further reference is available. FIG. 3 Show and describe the frequency content associated with the acquired HRV data.

[0125] FIG. 3 Examples of neural system diagrams 300 supporting disease detection technologies according to various aspects of this disclosure are shown. Specifically, the neural system diagram 300 includes an HRV frequency content diagram 305-a and a neural system metric diagram 305-b.

[0126] HRV Frequency Content Plot 305-a illustrates how analyzing HRV bands can be used to capture the divergence of sympathetic and parasympathetic indices before disease to detect disease in the pre-symptom stage. Specifically, HRV Frequency Content Plot 305-a shows the low-frequency content (low-frequency curve 310-a) and high-frequency content (high-frequency curve 310-b) of over 10,000 individuals experiencing flu-like symptoms (including symptoms associated with COVID-19). The x-axis of HRV Frequency Content Plot 305-a plots the time before and after symptom onset (e.g., days), where time = 0 indicates the onset of symptoms for the corresponding user (e.g., the first development of symptoms). The y-axis of HRV Frequency Content Plot 305-a is normalized to plot the two different metrics together (e.g., low-frequency curve 310-a and high-frequency curve 310-b).

[0127] Low-frequency curve 310-a represents the 99th percentile (99%ile) of the peak frequency of the HRV metric derived from the IBI series in the low-frequency band during nighttime sleep. High-frequency curve 310-b represents the 1st percentile (1%ile) of the peak frequency of another HRV metric derived from the IBI series in the high-frequency band during nighttime sleep. In some respects, low-frequency curve 310-a may represent the sympathetic nervous system response, while high-frequency curve 310-b may represent the parasympathetic nervous system response.

[0128] As shown in HRV frequency content diagram 305-a, a coordinated shift can exist between the two frequency ranges before symptom onset. That is, there is a divergence between the low-frequency curve 310-a and the high-frequency curve 310-b before symptom onset. Because the low-frequency curve 310-a and the high-frequency curve 310-b are associated with sympathetic and parasympathetic activity, respectively, the divergence of the corresponding curve 310 before symptom onset can make the corresponding responses (e.g., sympathetic response, parasympathetic response) more pronounced. This divergence between the low-frequency curve 310-a and the high-frequency curve 310-b can reflect changes in input to immune organs (such as bone marrow) to stimulate the release of immune cells into the bloodstream to fight infection.

[0129] In some aspects, system 200 can identify pre-symptomatic stages (e.g., before disease onset at time = 0) of a disease based on low-frequency content (e.g., low-frequency curve 310-a) and / or high-frequency content (e.g., high-frequency curve 310-b) of a user's HRV data. In some cases, system 200 (e.g., ring 104, user device 106, server 110, machine learning classifier) ​​can identify the divergence between low-frequency curve 310-a and high-frequency curve 310-b to identify a disease. For example, during a first interval (e.g., a reference window), the normalized low-frequency curve 310-a may be greater than the normalized high-frequency curve 310-b. In contrast, during a second time interval (e.g., a prediction window), the normalized high-frequency curve 310-b may be greater than the normalized low-frequency curve 310-a. Accordingly, system 200 can detect disease onset based on the divergence between the corresponding curves 310 between the first and second time intervals.

[0130] System 200 can utilize additional physiological parameters associated with the nervous system response to determine the onset of a disease. For example, neurological metrics diagram 305-b illustrates three different metrics derived from the user's IBI series that can be used for disease detection: resting heart rate (curve 310-c), mean HRV score (curve 310-d), and recovery metric (curve 310-e). In some implementations, as described earlier herein, resting heart rate, mean HRV score (e.g., "HRV balance"), and recovery metric (e.g., "recovery index") may include "contributors" or "contributing factors" for determining the user's readiness score.

[0131] The x-axis of the neurological metrics plot 305-b shows the time (e.g., days) before and after the onset of symptoms, where time = 0 indicates the onset of symptoms for the corresponding user (e.g., the first development of symptoms). Data for the corresponding curves 310-c, 310-d, and 310-e of the neurological metrics plot 305-b can be calculated by comparing the most recent data with the user's long-term average (which is normalized to 0 to 100 (y-axis)). FIG. 4 As shown, the corresponding neurological metrics indicated in the neurological metrics diagram 305-b can provide valuable insights into disease detection in the pre-symptom period.

[0132] Specifically, curve 310-d, which correlates with a user's mean HRV score, or "HRV balance," generally declines before symptom onset. Curve 310-d, reflecting a user's mean HRV score (e.g., HRV balance), compares recent nighttime HRV (e.g., a 14-day weighted average of the RMSSD transformed into a logarithm, where more recent data is given more weight) to the user's long-term HRV over the past few months. Furthermore, curve 310-c, reflecting resting heart rate (which compares the previous night's lowest ten-minute heart rate to the user's long-term mean heart rate), also declines before symptom onset. Finally, curve 310-e, reflecting the recovery index (e.g., recovery metric data), also shows an increase in the number of days leading up to symptom onset. Recovery metric data, or recovery index, can refer to how long it takes for a user's resting heart rate to stabilize at night. An increase in curve 310-e reflects an increased proportion of nights dedicated to recovery once the heart rate has reached its minimum. A longer recovery time than usual can mildly predict disease progression. In summary, decreases in curve 310-c (e.g., decreases in resting heart rate), decreases in curve 310-d (e.g., decreases in mean HRV fraction), increases in curve 310-e (e.g., increases in recovery metric data), or any combination thereof, can be used for disease prediction.

[0133] FIG. 4 Examples of neural system diagrams 400 supporting disease detection techniques according to various aspects of this disclosure are shown. Specifically, the neural system diagram 400 includes an HRV frequency content diagram 405-a, a sleep duration diagram 405-b, an RMSSD diagram 405-c, and a REM sleep diagram 405-d.

[0134] The corresponding x-axis of Figures 405-a to 405-d shows the dates (e.g., month-day) before and after the onset of symptoms, where the vertical reference lines in each figure in Figure 405 indicate the onset of the user's disease symptoms. The y-axis of Figure 405-a shows the correlation between high-frequency and low-frequency content from the user's HRV data. The y-axis of Figure 405-b shows the user's sleep time, measured as the duration (in minutes) after midnight on the corresponding date. The y-axis of Figure 405-c shows the RMSSD measurement in milliseconds for the user's longest sleep duration, and the y-axis of Figure 405-d shows the user's total REM sleep duration in seconds.

[0135] As seen in HRV frequency content plot 405-a, a significant increase in the correlation between high-frequency HRV peak frequency and low-frequency HRV peak frequency was observed approximately 5–7 days prior to symptom onset. Furthermore, sleep duration plot 405-b shows that users can fall asleep earlier in the days leading up to symptom onset (e.g., a decrease in the curve in sleep duration plot 405-b), and RMSSD plot 405-c shows a lower RMSSD in the HRV data in the days leading up to symptom onset. A decrease in RMSSD (and / or other HRV measures) can indicate the withdrawal of parasympathetic symptoms, which may indicate impending illness. Finally, REM sleep plot 405-d shows an increase in REM sleep leading up to symptom onset.

[0136] although FIG. 5 The individual neurological features / parameters shown may be somewhat noisy individually, but these corresponding parameters can be used together or as a combination to effectively predict disease. For example, an increased correlation between high-frequency and low-frequency HRV content, as well as earlier sleep time and increased REM sleep, can be used to identify a user's potential transition from a healthy to an unhealthy state.

[0137] FIG. 6 Examples of neural system diagrams 500 supporting disease detection technologies according to various aspects of this disclosure are shown. Specifically, the neural system diagram 500 includes a first diagram 505-a showing the longest sleep duration for the deep sleep stage and the REM sleep stage, and a second diagram 505-b showing the relative proportions of total sleep classified as deep sleep and REM sleep.

[0138] The x-axis of corresponding figures 505-a and 505-b shows the time (e.g., days) before and after the onset of symptoms, where time = 0 indicates the date of symptom onset for the corresponding user. The y-axis of corresponding figures 505-a and 505-b is z-normalized to show the corresponding curves on the same graph, where the first figure 505-a shows the length of time the corresponding user spends in the REM sleep stage (curve 510-a) and the deep sleep stage (curve 510-b), and the second figure 505-b shows the relative proportion of total sleep for users classified as REM sleep (curve 510-c) or deep sleep (curve 510-d).

[0139] During sleep, users exhibit different sleep stages / phases (e.g., deep sleep, light sleep, REM sleep, and awake sleep). REM and non-REM sleep stages exhibit characteristically different patterns of nervous system balance, and variations in these sleep stages can be used to predict disease onset. Specifically, system 200 can be configured to input physiological data (e.g., HRV data, respiratory rate data, temperature data, etc.) collected from ring 104 into a classifier (e.g., a machine learning classifier), which categorizes the physiological data into the corresponding sleep stages. Subsequently, sleep stage data (e.g., data indicating the duration a user spends in a given sleep stage) can be used to predict diseases. In this respect, the classifier / algorithm can create or “learn” the complex interactions occurring between these sleep stages and measures of nervous system balance or HRV. By examining these features together, the machine learning classifier can develop a more accurate understanding of the complexity of how the nervous system responds to diseases during sleep.

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

[0141] In some cases, physiological data obtained from users can be used in a “sleep intelligence” manner to predict diseases. That is, when predicting diseases, system 200 can utilize only physiological data collected during specific times of the night and / or specific sleep stages. For example, features can be determined chronologically based on the user’s known circadian rhythms and physiology, where features can be extracted from the early, middle, or late parts of the night, where different physiological effects may be dominant.

[0142] For example, it's possible that HRV data collected during REM sleep periods is more useful for disease detection compared to HRV data collected during other sleep stages (e.g., deep sleep, light sleep). Thus, in some implementations, system 200 can utilize physiological data collected during defined sleep stages, night duration, and / or a particular type of sleep stage when predicting a disease. For instance, system 200 can utilize HRV data collected during REM sleep periods within a first time interval (e.g., a reference window) and HRV data collected during REM sleep periods within a second time interval (e.g., a prediction window) to identify conditions that meet deviation criteria and predict disease onset.

[0143] Similarly, system 200 can use physiological data collected at defined time intervals within a user's natural circadian rhythm to determine disease. For example, according to a user's natural circadian rhythm, physiological changes between approximately 2:00 AM and 4:00 AM may be more indicative of disease because this time interval corresponds to the time when the body naturally tends to increase its biological response to fight disease. As another example, according to a user's natural circadian rhythm, physiological changes within the first 180 minutes after the user's normal sleep time (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, a user's natural circadian rhythm can be used to identify absolute and relative time windows of particular interest when determining / predicting disease. Therefore, system 200 can identify a user's circadian rhythm and can compare physiological data collected within specific time intervals of the circadian rhythm with physiological data collected within the same time intervals of the circadian rhythm to detect disease. For example, system 200 can compare HRV data collected between 2:00 a.m. and 4:00 a.m. with the user's baseline HRV data collected between 2:00 a.m. and 4:00 a.m. in previous days to determine deviations from the baseline HRV data and detect diseases.

[0144] An example for determining / predicting a user's transition from a healthy to an unhealthy state can be illustrative. In this example, ring 104 may acquire physiological data from the user over time. For example, 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. The corresponding data streams (e.g., temperature data, heart rate data, HRV data, etc.) may be referred to as "parameters" of the physiological data. Ring 104 may transmit the acquired / determined physiological data to user device 106. Furthermore, in some aspects, user device 106 may transmit the acquired physiological data to server 110.

[0145] User equipment 106 and / or server 110 may determine a health 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". User equipment 106 may determine a value 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 time window 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 consecutive time windows. In some implementations, the two time windows may be separated from each other for 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 of the reference window, prediction window, unhealthy time window, and recovery time window may have any duration. For example, time windows may be on the order of minutes, hours, days, or weeks.

[0146] User equipment 106 and / or server 110 can determine healthy baseline values / ranges for corresponding parameters of physiological data. Healthy baseline values / ranges can indicate the values ​​and / or ranges of a user's physiological parameters when the user is in a healthy state. For example, healthy baseline values / ranges can indicate healthy temperature characteristics, respiratory rate characteristics, HR characteristics, and / or HRV characteristics. User equipment 106 can determine one or more healthy baseline values / ranges for each of the measured physiological parameters. For example, user equipment 106 and / or server 110 can determine a healthy baseline HRV range, a healthy baseline respiratory rate range, a healthy baseline temperature range, etc. User equipment 106 and / or server 110 can determine the healthy baseline values / ranges for corresponding parameters based on physiological data acquired in a baseline reference window (e.g., a first time interval). In some implementations, the baseline values / ranges can be values / ranges in the time domain, frequency domain, or both.

[0147] For the purposes of this disclosure, the terms "physiological data," "baseline physiological data," and similar terms may be used to refer not only to the collected physiological readings (e.g., temperature readings, heart rate readings, etc.) but also to 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 raw / processed temperature readings collected from a user, as well as the frequency content of the temperature data. In this respect, the terms "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 raw / processed temperature readings, as well as other rhythmic temperature parameters, such as frequency, amplitude, phase, stability, etc.

[0148] In some implementations, 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) for disease detection. In some implementations, Bayesian statistical methods may be utilized, whereby the reference window constitutes a prior distribution and the prediction window constitutes a posterior distribution. In other implementations, Bayesian methods may be used to select an appropriate discrimination threshold at which the disease probability output by the model can be classified as actionable or inactionable from a user- or employer-based perspective. For example, the prevalence of COVID-19 in a local area, employment hub, or similar demographic can provide a prior distribution relative to which the statistical probability of a posterior data-driven distribution is assessed.

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

[0150] Subsequently, user equipment 106 and / or server 110 can determine whether a transition from a healthy to an unhealthy state exists based on health-to-unhealthy transition criteria (e.g., deviation criteria). Deviation criteria may indicate one or more deviations (e.g., temperature deviation criteria, HRV deviation criteria, respiratory rate deviation criteria), the satisfaction of which indicates a potential transition from a healthy to an unhealthy state. Each health baseline value / range may be associated with one or more deviation criteria. In some implementations, a single deviation from a health baseline range / value may satisfy a deviation criterion. In some implementations, deviation criteria may require multiple deviations for one or more physiological parameters within a given time interval, such as one or more HRV deviations, temperature deviations, one or more respiratory rate deviations, etc.

[0151] If one or more deviation criteria are met, user device 106 can notify the user that a transition from a healthy state to an unhealthy state has been detected / predicted. For example, wearable application 250 can notify the user in another way (e.g., push notification) in application GUI 275 or on user device 106. As another example, if server 110 makes this determination, server 110 can notify the user via web-based GUI 275 or another way (e.g., push notification). In some implementations, GUI 275 can present physiological data associated with baseline data and / or deviations (e.g., in a dashboard). In some implementations, GUI 275 can provide a summary value summarizing the deviations and / or determinations (e.g., a summary prediction value). In some implementations, GUI 275 can 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.

[0152] In some implementations, 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. In addition to disease detection / prediction, risk / predictive values, other physiological data / values, and the techniques described herein can be used for a variety of purposes. For example, the data / values ​​can be used for diagnosis, prognostic prediction (e.g., who might require 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 at what frequency individuals should be tested), precision medicine (e.g., what treatment is most effective for whom), monitoring of treatment efficacy (e.g., what a given treatment leads to daily improvement), emergency care triage, pharmacodynamic / response purposes, and other purposes. Such digital biomarkers may be highly effective for patients with suspected COVID-19 or flu-like illness in order to prevent the spread of disease, facilitate work resumption, enable early identification in pre-symptomatic or asymptomatic individuals, and potentially identify early prognostic biomarkers with the likelihood of subsequent deterioration.

[0153] In some implementations, system 200 can be configured to provide information or other insights about identified disease assessment metrics (e.g., disease risk metrics, disease prediction metrics). Personalized insights can indicate aspects of the collected physiological data used to generate disease assessment scores. For example, providing personalized insights can provide additional information driving a high disease assessment score if a user does not experience high temperature (e.g., no fever) but still exhibits a relatively high disease assessment score (e.g., high disease probability). Furthermore, providing personalized insights can drive greater user engagement. Additionally, personalized insights can provide answers to questions such as, “What drives my high disease assessment score?”, “Why do I have a high disease assessment score if my temperature is normal?”, “Why do I sometimes see large variations in my disease risk metrics (e.g., Health Risk Management (HRM) score) from day to day?”, “Why does my readiness score say one thing, but my HRM score says something else?”, “I have asthma, is my score high because of my breathing rate, or because of something else?” In this respect, insights can explain the contributing factors to disease assessment scores without exposing the raw physiological data used to generate the scores, user privacy, or details of the algorithms / models.

[0154] For example, user device 106 can display one or more parameters of the collected physiological data via GUI 275, which are key contributors to the generated disease assessment score. For instance, if a high disease assessment score is determined primarily by a high temperature reading, GUI 275 can indicate that the temperature change is the primary cause of the high disease assessment score. As another example, if a user exhibits an increased respiratory rate and elevated resting heart rate, but no increase in temperature, GUI 275 can indicate that respiratory rate and resting heart rate are the primary causes of the high disease assessment score. In other cases, it may be possible to display trends in all or most significant contributors to a given user's health over time.

[0155] In some implementations, system 200 can be configured to receive user input about detected / predicted diseases to train a classifier (e.g., supervised learning for a machine learning classifier) ​​and improve disease detection techniques. For example, user device 106 can display a disease risk metric indicating the relative likelihood that a user will become ill. The user can then input one or more user inputs, such as symptom onset, positive disease test results, etc. These user inputs can then be fed into a classifier to train it. In other words, user input can be used to validate or confirm the determined disease risk metric.

[0156] While much of this disclosure has been described in the context of determining / predicting transitions from a healthy to an unhealthy state based on acquired physiological data (e.g., HRV data, temperature data), various aspects of this disclosure can also be used to determine / predict transitions from an unhealthy to a healthy state based on acquired physiological data. For example, user device 106 and / or server 110 may detect transitions based on temperature biomarkers and other physiological parameters (e.g., pulse waveform data, respiratory rate data, heart rate data, HRV data, activity recorder data, conductance of skin data, oxygen saturation data) to determine / predict when a user will (or is currently) transition from an unhealthy state to a healthy state. Similar notifications and alerts (e.g., via GUI 275) indicating detected transitions may be provided to the user.

[0157] Similar techniques using the user's baseline temperature range can be used to identify / predict a user's illness in the pre-symptom stage. For example, ring 104 can acquire physiological data (e.g., temperature data) from the user at a first time interval (e.g., a reference window). Temperature data may include skin temperature measured on the user's finger. Temperature data may be sampled at a sampling rate (e.g., one sample / minute, etc.) or a temperature collection period. In some implementations, temperature data may be sampled continuously throughout the day and night. While skin temperature measured at the finger can be used, other temperature measurements (e.g., skin and / or core temperature) may be acquired from different user locations. Ring 104 may transmit the acquired / identified data to user device 106 or other computing devices (e.g., server 110). Similarly, user device 106 may transmit the acquired physiological data to server 110. User device 106 and / or server 110 may acquire temperature data from the user for one or more days. Furthermore, user device 106 and / or server 110 may continue to acquire user temperature data from ring 104 (e.g., via user device 106) over time.

[0158] In some implementations, user equipment 106 and / or server 110 may filter the received temperature data. For example, server 110 may apply a low-pass filter to the temperature data. In some implementations, user equipment 106 and / or server 110 may implement one or more transformations when processing the temperature data. For example, server 110 may combine a low-pass filter with a discrete wavelet transform (DWT). Filtering the temperature data can reduce noise and some extreme fluctuations in the temperature data. For example, initial filtering / processing of the temperature data can remove false anomalies, which can enable the corresponding devices of system 200 to more clearly identify true anomalies / patterns that may better indicate early disease onset. Furthermore, ring 104, user equipment 106, server 110, or other computing devices may implement processing to remove erroneous data readings. For example, temperature readings or other physiological readings associated with a large amount of activity (e.g., as indicated by a motion sensor) may be removed from the data or otherwise mathematically adjusted by an algorithm. In addition, temperatures that do not indicate user temperature (such as hot showers) may be removed or mathematically adjusted. Removing erroneous or unreliable data can help ensure more reliable predictions.

[0159] Subsequently, user equipment 106 and / or server 110 can determine baseline temperature data associated with the user based on temperature data collected within a first time interval (e.g., a reference window). Baseline temperature data may include linear statistical measures of the temperature data (e.g., minimum / maximum / mean / median temperature readings), and dynamic descriptions of the temperature readings, such as temperature periodicity, frequency content (e.g., frequency components, baseline frequency content), stability of frequency over time (e.g., stability of temperature readings relative to menstruation, superluminal rhythms, diurnal rhythms), or any combination thereof, and the relationship of these dynamic descriptions to those dynamic descriptions of other physiological variables.

[0160] In some aspects, user equipment 106 and / or server 110 may receive additional temperature data collected by ring 104 within a second time interval (e.g., a prediction window). In this example, user equipment 106 and / or server 110 may compare the additional temperature data with baseline temperature data to identify whether one or more deviation criteria are met. For example, server 110 may feed the baseline temperature data and the additional temperature data into a classifier configured to identify the satisfaction (or lack thereof) of one or more deviation criteria. In some cases, the classifier may compare the temperature data with the baseline temperature data to determine whether the deviation or change between the temperature data and the baseline temperature data satisfies (e.g., is greater than or equal to) a certain temperature change threshold. In other words, the classifier may identify the satisfaction of a deviation criterion if the change between the temperature reading / range and the user's baseline temperature reading / range exceeds a temperature change threshold.

[0161] System 200 can then notify the user of detected / predicted diseases based on the fulfillment of deviation criteria. For example, user device 106 can display an indication of a disease risk metric via GUI 275, where the disease risk metric is associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0162] In some cases, user equipment 106 and / or server 110 can identify deviation criteria (e.g., predict disease) based on the deviation between high and / or low daytime temperature readings (e.g., maximum and / or minimum daytime temperature readings) between baseline temperature data and supplemental temperature data. For example, a change in temperature variation threshold (e.g., a change greater than or equal to a certain threshold) between the user's typical high daytime temperature readings between baseline temperature data and supplemental temperature data can indicate disease. As another example, a change in temperature variation threshold (e.g., a change greater than or equal to a certain threshold) between the user's typical low daytime temperature readings between baseline temperature data and supplemental temperature data can indicate disease. In some cases, a user may deviate from both high and low temperatures before the onset of symptoms. Furthermore, while large temperature deviations can indicate the occurrence of disease, in some implementations, smaller deviations can also indicate the occurrence of disease. Moreover, determining / predicting disease based on the user's own reference temperature data can provide a level of personalized detection that cannot be provided by other disease detection techniques, such as those that rely on absolute temperature values ​​relative to typical general temperature thresholds (e.g., 37°C).

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

[0164] In some implementations, frequency domain features can be approximated using peak-finding algorithms tuned to a similar frequency range. These peak (or trough)-finding features can quantify the peak spikes, the number of peaks, the distance between adjacent peaks, and the peak width. Such approximations of frequency domain features allow algorithms to operate in real-time generation environments while capturing rhythmic patterns of both normal and super-diurnal rhythms, as well as disruptions to these rhythms that may be caused by disease. An example of such an approximation is the approximation of the 22-26 hour diurnal rhythm of temperature by including daily features that quantify the daytime minimum temperature value and the nighttime maximum temperature value. Combined, such features can effectively capture spikes or amplitude variations in the 22-26 hour diurnal rhythm caused by disease.

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

[0166] User equipment 106 and / or server 110 can determine whether a user's recent (e.g., current) temperature data deviates from one or more healthy temperature baseline values / ranges. For example, user equipment 106 can determine whether the low-frequency signal intensity deviates from a healthy range during a second time interval (e.g., a prediction window). As another example, user equipment 106 can determine whether the low-frequency signal intensity for a specific duration within a user's natural circadian rhythm deviates from a healthy baseline relative to the corresponding duration of the circadian rhythm during a first time interval (e.g., a reference window).

[0167] User equipment 106 and / or server 110 can then determine whether a transition from a healthy state to an unhealthy state exists based on deviation criteria (e.g., a health / unhealthy transition criterion). 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, user equipment 106 and / or server can then determine, based on frequency domain characteristics of the temperature data, whether the output from one or more models (e.g., a machine learning classifier) ​​indicates that the user is transitioning from a healthy state to an unhealthy state.

[0168] It should be noted that frequency domain temperature data can provide insights into a user's health status that may not be visually apparent in time domain data. For example, time domain temperature data may not necessarily show fever or other temperature changes, while the frequency domain can use the techniques described herein to provide relevant information about a user's health status and potential transitions. Furthermore, while the techniques described herein can analyze data based on a roughly 22- to 26-hour range corresponding to circadian rhythms, ranges other than those corresponding to circadian rhythms can also be used. For example, frequency domain content associated with 8-12 hour ranges (e.g., hypersolar rhythms), 2-5 hour ranges (e.g., hypersolar rhythms), and / or 1-2 hour ranges (e.g., sleep-related rhythms) can be used. Other ranges besides those described herein can also be used to analyze temperature deviations and detect / predict transitions between healthy and unhealthy states.

[0169] In some implementations, frequency analysis of temperature data can be presented as a heatmap or a spectrogram. For example, a spectrogram can graphically show the frequency content of temperature against a time signal (e.g., showing the low-frequency to high-frequency content of acquired temperature data over time). A spectrogram of frequency-domain temperature data shows deviations in low-frequency signal strength (e.g., deviations in the low-frequency power range) and can be generated / computed using various techniques. For example, continuous wavelet transform (CWT), Fourier transform (e.g., fast Fourier transform), or other techniques can be used to compute the spectrogram data.

[0170] The y-axis of a spectrogram of frequency-domain temperature data can indicate the unit of period length in hours (e.g., where period = 1 / frequency). In other words, the y-axis can represent the frequency content of the signal in terms of period length (e.g., in hours). In some cases, a spectrogram of frequency-domain temperature data can show high signal strength corresponding to an approximate circadian rhythm (e.g., within a 22-26 hour period, centered on 24 hours), which can indicate that a user is transitioning from a healthy state to an unhealthy state, as described above. In some implementations, user equipment 106 and / or server 110 can detect / predict a transition to an unhealthy state based on one or more deviation criteria of low-frequency signal strength corresponding to the user's approximate circadian rhythm (e.g., a pattern of low-frequency signal strength within a 22-26 hour period).

[0171] In some respects, other "rhythmic parameters" of the acquired temperature data (besides the frequency content of the temperature data) can also be used to identify / predict diseases. Generally, frequency content is only one component of a user's natural physiological / biological rhythms (e.g., circadian rhythms, hyperdiurnal rhythms, etc.). Other rhythm-derived parameters (or rhythm assessment parameters) associated with physiological rhythms can include amplitude, stability, phase, etc.

[0172] Deviation criteria (e.g., healthy / unhealthy transition criteria) may include one or more of the deviation and transition criteria described herein, including deviations in low-frequency signal strength (e.g., deviations in the low-frequency power / signal strength range). Deviation criteria are met when a user's frequency-domain temperature data deviates outside the healthy range of low-frequency signal strength (e.g., based on baseline temperature data). In some implementations, the healthy range of frequency-domain temperature data may be defined for each corresponding user as 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 about the center of the 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.

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

[0174] In some implementations, deviation criteria (e.g., transition criteria) may include multiple desired deviations from the 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 satisfied deviation criteria (e.g., two or more). In some implementations, a deviation duration threshold time period and / or a threshold amplitude may be required to satisfy the deviation criteria. In some implementations, deviation criteria may include multiple 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 detecting a high deviation. Deviation criteria may include one or more deviations for any physiological parameter (such as temperature, respiratory rate, heart rate, and HRV). In some implementations, deviation criteria may be based on deviations in the time domain, frequency domain, or both.

[0175] In some implementations, a transition from a healthy state to an unhealthy state can be detected / predicted in response to the existence of a threshold number of deviation criteria being met (such as meeting a temperature deviation criterion and one or more other deviation criteria). In some implementations, the deviation criteria may include combination determination, where multiple different deviation criteria are considered. For example, different weights may be assigned to different deviations (e.g., heavier weights are assigned to stronger deviation criteria), and a transition from a healthy state to an unhealthy state can be detected / predicted if the sum of the different weighted criteria is greater than a threshold. In some implementations, the deviation criteria may need to satisfy a defined sequence of indicators, such as meeting a temperature criterion followed by another transition criterion.

[0176] It has been found that the low-frequency signal intensity of temperature data may deviate from the healthy baseline range before the onset of influenza and fever. Deviation of low-frequency signal intensity outside the healthy baseline range can indicate that a user may be entering an unhealthy state. Furthermore, the low-frequency signal intensity may return to the healthy baseline range before recovering. A return of low-frequency signal intensity to the healthy range indicates that a user may be returning to a healthy state.

[0177] As described herein, ring 104 (or other devices) can acquire user temperature data (e.g., skin temperature data) throughout the day and night. The frequency domain analysis techniques described herein can use any combination of daytime and / or nighttime data to detect / predict transitions between healthy and unhealthy states for a user. For example, in some implementations, computing devices (e.g., ring 104, user device 106, server 110) can perform frequency domain analysis on nighttime data (such as nighttime data from consecutive nights (e.g., when the user is asleep)). As another example, in some implementations, computing devices can perform frequency domain analysis on data from the entire day and night, such that the data includes consecutive days of data as the user alternates between wakeful and sleep times. In still other examples, computing devices can perform frequency domain analysis on daytime data, such that the data includes consecutive days of data acquired while the user is awake / active.

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

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

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

[0181] In some implementations, components of system 200 (e.g., user device 106, server 110) can select time intervals (e.g., a first time interval / reference window, a second time interval / prediction window) for disease detection. Specifically, system 200 can select / identify different time intervals (e.g., different windows) such that physiological data acquired during each time interval can be compared with each other. By comparing physiological data acquired during different time intervals, system 200 can determine whether the physiological data acquired during the corresponding time intervals meet a deviation criterion (e.g., a deviation meeting a certain threshold), where meeting the deviation criterion indicates a disease.

[0182] For example, user equipment 106 and / or server 110 can select a reference window and a prediction window for the acquired physiological data (e.g., temperature data, HRV data, etc.). In some aspects, user equipment 106 and / or server 110 can define a reference window and a subsequent prediction window for the acquired physiological data. Physiological data acquired during the reference window (e.g., a first time interval) can be used to determine baseline physiological data (e.g., baseline temperature data, baseline HRV data, etc.). Comparatively, physiological data acquired during the prediction window (e.g., a second time interval) can be compared with the baseline physiological data to determine whether a deviation criterion between the corresponding time intervals is met. In some cases, the prediction window may include recently acquired temperature data (e.g., temperature data from the last 1-5 days).

[0183] In some implementations, the reference window and prediction window can be defined in daily increments. For example, the reference window may include one or more days of physiological data (e.g., a week's worth of temperature data). Similarly, the prediction window may include one or more days of temperature data (e.g., an autoregressive strategy applied to feature specifications within that prediction window). The size of the reference window and prediction window can vary depending on the amount of physiological data available. For example, the reference window and prediction window can have a minimum size when a minimum amount of physiological data is available, or they can be drawn from existing knowledge of demographically / medically similar users. In a specific example, if server 110 operates on at least two days of physiological data and currently has two days of user physiological data, server 110 can choose a reference window for a single day's data and a prediction window for subsequent days' data. Using a minimum amount of available data allows server 110 to detect transitions between healthy and unhealthy states earlier than if server 110 were waiting to acquire a larger dataset for computation.

[0184] When user device 106 and / or server 110 acquire more physiological data from ring 104, user device 106 and / or server 110 may extend the reference window and / or prediction window. For example, server 110 may extend the reference window to establish a more robust physiological dataset for analysis. In a specific example, acquiring data from the third day may allow the reference window to extend to data from the previous two days. In this specific example, the prediction window may occupy the data from the most recent day (e.g., data from the third day). Server 110 may extend the reference window and prediction window to any length. In some implementations, server 110 may require that the physiological data for a day include the minimum portion of valid data (e.g., within a meaningful temperature threshold) for that day (e.g., 90% or more of the day). While each window may include data from one or more days, reference windows and prediction windows for other durations of physiological data can be implemented.

[0185] Reference and prediction windows used for disease detection can be of any length (e.g., hours, days, etc.). In some cases, the reference window may include seven days of data, while the prediction window may include two days of data (e.g., data from the most recent two days). The reference and prediction windows can be scrolling windows that move over time. For example, the windows may move in one-day increments or other increments. In some implementations, the windows may move in one-day increments, such that prediction calculations are performed no later than morning (e.g., the user's wake-up time), allowing predictions to be provided to the user before the start of the day (e.g., before work).

[0186] While a single prediction window can be defined, in some implementations, user device 106 and / or server 110 can define multiple prediction windows. For example, multiple prediction windows may appear sequentially after a reference window. Each of these multiple prediction windows may include data from one or more days. In some implementations, server 110 may initially expand the reference window upon receiving new data. After the reference window has expanded to the desired length (e.g., seven days), the server may add one or more additional prediction windows for additional physiological data for each day.

[0187] While user device 106 and / or server 110 may use both a reference window and a prediction window, in some implementations, aspects of this disclosure may detect a user's transition between a healthy and unhealthy state based on a prediction window without using a reference window. For example, server 110 may use data from one or more other users (e.g., users with similar demographics, similar physiological data, etc.) to determine whether a user is transitioning between a healthy and unhealthy state. In the absence of sufficient available data to form a reference window, server 110 may use only the prediction window. For example, if only physiological data for a single current day is available, server 110 may use the first day as the prediction window. Subsequently, server 110 may acquire additional data (e.g., additional days) and define both the reference window and the prediction window. If a reference window is unavailable, server 110 may select detection / prediction parameters (e.g., rating features) based on similar other users (e.g., similar age, gender, baseline characteristics, etc.).

[0188] In some aspects, user equipment 106 and / or server 110 can generate physiological parameter distributions or histograms (e.g., temperature distributions, HRV distributions, etc.) for each window (e.g., a reference window, a prediction window). For example, in the context of temperature data, the distribution can indicate the number of temperature values ​​falling within a specified probability range. For example, for a seven-day reference window, the distribution can indicate the number of temperature values ​​falling within a specified range during the seven-day window period. As another example, for a multi-day prediction window, the distribution can indicate the number of temperature values ​​falling within a specified range during the multi-day window period. In implementations using multiple windows, the distribution can be performed for each of the reference window and / or prediction window. For example, first and second windows can have corresponding first and second reference / prediction window distributions.

[0189] User equipment 106 and / or server 110 can determine one or more physiological parameter distribution values ​​(e.g., temperature distribution values, HRV distribution values) for each of these distributions. Distribution values ​​can be values ​​indicating how temperature and other signal values ​​are distributed within a window. For example, the distribution values ​​of a window can indicate the central tendency, deviation, kurtosis, and skewness of the values ​​within that window.

[0190] User equipment 106 and / or server 110 may determine one or more distributions for each window. In some implementations, each distribution may be associated with a threshold defining a minimum or maximum value associated with the distribution value, and / or with a nonparametric quantile of the distribution at the low end (e.g., .001, .01) and high end (e.g., .95, .975, .99) of the spectrum. For example, regarding high temperature deviation, the distribution value may be determined using a high percentile temperature value. In this example, temperature values ​​above this high percentile temperature value may be defined as high temperature deviation. In other words, any temperature above this high threshold temperature value may be considered high temperature deviation or anomaly. Regarding low temperature deviation, 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 deviation. In other words, any temperature below a minimum temperature threshold may be defined as low temperature deviation or possibly anomaly.

[0191] Thresholds can be defined in several ways. In some implementations, thresholds can be defined based on values ​​included in a distribution within the window. For example, a threshold can be defined as the upper / lower quantile of the distribution. In a specific example, the threshold for high-temperature deviation can be defined as temperatures greater than 95% of the temperatures in the distribution. In another specific example, the threshold for low-temperature deviation can be defined as temperatures less than the minimum 5% of the temperatures in the distribution. In some implementations, the distribution and / or threshold can be determined in other ways. For example, the distribution value and / or threshold can be determined based on the maximum / minimum temperature in the distribution, the temperature range in the distribution, the mean / median temperature in the distribution, and / or other factors associated with the distribution. Other processing techniques can also be used to determine the distribution value.

[0192] In some instances, the distributions under discussion can be multivariate. For example, given the inherent physiological relationship between activity (or MET unit) and temperature, a server can assess anomalies or changes relative to a multivariate distribution. Similarly, the distributions of heart rate, HRV, respiratory rate, and temperature can be understood within a multivariate context. The consistency or lack thereof of certain signals and their multivariate time series at certain times of day (e.g., at the onset of sleep) can provide useful features for prediction, detection, or prognostic algorithms.

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

[0194] Server 110 can determine the high temperature distribution values ​​in the prediction window in a similar manner to the reference window. In some implementations, server 110 can use values ​​from the reference window to define a threshold used in the prediction window. For example, server 110 can use a threshold (e.g., a temperature threshold) from the reference window as a threshold in the calculation of the prediction window.

[0195] In some implementations, the comparison between the reference window and the prediction window can combine reference windows derived from multiple time scales. For example, human behavior can vary significantly over a seven-day cycle due to weekday-weekend variations, leading to significant physiological changes, while human hormone cycles vary on an approximately monthly basis (particularly in women), which also specifically leads to physiological and skin temperature variations. External temperatures can change over an annual cycle and thus affect skin temperature anomalies observed in daily life. Therefore, an appropriate reference window can combine a set of weighted inputs from different information scales, or weight a given current distribution based on multiple previous reference distributions measured across various behavioral and biologically relevant time scales.

[0196] In some implementations, user device 106 and / or server 110 may determine multiple distribution values ​​for each window. For example, server 110 may determine multiple high-temperature (or multivariable temperature / activity) distribution values ​​for each window. As another example, server 110 may determine multiple low-temperature distribution values ​​for each window. As yet another example, server 110 may determine one or more distribution values ​​for high and low temperatures within a window. In a specific example, server 110 may determine high-temperature distribution values ​​at threshold quantiles of .999, .995, and .975. Server 110 may also determine low-temperature distribution values ​​at threshold quantiles of .025, .01, and .001. In implementations that determine multiple high / low temperature distribution values, some temperature values ​​above multiple thresholds may be counted twice (e.g., counted once for each distribution value). Alternatively, these distribution values ​​may be calculated based on the number of temperature values ​​between these thresholds. In some iterations, this comparison between the reference and early detection / prediction windows may be calculated using the Kullback-Leibler (KL) divergence method or direct density ratio estimation.

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

[0198] For example, server 110 can determine a relative distribution value (e.g., a relative distribution ratio) that indicates the amount of deviation between temperature values ​​in the prediction window and those in the reference window. In one example, server 110 can 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, server 110 can determine the relative distribution value for each of the multiple pairs of distribution values.

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

[0200] Diseases can be identified using peak values ​​in the relative distribution values ​​within the corresponding window. The presence of peak values ​​in the relative distribution values ​​(e.g., .999 threshold, .975 threshold, .005 threshold, .001 threshold) can indicate the onset of a disease. For example, the number of peaks and / or the value of peaks over time can indicate the onset of a disease. Server 110 can determine whether a user is transitioning from a healthy state to an unhealthy state based on the number of peaks, the value of the peaks, the arrangement of the peaks, and the additional data described herein.

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

[0202] In some implementations, server 110 may output a disease risk metric or disease prediction metric, which indicates the relative probability that a user will transition from a healthy state to an unhealthy state. For example, server 110 may determine the disease prediction metric based on one or more calculated relative distribution values. In some implementations, server 110 may generate a single or multiple prediction values ​​associated with one or more meanings described herein. In some implementations, the prediction value may be a decimal value, which may have multiple meanings depending on how server 110 is configured. In other implementations, the prediction value may be a binary value, such as a value of 0 or 1, which may have multiple meanings. In some implementations, the disease prediction metric may indicate the likelihood of a disease. For example, a decimal value may indicate the probability that a user is transitioning to an unhealthy state. As another example, a binary value of 1 may indicate that a 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 unlikely to be transitioning.

[0203] User equipment 106 and / or server 110 can determine disease risk metrics (e.g., disease prediction metrics) in various different ways. The meaning of the predicted value can depend on how it is calculated. In some implementations, server 110 may use a function (e.g., an equation) that receives relative distribution values ​​and calculates the predicted value based on those values. In some implementations, the function may include weights applied to different relative distribution values. In some implementations, server 110 may use rule-based computation to calculate the predicted value. Example 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 peaks in the relative distribution values, or any other data related to the magnitude / timing / arrangement and / or other distribution parameters of the relative distribution values.

[0204] In some implementations, user device 106 and / or 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 predicted values ​​may be referred to herein as an “early detection / prediction model” or a “prediction model.” This prediction model may be trained on training data. The training data may include data from a set of users labeled according to when a user develops symptoms of a disease. In some implementations, the prediction model may receive relative distribution values ​​as input. The prediction model may generate one or more disease prediction values ​​based on the received input. The interpretation of one or more prediction values ​​may depend on how the model was generated. In some implementations, as described herein, if the model is trained using data labeled according to symptom onset, the disease risk metric output by the model may indicate the likelihood of a disease.

[0205] In some implementations, user device 106 and / or server 110 may implement autoregressive features (e.g., in modeling). For example, server 110 may define multiple prediction windows. In implementations where server 110 defines multiple prediction windows, server 110 may compute a relative distribution value for each prediction window. In these implementations, server 110 may generate one or more prediction values ​​based on the relative distribution value for each prediction window. For example, if the prediction model takes the relative distribution value as input, the model can receive twice as many inputs when using two prediction windows instead of a single prediction window. Using multiple prediction windows allows for more accurate modeling of diseases exhibiting different characteristics in terms of incubation period, viral replication period, or the number of days before the expected onset of symptoms. For example, using a separate prediction window of multiple days may capture the incubation period of the disease better than a single, larger prediction window. In some implementations, the autoregressive component can detect a phasic transition defined by multiple overshoots at daily or diurnal rhythm frequencies, which overlays the slope of the multi-day baseline increase, close to the day of symptom onset, and reflects set-point changes in thermoregulation associated with febrile state and / or pyrogen mediators and / or other sterile or pathogen-related immune stimulation (DAMP and PAMP), with the theoretical potential to influence thermoregulation.

[0206] In some implementations, system 200 may utilize location information associated with the corresponding user (e.g., the user's geographic location) to further improve disease detection technology for that user. The body's ability to maintain its internal temperature within a comfortable range (e.g., not too hot, not too cold) is crucial for health function. Changes in ambient temperature (e.g., surrounding temperature) are one of the main factors our bodies must constantly adjust to, thus requiring adjustments to our body's "thermostat" settings, or how the body dynamically raises and lowers its temperature throughout the day in response to various disturbances (e.g., infection, exercise-induced fever, going outside, and experiencing drastic temperature changes).

[0207] Users living at more extreme latitudes (e.g., closer to the poles) experience colder climates with greater seasonal variations in light. Therefore, users at higher latitudes must adapt to more extreme cold and light. For example, in Helsinki, Finland (latitude ~60°N), the average monthly temperature can range from approximately -7°C to 21°C, and the average hours of daylight can range from approximately 6 to 19 hours. In contrast, in Crete, Greece (latitude approximately 35°N), the average monthly temperature can range from approximately 12°C to 30°C, and the average hours of daylight can range from approximately 10 to 14.5 hours. Exposure is a crucial regulator of the daily diurnal rhythm of temperature.

[0208] Exposure to hot or cold climates affects distal skin temperature, especially during the day, which can lead to “ceiling” and “floor” effects that influence disease detection. For example, on average, the 99th percentile skin temperature reading of a first user living in a colder climate may be slightly colder than that of a second user living in a warmer climate. This difference may make an increase in the 99th percentile skin temperature reading due to disease more noticeable for users living in colder climates. Conversely, in warmer climates, the influence of the external environment on transient increases in the 99th percentile skin temperature reading may add more “noise” or partially mask the effects of disease. Thus, when there is a large temperature gradient between internal body temperature and ambient temperature (such as in colder climates), wearable devices (e.g., Ring 104) may be advantageous in detecting small increases in temperature and heart rate or decreases in HRV due to the vasoconstrictive response used to prevent excessive heat loss and promote an increase in core temperature.

[0209] In other words, temperature deviations can be more pronounced for users living in colder climates compared to those living in warmer climates. Consequently, skin temperature deviations in users in colder climates may be a better indicator of disease (e.g., with higher predictive value) compared to deviations in skin temperature in users living in warmer climates. (See reference...) FIG. 7 and FIG. 6 The concept is further illustrated and described.

[0210] FIG. 7 An example of a temperature data graph 600 supporting disease detection technology according to various aspects of this disclosure is shown. Specifically, the temperature data graph 600 includes a first graph 605-a and a second graph 605-b, the first graph showing the user's high daytime temperature readings / range in cooler climates and the second graph showing the user's high daytime temperature readings / range in warmer climates.

[0211] The x-axis of Figures 605-a and 605-b shows the time (e.g., days) before and after the onset of symptoms, where time = 0 indicates the onset of symptoms (first discovery of symptoms) for users in cooler climates (e.g., higher latitudes; 55°N) and warmer climates (e.g., lower latitudes; 35°N). The onset of illness at time = 0 in Figures 605-a and 605-b can encompass a variety of respiratory or flu-like illnesses, including COVID-19, influenza, and other illnesses with similar symptoms. The y-axis of Figures 605-a and 605-b shows the highest daytime temperatures (in degrees Celsius) for users in cooler and warmer climates, respectively. Specifically, the y-axis of Figures 605-a and 605-b shows the 99th percentile (99 ile) temperature reading for users during the daytime, which, after filtering out outliers, can be considered the maximum daytime temperature for the corresponding user.

[0212] As shown in Figure 605-a, which illustrates high daytime temperature readings / ranges for users in high latitudes (e.g., near Finland) and / or colder climates, the maximum daytime temperature measured via wearable devices can increase over days and weeks that trigger symptom onset. Because skin temperature at the periphery (e.g., hands, fingers) tends to be lower during the day in colder climates, it may be easier to detect the body attempting to increase core temperature through peripheral vasoconstriction. This may also be particularly pronounced during the day, as skin temperature and core temperature are less correlated and more counter-regulated during the day, unlike during sleep.

[0213] In contrast, referring to Figure 605-b, which shows the range of high daytime temperature readings for users in lower latitudes (e.g., the southern part of the United States) and / or warmer climates, users in cooler climates exhibit a less significant increase in high daytime temperatures that lead to disease outbreaks compared to users in cooler climates. In other words, for users in warmer climates, disease may not definitively manifest as an increase in daytime maximum temperatures. In summary, it has been found that users in cooler climates may experience a more significant increase in high daytime temperatures compared to users in warmer climates.

[0214] FIG. 7 An example of a temperature data graph 700 supporting disease detection technology according to various aspects of this disclosure is shown. Specifically, the temperature data graph 700 includes a first graph 705-a and a second graph 705-b, the first graph showing low daytime temperature readings for users in cooler climates and the second graph showing low daytime temperature readings for users in warmer climates.

[0215] The x-axis of Figures 705-a and 705-b shows the time (e.g., days) before and after the onset of symptoms, where time = 0 indicates the onset of symptoms (e.g., the initial development of symptoms) for users in colder climates (e.g., higher latitudes; 55°N) and warmer climates (e.g., lower latitudes; 35°N), respectively. The illness onset at time = 0 in Figures 705-a and 705-b can encompass a variety of respiratory or flu-like illnesses, including COVID-19, influenza, and other illnesses with similar symptoms. The y-axis of Figures 705-a and 705-b illustrates the low daytime temperatures (in degrees Celsius) for users in colder and warmer climates, respectively. Specifically, the y-axis of Figures 705-a and 705-b shows a percentile (1%ile) of the user's temperature reading during the daytime after filtering out outliers, which can be considered as the minimum daytime temperature for the corresponding user. It should be noted in this paper that the absolute value of the y-axis is significantly different in the first figure 705-a (22-23℃) compared to the second figure 705-b (25-28℃).

[0216] Infection / illness can drive an increase in core body temperature. One way the body achieves this increase is by conserving heat to prevent heat loss through the body's shell. The skin does this partly through vasoconstriction (narrowing the small blood vessels at the skin's surface). This vasoconstriction is most pronounced with increasing minimum daytime temperatures, such as... FIG. 6 As shown. This phenomenon can be identified and / or characterized by 1% ile of daytime temperature distribution taken from a user for a day (compared to the previous day or baseline time period for the same user) for different machine learning algorithms.

[0217] For example, as shown in Figures 705-a and 705-b, daytime temperature readings / ranges for a user at 1% ile may increase during periods of illness, regardless of latitude or climate. Furthermore, the comparison of Figures 705-a and 705-b illustrates that users living in colder climates may experience a greater increase in daytime low temperature readings / ranges on days and weeks that lead to illness (e.g., a greater pre-symptom increase in low daytime temperatures for users in colder climates).

[0218] Therefore, in some implementations, system 200 can leverage location information and other factors (e.g., latitude, season, environmental exposure) to improve the disease prediction techniques described herein. For example, the algorithm or machine learning classifier may include the user's latitude or longitude, the month of the year, or utilize seasonally corrected time series to make the resulting temperature signal "stable" relative to climate-related changes. The algorithm / classifier (such as tree-based algorithms or other machine learning models) can learn to model the interaction between exposure and environmental factors and the unique physiological time series of an individual user. In some cases, the classifier may combine multiple signals sensitive to environmental, climatic, and seasonal effects to improve the signal-to-noise ratio for better disease detection. Furthermore, the classifier can be configured to predict diseases differently for user pools grouped based on certain similar characteristics, which may include location, climate, and environmental exposure factors.

[0219] In other words, latitude and / or other location information can be used as a coarse proxy for the general range of local temperatures, especially when considered in conjunction with time-based features such as seasons or months of the year. These features can act as “moderators” or factors influencing the relative predicted values ​​of statistical daytime temperature readings used to predict diseases. These moderators can determine whether a given daytime temperature feature is particularly useful as a predictor of disease. In some implementations, system 200 can use more sophisticated weather and regional information, combined with the geographic location of users from its user equipment 106, to derive more accurate estimates of environmental exposure and identify when individuals are inside or outside. Such location information can be used to determine the relative predictive accuracy of temperature data used to identify diseases.

[0220] For example, user device 106 and / or server 110 of system 100 may receive user-associated temperature data acquired by ring 104. User device 106 and / or server 110 may additionally receive / identify user-associated location information. Location information may include the user's geographic location, the user's latitude, or both. In some cases, user device 106 and / or server 110 may receive the user's location information based on user input received via GUI 275. For example, the user may enter their home address or approximate home location within wearable application 250. Additionally or alternatively, user device 106 and / or server 110 may determine location information based on the global positioning module of user device 106 (e.g., a Global Positioning Satellite (GPS) module, a Global Navigation Satellite System (GNSS) module, or any combination thereof).

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

[0222] Specifically, machine learning classifiers can use location information to identify / generate one or more "predictive weights" associated with the acquired temperature data. These predictive weights can be correlated with the relative predictive accuracy used to detect diseases. For example, as... FIG. 7 and FIG. 8 As shown and described, users in colder climates may experience more significant temperature variations leading to illness compared to users in warmer climates. Therefore, temperature variations (and temperature readings) for users in colder climates can have a higher relative “predictive weight” compared to temperature variations / readings for users in warmer climates. In some cases, location data can be used to determine the user's geographic location and / or climate data (e.g., ambient temperature data), which can be used to generate predictive weights. Ambient temperature data can be based on data obtained from user device 106, time of year, climate data for the determined geographic location, or any combination thereof.

[0223] Therefore, in some cases, a machine learning classifier can assign relatively high prediction weights to temperature data collected from users in colder climates and relatively low prediction weights to temperature data collected from users in warmer climates. Subsequently, when identifying the prediction weights for the temperature data collected from users, the machine learning classifier can "weight" the collected temperature data based on (e.g., using) the prediction weights to generate weighted temperature data. The machine learning classifier can then use the weighted temperature data to identify conditions that meet the bias criteria and predict diseases.

[0224] By determining a user's location information and, based on that location information (and / or ambient temperature data), determining the prediction weights for temperature data, the technique described herein can be configured to compensate for skin temperature responses between users in different climates. In other words, location information (e.g., latitude) can be used as a coarse proxy for external climate / ambient temperature, which can be used to determine the relative prediction accuracy of temperature data for disease identification. Accordingly, the technique described herein can support more accurate and efficient disease detection technologies on an international scale.

[0225] Location can also influence seasonal variations, which manifest as biological rhythm parameters (e.g., day length, which is affected by latitude throughout the calendar year, and can influence the diurnal rhythm parameters of temperature). In this way, location information can be used in several ways to weight or modify the classification of “healthy” and “unhealthy” time intervals, where seasonality or seasonal phases are factors.

[0226] Furthermore, in some respects, if information about disease rates is available at the user's location, the disease detection threshold or classifier for an individual or group can be modified. For example, if the flu case rate is significantly higher in Miami, and the user's location information indicates that the user is located in Miami, the detection threshold can be lowered to reflect the increased local risk.

[0227] In an additional or alternative implementation, instead of generating prediction weights for temperature data, system 200 can simply input both temperature data and location information into a classifier, allowing the classifier to learn which combinations of temperature data and location information are predictions of disease. In other words, system 200 can input temperature data and location information into a classifier (e.g., a machine learning classifier) ​​and train the classifier to determine / predict disease based on the received temperature data and location information. In such a case, the classifier can be trained to recognize that temperature variations across users can exhibit varying predictive accuracy when predicting disease based on the relative location (and / or climate / ambient temperature) of each corresponding user.

[0228] In some implementations, system 200 may additionally or alternatively use data associated with modifiable behavioral predictors, such as sleep and activity, to perform disease detection. Scientific evidence has shown that healthy behaviors, such as more proactive or better sleep, can minimize the risk of flu-like illnesses, including COVID-19, and can even alter the strength of antibody responses. However, conventional wearable devices have not yet effectively identified metrics associated with sleep and activity that can be collected via wearable devices to detect disease in the pre-symptomatic stage.

[0229] Some aspects of predictive algorithms / classifiers used to identify diseases (such as the user's age, gender, physiological condition, or pre-existing medical conditions) are generally beyond the user's control and can change. In contrast, activity and sleep are health behaviors that the user can modify ("modifiable behavior predictors"). Furthermore, these modifiable behavior predictors can exhibit changes as the user becomes ill. Accordingly, the techniques described herein can utilize data related to modifiable behavior predictors collected via ring 104 to further refine disease detection techniques during the pre-symptom state. Modifiable behavior predictors that can be used to perform disease detection may include, but are not limited to, daytime activity, sleep duration and sleep timing (e.g., sleep time, wake-up time), compliance associated with wearing ring 104 (e.g., frequency / consistency of the user wearing ring 104), etc.

[0230] A key behavioral marker of the disease is feeling more easily fatigued and having little energy for exercise. This feeling of fatigue is caused by inflammatory proteins (such as cytokines), which are secreted by the immune system when recognizing virus-infected cells. These inflammatory cytokines signal the brain to conserve energy, and the brain achieves this by modifying our behavior to reduce our energy expenditure.

[0231] In some aspects, the ring 104 can be configured to use activity recording sensors and / or accelerometers to measure activity (e.g., motion). The ring 104, user equipment 106, and / or server 110 can be configured to convert activity recording data and / or other activity-related data (e.g., accelerometer data) and convert these data streams into an estimate of MET, a measurement of energy consumed during the activity. This can be referenced... FIG. 8 Further illustration and description.

[0232] FIG. 8 An example of a modifiable behavior predictor 800 supporting disease detection technology according to various aspects of this disclosure is shown. Specifically, the modifiable behavior predictor 800 includes a first figure 805-a and a second figure 805-b, the first figure 805-a showing three activity-related measures (normalized for comparison) in the days before and after symptom onset, and the second figure 805-b showing sleep duration-related measures (e.g., sleep duration, wake-up time) in the days before and after symptom onset.

[0233] The x-axis of Figures 805-a and 805-b shows the time (e.g., days) before and after the onset of symptoms, where time = 0 indicates the onset of symptoms (e.g., the first development of symptoms). The y-axis of Figure 805-a is z-normalized to show the relative increase and decrease of activity-related measures over time within the same graph. The y-axis of Figure 805-b shows the changes in sleep time and wake time in normalized units.

[0234] refer to FIG. 9 Figure 805-a and curve 810-a show the user's daily inactivity duration over time, curve 810-b shows the user's average daily MET (e.g., energy expenditure) over time, and curve 810-c shows the total MET minutes accumulated over time during moderate- or high-intensity activity. As can be seen in Figure 805-a, users tend to become more inactive in the days leading up to symptom onset (e.g., the increase in curve 810-a before the onset of illness). Furthermore, the average daily MET (energy expenditure) decreases (e.g., the decrease in curve 810-b), and the total MET minutes accumulated during moderate- or high-intensity activity decreases in the days leading up to symptom onset (e.g., the decrease in curve 810-c). While all three curves 810-a, 810-b, and 810-c can show the most significant changes after symptom onset, there is an accelerating predictive change in the direction of decreased activity just before symptom onset. Accordingly, in some implementations, system 200 may use these characteristics / parameters (e.g., inactivity, average daily MET, total MET accumulated during activity) to predict disease.

[0235] While reduced activity (the decrease in curve 810-a) or a decrease in the daily average MET (the decrease in curve 810-b) can be helpful measures for disease detection, these changes can be subtle, and activity can change for many reasons other than disease. Furthermore, activity- or MET-based measures may be less meaningful than raw or absolute numbers, and are more meaningful when constructed to detect a decline relative to a person's usual activity level. Therefore, in some implementations, the corresponding components of system 200 (e.g., ring 104, user device 106, server 110) can be configured to determine the user's average daily MET as the change in the previous median daily MET relative to a representative previous baseline (e.g., fourteen days) for the same user. In other words, system 200 can compare activity and / or daily MET from a second time interval (e.g., a prediction window prior to symptom onset) with activity and / or daily MET determined from a previous first time interval (e.g., a reference window) to determine the expected change in the user's activity and / or daily MET. In this regard, activity between different time intervals and changes in daily MET (e.g., changes in daily MET relative to a user's baseline daily MET) can be used to identify the fulfillment of deviation criteria and predict disease onset.

[0236] In some implementations, system 200 may utilize a given user's raw absolute average daily MET score as a feature for disease detection, while also including the rolling mean of the daily MET average scores over the previous thirty days (which may be equally weighted or given progressively decreasing weights over time). Including these two features as input to a machine learning classifier / algorithm for disease detection allows the machine learning classifier to learn an in-user normalization strategy. In other words, by providing the user's historical activity and daily MET values ​​to the machine learning classifier, the classifier can determine the most recent change in activity / daily MET relative to the user's typical activity / daily MET level over a reference time interval (e.g., the past month).

[0237] Furthermore, exercise strengthens the immune system, making highly active users less susceptible to infection / disease. Therefore, using a rolling mean feature of activity and daily MET over a reference window (e.g., the past month) can enable machine learning classifiers to identify individuals with “stronger” immune systems who are less likely to get sick.

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

[0239] Furthermore, for users who are initially inactive, a “decline” in the mean MET due to illness may not be detectable. In other words, for highly inactive users, it may be difficult to detect a reduction in activity relative to the user’s normal low activity baseline. Therefore, when combined in a model that can learn interactions (e.g., a tree or neural network type algorithm), features that capture the user’s long-term “trait” or “reference” activity level, the consistency of those levels, and also characteristics of acute or “state” changes may be most useful.

[0240] FIG. 9 Examples of modifiable behavior predictor graphs 900 supporting disease detection technologies according to various aspects of this disclosure are shown. Specifically, the modifiable behavior predictor graph 900 includes an activity duration graph 905-a, an activity consistency graph 905-b, a MET graph 905-c, and a weekly pattern graph 905-d.

[0241] The x-axis of corresponding Figures 905-a to 905-d shows the dates (e.g., month-day) before and after the onset of symptoms, where the reference line between May 11 (05-11) and May 18 (05-18) within each Figure 905 indicates the onset of the user's corresponding disease symptoms (e.g., dry / wet breathing, allergic reactions, gastrointestinal symptoms, fever, etc.). The y-axis of Figure 905-a shows the rolling average of the duration of activity (in minutes) within a thirty-day window. The y-axis of Figure 905-b shows the standard deviation of the duration of activity (in minutes) within a thirty-day window (e.g., more or less activity consistency). The y-axis of Figure 905-c shows the daily MET expenditure (e.g., total performance in terms of effort). Finally, the y-axis of the weekly pattern Figure 905-d depicts a true / false indication of whether a given day on the x-axis includes a weekend day (e.g., 0 = weekday, 1 = weekend). Typically, weekly pattern diagrams 905-d (e.g., weekly pattern adjustment models) can be used to adjust activity expectations for users based on cyclical weekly patterns, since user activity can often be higher on weekends.

[0242] As in FIG. 9 As can be seen, users can exhibit a decrease in activity duration (e.g., a decrease in activity duration in Figure 905-a) and a decrease in activity consistency (e.g., a decrease in activity consistency in Figure 905-b) before the onset of symptoms. These patterns in activity duration and activity consistency often occur roughly simultaneously and can therefore be used as features for identifying / predicting disease. Furthermore, comparing Figure 905 with the weekly pattern figure 905-d shows that users typically exhibit higher activity levels on weekends compared to weekdays. Finally, an increase in activity duration (e.g., an increase in activity duration in Figure 905-a), an increase in activity consistency (e.g., an increase in activity consistency in Figure 905-b), and an increase in MET expenditure (e.g., an increase in MET in Figure 905-c) in the days following symptom onset can indicate a user's return from an unhealthy state to a healthy state (e.g., disease recovery).

[0243] Typically, system 200 can be with FIG. 9 The physiological data associated with the activity features shown (e.g., activity duration, activity consistency, MET) are input into a machine learning classifier, allowing the classifier to learn how to combine multiple activity features and determine the pattern that best describes each respondent user during the pre-symptom period. Using data from each respondent user to train the machine learning algorithm enables the classifier to identify each respondent user's personalized response to the disease, as each user may respond differently to the disease. Therefore, FIG. 9The activity characteristics shown can be used to identify / predict how a user will transition from an unhealthy state to a healthy state, and vice versa.

[0244] Generally, activity metrics show “seasonal” or predictable patterns that align with weekdays and weekends or certain days of the week. For example, such as FIG. 8 As shown, users are typically more active on weekends compared to weekdays. Similar cyclical patterns can be identified on a monthly, yearly, and other time basis. For example, users are generally more active in warmer months compared to colder months. This could be due to warmer weather and less rain / snow, or the impact of pandemic lockdowns altering active lifestyles.

[0245] Therefore, in some implementations, system 200 may utilize one or more models (e.g., pattern adjustment models) that describe relatively cyclical activities, behaviors, or other physiological parameters relative to a certain time interval. Models may include weekly activity models, yearly activity models, menstrual cycle models, etc. By taking into account the periodicity, predictable variability, or other physiological parameters of activity, the techniques described herein may be able to more effectively identify which variations in activity / physiological data are attributable to disease, and which variations are based on predictable periodic user behavior (e.g., more activity on weekends) and / or predictable physiological responses (e.g., monthly menstrual cycles).

[0246] For example, in some cases, components of system 200 (e.g., user devices, server 110) may generate features or models that represent weekdays as "0" and weekends as "1" (e.g., weekly pattern adjustment models) (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 model representing weekdays / weekends may be included along with activity features in a machine learning classifier or algorithm (e.g., tree algorithm, gradient boosting classification tree) to improve disease detection. In such cases, the machine learning classifier may build or "learn" feature interactions to interpret differences in user activity between weekends and weekdays to improve disease detection. For example, by feeding the weekly pattern adjustment model into a machine learning classifier, the classifier may be configured to determine that users are less active on weekdays and therefore less likely to identify low activity metrics (e.g., low MET) on weekdays as indicative of disease. In some cases, features may be each day of the week, which is pseudo-encoded as six different days of the week and a reference day.

[0247] In some implementations, System 200 can apply a Seasonal Autoregressive Integrated Moving Average (SARIMA) model, which can be applied to past time series of 30 days or longer, during which users are known to be healthy. The seasonal order parameter can be fixed to 7 to capture weekly seasonality. This model can be trained for each corresponding user, and the output is a parameter reflecting the degree to which a given user exhibits a weekly pattern in terms of activity. These personalized SARIMA coefficients, based on a rolling window of the past N days, can then be used as features for a larger machine learning classifier. Additionally or alternatively, a time series classification model (e.g., a randomized kernel transform (ROCKET) model or a MiniROCKET model) can be used, which inherently models autoregressive or other time-related patterns.

[0248] In some cases, when performing disease detection / analysis, user adherence to wearable devices can include additional, modifiable behavioral predictors. Borrowing terminology from behavioral medicine, "adherence" can refer to whether a user wears the ring 104, or how often they wear it (e.g., frequency / consistency of user wear of the ring 104). It has been found that, generally, users wear the ring 104 more frequently when they are ill (e.g., increased disease adherence). Furthermore, increased adherence has been found to indicate some users recovering from illness. In fact, users typically exhibit increased adherence shortly after symptom onset and during recovery (e.g., more consistent wear time, reduced non-wear time). This could be due to increased user interest in viewing physiological data when ill, or due to the fact that users are less likely to remove their ring 104 due to illness or various activities.

[0249] In this regard, the term "compliance data" can refer to data associated with the frequency or consistency of a user wearing the ring 104. In some aspects, the ring 104 can determine whether a user is wearing the ring based on the duration the ring 104 is charging, via the presence (or absence) of detected user temperature readings, respiratory rate, heart rate data, etc. In this regard, the ring 104 can determine the "compliance data" and transmit the "compliance data" to the user device 106 and / or the server 110, which can be used to determine the user's compliance with wearing the ring 104. Furthermore, compliance data (e.g., changes in compliance data) can be used by the system 200 to identify disease onset, recovery from disease, or both. For example, the user device 106 can identify changes in the user's compliance data (e.g., more frequent / consistent wearing of the ring 104, less frequent / consistent wearing of the ring 104). In this example, the user device 106 can determine a disease risk measure, predict disease onset / recovery, or any combination thereof based on changes in compliance data.

[0250] Fatigue symptoms can include another important behavioral marker of illness. When the body senses an infection, the immune system signals the brain to direct energy to fight it. Sleep timing features for machine learning algorithms can include falling asleep earlier than normal (“earlier sleep”), falling asleep faster (lower “wait time”), longer sleep duration than usual, waking up later than normal, etc. In some implementations, the disease detection classifier / algorithm described in this paper can include absolute values ​​as well as features representing previous typical averages or medians over a representative time period (such as fourteen days). In other implementations, the disease detection algorithm can represent the current day’s measurement as the difference between the current day’s measurement and the median of the previous fourteen days (or a representative baseline of a reasonable length). Such features can be fed into tree algorithms or neural network algorithms, with or without binary features representing a day of the week or a weekend / weekday.

[0251] For example, refer to again FIG. 10 Figure 805-b is shown. The x-axis of Figure 805-b shows the time (e.g., days) before and after the onset of symptoms, where time = 0 indicates the onset of symptoms (e.g., the first development of symptoms), while the y-axis of Figure 805-b shows the changes in sleep time and wake time in normalized units. Curve 810-d shows the user's sleep time, quantified in minutes since midnight and calculated as an increment of the user's median sleep time relative to a previous representative baseline period (e.g., the previous 7–14 days). Similarly, curve 810-e shows the user's wake time, quantified in minutes since midnight and calculated as an increment of the user's median wake time relative to a previous representative baseline period (e.g., the previous 7–14 days).

[0252] As can be seen in Figure 805-b, users typically go to bed earlier than the onset of disease symptoms (e.g., a decrease in curve 810-d) and wake up later (e.g., an increase in curve 810-e). Thus, in some implementations, system 200 can determine a user's sleep data (e.g., sleep duration, wake-up time) to determine the onset of disease. Specifically, changes in sleep data (e.g., changes in sleep duration and / or wake-up time) can be used to identify the fulfillment (or lack) of a bias criterion, which is then used to identify / predict the disease.

[0253] Not all users respond to illness in the same way. Furthermore, viruses and infections can affect users in different ways. Therefore, different users can exhibit different sleep patterns across a set of sleep timing variables in response to illness. Classifiers (e.g., machine learning classifiers, machine learning algorithms, tree-based algorithms) can be configured to automatically detect different sleep data patterns and thresholds across feature panels, which improves the disease prediction techniques described in this paper. Moreover, by using each user's own sleep data as reference data, classifiers can be trained on a personalized basis for each user, enabling the classifier to more accurately detect changes in each corresponding user's sleep data and thereby predict illnesses based on each corresponding user's sleep data.

[0254] FIG. 9 An example of a modifiable behavior predictor diagram 1000 supporting disease detection technology according to various aspects of this disclosure is shown. Specifically, the modifiable behavior predictor diagram 1000 includes a sleep time diagram 1005-a, a wake-up time diagram 1005-b, a sleep duration diagram 1005-c, and a weekly pattern diagram 1005-d.

[0255] The x-axis of corresponding Figures 1005-a to 1005-d shows the dates (e.g., month-day) before and after the onset of symptoms, where the reference line between May 11 (05-11) and May 18 (05-18) within each Figure 1005 shows the onset of the user's corresponding illness symptoms (e.g., dry / wet breathing, allergic reactions, gastrointestinal symptoms, fever, etc.). The y-axis of Figure 1005-a shows the user's sleep time, quantified in minutes from midnight and calculated as a rolling average over a 30-day window. The y-axis of Figure 1005-b shows the user's wake-up time, quantified in minutes from midnight and calculated as a rolling average over a 30-day window. The y-axis of Figure 1005-c shows the duration of the user's sleep in seconds per night. Finally, the y-axis of Weekly Pattern Chart 1005-d depicts a true / false indication of whether a given day on the x-axis includes a weekend (e.g., 0 = weekday, 1 = weekend). In general, Weekly Pattern Chart 1005-d can be used to adjust sleep expectations for users based on cyclical weekly patterns. For example, when users don't have to work, they are often able to sleep more on weekends.

[0256] As in FIG. 9As can be seen, it has been found that users tend to go to bed earlier (e.g., increased sleep time in Figure 1005-a) and wake up later (e.g., increased wake-up time in Figure 1005-b) on days that trigger symptom onset. Furthermore, users tend to sleep longer on days that trigger symptom onset (e.g., increased sleep duration in Figure 1005-c). In this regard, these characteristics of users' sleep data (e.g., sleep time, wake-up time, sleep duration) can be fed into a classifier (e.g., a machine learning classifier) ​​to identify bias criteria for predicting disease onset.

[0257] The relative consistency of various parameters (e.g., consistency of sleep duration, consistency of wake-up time) can also be used to perform the disease detection techniques described herein. Typically, humans have consistent sleep patterns (e.g., users usually sleep and wake around similar times each day). Consistent sleep patterns allow cells within the body to align with their environment and optimize energy efficiency by knowing the optimal time to mobilize energy into the bloodstream or fight infection. Thus, consistent sleep patterns can help prevent disease.

[0258] Therefore, sleep timing parameters / features associated with the “consistency” of a user’s sleep habits (e.g., sleep time and wake-up time) can be used to predict disease onset. Sleep time consistency and wake-up time consistency can be measured as the standard deviation relative to a reference time interval (e.g., the previous thirty days) from before midnight when the individual fell asleep or woke up. In particular, sleep time and wake-up time have been found to become more inconsistent (or variable) in the days preceding symptom onset. This may be due to behavioral changes during the disease’s incubation period. Thus, in some implementations, features / parameters associated with the consistency of sleep data (e.g., sleep time consistency, wake-up time consistency, sleep duration consistency) can be used to predict or identify diseases, as described herein.

[0259] In some implementations, system 200 may utilize one or more "pattern adjustment models" to improve the disease detection technology described herein. Pattern adjustment models can be used to interpret predictable variations in a user's behavior, activity, sleep patterns, and / or physiological data. In some implementations, pattern adjustment models can be used to interpret recurring cyclical patterns. Pattern adjustment models may include weekly pattern adjustment models, seasonal pattern adjustment models, yearly pattern adjustment models, or any combination thereof.

[0260] For example, as mentioned earlier in this article... FIG. 10 Figure 905-d and FIG. 11As depicted in Figure 1005-d, 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 can be used (e.g., input into a classifier) ​​to account for changes in a user's sleep patterns and / or activity patterns between weekdays and weekends. Accordingly, by inputting the weekly pattern adjustment model into a classifier, system 200 may be able to more effectively distinguish between changes in sleep / activity patterns that indicate an impending illness and changes attributable to normal cyclical changes in behavior throughout the week.

[0261] Similarly, annual pattern adjustment models and / or seasonal pattern adjustment models can help system 200 distinguish between changes in sleep / activity patterns that indicate an impending illness and changes attributable to normal cyclical variations in behavior throughout the year (e.g., users are typically less active during winter months compared to summer months). In some implementations, system 200 can generate a pattern adjustment model for each individual user on a per-user basis. Specifically, system 200 can acquire users' physiological data and generate user pattern adjustment models based on the acquired physiological data.

[0262] For example, by collecting users' physiological data over several weeks, system 200 can determine that users go to bed later, wake up later, and are generally more active on weekends compared to weekdays (this can be represented as a "user activity metric"). In this regard, system 200 can generate a weekly pattern adjustment model that captures this information. Accordingly, by generating a weekly pattern adjustment model for users, system 200 may be able to more effectively distinguish changes in users' behavior (e.g., sleep patterns, activity patterns) and / or physiological data that can be attributed to illness and simply to the user's normal weekly routine. For example, feeding the weekly pattern adjustment model into a classifier can reduce the likelihood that the classifier interprets later bedtimes and later wake-up times on weekends as attributable to illness.

[0263] In some respects, pattern-adjusting models can be used to generate “prediction weights” that can improve the disease detection techniques described in this paper. As previously noted, prediction weights can refer to some weighted or other metric associated with the relative predictive accuracy used to detect a disease. For example, higher prediction weights can be associated with higher relative accuracy in predicting a disease (e.g., more accurate in identifying the disease), while lower prediction weights can be associated with lower relative accuracy in predicting a disease (e.g., less accurate in identifying the disease).

[0264] For example, compared to weekdays, users are typically more likely to go to bed later, wake up later, and be more active on weekends. In this example, sleep data indicating later bedtimes and wake-up times on weekends could be associated with lower “predictive weights” because these parameters are more likely to be attributed to a user’s normal weekly sleep habits rather than indicating a disease. In this regard, system 200 can utilize a determined pattern adjustment model (e.g., a weekly pattern adjustment model, a seasonal pattern adjustment model, an annual pattern adjustment model) to generate one or more “predictive weights” for physiological data, sleep data, activity data, etc., where these predictive weights are used to improve the disease detection techniques described herein. Specifically, predictive weights and / or pattern adjustment models can be input into a classifier to determine whether bias criteria for identifying diseases are met (or lack thereof). Specifically, higher user activity metrics on weekends and lower user activity metrics on weekdays can be used to determine different “predictive weights” for weekends and weekdays, respectively, where changes in sleep data, activity data, or both are evaluated relative to the corresponding predictive weights.

[0265] In some implementations, system 200 may utilize a pattern adjustment model configured to interpret predictable periodic variations in physiological data attributable to a normal menstrual cycle (e.g., a menstrual cycle model). For example, it has been found that users with natural cycles exhibit variations in physiological data based on the individual user's position within their own menstrual cycle. This temperature variation can be attributed to progesterone, a hormone that regulates the menstrual cycle. For instance, a user's temperature may fluctuate throughout their menstrual cycle, with the user typically exhibiting the highest temperature readings during the luteal phase of the cycle. Utilizing a menstrual cycle model allows system 200 to more efficiently determine variations in physiological data and other parameters (e.g., sleep data, activity data) attributable to disease, and which variations are solely due to the user's natural menstrual cycle. Specifically, the use of a menstrual cycle model can reduce or eliminate the frequency with which system 200 incorrectly interprets natural temperature increases throughout the menstrual cycle as indicative of disease.

[0266] In some implementations, system 200 can generate a menstrual cycle model for each corresponding user. In other words, system 200 can utilize the physiological data of each corresponding user to generate a menstrual cycle model customized for that user. This can be referred to... FIG. 11 Further illustration and description.

[0267] FIG. 12An example of a menstrual cycle model 1100 supporting disease detection technology according to various aspects of the present invention is shown. Specifically, the menstrual cycle model 1100 shows a raw temperature data diagram 1105-a, a filtered temperature data diagram 1105-b, a square wave temperature data diagram 1105-c, and a cycle phase diagram 1105-d.

[0268] The x-axis of each corresponding graph shows the time (e.g., date) at which the user's menstrual cycle is being assessed. The y-axis of the raw temperature data graph 1105-a and the filtered temperature data graph 1105-b shows the deviation of the user's high daily temperature readings (in degrees Celsius) relative to the measured average high daily temperature readings of the user over a reference period (e.g., the previous sixty days). In other words, the y-axis of graphs 1105-a and 1105-b shows the user's intra-cycle temperature deviation. The y-axis of the square wave temperature data graph 1105-c shows the predicted phase of the cycle, where 1 indicates the luteal phase and 0 indicates the follicular phase. The y-axis of the cycle phase graph 1105-d shows the phase of the user's menstrual cycle from 0 to 1, where 0 indicates the start of a new menstrual period and 1 indicates the end of the menstrual cycle.

[0269] In some aspects, system 200 may acquire physiological data (e.g., temperature data) from the user over time. In some cases, user equipment 106 and / or server 110 may determine a single daily temperature for each corresponding day, which typically represents the high nighttime temperature reading for that day. A single high-temperature reading is shown in the raw temperature data graph 1105-a. Subsequently, user equipment 106 and / or server 110 may filter the raw temperature data (e.g., apply a bandpass filter) to generate a filtered temperature data graph 1105-b. Filtering the temperature data can remove any abnormally high or low temperature readings from the raw temperature data graph 1105-a, which could be attributed to a hot shower, being in the sun, etc.

[0270] A peak-finding algorithm can be used on corresponding Figure 1105 to identify peaks in temperature readings (e.g., temperature readings greater than or equal to a certain temperature threshold), as shown within corresponding Figure 1105. Typically, a peak-finding algorithm can find peaks in temperature readings that generally correspond to a specific phase within the menstrual cycle (e.g., the luteal phase). In other words, in some implementations, a peak-finding algorithm can be used to identify temperature spikes that correspond to the end of the menstrual period when the user typically exhibits a naturally rising temperature.

[0271] In some cases, system 200 can implement a peak-finding algorithm based on general understanding of the menstrual cycle. For example, the menstrual cycle of most women with natural cycles typically lasts 20 to 40 days. Accordingly, in some cases, the peak-finding algorithm can 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 therefore menstrual periods) that are less than 15 days apart from each other. In this regard, system 200 can implement a menstrual cycle duration threshold to generate a menstrual cycle model. The term "menstrual cycle duration threshold" can refer to the estimated menstrual period timing relative to a previous menstrual period (e.g., the duration between menstrual periods), the estimated duration between luteal phases relative to a previous luteal phase, the estimated follicular phase timing relative to a previous follicular phase, or any combination thereof. The use of a menstrual cycle duration threshold also allows the system to more effectively identify specific phases within the menstrual cycle in the presence of noisy temperature readings attributable to birth control and / or menopause. Furthermore, in some implementations, the peak finding algorithm can be configured to identify temperature peaks only when the user's temperature reading has increased (e.g., met a certain temperature threshold) for a certain number of days.

[0272] Subsequently, user equipment 106 and / or server 110 can identify characteristics of the user's menstrual cycle (e.g., menstrual period). In some cases, system 200 can identify the menstrual period based on peaks identified via a peak finding algorithm (e.g., based on a menstrual cycle duration threshold). In additional or alternative cases, system 200 can identify the menstrual period of a corresponding user's menstrual cycle based on user input received via user equipment 106. For example, a user can input one or more user inputs via GUI 275 of user equipment 106, where the user inputs are associated with the user's menstrual cycle. The user inputs may indicate the start / end of the menstrual period, the ovulation period of the menstrual cycle, etc. In some cases, system 200 may cause user equipment 106 (e.g., GUI 275) to display a prompt for user input related to the user's menstrual cycle, where the user input is received in response to the prompt.

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

[0274] System 200 can then generate a menstrual cycle model for the user based on the characteristics of the identified corresponding user's menstrual cycle (e.g., based on the start / end of the identified menstrual period, the start / end of the identified follicular / luteal phase, etc.). For example, as shown in cycle phase diagram 1105-d, the menstrual cycle model can indicate the user's cycle phase. The cycle phase can be measured from 0 to 1 to indicate how far the user has progressed through the menstrual period over time (e.g., the percentage of distance traveled). For example, if the user's menstrual period typically lasts 25 days, then each day would represent 1 / 25 = 0.04 of the menstrual cycle. For example, the first day of a new menstrual period can be represented by 0.04 in cycle phase diagram 1105-d (1 / 25 = 0.04), and the second day of the menstrual period can be represented by 0.08 in cycle phase diagram 1105-d (2 / 25 = 0.08). Similarly, the twenty-fifth day of menstruation (e.g., possibly the last day) can be represented by 1 in the cycle phase diagram 1105-d (25 / 25 = 1), which indicates that menstruation is at or nearing its end.

[0275] When generating a menstrual cycle model for a user, system 200 can utilize the menstrual cycle model to more effectively determine scores for the user (e.g., sleep score, readiness score). For example, based on the menstrual cycle model, a classifier can be configured to identify elevated temperatures that the user typically exhibits at the end of each menstrual period. To this end, the classifier can be configured to consider the expected high temperatures during the later part of the menstrual period when determining sleep and readiness scores.

[0276] Furthermore, system 200 can be configured to utilize a menstrual cycle model for each corresponding user in order to improve the disease detection / prediction techniques described herein. By inputting the user's menstrual cycle model along with the user's physiological data into a classifier, the classifier can be configured to more effectively identify whether changes in physiological data (e.g., an increase in temperature readings) are attributable to an impending illness or simply to the user's natural menstrual cycle.

[0277] For example, in some implementations, system 200 may determine one or more prediction weights for temperature data acquired from a user based on a determined menstrual cycle model. As previously noted herein, prediction weights may be associated with the relative predictive accuracy of the temperature data used to predict disease. Specifically, temperature data with higher prediction weights may indicate more disease (e.g., higher prediction accuracy), while temperature data with lower prediction weights may indicate less disease (e.g., lower prediction accuracy). For example, referring to cycle phase diagram 1105-d, system 200 may determine that high temperature readings acquired during the earlier part of the menstrual cycle (e.g., days closer to 0 on the 0-1 scale) are associated with higher prediction weights, while high temperature readings acquired during the later part of the menstrual cycle (e.g., days closer to 1 on the 0-1 scale) are associated with lower prediction weights. These prediction weights may take into account the fact that users naturally exhibit elevated temperature readings near the end of each menstrual cycle, making the elevated temperature readings toward the end of each menstrual cycle natural and expected, and therefore unlikely to indicate disease.

[0278] As another example, temperature readings of users acquired during the menstrual, luteal, and / or follicular phases may be associated with relatively low predictive weights (e.g., lower relative predictive accuracy for detecting diseases), while temperature readings of users acquired outside the menstrual, luteal, and / or follicular phases may be associated with relatively high predictive weights (e.g., higher relative predictive accuracy for detecting diseases).

[0279] User equipment 106 and / or server 110 can be configured to weight temperature data acquired from the user over time using one or more prediction weights to generate weighted temperature data. By weighting the acquired temperature data, system 200 (e.g., a classifier implemented by system 200) can be configured to interpret the fact that elevated temperature readings throughout a natural menstrual cycle can more or less indicate a disease, depending on when the corresponding temperature readings are collected during that menstrual cycle. The weighted temperature readings can then be used to identify conditions that meet a bias criterion used to determine / predict a disease.

[0280] In some implementations, system 200 can be configured to test and validate classifiers, algorithms, or models for identifying / predicting diseases based on data collected from multiple users. For example, server 110 of system 200 can receive training data from a set of user devices 106. Each of the user devices 106 can be associated with ring 104 or other wearable devices 104 configured to collect physiological data from the corresponding user (e.g., communicatively coupled to ring 104 or other wearable devices 104). Training data may include collected physiological data (e.g., temperature data, HRV data, etc.) and / or user status data collected from a set of users. Furthermore, server 110 can be configured to generate disease assessment metrics (e.g., disease risk metrics, disease prediction metrics) and transmit these metrics to user devices 106.

[0281] Continuing with the same example, server 110 can acquire physiological data (e.g., temperature data) and user status data from a set of user devices 106. User status data can include various types of data. For example, user status data can include symptom data, such as symptom descriptions and timing. User status data can also include diagnostic status. In some implementations, user status data can include self-reported data that a user can report to server 110. In other implementations, user status data can be reported to server 110 by another party. In some implementations, self-reported data can be validated by an external source (e.g., a doctor's diagnosis and test results). In some implementations, user status data can include conclusions drawn from user physiological data, such as symptoms / diseases (e.g., fever) determined based on temperature data or other user physiological data.

[0282] Example self-reported data may include symptoms indicating a disease, such as influenza A / B or COVID-19. In other implementations, symptoms may be more commonly 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, server 110 and / or user device 106 may provide a list of symptoms / diseases for the user to select from a web-based GUI 275 and / or application GUI 275. User status data may be reported at various times. For example, user status data may be reported once (e.g., at the onset of a disease) or multiple times (e.g., daily). In this regard, in response to receiving an algorithmically generated prediction of the probability of a disease, a semi-supervised disease detection model may be provided with user feedback. For example, the user may be provided with a menu of options or a checklist of possible recent behavioral, environmental, or health-related changes, which may alternatively consider phase transitions detected by a ring or other device. The user's response to such prompts can then be used (e.g., in a Bayesian manner) to adjust future predictions for that user.

[0283] Additional example user status data and training data may include, but are not limited to: 1) blood / swab / biological or medical tests used to confirm diagnosis or quantify infection / immunity / vaccination response; 2) medical record data; 3) symptom recall bias derived from self-reported timing relative to the time a user has reported experiencing symptoms (e.g., features in the model that calibrate confidence in self-reports relative to recall bias affecting subjective symptom reporting); 4) COVID-19 prevalence over time by region (city, postal code, etc.); 5) prevalence specific to certain employment centers (e.g., hospitals 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 external temperature, humidity, etc.; and 8) transportation data (e.g., metrics for deriving whether a user uses public transportation and quantifying the movement of the local population).

[0284] In some implementations, user status data may include other data, such as the user's geographic location (e.g., latitude / longitude) associated with the acquired temperature data. Such geographic location data can be used to generate geographic location-specific predictive models. Furthermore, geographic location data can be used to assess whether a user is likely to transition to an unhealthy state. User status data may also indicate the user's employment location and type, user demographics (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 can be used to make more targeted predictive models and predictive determinations.

[0285] Server 110 (e.g., a model generation module) can train one or more disease prediction models (e.g., classifiers, algorithms, or other models for detecting / predicting diseases) using a training dataset that includes physiological data (e.g., temperature data) and associated user state data. Server 110 can use training data with various labels to generate the disease prediction models (e.g., classifiers) described herein. In some implementations, server 110 can use training data that includes a relative distribution of values ​​divided into daily values. Server 110 may also include labels for the daily relative distribution data indicating whether a user is healthy or unhealthy. For example, these labels could be 1 for unhealthy (e.g., symptom onset) and 0 for healthy. In this example, the disease prediction model can generate a disease risk measure for the user. In some cases, the disease risk measure can include a disease prediction value between 0 and 1, indicating the likelihood that the user is transitioning to an unhealthy state. Server 110 can generate disease prediction models using data from several days (e.g., several weeks) for each user.

[0286] Subsequently, server 110 can test / validate the performance of one or more disease prediction models (e.g., classifiers). In some implementations, server 110 can test / validate one or more disease prediction models by comparing the outputs from one or more disease prediction models with the training data. In other words, server 110 can use supervised learning techniques to test / validate the performance of one or more disease prediction models. Server 110 can then use one or more disease prediction models to generate disease assessment metrics (e.g., disease risk metrics, disease prediction values) for users, as described herein, where the disease assessment metric is associated with the probability or likelihood that the corresponding user will transition from a healthy state to an unhealthy state.

[0287] In some implementations, user device 106 and / or server 110 can generate and / or interpret disease assessment metrics (e.g., disease risk metrics, disease prediction values) based on the characteristics of each respective user. For example, server 110 can generate and / or interpret disease risk metrics based on the user's location. In one example, a lower indicated probability of disease can be alerted to a user in a geographically less disease-prevalent location compared to a user in a less disease-prevalent location (e.g., using Bayesian statistics or other methods). Similarly, server 110 can generate / interpret disease risk metrics based on similarity to other users, such as those in the same location / employment type (e.g., the same office, the same frontline work, etc.), which involves clustering or hybrid modeling techniques. In this case, server 110 can warn a user of potential illness with a lower probability if others in their workplace are sick. In some implementations, a threshold can be set by the manager / employer. One or more predictive models can be trained and / or used based on user characteristics.

[0288] FIG. 2 An example of a health management platform 1200 supporting disease detection technology according to various aspects of this disclosure is shown. The health management platform 1200 may implement or be implemented by various aspects of system 100, system 200, or both.

[0289] The health management platform 1200 can be configured to perform health monitoring (e.g., HRM services) for one or more users 102. Specifically, the health management platform 1200 can be configured to monitor (e.g., continuously monitor) the physiological data of one or more users 102 in order to provide physiological data, disease risk metrics, etc., to some administrators (e.g., administrator user devices 106-d) associated with one or more users 102. In some implementations, the administrator user device 106-d may be operated or associated with healthcare professionals (e.g., doctors, nurses), organizational administrators (e.g., business owners, corporate managers), personal trainers, coaches (e.g., sports team coaches), etc. In this regard, the health management platform 1200 can be configured to provide a certain administrator (administrator user device 106-d) with health-related information (e.g., disease risk scores) associated with one or more users 102.

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

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

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

[0293] In some implementations, the health management platform 1200 can enable the GUI of the administrator user device 106-d to display all or part of the physiological data obtained from the corresponding user, and / or parameters calculated / identified based on the obtained physiological data. For example, when the administrator user device 106-d is associated with the administrator of the doctor's office of users 102-a, 102-b, and 102-c, the administrator user device 106-d can receive and display physiological data associated with the corresponding user 102, sleep data of the corresponding user 102 (e.g., sleep stage, sleep duration), etc. In this respect, the health management platform 1200 can enable the continuous reporting of health-related data for each corresponding user to applicable medical professionals or other users, which can enable more accurate and comprehensive medical decisions for the corresponding user 102.

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

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

[0296] In some aspects, the health management platform 1200 can report physiological data and / or disease risk measures based on one or more user inputs received via administrator user device 106-d and / or other user devices 106 (via administrator user device 106-d). User inputs can be associated with the identification of disease risk measures, the reporting of disease risk measures, or both. In other words, user inputs can be used to customize how disease risk measures are reported, which disease risk measures are reported, etc. User inputs can be associated with thresholds used to identify disease risk measures, thresholds used to report disease risk measures, or both.

[0297] For example, an administrator can input (e.g., via administrator user device 106-d) a threshold for reporting disease risk metrics. In this example, the health management platform 1200 can be configured to report a disease risk metric to administrator user device 106-d only when the corresponding disease risk metric meets (e.g., is greater than or equal to) the threshold. In this respect, the health management platform 1200 can be customized to generate a disease alert only when the health management platform 1200 predicts that user 102 will become ill with a certain threshold confidence level. Such a technique can reduce the number of alerts sent to administrator user device 106-d.

[0298] In some aspects, the health management platform 1200 (e.g., server 110, user devices 106-a, 106-b, 106-c) can enable the administrator user device 106-d to display one or more recommendations. These recommendations can be associated with disease risk metrics determined for the respective users 102-a, 102-b, and 102-c. For example, the administrator user device 106-d might display recommendations for user 102 to schedule a doctor's appointment, for user 102 to stay home instead of going to work or engaging in another activity, for user isolation, and for user 102 to prepare for potential illnesses (e.g., moisturizing, resting), etc. In this way, the health management platform 1200 can help prevent the spread of disease and mitigate the possibility of disease outbreaks.

[0299] In some cases, the health management platform 1200 can (via administrator user device 106-d) generate recommendations for users 102 other than the user 102 predicted to be sick. For example, if server 110 predicts that first user 102-a is likely to be sick (e.g., high disease risk measure), and first user 102-a shares a cubicle with second user 102-b, then server 110 can enable administrator user device 106-c to display recommendations for second user 102-b to schedule a doctor's appointment or stay home instead of going to work, based on first user 102-a's disease risk measure and the potential connection between first user 102 and second user 102.

[0300] Furthermore, the health management platform 1200 can be configured to modify the disease risk metric of a user 102 based on the disease risk metric of another user 102. For example, continuing the example above, a first user 102-a and a second user 102-b may share a cubicle. This information can be entered into the health management platform 1200 via an administrator user device 106-d and can be used to determine potential contact and / or potential close proximity between users 102-a and 102-b. In this example, the server 110 can determine a first disease risk metric for the first user 102-a and a second disease risk metric for the second user 102-b. The first disease risk metric may indicate the likelihood that the first user 102-a is sick or will become sick. Accordingly, the server 110 can be configured to selectively modify (e.g., selectively increase) the second disease risk metric of the second user 102-b based on the first disease risk metric of the first user 102-a and / or the potential contact / potential close proximity between the respective users 102-a and 102-b.

[0301] FIG. 14 A block diagram 1300 of a device 1305 supporting disease detection technology according to various aspects of this disclosure is shown. Device 1305 may include an input module 1310, an output module 1315, and a wearable application 1320. Device 1305 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0302] Input module 1310 may provide 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 related to disease detection technologies). Information may be transmitted to other components of device 1305. Input module 1310 may utilize a single antenna or a group of multiple antennas.

[0303] Output module 1315 may provide means for transmitting signals generated by other components of device 1305. For example, output module 1315 may transmit information associated with various information channels (e.g., control channels, data channels, information channels related to disease detection technologies), such as packets, user data, control information, or any combination thereof. In some examples, output module 1315 may be located in the same location as input module 1310 in the transceiver module. Output module 1315 may use a single antenna or a group of multiple antennas.

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

[0305] According to the examples disclosed herein, wearable application 1320 can support automatic disease detection. Data acquisition component 1325 can be configured or otherwise supported to provide means for receiving user-associated HRV data from the wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval. Classifier component 1330 can be configured or otherwise supported to provide means for inputting HRV data into a classifier. Classifier component 1330 can be configured or otherwise supported to provide means for identifying a first subset of HRV data collected during the first time interval and a second subset of HRV data collected during the second time interval that satisfy one or more deviation criteria. User interface component 1335 can be configured or otherwise supported to provide means for displaying a disease risk measure associated with the user, at least in part, based on satisfying one or more deviation criteria, the disease risk measure being related to the relative probability that the user will transition from a healthy state to an unhealthy state.

[0306] FIG. 15 A block diagram 1400 of a wearable application 1420 supporting disease detection technology according to various aspects of this disclosure is shown. Wearable application 1420 may be an example of a wearable application as described herein, or an aspect of wearable application 1320, or both. Wearable application 1420 or its various components may be examples of apparatuses for performing various aspects of the disease detection technology as described herein. For example, wearable application 1420 may include a data acquisition component 1425, a classifier component 1430, a user interface component 1435, a sleep stage component 1440, a circadian rhythm component 1445, a user input component 1450, or any combination thereof. Each of these components may communicate directly or indirectly with each other (e.g., via one or more buses).

[0307] According to the examples disclosed herein, wearable application 1420 can support automatic disease detection. Data acquisition component 1425 can be configured or otherwise supported to provide means for receiving user-associated HRV data from the wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval. Classifier component 1430 can be configured or otherwise supported to provide means for inputting HRV data into a classifier. In some examples, classifier component 1430 can be configured or otherwise supported to provide means for identifying a first subset of HRV data collected during the first time interval that satisfies one or more deviation criteria between the second subset of HRV data collected during the second time interval. User interface component 1435 can be configured or otherwise supported to provide means for displaying a user-associated disease risk measure, at least in part, based on satisfying one or more deviation criteria, which is related to the relative probability that the user will transition from a healthy state to an unhealthy state.

[0308] In some examples, classifier component 1430 may be configured or otherwise supported as means for determining the frequency content of HRV data within at least a portion of a first time interval and at least a portion of a second time interval, wherein identification of one or more deviation criteria is based at least in part on the frequency content.

[0309] In some examples, to support the determination of the frequency content of HRV data, classifier component 1430 may be configured or otherwise support means for determining the low-frequency content of HRV data. In some examples, to support the determination of the frequency content of HRV data, classifier component 1430 may be configured or otherwise support means for determining the high-frequency content of HRV data, wherein identification of one or more deviation criteria is based at least in part on low-frequency content, high-frequency content, or both.

[0310] In some examples, classifier component 1430 may be configured or otherwise supported as means for identifying the divergence between low-frequency content of HRV data and high-frequency content of HRV data between a first time interval and a second time interval, wherein the identification of satisfying one or more deviation criteria is based at least in part on the identification divergence.

[0311] In some examples, the data acquisition component 1425 may be configured or otherwise supported to provide means for receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval. In some examples, the sleep stage component 1440 may be configured or otherwise supported to provide means for identifying multiple sleep stages associated with a user, at least in part, based on physiological data. In some examples, the sleep stage component 1440 may be configured or otherwise supported to provide means for identifying a first portion of HRV data corresponding to a first sleep stage among multiple sleep stages within a first time interval and a second portion of HRV data corresponding to a second sleep stage among multiple sleep stages within a second time interval, the first and second sleep stages comprising the same type of sleep stage, wherein inputting HRV data to a classifier includes inputting both the first and second portions of the HRV data.

[0312] In some examples, the circadian rhythm component 1445 may be configured or otherwise supported to include means for identifying at least a first portion of a first time interval and a second portion of a second time interval based at least in part on a circadian rhythm associated with a user. In some examples, the circadian rhythm component 1445 may be configured or otherwise supported to include means for identifying a first portion of HRV data corresponding to the first portion of the first time interval and a second portion of HRV data corresponding to the second portion of the second time interval, wherein inputting HRV data into a classifier includes inputting both the first and second portions of the HRV data.

[0313] In some examples, classifier component 1430 may be configured or otherwise supported as means for identifying RMSSD metrics associated with HRV data, wherein the identification of those satisfying one or more deviation criteria is based at least in part on the RMSSD metrics.

[0314] In some examples, the data acquisition component 1425 may be configured or otherwise supported to allow means for receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval. In some examples, the classifier component 1430 may be configured or otherwise supported to allow means for identifying resting heart rate data, mean HRV score data, recovery measurement data, or any combination thereof, at least in part based on the physiological data. In some examples, the classifier component 1430 may be configured or otherwise supported to allow means for inputting resting heart rate data, mean HRV score data, recovery measurement data, or any combination thereof into a classifier, wherein identification of data satisfying one or more deviation criteria is at least in part based on resting heart rate data, mean HRV score data, recovery measurement data, or any combination thereof.

[0315] In some examples, classifier component 1430 may be configured or otherwise supported as means for identifying a decrease in resting heart rate data between a first time interval and a second time interval, a decrease in HRV mean fraction data between the first time interval and the second time interval, an increase in recovery metric data between the first time interval and the second time interval, or any combination thereof, wherein identification of one or more deviation criteria is based at least in part on the decrease in resting heart rate data, the decrease in HRV mean fraction data, the increase in recovery metric data, or any combination thereof.

[0316] In some examples, the data acquisition component 1425 may be configured or otherwise supported to provide means for receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval. In some examples, the classifier component 1430 may be configured or otherwise supported to provide means for inputting physiological data into a classifier. In some examples, the classifier component 1430 may be configured or otherwise supported to provide means for classifying physiological data collected during the first and second time intervals into a plurality of sleep intervals during the first and second time intervals, each of the plurality of sleep intervals being associated with one of a waking sleep stage, a light sleep stage, a REM sleep stage, or a deep sleep stage, wherein identification of satisfaction of one or more bias criteria is based at least in part on the classification of the physiological data.

[0317] In some examples, classifier component 1430 may be configured or otherwise supported as means for identifying a first variation in the duration of a first sleep stage associated with the REM sleep stage between the first time interval and the second time interval, a second variation in the duration of a second sleep stage associated with the deep sleep stage between the first time interval and the second time interval, wherein the identification of satisfying one or more deviation criteria is based at least in part on the first variation, the second variation, or both.

[0318] In some examples, user input component 1450 may be configured or otherwise supported for receiving user input via a user device in response to causing the GUI to display a disease risk metric. In some examples, classifier component 1430 may be configured or otherwise supported for training a classifier using user input. In some examples, user input indicates a positive disease test, the onset of disease symptoms, or both.

[0319] In some examples, the wearable device includes a wearable ring device. In some examples, the wearable device uses arterial blood flow-based HRV data to collect data from the user. In some examples, the user device includes a user device associated with the user, a user device associated with an administrator and a user group including the user, or both.

[0320] In some examples, HRV data is associated with multiple users including the user, and the classifier component 1430 may be configured or otherwise supported to enable means for identifying a disease risk measure associated with each of the multiple users, at least in part, based on the HRV data of each respective user. In some examples, HRV data is associated with multiple users including the user, and the user interface component 1435 may be configured or otherwise supported to enable the GUI of the administrator user device to display at least one disease risk measure associated with at least one of the multiple users.

[0321] FIG. 2A diagram of a system 1500 including a device 1505 supporting disease detection technology according to various aspects of this disclosure is shown. Device 1505 may be an example of a device 1505 as described herein or a component including a device 1505 as described herein. In some implementations, device 1505 may include an example of a user device 106 described herein. Device 1505 may include components for bidirectional communication with wearable devices (e.g., ring 104) and 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 communicate electronically or be otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., bus 1545).

[0322] The communication module 1510 can manage the input and output signals of the device 1505 via the antenna 1515. The communication module 1510 may include... FIG. 2 An example of the communication module 220-b of the user equipment 106 shown and described herein. In this respect, the communication module 1510 can manage communication with the ring 104 and the server 110, such as... FIG. 16 As shown. Communication module 1510 can also manage peripheral devices not integrated into device 1505. In some cases, communication module 1510 can represent a physical connection or port to an external peripheral device. In some cases, communication module 1510 can utilize an operating system, such as Alternatively, it may be another known operating system. In other cases, the communication module 1510 may represent or interact with a wearable device (e.g., ring 104), modem, keyboard, mouse, touchscreen, or similar device. In some cases, the communication module 1510 may be implemented as part of the processor 1540. In some examples, a user can interact with the device 1505 via the communication module 1510, the user interface component 1525, or via hardware components controlled by the communication module 1510.

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

[0324] User interface component 1525 can manage data storage and processing in database 1530. In some cases, users can interact with user interface component 1525. In other cases, user interface component 1525 can operate automatically without user interaction. Database 1530 can be an example of a single database, a distributed database, multiple distributed databases, a data repository, a data lake, or an emergency backup database.

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

[0326] Processor 1540 may include intelligent hardware devices (e.g., general-purpose processors, digital signal processors (DSPs), central processing units (CPUs), microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, processor 1540 may be configured to use a memory controller to operate a memory array. In other cases, the memory controller may be integrated into processor 1540. Processor 1540 may be configured to execute computer-readable instructions stored in memory 1535 to perform various functions (e.g., functions or tasks supporting methods and systems for sleep staged algorithms).

[0327] Based on the examples disclosed herein, wearable application 1520 can support automatic disease detection. For example, wearable application 1520 can be configured or otherwise supported to support means for receiving user-associated HRV data from a wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval. Wearable application 1520 can be configured or otherwise supported to support means for inputting HRV data into a classifier. Wearable application 1520 can be configured or otherwise supported to use a classifier to identify whether a first subset of HRV data collected during the first time interval and a second subset of HRV data collected during the second time interval satisfy one or more deviation criteria. Wearable application 1520 can be configured or otherwise supported to enable a user device's GUI to display, at least in part, a disease risk measure associated with the user and related to the relative probability of the user transitioning from a healthy state to an unhealthy state, based on satisfying one or more deviation criteria.

[0328] By including or configuring a wearable application 1520 according to the examples described herein, device 1505 can support techniques for improved disease detection / prediction. Specifically, the techniques described herein can enable disease detection in the pre-symptom stage based on neurologically relevant characteristics / parameters that can be obtained via wearable device 104. Accordingly, by enabling disease detection in the pre-symptom stage, the techniques described herein can reduce the spread of disease and decrease its severity.

[0329] FIG. 1 to FIG. 15 A flowchart illustrating a method 1600 supporting disease detection technology is shown according to various aspects of this disclosure. Operation of method 1600 may be implemented by user equipment 106 or components thereof as described herein. For example, operation of method 1600 may be as described in reference... FIG. 14 The described functions are executed by user equipment 106. In some examples, user equipment 106 may execute a set of instructions to control the functional elements of user equipment 106 to perform the described functions. Additionally or alternatively, user equipment 106 may use dedicated hardware to perform aspects of the described functions.

[0330] At 1605, the method may include receiving HRV data associated with a user from a wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval. Operation 1605 may be performed according to the examples disclosed herein. In some examples, aspects of operation 1605 may be derived from, as referenced... FIG. 14 The described data acquisition component 1425 is executed.

[0331] At 1610, the method may include inputting HRV data into a classifier. Operation 1610 may be performed according to examples disclosed herein. In some examples, it may be performed by, as referenced... FIG. 14 The classifier component 1430 described herein performs various aspects of operation 1610.

[0332] At 1615, the method may include using a classifier to identify one or more deviation criteria that satisfy a first subset of HRV data collected during a first time interval and a second subset of HRV data collected during a second time interval. Operation 1615 may be performed according to examples disclosed herein. In some examples, it may be performed by, as referenced... FIG. 14 The classifier component 1430 described herein performs various aspects of operation 1615.

[0333] At 1620, the method may include causing the user device's GUI to display a disease risk measure associated with the user, at least in part, based on satisfying one or more deviation criteria, the disease risk measure being related to the relative probability that the user will transition from a healthy state to an unhealthy state. Operation 1620 may be performed according to the examples disclosed herein. In some examples, such as those referenced... FIG. 17 As described, the various aspects of operation 1620 can be performed by user interface component 1435.

[0334] FIG. 1 to FIG. 15 A flowchart illustrating a method 1700 supporting disease detection technology according to various aspects of this disclosure is shown. Operation of method 1700 may be implemented by user equipment 106 or components thereof as described herein. For example, operation of method 1700 may be as described in reference... FIG. 14 The described functions are executed by user equipment 106. In some examples, user equipment 106 may execute a set of instructions to control the functional elements of user equipment 106 to perform the described functions. Additionally or alternatively, user equipment 106 may use dedicated hardware to perform aspects of the described functions.

[0335] At 1705, the method may include receiving HRV data associated with a user from a wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval. Operation 1705 may be performed according to examples as disclosed herein. In some examples, aspects of operation 1705 may be as described in references... FIG. 14 The data acquisition component 1425 described is used for execution.

[0336] At 1710, the method may include inputting HRV data into a classifier. Operation 1710 can be performed according to examples disclosed herein. In some examples, it can be performed as described in the references... FIG. 14The classifier component 1430 described herein performs various aspects of operation 1710.

[0337] At 1715, the method may include determining the frequency content of HRV data within at least a portion of a first time interval and at least a portion of a second time interval. Operation 1715 may be performed according to examples disclosed herein. In some examples, it may be performed by, as referenced... FIG. 14 The classifier component 1430 described herein performs various aspects of operation 1715.

[0338] At 1720, the method may include using a classifier to identify whether one or more deviation criteria are satisfied between a first subset of HRV data collected in a first time interval and a second subset of HRV data collected in a second time interval, wherein the identification of satisfying the one or more deviation criteria is based at least in part on frequency content. Operation 1720 may be performed according to examples as disclosed herein. In some examples, it may be performed by, as referenced... FIG. 14 The classifier component 1430 described herein performs various aspects of operation 1720.

[0339] At 1725, the method may include causing the user device's GUI to display a disease risk measure associated with the user, at least in part, based on satisfying one or more deviation criteria, the disease risk measure being related to the relative probability that the user will transition from a healthy state to an unhealthy state. Operation 1725 may be performed according to examples as disclosed herein. In some examples, aspects of operation 1725 may be derived from references... FIG. 18 The user interface component 1435 described herein is used for execution.

[0340] FIG. 1 to FIG. 15 A flowchart illustrating a method 1800 supporting disease detection technology according to various aspects of this disclosure is shown. Operation of method 1800 may be implemented by user equipment 106 or components thereof as described herein. For example, operation of method 1800 may be as described in reference... FIG. 14 The described functions are executed by user equipment 106. In some examples, user equipment 106 may execute a set of instructions to control the functional elements of user equipment 106 to perform the described functions. Additionally or alternatively, user equipment 106 may use dedicated hardware to perform aspects of the described functions.

[0341] At 1805, the method may include receiving HRV data associated with a user from a wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval. Operation 1805 may be performed according to the examples disclosed herein. In some examples, aspects of operation 1805 may be derived from, as referenced... FIG. 14 The described data acquisition component 1425 is used to perform this task.

[0342] At 1810, the method may include identifying at least a first portion of a first time interval and a second portion of a second time interval based at least in part on a circadian rhythm associated with the user. Operation 1810 may be performed according to examples as disclosed herein. In some examples, aspects of operation 1810 may be derived from, as referenced... FIG. 14 The described circadian rhythm component 1445 is used to perform this.

[0343] At 1815, the method may include identifying a first portion of HRV data corresponding to a first portion of a first time interval and a second portion of HRV data corresponding to a second portion of a second time interval. Operation 1815 may be performed according to examples disclosed herein. In some examples, aspects of operation 1815 may be derived from, as referenced... FIG. 14 The described circadian rhythm component 1445 is used to perform this.

[0344] At 1820, the method may include inputting HRV data into a classifier, wherein inputting HRV data into the classifier includes a first portion of inputting HRV data and a second portion of inputting HRV data. Operation 1820 may be performed according to examples as disclosed herein. In some examples, it may be performed by, as referenced... FIG. 14 The classifier component 1430 described herein performs various aspects of operation 1820.

[0345] At 1825, the method may include using a classifier to identify one or more deviation criteria that satisfy a first subset of HRV data collected during a first time interval and a second subset of HRV data collected during a second time interval. Operation 1825 can be performed according to examples as disclosed herein. In some examples, aspects of operation 1825 may be derived from references... FIG. 14 The described classifier component 1430 is used to perform this.

[0346] At 1830, the method may include causing the user device's GUI to display a disease risk measure associated with the user, at least in part, based on satisfying one or more deviation criteria, the disease risk measure being related to the relative probability that the user will transition from a healthy state to an unhealthy state. Operation 1830 may be performed according to examples as disclosed herein. In some examples, aspects of operation 1830 may be derived from references... ​ The user interface component 1435 described herein is used for execution.

[0347] It should be noted that the methods described above describe possible implementations, and these operations and steps can be rearranged or otherwise modified, and other implementations are possible. Furthermore, two or more aspects from these methods can be combined.

[0348] A method for automatically detecting diseases is described. The method may include: receiving user-associated HRV data from a wearable device, the HRV data being collected via the wearable device over a first time interval and a second time interval following the first time interval; inputting the HRV data into a classifier; using the classifier to identify whether a first subset of the HRV data collected during the first time interval and a second subset of the HRV data collected during the second time interval satisfy one or more deviation criteria; and causing a GUI of the user device to display a disease risk measure associated with the user, at least in part, based on the satisfaction of one or more deviation criteria, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0349] An apparatus for automatically detecting diseases is described. The apparatus may include a processor, memory coupled to the processor, and instructions stored in the memory. These instructions can be executed by the processor to cause the apparatus to: receive user-associated HRV data from a wearable device, the HRV data being collected via the wearable device over a first time interval and a second time interval following the first time interval; input the HRV data into a classifier; use the classifier to identify whether a first subset of the HRV data collected in the first time interval and a second subset of the HRV data collected in the second time interval satisfy one or more deviation criteria; and cause a GUI of a user device to display a user-associated disease risk measure based at least in part on satisfying one or more deviation criteria, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0350] Another apparatus for automatically detecting diseases is described. The apparatus may include: means for receiving HRV data associated with a user from a wearable device, the HRV data being collected via the wearable device during a first time interval and a second time interval following the first time interval; means for inputting the HRV data into a classifier; means for using the classifier to identify whether a first subset of the HRV data collected during the first time interval and a second subset of the HRV data collected during the second time interval satisfy one or more deviation criteria; and means for causing a GUI of the user device to display a disease risk measure associated with the user, at least in part, based on satisfying one or more deviation criteria, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0351] A non-transitory computer-readable medium is described, storing code for automated disease detection. The code may include instructions executable by a processor to: receive user-associated HRV data from a wearable device, the HRV data being collected via the wearable device over a first time interval and a second time interval thereafter; input the HRV data into a classifier; use the classifier to identify whether one or more deviation criteria are met between a first subset of the HRV data collected in the first time interval and a second subset of the HRV data collected in the second time interval; and cause a GUI of a user device to display a user-associated disease risk measure, at least in part, based on the satisfaction of one or more deviation criteria, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

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

[0353] In some examples of the methods, apparatuses, and nontransitory computer-readable media described herein, determining the frequency content of HRV data may include operations, features, means, or instructions for determining the low-frequency content and the high-frequency content of HRV data, wherein identification of satisfying one or more deviation criteria may be based at least in part on the low-frequency content, the high-frequency content, or both.

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

[0355] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for performing the following steps: receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval; identifying multiple sleep stages associated with the user based at least in part on the physiological data; and identifying a first portion of HRV data corresponding to a first sleep stage among the multiple sleep stages during the first time interval and a second portion of HRV data corresponding to a second sleep stage among the multiple sleep stages during the second time interval, the first and second sleep stages comprising the same type of sleep stage; wherein inputting HRV data into a classifier includes inputting the first portion of HRV data and the second portion of HRV data.

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

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

[0358] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for performing the following steps: receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval; identifying resting heart rate data, mean HRV score data, recovery measurement data, or any combination thereof based at least in part on the physiological data; and inputting the resting heart rate data, mean HRV score data, recovery measurement data, or any combination thereof into a classifier, wherein identification satisfying one or more deviation criteria may be based at least in part on the resting heart rate data, mean HRV score data, recovery measurement data, or any combination thereof.

[0359] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for identifying a decrease in resting heart rate data between a first time interval and a second time interval, a decrease in HRV mean fraction data between the first time interval and the second time interval, an increase in recovery measurement data between the first time interval and the second time interval, or any combination thereof, wherein identification of satisfying one or more deviation criteria may be based at least in part on a decrease in resting heart rate data, a decrease in HRV mean fraction data, an increase in recovery measurement data, or any combination thereof.

[0360] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for performing the following steps: receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval; inputting the physiological data into a classifier; and classifying the physiological data collected during the first time interval and the second time interval into a plurality of sleep intervals during the first time interval and the second time interval, each of the plurality of sleep intervals being associated with one of a waking sleep stage, a light sleep stage, a REM sleep stage, or a deep sleep stage, wherein identification of meeting one or more bias criteria may be based at least in part on the classification of the physiological data.

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

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

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

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

[0365] In some examples of the methods, apparatuses and non-transitory computer-readable media described herein, wearable devices include wearable ring devices.

[0366] In some examples of the methods, apparatuses and non-transitory computer-readable media described herein, wearable devices use arterial blood flow-based methods to collect HRV data from a user.

[0367] In some examples of the methods, apparatuses and nontransitory computer-readable media described herein, user equipment includes user equipment associated with a user, user equipment associated with an administrator and a user group including the user, or both.

[0368] In some examples of the methods, apparatuses, and nontransitory computer-readable media described herein, HRV data may be associated with multiple users, including the user, and the methods, apparatuses, and nontransitory computer-readable media may further include operations, features, means, or instructions for performing the following steps: using a classifier to identify a disease risk measure associated with each corresponding user based at least in part on the HRV data of each of the multiple users; and causing the GUI of the administrator user device to display at least one disease risk measure associated with at least one of the multiple users.

[0369] A method for automatically detecting diseases 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 within a first time interval; identifying baseline temperature data associated with the user based at least in part on the temperature data collected within 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 within a second time interval following the first time interval; inputting the baseline temperature data and the additional temperature data into a classifier; using the classifier to identify whether the baseline temperature data and the additional temperature data meet one or more deviation criteria; and causing a GUI of the user device to display a disease risk measure associated with the user based at least in part on meeting one or more deviation criteria, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0370] An apparatus for automatically detecting diseases is described. The apparatus may include a processor, memory coupled to the processor, and instructions stored in the memory. These instructions can be executed by the processor to cause the apparatus to: receive user-associated temperature data from a wearable device, the temperature data being collected via the wearable device during a first time interval; identify user-associated baseline temperature data based at least in part on the temperature data collected during the first time interval; receive user-associated additional temperature data from the wearable device, the additional temperature data being collected via the wearable device during a second time interval following the first time interval; input the baseline temperature data and the additional temperature data into a classifier; use the classifier to identify whether the baseline temperature data and the additional temperature data meet one or more deviation criteria; and, based at least in part on meeting one or more deviation criteria, cause a GUI on a user device to display a disease risk measure associated with the user, the disease risk measure being correlated with the relative probability of the user transitioning from a healthy state to an unhealthy state.

[0371] Another apparatus for automatically detecting diseases is described. The apparatus may include: means for receiving temperature data associated with a user from a wearable device, the temperature data being collected via the wearable device during a first time interval; means for identifying baseline temperature data associated with the user based at least in part on the temperature data collected during the first time interval; means for receiving additional temperature data associated with the user from the wearable device, the additional temperature data being collected via the wearable device during a second time interval following the first time interval; means for inputting the baseline temperature data and the additional temperature data into a classifier; means for using the classifier to identify whether the baseline temperature data and the additional temperature data meet one or more deviation criteria; and means for causing a user device's GUI to display a disease risk measure associated with the user based at least in part on meeting one or more deviation criteria, the disease risk measure being associated with the relative probability that the user will transition from a healthy state to an unhealthy state.

[0372] A non-transitory computer-readable medium is described, storing code for the automated detection of diseases. The code may include instructions executable by a processor to: receive user-associated temperature data from a wearable device, collected via the wearable device during a first time interval; identify user-associated baseline temperature data based at least in part on the temperature data collected during the first time interval; receive user-associated additional temperature data from the wearable device, collected via the wearable device during a second time interval following the first time interval; input the baseline and additional temperature data into a classifier; use the classifier to identify whether the baseline and additional temperature data meet one or more deviation criteria; and cause a GUI on a user device to display a disease risk measure associated with the user, which is related to the relative probability of the user transitioning from a healthy to an unhealthy state, based at least in part on the satisfaction of one or more deviation criteria.

[0373] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, apparatuses, or instructions for performing the following steps: identifying baseline frequency content of baseline temperature data associated with a user, identifying additional frequency content of additional temperature data, and inputting the baseline frequency content and additional frequency content into a classifier, wherein identification of one or more deviation criteria may be based at least in part on the baseline frequency content and additional frequency content.

[0374] Some examples of the methods, apparatuses, 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 baseline temperature data of at least the first day in a first time interval and a second high daytime temperature range within additional temperature data of at least the second day in a second time interval, wherein the first and second high daytime temperature ranges may be greater than or equal to percentile thresholds of temperature readings collected from the user on the first and second days, respectively, wherein identification satisfying 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.

[0375] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, identifying that one or more deviation criteria are met may include operations, features, devices, or instructions for identifying that the change between a first high daytime temperature range and a second high daytime temperature range exceeds a temperature change threshold.

[0376] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a first low daytime temperature range within baseline temperature data of at least the first day in a first time interval and a second low daytime temperature range within additional temperature data of at least the second day in a second time interval, wherein the first and second low daytime temperature ranges may be less than or equal to percentile thresholds of temperature readings collected from the user on the first and second days, respectively, wherein identification of one or more deviation criteria may be based at least in part on the first low daytime temperature range, the second low daytime temperature range, or both.

[0377] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, identifying that one or more deviation criteria are met may include operations, features, devices, or instructions for identifying that the change between a first low daytime temperature range and a second low daytime temperature range exceeds a temperature change threshold.

[0378] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a first subset of baseline temperature data and a second subset of additional temperature data, the first subset being collected by the wearable device during daytime intervals within a first time interval, and the second subset being collected by the wearable device during daytime intervals within a second time interval, wherein inputting temperature data into a classifier includes inputting the first subset of baseline temperature data and the second subset of additional temperature data into the classifier.

[0379] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for identifying daytime intervals 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.

[0380] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying user-associated location information within at least a portion of a first time interval and at least a portion of a second time interval and inputting such location information into the classifier, wherein the classifier may be configured to identify, at least in part, those satisfying one or more deviation criteria based on the location information.

[0381] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for identifying ambient temperature data associated with a user's geographic location, at least in part, based on location information, and for inputting the ambient temperature data into a classifier, wherein identification satisfying one or more deviation criteria may be based at least in part on the ambient temperature data.

[0382] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for identifying climate data, time of year, or both, wherein the identification of ambient temperature data may be based at least in part on climate data, time of year, or both.

[0383] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, identifying location information may include operations, features, means, or instructions for receiving indications of location information from a user equipment.

[0384] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, location information includes the user's geographic location, the user's latitude, or both.

[0385] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for using a classifier to identify one or more prediction weights associated with additional temperature data, at least in part, based on location information, which are related to relative predictive accuracy for detecting a disease, wherein identification of satisfying one or more deviation criteria may be based at least in part on one or more prediction weights.

[0386] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, apparatuses, or instructions for performing the following steps: weighting additional temperature data using a classifier based at least in part on one or more prediction weights to generate weighted temperature data; receiving additional physiological data associated with a user from a wearable device, the additional physiological data being collected via the wearable device during a first time interval and a second time interval; and inputting the additional physiological data into a classifier, wherein identification of satisfying one or more bias criteria may be based at least in part on the weighted temperature data, the additional physiological data, or a combination thereof.

[0387] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, receiving temperature data within a first time interval may include operations, features, means, or instructions for receiving multiple temperature readings associated with a user based on the periodicity of temperature collection for each day of the first time interval over a multi-day period.

[0388] In some examples of the methods, apparatuses and non-transitory computer-readable media described herein, wearable devices include wearable ring devices.

[0389] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, wearable devices collect physiological data from users based on arterial blood flow.

[0390] In some examples of the methods, apparatuses and nontransitory computer-readable media described herein, user equipment includes user equipment associated with a user, user equipment associated with an administrator and a user group including the user, or both.

[0391] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, temperature data and additional temperature data may be associated with multiple users, including the user, and the methods, apparatuses, and non-transitory computer-readable media may further include operations, features, means, or instructions for performing the following steps: identifying baseline temperature data associated with each of the multiple users, at least in part based on the received temperature data; inputting the baseline temperature data of each of the multiple users into a classifier; using the classifier to identify a disease risk measure associated with each of the multiple users, at least in part based on the baseline temperature data of each corresponding user; and causing the GUI of the administrator user device to display at least one disease risk measure associated with at least one of the multiple users.

[0392] A method for automatically detecting diseases is described. The method may include: receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval thereafter; identifying user-associated physical activity data, sleep data, or both, within at least a portion of the first time interval and at least a portion of the second time interval, based at least partially on the received physiological data; inputting the physical activity data, sleep data, or both into a classifier; using the classifier to identify a first subset of the physical activity data, a first subset of the sleep data, or both collected during the first time interval, satisfying one or more deviation criteria with a corresponding second subset of the physical activity data, a corresponding second subset of the sleep data, or both collected during the second time interval; and causing a GUI of the user device to display a user-associated disease risk measure, at least partially based on satisfying one or more deviation criteria, the disease risk measure being associated with the probability that the user will transition from a healthy state to an unhealthy state.

[0393] An apparatus for automatically detecting diseases is described. The apparatus may include a processor, memory coupled to the processor, and instructions stored in the memory. These instructions can be executed by the processor to cause the apparatus to: receive user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval thereafter; identify user-associated physical activity data, sleep data, or both, within at least a portion of the first time interval and at least a portion of the second time interval, based at least partially on the received physiological data; input the physical activity data, sleep data, or both into a classifier; use the classifier to identify a first subset of physical activity data, a first subset of sleep data, or both collected during the first time interval, satisfying one or more deviation criteria with a corresponding second subset of physical activity data, a corresponding second subset of sleep data, or both collected during the second time interval; and cause a GUI of a user device to display a user-associated disease risk measure, at least partially based on satisfying one or more deviation criteria, the disease risk measure being associated with the probability that the user will transition from a healthy state to an unhealthy state.

[0394] Another apparatus for automatically detecting diseases is described. These apparatuses may include: means for receiving user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval thereafter; means for identifying user-associated physical activity data, sleep data, or both, within at least a portion of the first time interval and at least a portion of the second time interval, based at least partially on the received physiological data; means for inputting the physical activity data, sleep data, or both into a classifier; means for using the classifier to identify a first subset of physical activity data, a first subset of sleep data, or both collected during the first time interval, and a corresponding second subset of physical activity data, a corresponding second subset of sleep data, or both collected during the second time interval, satisfying one or more deviation criteria; and means for causing a user device's GUI to display a user-associated disease risk measure based at least partially on satisfying one or more deviation criteria, the disease risk measure being associated with the probability that the user will transition from a healthy state to an unhealthy state.

[0395] A non-transitory computer-readable medium is described, storing code for the automated detection of diseases. The code may include instructions executable by a processor to: receive user-associated physiological data from a wearable device, the physiological data being collected via the wearable device during a first time interval and a second time interval thereafter; identify user-associated physical activity data, sleep data, or both, within at least a portion of the first time interval and at least a portion of the second time interval, based at least in part on the received physiological data; input the physical activity data, sleep data, or both into a classifier; use the classifier to identify a first subset of the physical activity data, a first subset of the sleep data, or both collected during the first time interval, satisfying one or more deviation criteria with a corresponding second subset of the physical activity data, a corresponding second subset of the sleep data, or both collected during the second time interval; and cause a GUI of a user device to display a user-associated disease risk measure, at least in part, based on the satisfaction of one or more deviation criteria, the disease risk measure being associated with the probability that the user will transition from a healthy state to an unhealthy state.

[0396] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for identifying a reduction in physical activity associated with the user between the first and second time intervals based at least in part on physical activity data associated with the user between the first and second time intervals, a reduction in energy expenditure, or both, wherein identification of satisfying one or more deviation criteria may be based at least in part on a reduction in physical activity, a reduction in energy expenditure, or both.

[0397] S...

Claims

1. A system for automatically detecting illness, comprising: a wearable device configured to measure physiological data from a user, the physiological data including heart rate variability data measured from the user over a first time interval and a second time interval after the first time interval; a user device communicatively coupled with the wearable device; and a processor configured to: receive, from the wearable device, the heart rate variability data associated with the user, wherein the heart rate variability data is measured via one or more light-based sensors of the wearable device that interface with tissue of the user; input the heart rate variability data into a machine learning classifier, wherein the machine learning classifier is configured to extract a set of features from the heart rate variability data; identify, with the machine learning classifier, consecutive root mean square successive differences (RMSSD) data and resting heart rate data associated with the user based at least in part on the heart rate variability data; identify, using the machine learning classifier, satisfaction of one or more deviation criteria between a first subset of the set of features associated with the first time interval and a second subset of the set of features associated with the second time interval, wherein the machine learning classifier is configured to identify the satisfaction of the one or more deviation criteria based at least in part on the RMSSD data; and cause a graphical user interface of the user device to display, based at least in part on the satisfaction of the one or more deviation criteria, an illness risk measure associated with the user, the illness risk measure associated with a probability that the user will transition from a healthy state to an unhealthy state due to a viral or bacterial infection. the processor is further configured to:

2. The system of claim 1, wherein, determine, using the machine learning classifier, a frequency content of the heart rate variability data over at least a portion of the first time interval and at least a portion of the second time interval, wherein the set of features includes the frequency content, and wherein identifying the satisfaction of the one or more deviation criteria is based at least in part on the frequency content. to determine the frequency content of the heart rate variability data, the processor is further configured to:

3. The system of claim 2, wherein, determine, using the machine learning classifier, a low frequency content of the heart rate variability data; and determine, using the machine learning classifier, a high frequency content of the heart rate variability data, wherein the set of features includes the low frequency content and the high frequency content, and wherein identifying the satisfaction of the one or more deviation criteria is based at least in part on the low frequency content, the high frequency content, or both. the processor is further configured to: identify, using the machine learning classifier, a divergence between the low frequency content of the heart rate variability data and the high frequency content of the heart rate variability data, wherein identifying the satisfaction of the one or more deviation criteria is based at least in part on identifying the divergence.

4. The system of claim 3, wherein, the processor is further configured to: ​ 5. The system of claim 1, wherein, ​ receiving, from the wearable device, physiological data associated with the user, the physiological data collected via the wearable device over the first time interval and the second time interval; identifying, based at least in part on the physiological data, a plurality of sleep stages associated with the user; and using the machine learning classifier to identify a first portion of the heart rate variability data corresponding to a first sleep stage of the plurality of sleep stages within the first time interval and a second portion of the heart rate variability data corresponding to a second sleep stage of the plurality of sleep stages within the second time interval, the first sleep stage and the second sleep stage comprising a same type of sleep stage, wherein the machine learning classifier is configured to identify the satisfaction of the one or more deviation criteria based on a comparison of the first portion of the heart rate variability data and the second portion of the heart rate variability data.

6. The system of claim 1, wherein, the processor is further configured to: identify, based at least in part on a circadian rhythm associated with the user, at least a first portion of the first time interval and a second portion of the second time interval; and identify a first portion of the heart rate variability data corresponding to the first portion of the first time interval and a second portion of the heart rate variability data corresponding to the second portion of the second time interval, wherein inputting the heart rate variability data into the machine learning classifier comprises inputting the first portion of the heart rate variability data and the second portion of the heart rate variability data.

7. The system of claim 1, wherein: the disease risk metric is associated with a probability that the user is experiencing a viral infection, and wherein the set of features extracted by the machine learning classifier is associated with an immune response of the user within a pre-symptomatic period of the viral infection, and wherein the graphical user interface is caused to display the disease risk metric within the pre-symptomatic period before the user exhibits symptoms of the viral infection.

8. The system of claim 1, wherein: the set of features extracted by the machine learning classifier includes a rhythmic pattern of heart rate variability data based at least in part on a circadian rhythm of the user over the entire first time interval, and the machine learning classifier is further configured to identify the satisfaction of the one or more deviation criteria based at least in part on the rhythmic pattern and the circadian rhythm.

9. The system of claim 8, wherein, the processor is further configured to: identify, using the machine learning classifier, the satisfaction of the one or more deviation criteria based at least on heart rate variability data within a time interval immediately following a sleep time of the user and / or heart rate variability data within a time interval immediately preceding a wake time of the user.

10. The system of claim 1, wherein, the processor is further configured to: receive, from the wearable device, physiological data associated with the user, the physiological data collected via the wearable device over the first time interval and the second time interval; inputting the physiological data into the machine learning classifier; and classifying the physiological data collected over 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, each sleep interval of the plurality of sleep intervals being associated with one of a wake sleep stage, a light sleep stage, a rapid eye movement sleep stage, or a deep sleep stage, wherein identifying the satisfaction of the one or more deviation criteria is based at least in part on classifying the physiological data.

11. The system of claim 10, wherein, the processor is further configured to: identify, using the machine learning classifier, a first change in a first sleep stage duration associated with the rapid eye movement sleep stage between the first time interval and the second time interval, a second change in a second sleep stage duration associated with the deep sleep stage between the first time interval and the second time interval, or both, wherein identifying the satisfaction of the one or more deviation criteria is based at least in part on the first change, the second change, or both.

12. The system of claim 1, wherein, the processor is further configured to: receive, via the user device and in response to causing the graphical user interface to display the disease risk metric, a user input; and train the machine learning classifier to predict a disease based at least in part on the user input.

13. The system of claim 12, wherein the user input indicates a positive disease test, an onset of a symptom of a disease, or both.

14. The system of claim 1, wherein, the processor is further configured to: identify, based at least in part on the heart rate variability data, respiration rate data associated with the user; and input the respiration rate data into the machine learning classifier, wherein identifying the satisfaction of the one or more deviation criteria is based at least in part on the respiration rate data.

15. The system of claim 1, wherein the wearable device comprises a wearable ring device.

16. The system of claim 1, wherein the wearable device collects the heart rate variability data from the user based on arterial blood flow.

17. The system of claim 1, wherein, the processor is further configured to: determine demographic disease data associated with a group of users within a geographic location, the geographic location being associated with the user, wherein the demographic disease data is associated with a probability of a disease within the group of users; and input the demographic disease data into the machine learning classifier, wherein the machine learning classifier is configured to identify the satisfaction of the one or more deviation criteria based at least in part on the demographic disease data.

18. The system of claim 1, wherein the heart rate variability data is associated with a plurality of users including the user, the heart rate variability data being collected via a plurality of wearable devices associated with the plurality of users, the processor is further configured to: identify, using the machine learning classifier, a respective disease risk metric associated with each user of the plurality of users based at least in part on the heart rate variability data of each user of the plurality of users; and 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.

19. An apparatus for automatically detecting a disease, comprising: a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to: receive heart rate variability data associated with a user from a wearable device, wherein the heart rate variability data is measured by one or more light-based sensors of the wearable device that interface with tissue of the user, and wherein the heart rate variability data is collected via the wearable device over a first time interval and a second time interval after the first time interval; input the heart rate variability data into a machine learning classifier, wherein the machine learning classifier is configured to extract a set of features from the heart rate variability data; identify, with the machine learning classifier, continuous root mean square successive difference (RMSSD) data and resting heart rate data associated with the user based at least in part on the heart rate variability data; identify, using the machine learning classifier, that one or more deviation criteria are satisfied between a first subset of the set of features associated with the first time interval and a second subset of the set of features associated with the second time interval, wherein the machine learning classifier is configured to identify the satisfaction of the one or more deviation criteria based at least in part on the RMSSD data; and cause a graphical user interface of a user device to display a disease risk metric associated with the user based at least in part on the satisfaction of the one or more deviation criteria, the disease risk metric associated with a probability that the user will transition from a healthy state to a non-healthy state due to a viral or bacterial infection.

20. The apparatus of claim 19, wherein the instructions are further executable by the processor to cause the apparatus to: determine a frequency content of the heart rate variability data over at least a portion of the first time interval and over at least a portion of the second time interval, wherein identifying that the one or more deviation criteria are satisfied is based at least in part on the frequency content.

Images