Detect user temperature and assess physiological symptoms of respiratory conditions

Abstract

Temperature data obtained from a wearable device, for example at the user's wrist or within the device itself, can be used as a proxy for assessing changes in core body temperature. Sensor data can be provided to determine the user's skin temperature as well as the internal device temperature. The correlation between these two temperatures can be used to monitor subsequent temperature changes, which can indicate changes in the user's core body temperature. The temperature change of the proxy temperature can be evaluated against a threshold to determine whether the user's core body temperature has also increased, which can indicate one or more physiological symptoms or events. In addition, additional physiological variables such as respiratory rate, nocturnal heart rate, and heart rate variability can be analyzed for early signs of impending illness. A trained machine learning classifier can output a predicted disease state for an individual based on these parameters.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 065,254, filed on August 13, 2020, which is incorporated herein by reference in its entirety. Background Art

[0003] Wearable electronic devices have become popular among consumers. Wearable electronic devices can use various sensors to track the user's activities or biometric data. The data captured from these sensors can be analyzed to provide information to the user, such as an estimate of how far they have walked in a day, their heart rate, how much time they have spent sleeping, etc. However, there are technical problems associated with the ability to collect enough data to provide users with an overall picture of their current or expected future health. In particular, traditional devices are limited in being able to detect parameters that accurately and automatically detect a user's temperature (as well as various other body parameters) for use in assessing physiological symptoms associated with respiratory disorders and / or other medical conditions. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0005] Figure 1 An example of a user with a wearable device on a limb according to various embodiments of the present disclosure is illustrated.

[0006] Figure 2 An example of a user interacting with a wearable device on a limb according to an embodiment of the present disclosure is illustrated.

[0007] Figure 3 Illustrated is an example set of devices capable of communicating according to an embodiment of the present disclosure.

[0008] Figures 4A to 4D is a graphical representation of a temperature response according to an embodiment of the present disclosure.

[0009] Figure 5 is a graphical representation of a temperature response according to an embodiment of the present disclosure.

[0010] Figure 6 is a flow chart of an embodiment of a data processing system according to an embodiment of the present disclosure.

[0011] Figure 7 is a graphical representation of a temperature comparison according to an embodiment of the present disclosure.

[0012] Figure 8 is a flow chart of an embodiment of a method for determining a temperature change of an agent temperature according to an embodiment of the present disclosure.

[0013] Figure 9 is a framework for assessing the presence of disease according to an embodiment of the present disclosure.

[0014] Figure 10 is a visual representation of a series of input images representing user symptoms according to an embodiment of the present disclosure.

[0015] Figure 11 is a graphical representation of a disease predictor according to an embodiment of the present disclosure.

[0016] Figure 12 is a flowchart of an embodiment of a method for predicting a disease according to an embodiment of the present disclosure.

[0017] 13A to 13D is a graphical representation of calculated Z-scores for different data components according to an embodiment of the present disclosure.

[0018] Figure 14 Illustrated is a set of basic computer components of one or more devices of the present disclosure according to various embodiments of the present disclosure. Summary of the Invention

[0019] Aspects and advantages of the invention will be set forth in part in the following description, or may be obvious from the description, or may be learned through practice of the invention.

[0020] In one aspect, the present disclosure relates to a method for assessing the presence or likelihood of developing a medical condition in a user of a wearable computing device. The method includes receiving, from a first sensor on the wearable computing device, first temperature data associated with a first temperature measurement of the user. The method also includes receiving, from a second sensor on the wearable computing device, second temperature data associated with a second temperature measurement of the user, the second sensor being located at a different location than the first sensor. Furthermore, the method includes determining a proxy temperature based, at least in part, on the first temperature data and the second temperature data. Furthermore, the method includes determining a temperature change based, at least in part, on the proxy temperature. Furthermore, the method includes comparing the temperature change to a temperature threshold. Furthermore, the method includes determining, via the wearable computing device, a preliminary assessment of the user's medical condition based on the temperature change. Accordingly, the method includes generating and displaying, via a display of the wearable computing device, a recommendation to the user based on the preliminary assessment.

[0021] In one embodiment, the first temperature data is the skin temperature of a user of the wearable computing device. In another embodiment, the second temperature data is the internal temperature of the wearable computing device. Furthermore, in one embodiment, the proxy temperature is related to the core body temperature of the user of the wearable computing device.

[0022] In further embodiments, the temperature threshold is at least one of a standard deviation from a baseline temperature or a specified temperature.

[0023] In a further embodiment, the method includes receiving third temperature data corresponding to a proxy temperature over a time period, and determining a baseline temperature based at least in part on the third temperature data.

[0024] In another embodiment, the method includes determining a preliminary assessment of a medical condition of the user based on the temperature changes using at least one machine learning algorithm. In certain embodiments, the medical condition may include at least one of a fever, an illness, an ovulation event, or a circadian rhythm fluctuation.

[0025] In another aspect, the present disclosure relates to a wearable computing device that includes one or more sensors, at least one processor, and at least one memory device having instructions that, when executed by the at least one processor, cause the wearable computing device to receive first temperature data associated with a first temperature measurement of a user from a first sensor on the wearable computing device, receive second temperature data associated with a second temperature measurement of the user from a second sensor on the wearable computing device, the second sensor being located at a different location than the first sensor, determine a proxy temperature based at least in part on the first temperature data and the second temperature data, determine a temperature change based at least in part on the proxy temperature, compare the temperature change to a temperature threshold, determine a preliminary assessment of a medical condition of the user based on the temperature change, and generate and display, via a display, a recommendation to the user based on the preliminary assessment.

[0026] In yet another aspect, the present disclosure relates to a method for assessing the likelihood of the presence or development of a medical condition in a user of a wearable computing device. The method includes receiving first data indicative of a physiological response of the user from one or more sensors on the wearable computing device. The method also includes receiving second data indicative of at least one of demographic information or health information related to the user as input from the user of the wearable computing device. Furthermore, the method includes determining a Z-score for at least one component of the first data using a trained neural network of the wearable computing device. Furthermore, the method includes determining a probability that the severity of the at least one component exceeds a threshold value using a trained machine learning system of the wearable computing device. Furthermore, the method includes providing an instruction to the user, via the wearable computing device, to perform an action.

[0027] In an embodiment, the first data is at least one of the user's temperature, respiratory rate, oxygen, heart rate variability, or blood pressure waveform variation. In another embodiment, the demographic information is at least one of the user's age, gender, or geographic location, and the health information is at least one of the user's one or more symptoms, BMI, or comorbidities. In a further embodiment, the severity corresponds to the likelihood of requiring medical intervention. DETAILED DESCRIPTION

[0028] In the following description, various embodiments are described. For illustrative purposes, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that these embodiments may be practiced without these specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the described embodiments.

[0029] As computing devices become increasingly ubiquitous and portable, many advantages can be seen in the areas of health monitoring and diagnostics. Computing devices, particularly computing devices that can be worn or carried by a user, can include one or more sensors to detect physiological information about the user and / or the user's surroundings. This information can be used to observe, detect, or diagnose various health conditions outside of a traditional clinic or laboratory setting. For example, in the case of detecting disease and / or various medical conditions, a portable or wearable electronic device may be able to detect temperature changes throughout the user's body. Additionally, the computing device may be able to record and interpret the detected information about the user and / or the environment to determine a health assessment. As in the previous example, the wearable electronic device may be able to record changes in core body temperature and generate an assessment that the user is experiencing a disease or medical condition.

[0030] Thus, the present disclosure relates to technical solutions / benefits to the aforementioned technical problems related to the ability to collect sufficient data to provide a user with an overall picture of their current or expected future health. Thus, the present disclosure relates to a system and method for assessing the presence or likelihood of development of a medical condition in a user of a wearable computing device. In a specific embodiment, for example, the wearable computing device includes first and second sensors for generating first and second temperature data from different locations. A proxy temperature can then be determined based on the first and second temperature data, such that temperature changes can be determined and compared to a threshold. Thus, changes above the threshold can be used to determine a preliminary assessment of the user's medical condition based on the temperature changes. The wearable computing device can then generate and display recommendations to the user based on the preliminary assessment. Thus, the systems and methods of the present disclosure provide technical benefits of early disease detection, which can be used to prevent and reduce the spread of disease.

[0031] In various embodiments, a wearable device may include a watch or ring that can be used as a proxy for a user's temperature (e.g., basal temperature, core body temperature, etc.). For example, a first temperature may be taken at the wrist, and a second temperature may be taken internally of the device, e.g., using one or more sensors within the device. Correlation between the skin temperature and the internal device temperature may enable an estimate of the user's body temperature.

[0032] Additionally, a wearable device communicatively coupled to one or more other devices may also receive user input regarding potential symptoms experienced by the user. These symptoms may then be collected and evaluated against sensor information, such as the user's temperature, respiratory rate, oxygen, heart rate variability, and the like. The evaluation may be performed to provide a preliminary diagnosis and / or recommendations for seeking a diagnosis of a potential illness, such as a respiratory disease. Furthermore, in various embodiments, the data may be used to predict an upcoming illness and / or predict the severity of an illness.

[0033] Referring now to the accompanying drawings, Figure 1 An example is illustrated of a user 100 wearing a wearable computing device 102 around a wrist 104 of the user 100. The wearable computing device 102 may also be referred to as a wearable or fitness tracker, and may also include a device worn around the chest, leg, head, or other body part, or a device to be clipped or otherwise attached to a piece of clothing worn by the user 100. The wearable computing device 102 may collectively or individually capture data related to any one or more of: caloric energy expenditure, floors climbed or descended, heart rate, heart rate variability, heart rate recovery, location and / or heading (e.g., via GPS), altitude, walking speed and / or distance traveled, laps swam, bicycle distance and / or speed, blood pressure, blood glucose, skin conduction, skin and / or body temperature, electromyography data, electroencephalography data, weight, body fat, breathing rate and patterns, various body movements, and the like. Additional data may be provided from external sources, for example, a user may enter their height, weight, age, stride length, or other data in a user profile on a fitness tracking website or application, and this information may be used in combination with some of the above data to make certain assessments or determine user behavior, such as the distance the user has traveled or the calories burned. The wearable computing device 102 may also measure or calculate metrics related to the environment surrounding the user, such as atmospheric pressure, weather conditions, sunlight exposure, noise exposure, and magnetic fields.

[0034] In some embodiments, the wearable computing device 102 can be connected to the network directly or via an intermediary device. For example, the wearable computing device 102 can be connected to the intermediary device via a Bluetooth connection, and the intermediary device can be connected to the network via an Internet connection. In various embodiments, a user can be associated with a user account, and the user account can be associated with multiple different networked devices (i.e., logged into multiple different networked devices). In some embodiments, additional devices can provide any of the above data and other data, and / or receive data for various processing or analysis. Additional devices can include computers, servers, handheld devices, temperature control devices, or vehicles, etc.

[0035] Figure 2An example wearable computing device 200 that can be used in accordance with various embodiments is illustrated. In this example, the wearable computing device 200 is a smartwatch, although fitness trackers and other types of devices can also be utilized. Furthermore, although the wearable computing device 200 is shown as being worn on a user's wrist, similar to Figure 1 Examples include, but there can also be other types of devices worn on or near other parts of the user's body, such as on a finger, in the ear, around the chest, etc. For many of these devices, there will be at least some amount of wireless connectivity to enable data transfer between the networked device or computing device and the wearable device. This can take the form of a Bluetooth connection that can synchronize specified data between the user's computing device and the wearable device, or a cellular or Wi-Fi connection that can transmit data over at least one network, such as the Internet or a cellular network, among other such options.

[0036] As mentioned above, such wearable devices can provide various other types of functionality that can be related to the health of the person wearing the device. For example, there can be sensors embedded within the device that can collect data that can be processed on the device, on a connected device, on a remote server, or some combination thereof. In addition, as shown in the figure, Figure 2 2. A wearable computing device 200 is positioned on a user's arm 202. The wearable computing device 200 includes a screen 204 with which the user can interact, such as by inputting information using their finger 206. For example, the screen 204 can prompt the user to answer one or more questions. Additionally, as noted herein, the screen 204 can also provide additional information and / or display connected devices, which can also be used to input information that can be used by the device 200.

[0037] Figure 3An example environment 300 is illustrated in which aspects of various embodiments can be implemented. In this example, a person may own multiple different devices capable of communicating using at least one wireless communication protocol. In this example, a user may have a smartwatch 302 or fitness tracker that the user desires to communicate with a smartphone 304 and a tablet 306. The ability to communicate with multiple devices enables the user to use an app installed on smartphone 304 or tablet 306 to obtain information from smartwatch 302, such as heart rate data captured using sensors on the smartwatch. The user may also desire to enable smartwatch 302 to communicate with a service provider 308 or other such entity, which can obtain and process data from the smartwatch and provide functionality that might not otherwise be available on the smartwatch or apps installed on the respective devices. The smartwatch may be able to communicate with service provider 308 via at least one network 310, such as the Internet or a cellular network, or may communicate with one of the various devices via a wireless connection, such as Bluetooth, which can then communicate via the at least one network. In various embodiments, many other types or reasons for communication are possible.

[0038] Beyond simply being able to communicate, users may also want devices to be able to communicate in multiple ways or with certain parties. For example, users may want communications between devices to be secure, especially if the data may include personal health data or other such communications. Device or application providers may also be required to protect this information, at least in some cases. Users may also want devices to be able to communicate with each other simultaneously, rather than sequentially. This is particularly true in situations where pairing may be required, as users may prefer to pair each device at most once, or to not require manual pairing. Users may also want communication to be standards-based as much as possible, requiring minimal user intervention and enabling devices to communicate with as many other types of devices as possible, which is often not the case with proprietary formats. Thus, a user may want to be able to walk around the room with a device and have it automatically communicate with another target device with minimal effort on the user's part. Traditionally, devices have used wireless local area networks (WLANs) to communicate with other devices using communication technologies such as Wi-Fi. Smaller or lower-capacity devices, such as many Internet of Things (IoT) devices, have instead utilized communication technologies such as Bluetooth, particularly Bluetooth Low Energy (BLE), which has very low power consumption.

[0039] Such as Figure 3The illustrated environment 300 enables data to be captured, processed, and displayed in a variety of different ways. For example, data can be captured using sensors on a smartwatch 302, but due to limited resources on the smartwatch, the data can be transmitted to a smartphone 304 or a service provider system 308 (or cloud resources) for processing, and the results of the processing can then be presented back to the user on the smartwatch 302, smartphone 304, or another such device associated with the user (such as a tablet 306). In at least some embodiments, the user can also use an interface on any of these devices to provide input, such as health data, which can then be considered when making the determination.

[0040] In at least one embodiment, data determined for a user can be used to determine state information, such as can be related to the user's current arousal level or state. At least some of this data can be determined using sensors or components that can measure or detect various aspects of the user, while other data can be manually input by the user or otherwise obtained. In at least one embodiment, an arousal determination algorithm can be utilized that takes as input a plurality of different inputs, where the different inputs can be obtained manually, automatically, or otherwise. In at least one embodiment, such an algorithm can employ various types of factors to identify events or activations that are associated with arousal or "stress" events that activate a sympathetic nervous system response.

[0041] Determining a user's core body temperature based on measurements from an extremity, such as an arm or leg, can be challenging. For example, in some cases, a user's physiological responses can act to direct blood to their core. Additionally, some users may have "cold hands," regardless of other factors. Therefore, traditional skin temperature measurements at a user's extremities provide lower accuracy for determining a user's core body temperature, which can be assessed to identify a user with a fever. Embodiments of the present disclosure are directed to using a combination of temperature measurements, such as a user's skin temperature and internal device temperature, to act as a proxy for core body temperature. Core body temperature can be used to determine various physical conditions of a user, such as a fever, ovulation events, circadian rhythm fluctuations, and the like.

[0042] Embodiments of the present disclosure may use one or more machine learning systems to evaluate a user's temperature fluctuations to determine wrist and / or device temperature as a proxy for body temperature. For example, the temperature at the wrist may be recorded over a time period (e.g., every hour, every half hour, etc.). It will be understood that the time period for recording temperature may be at night, where less variation is expected due to environmental factors such as sunlight exposure, activity level, etc. Additionally, information may be obtained from an internal temperature sensor (e.g., inside the device). In various embodiments, for example, where there is good contact between the user and the device, the temperatures may be substantially similar. The internal temperature may also be collected over a time period that may correspond to the time period for collecting the user's wrist or skin temperature.

[0043] Various embodiments of the present disclosure may also include user information that can be used as "ground truth" data for a machine learning system to assess the user's overall health level. For example, a user may manually report feeling warm or hot during the day, such as through an application on a smartphone or through prompt questions from the device. Thus, the temperature sensor and / or the correlation formed by the temperature sensor can be informed by the user's self-reported information. Thereafter, the user's temperature can be monitored over a period of time (such as a few days) to detect an increase or decrease in temperature. For example, a user may report that they are starting to feel unwell. The device can analyze temperature trends over the previous few days and detect an increase in temperature over a period of time. Thereafter, the device can continue to monitor the temperature and notify the user when the user's temperature exceeds a threshold, which can indicate a fever, or can warn the user that their temperature has exceeded a certain change threshold over a period of time.

[0044] As noted above, in various embodiments, temperature may be collected at night, such as when the user is asleep, due to reduced activity levels, which may otherwise change or affect the user's body temperature. Figures 4A to 4D 400, 420, 440, 460 are graphical representations of temperature distributions for nighttime temperature 402, daytime temperature 404, and off-wrist temperature 406. In the illustrated embodiment, off-wrist temperature 406 is shown to have a distribution less than that of nighttime temperature 402 and daytime temperature 404. Therefore, this information can be useful in predicting when a user is not wearing the device, thereby removing temperature measurement data that could artificially reduce the user's temperature information. Furthermore, these measurements indicate that the user is providing heat to the device. Figures 4A to 4D Each of 402 illustrates the correlation between nighttime temperature 402 and daytime temperature 404. Thus, it is possible that external factors may not significantly affect the internal temperature of the device.

[0045] Figure 5500 is a graphical representation of temperature measurements taken over a period of several days compared to a ground truth. The temperature measurements may correspond to internal device temperatures, which may be provided by temperature sensors on relevant internal components, such as sensors on a battery, thereby simplifying the device by reducing the number of components added to the internal chamber. In this example, different readings were evaluated, including the mean, median, 75th percentile, 90th percentile, and mode. This set of readings 502 is compared to a ground truth 504. In the illustrated embodiment, the mean temperature was found to provide substantially similar data to the other candidates and, for simplicity, can be used with embodiments of the present disclosure to track temperature changes over time.

[0046] Figure 6 is a flow chart of an embodiment of a process 600 for smoothing or processing data in order to determine nighttime temperature. In the illustrated embodiment, the process receives as input temperature data 602, sleep classification 604, and on-wrist data 606. The temperature data 602 may correspond to readings that may be obtained over a time period and may be further sampled and smoothed over sub-time periods. The sleep classification 604 may be a score or indication of a user's sleep state, such as whether the user is asleep, awake, etc. The on-wrist data 606 may provide information to determine time periods when the device was on the user's wrist. Time periods when the device was not on the wrist may be discarded as they may provide artificially low temperatures, such as Figures 4A-4D shown.

[0047] In this example, nighttime data 608 is extracted from the input information 602, 604, 606 and a mean can be calculated, as shown at 610. Post-processing and / or smoothing operations 612 can also be performed to determine the nighttime temperature 614. For example, post-processing can include removing outlier information, changing the time period for evaluation, etc. Post-processing can be optional depending on noise, data acquisition errors, etc. An embodiment can calculate a baseline temperature for a user. The baseline temperature is the average of the nighttime temperature values ​​calculated over several nights. The baseline temperature should not fluctuate too much due to physiologically relevant events, such as fever or ovulation. In various embodiments, the baseline temperature is calculated by averaging four (4) weeks of nighttime temperature values. However, if less than four weeks of data are available, the baseline can be established using less time (e.g., two or three nights) and then updated as more data becomes available.

[0048] Once baseline information is established, changes in temperature can be evaluated against thresholds to identify physiologically relevant events. For example, the baseline can correspond to the median sleep temperature over several nights, the relative temperature can be the difference between the mean nightly temperature and the baseline, an elevated temperature can be a categorical value (e.g., two standard deviations from the baseline or greater than 36°C), and a decreased temperature can also be a categorical value (e.g., less than two standard deviations from the baseline). Figure 7 700 is a graphical representation of a temperature analysis over a period of time. As shown, a baseline 702 is provided at zero, and relative temperature 704 is shown as deviations from the baseline. Increasing and decreasing markers 706, 708 are provided at the relative temperature and the mean nighttime relative temperature at two standard deviations from the baseline. Thus, the information can be evaluated to determine elevated temperatures that may indicate fever, ovulation, etc.

[0049] Data sources with different resolutions can be used with embodiments of the present disclosure. By way of example only, a first data set may record the minimum and maximum temperatures every hour. The first data set may have an accuracy of 0.01 degrees Celsius (°C). The average of these minimum and maximum values ​​can be used as a proxy for the true mean. As another example, a second data set may record the temperature every minute. The second data set may have an accuracy of 0.1°C. It should be understood that for data with lower resolution, correlations can be calculated so that either data set can be used.

[0050] It should be understood that a variety of different sensor data may also be incorporated into embodiments of the present disclosure to evaluate temperature data. For example, information from a UV sensor or light sensor can determine whether it is day or night and / or whether the wearable device is under a cover or blanket or outside. Additionally, a pressure sensor may be integrated into the wearable device to determine whether contact with the user's wrist is sufficient to obtain a skin temperature measurement. Additionally, a GPS signal may provide a location for the user to determine if they are outdoors or engaging in physical activity. Thus, a variety of different sensor data may be used with embodiments of the present disclosure to determine whether one or more of skin temperature and / or internal device temperature can be used as a proxy for body temperature and determination of changes in body temperature.

[0051] Figure 8 800 is a flow chart of an embodiment of a method 800 for determining an agent temperature according to the present disclosure. It should be understood that for any process discussed herein, additional, fewer, or alternative steps can be performed in a similar or alternative order or in parallel within the scope of various embodiments. In this example, as shown at 802, first temperature data is received from a first sensor or component of a wearable computing device. The first temperature data may indicate skin temperature, such as the skin temperature at the wrist of a user wearing the wearable computing device. For example, in an embodiment, the skin temperature may be a contact sensor pressed against the skin to obtain the skin surface temperature. As described above, the skin temperature may be sampled, averaged, etc. over a time period and, in some embodiments, may also correspond to an average temperature over a time period.

[0052] As shown in 804, second temperature data can be received from a second sensor or component of the wearable device. In various embodiments, the second temperature data corresponds to the internal device temperature of the wearable computing device. For example, the internal device temperature can be obtained from one or more sensors associated with a device component, such as a sensor that measures battery temperature. As shown in 806, a combination of at least the first temperature data and the second temperature data can be used to determine a proxy temperature. For example, changes in the proxy temperature can also indicate changes in the user's internal body temperature. The proxy temperature can be determined at least in part by comparing the difference between the first temperature data and the second temperature data. For example, if the first temperature data is substantially similar to the second temperature data (e.g., within a temperature threshold), the data from each sensor can be used to determine an average temperature to use as a proxy temperature. However, if the information is different, various techniques can be utilized, such as collecting an average over a time period, finding a correlation between the minimum and maximum temperatures, and the like.

[0053] As described herein, the proxy temperature can be an estimate or calculation of the user's internal body temperature. The proxy temperature can be determined using one or more data analysis techniques that can correlate at least one of the first temperature data or the second temperature data with body temperature. For example, if the user is sleeping and has the wearable computing device covered on their body, the environment can be able to draw a correlation between the proxy temperature and the body temperature because the environment can create a stable state or closed system for measurement. It should be understood that other sensor data can also be used to determine whether such a state exists, such as UV or light detectors or proximity detectors, as well as other sensors or components. In addition, in various embodiments, data can be acquired over time to establish a correlation between skin temperature and / or internal device temperature and body temperature. For example, it can be determined that changes in body temperature also affect changes in skin temperature or internal device temperature, and therefore, such changes can also be monitored.

[0054] In various embodiments, as shown at 808, a temperature change relative to the proxy temperature is determined. For example, the proxy temperature may increase over a period of time, and as a result, the change in temperature will indicate a change from a baseline or a previous period of time. The temperature change may also be evaluated against a temperature threshold, as shown at 810. If the change exceeds the temperature threshold, the temperature change may indicate a physiological change, such as a fever, ovulation, etc. If the change does not exceed the threshold, the change may be recorded and, if the change is present over time, may be used to update the user's baseline.

[0055] The user may preferably wish to wear several devices (e.g., one on each wrist) or even separate proximal temperature patches to provide a more stable proxy for core body temperature. In this case, the temperature estimates can be combined via averaging or other techniques to provide a more stable estimate.

[0056] Furthermore, skin temperature sensors embedded in wearable devices can be configured to provide additional information about a user's sleep stages and quality. It is known that temperature regulation decreases during REM sleep, so a higher degree of temperature variability will be seen during these stages. Skin temperature can also reflect a user's overall thermal comfort and enhance or disrupt sleep. Users can use Figure 7 The temperature patterns shown are related to personal sleeping comfort.

[0057] Respiratory rate, heart rate, and heart rate variability are some of the health indicators that are easily measured through consumer devices and can potentially provide early signs of disease. This makes consumer devices valuable tools for detecting various diseases and, according to embodiments of the present disclosure, predicting disease or severity based on data obtained from consumer devices.

[0058] Embodiments of the present disclosure include one or more machine learning systems, which may include one or more logistic regression classifiers to predict a patient's need for hospitalization or severity of illness given symptoms experienced, age, gender, and BMI, as well as other potential information. In addition, the systems and methods may include one or more convolutional neural network classifiers to predict whether a person is sick on a particular day given respiratory rate, heart rate, and heart rate variability data for that day and the previous few days. Embodiments of the present disclosure have identified that respiratory rate and heart rate are typically elevated with illness, while heart rate variability is decreased. Measuring these indicators can aid in early diagnosis and monitoring the progression of the illness. The symptoms present can also indicate the severity of the illness. For example, certain illnesses may result in a variety of outcomes based on demographics and comorbidities, such as being male, older, or having a higher BMI.

[0059] In subjects exhibiting disease symptoms, heart rate variability is often reduced, while heart rate and respiratory rate are often elevated. Recent research suggests that measuring these metrics using consumer smartwatches or tracker devices may aid in early disease detection, such as respiratory illness. The disclosed embodiments demonstrate that user symptoms have prognostic value in predicting disease onset and severity.

[0060] Respiratory and other highly contagious illnesses can cause large numbers of people to become ill and infect others, further spreading the disease within the population. For example, 2020 saw the emergence of a global pandemic caused by the severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) virus (e.g., Covid-19). The illness caused by this virus typically presents as a lower respiratory tract infection, although many atypical presentations have been reported. This presents a significant health challenge globally due to the virus's apparent high transmissibility among previously unexposed individuals. Of particular concern is the ongoing debate regarding the primary mechanism of transmission (e.g., the importance of airborne versus fomite transmission) and the potential for infection by asymptomatic and pre-incubated patients. The illness is highly contagious and can be transmitted 2 to 3 days before symptom onset, peaking 0.7 days before symptoms, as reported by He et al. Therefore, early detection is advantageous for SARS-CoV-2 and other highly transmissible illnesses.

[0061] The widespread availability and ubiquity of consumer wearable devices has made it possible to predict the onset of respiratory illnesses such as SARS-CoV-2 using health indicators such as respiratory rate, heart rate, heart rate variability, sleep, and step count. For example, Karjalaninen et al. have determined that each 1°C increase in body temperature can increase heart rate by an average of 8.5 beats per minute. Therefore, measuring resting heart rate or heart rate during sleep can be a useful diagnostic tool. Similarly, when a patient develops a fever, respiratory rate increases, as shown by Jensen et al. Heart rate variability (HRV) is the variability in the time between consecutive heartbeats (the time between consecutive heartbeats is called the "RR interval") and is a noninvasive tool for probing the autonomic nervous system (Shaffer et al.), with reduced values ​​indicating increased mortality (Tsuji et al.) and providing early diagnosis of infection (Ahmad et al.). For example, a study of heart rate variability in patients with severe Covid-19 showed that both approximate and sample entropy were reduced in Covid-19 patients compared to patients with severe sepsis (Kamaleswaran et al.).

[0062] Zhu et al. studied heart rate and sleep data collected from Huami devices to potentially identify outbreaks of Covid-19. Menni et al. analyzed symptoms reported through a smartphone app and developed a model to predict the likelihood of Covid-19 based on symptoms. Marinsek et al. studied data from Fitbit devices as a means of early detection and management of Covid-19. Miller et al. used respiratory rate obtained from Whoop devices to detect Covid-19. Mishra et al. analyzed heart rate, step count, and sleep data collected from Fitbit devices to identify the onset of Covid-19.

[0063] Embodiments of the present disclosure contemplate correlations between changes in physiological signs of respiratory rate, heart rate, and HRV and the corresponding presence of a condition as assessed by validated laboratory tests and self-reported symptoms and the time course of the condition. For example, a wearable device such as that described herein may include one or more sensors to measure heart rate and a basal beat-to-beat interval (RR) that characterizes heart rate variability. In addition, the wearable device may include a user-facing application that can provide prompts and / or receive input indicating a user response. User input may include information about potential symptoms as well as demographic data such as age, sex, body mass index, and relevant background medical information, such as underlying conditions such as diabetes, coronary artery disease, or hypertension.

[0064] For example, a user device can be used to provide the user with a survey about a specific condition or group of medical conditions. Continuing with the example related to Covid-19, but understanding that such survey questions can also be applied to other conditions, such as the flu, urinary tract infections, etc., the user can be asked whether they have been tested for the presence of the condition or disease, whether they have symptoms, and whether they have been tested for any other conditions or diseases. This information can be collected to generate ground truth or training data for the machine learning system. For example, a user who tests confirmed positive can then provide their symptoms, the date of symptom onset, etc., which can be correlated with information from their wearable device to identify correlations between the measured information and underlying symptoms. It should be understood that as more users provide information, such as information on more confirmed positive cases, the training data set can be expanded.

[0065] It should be understood that a variety of information can be utilized to provide diagnostic or prognostic tools. For example, demographic information assessing user age, user gender, user geographic location, etc. can be utilized. Furthermore, comorbidities can also be provided and then used for further analysis, such as identifying comorbidities that increase the likelihood of complications of a particular disease. Examples include hypertension, diabetes, coronary artery disease, asthma, stroke, chronic kidney disease, chronic lung disease, chronic liver disease, or any other disease or condition that a user can self-report.

[0066] In addition, various embodiments may ask users who choose to participate in the survey about their symptoms. It should be understood that even if the user does not have symptoms (e.g., asymptomatic), this information can provide valuable data, where the information is presented together with a confirmed positive diagnosis. For example, asymptomatic carriers of Covid-19 are believed to be able to spread the disease. Therefore, when other symptoms do not prompt the user to get tested, it may be valuable to identify other factors, such as information obtained from sensors that may indicate infection. In addition, the severity of the symptoms can be classified as "mild," "moderate," "severe," and "critical." It should be understood that this classification may be subjective, as one or more users may consider certain symptoms to be more severe than others. Therefore, in various embodiments, the severity can also be classified by the treatment the user receives in order to provide quantitative guidance. For example, the user can provide an answer about the type of treatment they received. A sample of responses and the associated severity are provided in Table 1 below.

[0067] response Severity I have no symptoms. Asymptomatic I self-medicate alone. slight I treated myself with help from others. medium I needed hospitalization and I didn't need respiratory support. serious I need breathing treatment. critical Don't want to say. N / A

[0068] As a result, the severity of patients' symptoms can be grouped and analyzed, which can provide information to health officials in different regions. For example, different regions can identify the percentage of their populations with different factors associated with higher severity to prepare for treating patients in the event of a large number of infections.

[0069] It should be understood that the information collected from users can be analyzed to identify symptom prevalence, and in various embodiments, to identify different numbers of symptoms that, when paired together and / or with different severities, may lead to a greater likelihood of hospitalization. For example, a user who tests positive may have mild symptoms, such as cough and fatigue, while other users with cough, fatigue, and shortness of breath typically have moderate or severe symptoms. In this way, combinations of symptoms can also be used to predict the severity of the disease.

[0070] Figure 9 is a representation 900 of a framework for assessing the presence of a disease according to the present disclosure. In this example, day 0 represents the onset of symptoms. Data from day 0 to day 4 are classified as "positive" (e.g., Figure 9 These data were considered sick days. The data obtained on the 8 days from day -14 to day -8 were assigned to the "negative" class (as shown in Figure 2). Figure 9 (Indicated by "N" in the ). Subjects were considered "healthy" on these days, understanding that this classification may be an assumption that depends on various factors, such as the number of days since infection when symptoms appeared. Data from Days -7 to -1 were omitted because, as mentioned above, subjects may or may not show changes in their health indicators during this time period.

[0071] Embodiments of the present disclosure can calculate physiological data for each user daily, but it should be understood that other data collection intervals can also be used. For example, data collection can include estimated mean respiratory rate during deep (slow-wave) sleep, estimated mean sleep rate during light sleep when deep sleep is insufficient, mean nighttime heart rate during non-rapid eye movement (NREM) sleep, the root mean square of successive differences (RMSSD) of nighttime RR sequences, and the Shannon entropy of nighttime RR sequences. Other embodiments can include other estimates of heart rate variability, such as spectrum-based parameters (referred to in the literature as VLF, LF, HF, and LF / HF ratio), as well as other time-domain metrics such as SDNN, pNN50, TINN, detrended fluctuation analysis, and Allan variance. Assuming the wearable device is also capable of measuring raw photoplethysmography signals, physiological variables associated with blood pressure changes can be estimated. For example, the amplitude of the green PPG signal can be influenced by systolic blood pressure on a beat-by-beat basis. A sequence of increasing PPG amplitude can be interpreted as a sequence of increasing systolic blood pressure, and the corresponding RR interval can be obtained. Sequential methods can be used to form an estimate of baroreflex sensitivity based on overnight data. Physiologists have shown that baroreflex sensitivity may decrease during periods of fever (Front Physiol. 2019; 10:771. Published online, June 25, 2019, doi:10.3389 / fphys.2019.00771). More generally, there is evidence that mean arterial pressure increases during illness. Mean arterial pressure can be obtained from existing cuff-based blood pressure readers and manually entered on a wearable device, or imported into an associated dataset on a wearable app. Therefore, measurement of baroreflex sensitivity or mean arterial pressure can increase the set of values ​​fed into a classification system. In addition, another interesting physiological metric that can be obtained from a wearable device is an estimate of oxygen saturation (SpO2) in the blood. SpO2 can be obtained on a high-resolution timescale (e.g., every second) and then summarized on a daily basis through metrics such as the mean SpO2 over the night, the range of values ​​displayed by SpO2, or even more complex measures of oxygen saturation variability (e.g., variance, spectral analysis, number of nocturnal desaturations).

[0072] Various embodiments may limit or otherwise prioritize obtaining data during the night, such as during the time period of midnight to 7 a.m. Selecting this time period may minimize the impact of confounding effects such as exercise or caffeine intake. Additionally, the data may be further restricted to specific times or conditions, such as when the user is stationary, which may be measured by an accelerometer or other device sensor. RMSSD is a time domain measure used to estimate vagal-mediated changes (Shaffer et al.). In an embodiment, it is calculated at five minute intervals, and the median of these individual measurements is calculated for the entire night. Shannon entropy is a nonlinear time domain measure that is calculated using a histogram of the RR intervals throughout the night.

[0073] Using symptoms as input features, embodiments train a logistic regression classifier to predict the need for hospitalization (e.g., categories of "severe" and "critical"). Additionally, embodiments can train the model to identify the onset of illness. Because health indicators such as respiratory rate, heart rate, heart rate variability, blood pressure, baroreflex sensitivity, and oxygen saturation values ​​can vary significantly between users, embodiments calculate the equivalent of a Z score, represented by equation (1),

[0074]

[0075] where x is data from and / or calculated by a sensor, which may correspond to respiratory rate, heart rate, RMSSD, or entropy, and μ x and σ x are the rolling mean and rolling standard deviation of the indicator being measured.

[0076] In various embodiments, rolling values ​​for the mean and standard deviation are determined by evaluating the previous seven days of data to obtain initial estimates of the mean and standard deviation. It should be understood that seven days is used as an example only, and in various other embodiments, different time periods may be used. For each additional day of data, the data point is evaluated for outliers using equation (1). Thereafter, a probability is calculated from the Z score using a one-sided t-test (positive values ​​only for respiratory rate and heart rate, negative values ​​only for RMSSD and entropy). If the p-value is less than a selected threshold, the data point is considered outlier (i.e., the subject is assumed to be ill) and is added to the calculation of μ. x and σ x Otherwise, the point is added to the list and the updated mean and standard deviation are calculated. The threshold for the p-value can be specifically chosen based on various factors. It will be appreciated that if the threshold is too low, there is a risk of including sick days in μ x and σ x However, if the threshold is too high, the mean is biased to be lower or higher than the true value. For example, the threshold can be set to 0.05, but such an example is provided for illustrative purposes only.

[0077] For any given day D n , in the closest D n D i The mean and standard deviation are evaluated for each day, so i <= n. If a subject has data for fewer than 7 days (or any other number chosen), the mean and standard deviation are not calculated. In various embodiments, using equation (1) and μ x and σ x An estimate of the health metric (e.g., sensor data and / or data derived from the sensor) is used to calculate a Z score. In various embodiments, the Z score is thresholded. In this example, Z max = +5 and Z min =-3, but it will be appreciated that other thresholds may be chosen and rescaled to the range (0, 1).

[0078] The data can then be evaluated by constructing a 4 × 5 matrix with the D n In various embodiments, the Z score corresponds to the normalized Z score of D n …D n-4 Certain health indicators are measured over these days (4 health indicators in this example). Each day is represented by a matrix with data for that day and data for the previous four days. Missing data can be filled in using linear interpolation. In some embodiments, it may be desirable to limit the amount of missing data allowed. For example, missing data can only be filled in if there is a threshold amount of data, such as a minimum of 3 days of data. By adjusting each 4×5 matrix to a 28×28×1 matrix, each matrix can be used to form an "image" where the last dimension represents only one color channel.

[0079] It will be appreciated that in an initial step, a training subset, referred to as training data, may be used to train a machine learning system. For example, for 464 unique individuals with sufficient data, 4815 images may be obtained. This may be divided into a training set with 70% of the data, and the remainder into two exclusion sets. One exclusion set (the "CV set") may be used for cross-validation. Thereafter, a machine learning system, such as a convolutional neural network, may be trained. The network may comprise a single convolutional stage and a single dense stage, with nonlinearity introduced in the form of a "ReLu" layer, and the output layer being a softmax function.

[0080] For example, a logistic regression model can be trained to predict the need for hospitalization using symptoms along with age, sex, and BMI as input features using four-fold cross validation. The probability p of needing hospitalization can be approximated by equation (2),

[0081]

[0082] Where α=3:62, s i is the symptom (1 if the symptom exists, 0 otherwise), w i Corresponds to symptoms i The weights can be specifically selected based on diagnostic information, which can be collected and adjusted over time. For example, for new conditions, as new symptoms are identified, the weights can be increased.

[0083] In various embodiments, variables (e.g., age and BMI) may be scaled as shown in equation (3),

[0084]

[0085] where x s is a scaled version, and x represents age or BMI. x and σ x are the mean and standard deviation, respectively. For gender, 1 indicates male and 0 indicates female. Various embodiments may include a convolutional neural network trained to predict whether an individual is sick on any particular day given the respiratory rate, heart rate, RMSSD, and entropy Z-scores for the previous four days. The results of training this model are presented in Table 2 below.

[0086]

[0087] (b) Changes in training / cv / detection segmentation

[0088]

[0089] (c) Convolutional and dense layers

[0090]

[0091] As shown in the figure, three hyperparameters are varied: the number of filters in the convolutional stages, the number of neurons in the dense stages, and the filter size in the form k×k. The results subtable shows the AUC for different choices of k. As shown, smaller filter sizes perform slightly better than other filter sizes. The middle subtable shows the modeling performed on various folds of data. The data was randomly divided into training and exclusion sets, but the splits were performed four times using different seeds each time to reduce the risk of outliers affecting the results. The AUC varied from 0.71 to 0.80, indicating that some individuals showed only small changes in health indicators, while other individuals showed more measurable changes. The bottom subtable experiments with the number of filters and the number of neurons in the dense layer, where the effect on the AUC was very small.

[0092] Figure 10 An example input image of a single user according to the present disclosure is illustrated. Shown are days from day -5 to day +4, where day 0 represents the onset of symptoms. As shown, the images from day -5 to day -2 show no significant features and are consistent with normal health indicators. Day -1 shows a bright spot developing in the upper right corner, indicating elevated respiratory and heart rates, while the lower right corner is dark, indicating that the RMSSD and entropy are below normal. By day 3, the pattern evolves into light and dark bands, indicating a significant change in health indicators that persists over multiple days. The probability score increases from day -2 to day -1 and remains high thereafter. The appropriate threshold for classifying the probability score into disease / health categories is determined based on the specificity / sensitivity requirements.

[0093] It should be understood that specificity / sensitivity can be adjusted based on changes in various parameters. For example, when a subject is sick, a true positive as a prediction of being sick is desirable. A false positive, i.e., predicting being sick on days when the subject is not sick, is less desirable. Even less desirable are false negatives, where the subject is sick but is predicted to be not sick. Table 3 below lists the values ​​of specificity and sensitivity for a given prediction threshold (e.g., for a specific training / cv / detection split, i.e., fold #1), e.g., if the threshold is set to 0.533, 90% specificity and 48% sensitivity are displayed, or if the threshold is set to 0.286, 91% sensitivity and 31% specificity are displayed). High specificity allows the detection algorithm to not cause many false alarms, while high sensitivity is preferred for early warning systems that encourage people to stay at home even if they are at low risk.

[0094] Threshold Specificity Sensitivity 0.603 0.954 0.381 0.533 0.901 0.477 0.49 0.849 0.534 0.466 0.798 0.584 0.443 0.752 0.612 0.412 0.704 0.673 0.396 0.654 0.705 0.37 0.599 0.769 0.347 0.55 0.804 0.325 0.502 0.843 0.313 0.467 0.861 0.295 0.395 0.883 0.286 0.368 0.907 0.262 0.309 0.922 0.251 0.265 0.95

[0095] Figure 11 1100 is a graphical representation of a small fraction of users in the test set predicted as positive (e.g., predicted to be "sick" on different days). Day 0 is the onset of symptoms. Negative numbers indicate days before the onset of symptoms, while positive numbers indicate days after the onset of symptoms. Predictions for three different selections of specificity (Sp) and sensitivity (Se) from Table 3 are shown. As shown and described above, lower specificity results in a larger number of positive predictions before the onset of symptoms.

[0096] Embodiments provide a system and method for predicting a positive diagnosis and / or the possible severity (e.g., need for hospitalization) of a disease using information available from a wearable device and information provided by a user. Additionally, embodiments are capable of detecting certain symptoms or groups of symptoms that provide a higher likelihood of a severe case that may result in hospitalization or other advanced care. Additionally, demographic information and / or comorbidities may be identified to determine that a user has a higher likelihood of severe symptoms. In various embodiments, data available from a user device may be used for predictions such as respiratory rate, heart rate, and heart rate variability. Additionally, in embodiments, temperature may also be an indicator, which may use a proxy temperature as described above. Embodiments also include convolutional neural networks that have been trained to predict disease on any particular day given health indicators for the previous four days. High sensitivity models may detect disease 1 to 2 days in advance, while high specificity models are less likely to produce incorrect disease predictions.

[0097] Figure 1212 is a flow chart of an embodiment of a method 1200 for predicting a disease and / or the likely severity of a disease according to the present disclosure. In this example, as shown at 1202, first data is received from one or more sensors of a wearable computing device. As described above, the sensors may provide data related to respiratory rate, heart rate and heart rate variability, temperature, blood pressure, oxygen saturation, and the like. Additionally, as shown at 1204, the user may provide second data related to demographic or health information. For example, demographic information may include age, gender, and geographic location. Furthermore, health information may include BMI, comorbidities, and / or symptoms. As shown at 1206, a trained neural network may be used to collect and process this information to develop a Z-score. In such an embodiment, the Z-score may be processed into an image matrix and then evaluated over time to identify one or more symptoms indicative of a disease on a particular day. In various embodiments, the data is provided over a series of days, with variations in various factors providing indicators of the disease. Furthermore, in various embodiments, as shown at 1208, the data may be processed using a machine learning system, such as a trained linear classifier, to predict the user's symptoms and / or the severity of the disease. The severity can be related to the likelihood that the user will require intervention, such as hospitalization, for the illness. As shown in 1210, the wearable computing device can provide prompts to the user for subsequent actions. For example, the wearable computing device can identify possible symptoms before the illness and provide information to the user to stay home or seek medical care. In this way, the illness and its possible severity can be predicted. Alternative embodiments of symptom prediction are also considered. For example, a technique for implementing change point analysis can be considered to determine the time point when a person changes from a healthy state to an ill state (see Aminikhanghahi S, Cook DJ. A Survey of Methods for Time Series Change Point Detection. Knowl Inf Syst. 2017; 51(2): 339-367. doi: 10.1007 / s10115-016-0987-z for a survey of common methods for determining change points).

[0098] 13A to 13D is a graphical representation of the Z scores associated with different data components for a hypothetical user with a respiratory disease according to the present disclosure. In various embodiments, 13A to 13D Statistically significant changes associated with disease onset are illustrated, which can be used to provide alerts to users indicating disease onset or potential disease. It should be understood that these changes can be evaluated as percentage changes, absolute changes, etc. In addition, as 13A to 13DAs shown, information may be provided to users at different levels in a graphical manner, such as with color coding to illustrate different ranges of variability, to enable users to track their health over time.

[0099] Figure 13A Representative data from an individual user who has been diagnosed with a respiratory illness, possibly COVID-19, is illustrated. In this example, a graphical representation 1300 of respiratory rate Z-scores is presented, with the y-axis corresponding to the Z-score and the x-axis corresponding to the date. The illustrated representation 1300 includes a diagnosis date 1302 of April 28, 2020. As shown in the illustrated embodiment, the respiratory rate Z-score begins to increase before and after the diagnosis date 1302. The example includes a color-coded alert system in which red points indicate high statistical significance, yellow points indicate moderate levels of significance, and green points are within normal variability.

[0100] In certain embodiments, a threshold number of days that are at high or moderate statistical significance can be used as an indicator for providing an alert to a user. For example, in this example, a user can be alerted on April 29, 2020, where three of the previous four days had high statistical significance. It should be understood that a variety of different methods can be used to establish the threshold, such as increasing Z scores over a number of days, increasing Z score values, increasing average Z score values ​​over a time period, or any combination thereof. Additionally, it should be understood that the respiration rate Z score can be a factor in determining whether to provide an alert to a user, and in various embodiments, can be a weighting factor used to determine whether a threshold amount of data has been acquired to make a recommendation to the user, such as performing a diagnostic test.

[0101] 13B to 13D Additional representations 1320, 1340, 1360 of nighttime Z-score heart rate, Z-score RMSSD, and Z-score Shannon entropy corresponding to deep sleep RR intervals are included. Figure 13B Also shown is an increase after diagnosis 1302. Thus, in some embodiments, nighttime Z-score heart rate can also be used to assess the potential onset of disease and / or provide a recommendation for diagnostic testing. For example, in various embodiments, the combination of an increased Z-score respiration rate and an increased Z-score heart rate may be sufficient to meet a threshold to provide a notification to the user.

[0102] Figure 13C and Figure 13D Statistically significant changes in the RMSSD of the Z-scores and the Shannon entropy of the Z-scores following diagnosis 1302 are further illustrated. For example, as shown in representation 1340, three of the four days between April 30 and May 3 had highly statistically significant low RMSSD of the Z-scores. These dates correspond to and / or partially overlap with statistically high readings shown in the Z-score of respiration rate and the Z-score of heart rate. Figure 13D Representation 1360 also shows a moderately statistically significant deviation on April 30. Thus, embodiments of the present disclosure may utilize one or more data sets to determine various changes in the Z-score that may indicate an onset of disease.

[0103] Figure 14 The diagram illustrates a basic component set 1400 of one or more devices of the present disclosure according to various embodiments of the present disclosure. In this example, the device includes at least one processor 1402 for executing instructions that can be stored in a memory device or element 1404. It will be apparent to one of ordinary skill in the art that the device can include many types of memory, data storage, or computer-readable media, such as a first data storage for program instructions executed by (multiple) processors 1402, the same or separate storage can be used for images or data, removable memory can be used to share information with other devices, and any number of communication methods can be used to share with other devices. The device may also include at least a display 1406 (e.g., a touch screen, electronic ink (e-ink), organic light emitting diode (OLED), or liquid crystal display (LCD)), one or more power components, input / output elements 1410, one or more wireless components 1412, a transmitter 1416, a driver 1414, and / or a detector 1418, as well as devices such as servers that transmit information via other means such as light and data transmission systems. This equipment can also comprise port, network interface card or the wireless transceiver that can communicate by at least one network 1420.Input / output device 1410 can receive conventional input from the user.This input / output device 1410 can comprise for example button, touch pad, touch screen, roller, joystick, keyboard, mouse, trackball, keypad or any other such device or element, and the user can input command to this equipment thus.In certain embodiments, these input / output devices 1410 also can be connected by wireless infrared or bluetooth or other links.Yet, in certain embodiments, this equipment may not comprise any button at all, and may only control by the combination of visual and auditory commands, so that the user can control this equipment and need not contact with this equipment.

[0104] As discussed, according to the described embodiments, different methods can be implemented in a variety of environments. As will be appreciated, although several examples presented herein use a network-based environment for illustrative purposes, different environments may be used to implement the various embodiments as appropriate. The system includes an electronic client device, which can include any suitable device operable to send and receive requests, messages, or information over a suitable network and transmit the information back to the user of the device. Examples of such client devices include personal computers, cell phones, handheld messaging devices, laptops, set-top boxes, personal data assistants, e-book readers, and the like. The network can include any suitable network, including an intranet, the Internet, a cellular network, a local area network, or any other such network or combination thereof. The components used in such a system can depend, at least in part, on the type of network and / or environment selected. The protocols and components used for communicating via such networks are well known and will not be discussed in detail herein. Communication via the network can be achieved via wired or wireless connections, or combinations thereof. In this example, the network includes the Internet because the environment includes a web server for receiving requests and providing content in response to the requests, although alternative devices serving similar purposes may be used for other networks, as will be apparent to one of ordinary skill in the art.

[0105] The illustrative environment includes at least one application server and a data storage device. It should be understood that there can be several application servers, layers or other elements, processes or components, which can be linked or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data storage device. As used herein, the term "data storage device" refers to any device or combination of devices that can store, access and retrieve data, which can include any combination and number of data servers, databases, data storage devices and data storage media in any standard, distributed or clustered environment. The application server can include any appropriate hardware and software for integrating with the data storage device as needed to execute various aspects of one or more applications of the client device and handle most of the data access and business logic of the application.

[0106] The application server cooperates with the data storage device to provide access control services and can generate content to be transmitted to the user, such as text, graphics, audio and / or video. In this example, these contents can be provided to the user by the network server in the form of HTML, XML or another appropriate structured language. The processing of all requests and responses and the content transmission between the client device and the application server can be handled by the network server. It should be understood that the network and application server are not required, but are merely example components, because the structured code discussed in this article can be executed on any appropriate device or host discussed elsewhere in this article. The data storage device can include several separate data tables, databases or other data storage mechanisms and media for storing data related to specific aspects. For example, the illustrated data storage device includes a mechanism for storing content (e.g., production data) and user information, which can be used to provide content to the production side. The data storage device is also shown as including a mechanism for storing logs or session data. It should be understood that there can be many other aspects that need to be stored in the data storage device, such as page image information and access rights information, which can be appropriately stored in any of the mechanisms listed above, or in additional mechanisms stored in the data storage device. The data storage device can operate through its associated logic to receive instructions from the application server and obtain, update, or otherwise process data in response. In one example, a user may submit a search request for a certain type of item. In this case, the data storage device may access user information to verify the user's identity and can access directory details to obtain information about that type of item. This information can then be returned to the user, such as in a results list on a web page that the user can view via a browser on the user's device. Information about a specific item of interest can be viewed in a dedicated page or window in the browser.

[0107] Each server will typically include an operating system that provides executable program instructions for the general management and operation of the server, and will typically include a computer-readable medium storing instructions that, when executed by the server's processor, enable the server to perform its intended functions. Suitable implementations of the server's operating system and general functionality are known or commercially available and are readily implemented by one of ordinary skill in the art, particularly in light of the disclosure herein.

[0108] The environment in one embodiment is a distributed computing environment that utilizes several computer systems and components interconnected via communication links using one or more computer networks or direct connections. However, one of ordinary skill in the art will appreciate that such a system can operate equally well in systems having fewer or more components than illustrated. Therefore, the description of the system herein should be considered illustrative in nature and not limiting on the scope of the present disclosure.

[0109] Various embodiments can also be implemented in a variety of operating environments, which in some cases can include one or more user computers or computing devices that can be used to operate any of a number of applications. User or client devices can include any of a variety of general-purpose personal computers, such as desktop or laptop computers running standard operating systems, and cellular, wireless, and handheld devices running mobile software and capable of supporting a variety of networking and messaging protocols. Devices capable of generating events or requests can also include wearable computers (e.g., smart watches or glasses), VR headsets, Internet of Things (IoT) devices, voice command recognition systems, and the like. Such systems can also include multiple workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. These devices can also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0110] Most embodiments utilize at least one network familiar to those skilled in the art to support communications using any of a variety of commercially available protocols, such as TCP / IP, FTP, UPnP, NFS, and CIFS. The network can be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.

[0111] In embodiments utilizing a web server, the web server can run any of a variety of server or middle-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server(s) can also execute programs or scripts in response to requests from user devices, such as by executing one or more web applications, which can be implemented in any programming language, such as One or more scripts or programs written in C, C# or C++ or any scripting language such as Perl, Python or TCL and combinations thereof. The server(s) may also include a database server, including but not limited to a database server that can be accessed from and Commercially available servers, as well as open source servers, such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving, and accessing structured or unstructured data. The database servers may include table-based servers, document-based servers, unstructured servers, relational servers, non-relational servers, or a combination of these and / or other database servers.

[0112] As mentioned above, this environment can include various data storage devices and other memories and storage media. These can reside in various locations, such as on the storage medium of one or more computer locals (and / or reside therein), or away from any or all computers on the network. In a specific embodiment set, information can reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the function belonging to a computer, server or other network device can be suitably stored in local and / or remote locations. In the case where the system includes a computerized device, each such device can include a hardware element that can be electrically coupled via a bus, and these elements include, for example, at least one central processing unit (CPU), at least one input device (for example, mouse, keyboard, controller, touch-sensitive display element or keypad) and at least one output device (for example, display device, printer or loudspeaker). This system can also include one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices, for example random access memory (RAM) or read-only memory (ROM), and removable media devices, memory cards, flash memory cards etc.

[0113] Such a device can also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device), and a working memory as described above. The computer-readable storage medium reader can be connected to a computer-readable storage medium representing a remote, local, fixed, and / or removable storage device and a storage medium for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information, or be configured to receive a computer-readable storage medium. The system and various devices will typically also include a plurality of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or a web browser. It should be understood that alternative embodiments can have many variations different from those described above. For example, customized hardware and / or specific elements can also be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections to other computing devices such as network input / output devices can be employed.

[0114] Storage media and other non-transitory computer-readable media for containing code or code portions can include any suitable media known or used in the art, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical storage devices, cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the required information and can be accessed by system devices. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will understand other ways and / or methods of implementing various embodiments.

[0115] Although various embodiments of the present invention have been described above, it should be understood that they are presented by way of example only and not by way of limitation. Similarly, various figures may depict example architectures or other configurations of the present disclosure, which is done to help understand the features and functions that can be included in the present disclosure. The present disclosure is not limited to the example architectures or configurations shown, but can be implemented using various alternative architectures and configurations. In addition, although the present disclosure has been described above in terms of various exemplary embodiments and implementation schemes, it should be understood that the various features and functions described in one or more individual embodiments are not limited to their applicability to the specific embodiments in which they are described. On the contrary, they can be applied to one or more other embodiments of the present disclosure, either alone or in some combination, regardless of whether these embodiments are described or whether these features are presented as part of the described embodiments. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

[0116] Unless otherwise defined, all terms (including technical and scientific terms) have the ordinary and customary meanings to those skilled in the art and are not limited to special or customary meanings unless expressly defined herein. It should be noted that when describing certain features or aspects of the present disclosure, the use of a particular term should not be understood as indicating that the term is redefined herein to be limited to include any specific features of the feature or aspect of the present disclosure associated with the term. Unless expressly stated otherwise, the terms and phrases used in this application and their variations, especially in the appended claims, should be interpreted as open-ended and not restrictive. As an example of the foregoing, the term "including" should be interpreted as "including but not limited to," "including but not limited to," and the like; the term "comprising" as used herein is synonymous with "including," "containing," or "characterized by," and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps; the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," and the term "example" is used to provide illustrative examples of the items in question, rather than an exhaustive or limiting list thereof; adjectives such as "known," "normal," "standard," and terms of similar meaning should not be construed to limit the described items to a given time period or items available as of a given time, but should be construed to encompass known, normal, or standard technologies that are known or available at any time now or in the future; and the use of terms like "preferably," "preferred," "desirable," or "desirable," and words of similar meaning should not be construed to imply that certain features are critical, necessary, or even important to the structure or function of the invention, but are merely intended to highlight alternative or additional features that may or may not be used in a particular embodiment of the invention. Likewise, a group of items linked with the conjunction "and" should not be read as requiring that each and every one of those items be present in that group, but rather should be read as "and / or" unless expressly stated otherwise. Similarly, a group of items linked with the conjunction "or" should not be read as requiring mutual exclusivity among the group, but rather should be read as "and / or" unless expressly stated otherwise.

[0117] Where a range of values ​​is provided, it is understood that the upper and lower limits, and every intervening value between the upper and lower limits of the range, is encompassed within the embodiments.

[0118] With regard to the use of substantially any plural and / or singular terms herein, a person skilled in the art will be able to translate from the plural to the singular and / or from the singular to the plural, as appropriate, depending on the context and / or application. For the sake of clarity, various singular / plural arrangements may be clearly set forth herein. The indefinite article "a" or "an" does not exclude plural number. A single processor or other unit may perform the functions of several items listed in a claim. The fact that certain measures are cited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.

[0119] Those skilled in the art will further understand that if a specific number of claim references is intended to be introduced, such intention will be explicitly referenced in the claim, and if no such reference is made, no such intention exists. For example, to aid understanding, the following appended claims may contain the use of the introductory phrases "at least one" and "one or more" to introduce claim references. However, the use of such phrases should not be interpreted as indicating that a claim reference introduced by the indefinite article "a" or "an" limits any particular claim containing such introduced claim reference to embodiments containing only one such reference, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should generally be interpreted as meaning "at least one" or "one or more"); the same applies to the use of definite articles used to introduce claim references. In addition, even if a specific number of introduced claim references is explicitly referenced, those skilled in the art will recognize that such reference should generally be interpreted as meaning at least the referenced number (e.g., a simple reference to "two references" without other modifiers generally means at least two references, or two or more references). In addition, in those cases where there is a convention similar to "at least one of A, B, and C, etc.", generally speaking, such construction is intended to make the convention understood by those skilled in the art (e.g., "a system having at least one of A, B, and C" will include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those cases where there is a convention similar to "at least one of A, B, or C, etc.", generally speaking, such construction is intended to make the convention understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" will include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that, whether in the specification, claims, or drawings, virtually any transitional word and / or phrase indicating two or more alternative terms should be understood to include the possibility of one term, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B."

[0120] All numbers used in the specification indicating the amount of ingredients, reaction conditions, etc. should be understood to be modified by the term "about" in all cases. Therefore, unless otherwise indicated, the numerical parameters set forth herein are approximate values ​​that may vary depending on the desired properties sought to be obtained. At a minimum, and without attempting to limit the application of the doctrine of equivalents to the scope of any claim in any application claiming priority to this application, each numerical parameter should be interpreted according to the number of significant figures and ordinary rounding methods.

[0121] All features disclosed in this specification (including any accompanying appendices, claims, abstract and drawings), and / or all steps of any method or process so disclosed, may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. The disclosure is not limited to the details of any foregoing embodiments. The disclosure extends to any novel one or any novel combination of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one or any novel combination of the steps of any method or process so disclosed.

[0122] Various modifications to the embodiments described in this disclosure may be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but should be given the widest scope consistent with the principles and features disclosed herein. Certain embodiments of the present disclosure are encompassed in the accompanying claim set or will be presented in the future.

Claims

1. A method for assessing the presence or likelihood of development of a medical condition in a user of a wearable computing device, the method comprising: receiving first temperature data related to a first temperature measurement of the user from a first sensor on the wearable computing device; receiving second temperature data related to a second temperature measurement of the user from a second sensor on the wearable computing device, the second sensor being located at a different location than the first sensor; determining a proxy temperature based at least in part on the first temperature data and the second temperature data, including comparing a difference between the first temperature data and the second temperature data, wherein if the first temperature data is similar to the second temperature data within a temperature threshold, data from each of the sensors is used to determine an average temperature for use as the proxy temperature; determining a temperature change based at least in part on the proxy temperature; comparing the temperature change to a temperature threshold; determining, via the wearable computing device, a preliminary assessment of the user's medical condition based on the temperature change; and generating a recommendation for the user based on the preliminary assessment and displaying the recommendation for the user via a display of the wearable computing device, Wherein the first temperature data is a skin temperature of the user of the wearable computing device, and wherein the second temperature data is an internal temperature of the wearable computing device.

2. The method according to claim 1, wherein The proxy temperature is associated with a core body temperature of the user of the wearable computing device.

3. The method according to claim 1, wherein The temperature threshold is at least one of a standard deviation from a baseline temperature or a specified temperature.

4. The method according to claim 1, further comprising: receiving third temperature data corresponding to the proxy temperature within a time period; as well as A baseline temperature is determined based at least in part on the third temperature data.

5. The method of claim 1 , further comprising determining the preliminary assessment of the medical condition of the user based on the temperature change using at least one machine learning algorithm.

6. The method according to claim 1, wherein The medical condition includes at least one of a fever, an illness, an ovulatory event, or a circadian rhythm fluctuation.

7. A wearable computing device comprising: one or more sensors; at least one processor; as well as at least one memory device comprising instructions that, when executed by the at least one processor, cause the wearable computing device to: receiving first temperature data related to a first temperature measurement of a user from a first sensor on the wearable computing device; receiving second temperature data related to a second temperature measurement of the user from a second sensor on the wearable computing device, the second sensor being located at a different location than the first sensor; determining a proxy temperature based at least in part on the first temperature data and the second temperature data, including comparing a difference between the first temperature data and the second temperature data, wherein if the first temperature data is within a temperature threshold of the second temperature data, data from each of the sensors is used to determine an average temperature for use as the proxy temperature; determining a temperature change based at least in part on the proxy temperature; comparing the temperature change to a temperature threshold; determining a preliminary assessment of the user's medical condition based on the temperature change; and generating a recommendation for the user based on the preliminary evaluation and displaying the recommendation for the user via a display, Wherein the first temperature data is a skin temperature of the user of the wearable computing device, and wherein the second temperature data is an internal temperature of the wearable computing device.

8. The wearable computing device of claim 7, wherein: The proxy temperature is associated with a core body temperature of the user of the wearable computing device.

9. The wearable computing device of claim 7, wherein: The temperature threshold is at least one of a standard deviation from a baseline temperature or a specified temperature.

10. The wearable computing device of claim 7, wherein: The instructions further cause the at least one processor to: receiving third temperature data corresponding to the proxy temperature within a time period; and A baseline temperature is determined based at least in part on the third temperature data.

11. The wearable computing device of claim 7, wherein: The instructions further cause the at least one processor to: The preliminary assessment of the medical condition of the user is determined based on the temperature change using at least one machine learning algorithm.

12. The wearable computing device of claim 7, wherein: The medical condition includes at least one of a fever, an illness, an ovulatory event, or a circadian rhythm fluctuation.

Images