RU2818831C1 - Computerized decision support tool and medical device for detection of scratches and prediction of redness - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: group of inventions relates to a computerized decision support tool for detecting scratches and predicting redness. Disclosed is a system comprising a machine-readable medium for implementing the method, which comprises: processor; and a computer storage device having stored computer-executable instructions for performing operations when executed by a processor, wherein the operations comprise: receiving accelerometer data for a person; detecting hand movement using accelerometer data; use of computerized classification model to determine, based on the accelerometer data corresponding to the movement of the hands, that the movement of the arms indicates a scratching event; and initiating one or more responses based on at least a determination that the movement of the hands indicates a scratching event, wherein the operations performed by the processor executing the computer-executable instructions comprise determining the full sleep capability based on the accelerometer data, wherein full possibility of sleep comprises a period of time between when a person lies down in a motionless state, and when a person gets up from a motionless state, wherein hand movement is detected using accelerometer data corresponding to full sleep capability, wherein accelerometer data is captured by means of a wearable device having more than one sensors, wherein the wearable device additionally captures at least one of the temperature data around the body and the illumination data, wherein complete sleep capability is determined based on at least one of body temperature data and illumination data.

EFFECT: group of inventions provides detection of scratches and prediction of redness.

18 cl, 59 dwg

Description

State of the art

Atopic dermatitis is a chronic relapsing-remitting skin disease that affects approximately 10% of adults and 12% of children in the United States. It is characterized by red, scraped lesions on the skin with itching (scabies). People who experience itching typically scratch the affected skin, which increases the inflammation that causes itching and exacerbates the itch and scratching cycle. For many people with atopic dermatitis, itching peaks at night, leading to sleep disturbances.

Assessments of pruritus-associated disease such as atopic dermatitis have traditionally been subjective, anecdotal, and provide poor measures of the impact of atopic dermatitis. For example, one traditional tool is the clinical outcome assessment (COA), which involves a physician's assessment of the total body surface area of the injury and the severity of the injury. COAs are subjective in that their assessments vary among physicians and are episodic in nature, as they can only be performed while a person is being seen by a physician. Another traditional instrument is the patient-reported outcome (PRO), which is a qualitative and subjective report from the patient regarding the severity of itch. PROs may lack accuracy due to treatment noncompliance, recall bias, and daily fatigue.

The essence of the invention

This summary is provided to present in a simplified form a selection of concepts that are further described below in the detailed description. This entity is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation as an aid in defining the scope of the claimed subject matter.

Embodiments of the present disclosure provide improved computer decision support tools for detecting scratching and, in some aspects, predicting future flushing events. As used herein, the term “redness event” can mean an acute or very severe phase of itching. Embodiments may include using data obtained through a sensor device, which may be a wearable device, to automatically detect scratching events. Thus, scratching events can be detected based on a continuous stream of data input to one or more machine learning classifiers to provide an objective assessment of scratching. The detected scratching behavior, in accordance with some embodiments herein, is nighttime scratching or scratching during a period in which the user intends to sleep. This detection helps track scratching during peak itch times or even when the user is unaware of scratching. In this regard, detected scratching events, in accordance with embodiments of this disclosure, can provide more accurate indicators of the user's current itch and atopic dermatitis. Additionally, embodiments may use detected scratching patterns to predict the likely level of scabies in a future interval, which may indicate a future redness event. Detected scratching events and, in some embodiments, predicted future level of scabies and/or redness events may be used in computerized decision support tools to more accurately and timely monitor atopic dermatitis symptoms and initiate intervention and/or therapeutic treatments to relieve or prevent symptoms.

The scratching may be detected using accelerometer data obtained through a sensor worn by the person being tracked (who may also be referred to herein as the “patient” or “user”). Using these sensors, a hand movement event can be detected, and it can be determined whether or not the hand movement event represents a probable scratching event. In some aspects, prior to detection of hand movement events, context is defined as limiting the potential sensor data used to detect hand movement events. In some aspects, the context includes detecting whether or not a sensor is configured to properly receive data, for example, detecting that a sensor is being worn by a user, which would be more likely to result in accurate detection of hand movement events and, in turn, scratching events. Additionally, the user's sleep opportunity can be detected to determine the period of time during which the user intends to sleep, and arm movement events and scratching events can be detected using sensor data acquired during the user's sleep opportunity. Thus, scratching that occurs at night (when itching is at its peak) and/or while the user is sleeping and less likely to be aware of scratching may be detected.

A detected probable scratch event may be recorded and an action may be initiated based on one or more detected scratch events. For example, an alert or notification may be provided to a user to notify that user regarding the detected scratching event(s). Additionally, data associated with the detected scratching event can be processed for computer-implemented decision making. For example, scratch event data may be aggregated to identify the total number of detected scratch events over a period of time, such as a 24-hour time period. In some embodiments, the total scratch duration may also be determined by summing the durations of all detected scratch events within a given period of time. The total number of scratching events and/or the total duration of scratching may be used to trigger recommendations to seek medical treatment or consultation with a physician, or issue a notification to a user device associated with the monitored individual's physician. Additionally or alternatively, the total number of scratching events and/or the total duration of scratching may be added to the user's electronic calendar during the period of time during which scratching data is detected. Additionally, embodiments may determine the total number of scratching events and/or the total duration of scratching for multiple time periods to identify the severity of scratching over time and/or changes in scratching behavior, any of which may be used to trigger an action.

Detection of a scratching event may be achieved by applying one or more machine learning models to feature values extracted from the sensor data for the detected hand movement event. In some aspects, the machine learning model is an ensemble of models, such as a gradient boosting or random forest classifier. Aspects of the present disclosure may therefore include training a machine learning model(s) to detect whether a hand movement constitutes a scratching event or not.

Some embodiments of the present disclosure may further use detected scratching events to predict the likelihood that a user has scabies in a future time interval. Scratching patterns may be determined based on detected scratching events over a period of time. In some embodiments, the time period may be 24 hours, but it is contemplated that other time periods, such as 3 days or 5 days, may be used. Additional contextual information may be determined, for example, temperature and/or humidity levels at the user's location for the period of time during which scratching events are detected. Additionally, a prediction of temperature and/or humidity levels for a future time interval can be determined. Based on the scratching pattern and contextual information, the likely level of scabies for a future time interval can be determined. Additionally, some embodiments may predict a likely flushing event for a user by determining whether or not the predicted level of scabies is of sufficient severity to rise to a flushing event level. Determining the likelihood of a future scabies event may be determined by comparing the predicted scabies level to one or more scabies threshold levels.

Some embodiments may trigger an action based on the predicted level of scabies, and in some cases, a flushing event, during a future time interval. Initiating an action may include generating a notification regarding scabies or flushing to the patient or physician treating the monitored patient, adding the predicted level of scabies and/or flushing event to an electronic calendar for a future time slot, and/or providing one or more recommendations. The recommendation may be to initiate treatment, continue treatment, or modify treatment for the monitored patient. Additionally, the recommendation may be that the monitored patient schedule a consultation with a physician.

Additional aspects of this disclosure include detecting whether a tracked user is asleep or not using sensor data. Similar to some embodiments of comb event detection, sensor data obtained during times in which a configuration for proper data acquisition is detected and/or the user's sleep ability can be used to determine whether the user is asleep or not. The sensor data may be used to determine activity index values for time windows, and a combination of activity index values, eg, a weighted sum, may be compared to a sleep threshold to detect whether the user is sleeping or not. Determinations of periods of time during a user's sleep opportunity when the user is awake rather than asleep can be used to determine an overall sleep score that provides an indication of the user's sleep quality over a specified period of time, such as one night. In some aspects, the sleep score may further be determined based on detected scratching events, since a greater number of scratching events during a user's sleep opportunity may indicate lower sleep quality.

Brief description of drawings

Aspects of the disclosure are described in detail below with reference to the accompanying drawings, in which:

Fig. 1 is a block diagram of an exemplary operating environment suitable for implementing aspects of the present disclosure;

Fig. 2 is a diagram illustrating an exemplary computing architecture suitable for implementing aspects of the present disclosure;

Fig. 3A and 3B illustratively show the use of embodiments of the present disclosure;

Fig. 4A exemplarily shows a flowchart of an exemplary method for comb detection, in accordance with an embodiment of the present disclosure;

Fig. 4B exemplarily shows a schematic diagram of sensor wearing detection, in accordance with an embodiment of the present disclosure;

Fig. 4C exemplarily shows a schematic diagram of determining the sleep capability of a user, in accordance with an embodiment of the present disclosure;

Fig. 4D exemplarily shows a schematic representation of an exemplary process for detecting periods of sleep and wakefulness of a user, in accordance with an embodiment of the present disclosure;

Fig. 4E illustratively shows a schematic representation of exemplary aspects of a scratch detection process, in accordance with an embodiment of the present disclosure;

Fig. 4F exemplarily shows a schematic representation of an example process for providing decision support based on combing events, in accordance with an embodiment of the present disclosure;

Fig. 4G exemplarily shows a schematic representation of an exemplary process for treating itching using a motion sensing device associated with a subject, in accordance with an embodiment of the present disclosure;

Fig. 4H exemplarily shows a schematic representation of an exemplary process using scratch detection, in accordance with an embodiment of the present disclosure;

Fig. 5 exemplarily shows a flowchart of an exemplary redness prediction method, in accordance with an embodiment of the present disclosure;

Fig. 6A exemplarily shows a schematic representation of training an exemplary scratch detector, in accordance with an embodiment of the present disclosure;

Fig. 6B exemplarily shows a graphical representation of feature selection for an exemplary scratch detector, in accordance with an embodiment of the present disclosure;

Fig. 6C exemplarily shows a performance validation representation of an exemplary scratch detector, in accordance with an embodiment of the present disclosure;

Fig. 6D exemplarily shows a representation of statistical characteristics of exemplary scratch detectors, in accordance with an embodiment of the present disclosure;

Fig. 6E exemplarily shows a performance representation of an example sleep capability determination module, in accordance with an embodiment of the present disclosure;

Fig. 6F illustrates a performance validation representation of an exemplary sleep capability determination algorithm, in accordance with an embodiment of the present disclosure;

Fig. 7A exemplarily shows a schematic representation of signals indicating detected hand movement, in accordance with an embodiment of the present disclosure;

Fig. 7B exemplarily shows a schematic diagram of detection of continuous sleep and night scratching, in accordance with an embodiment of the present disclosure;

Fig. 8A-F illustratively show exemplary screenshots from a computing device showing aspects of exemplary graphical user interfaces (GUIs), in accordance with embodiments of the present disclosure;

Fig. 9A-I illustrate an exemplary embodiment of a computer software routine for detecting scratching and sleep, in accordance with embodiments of the present disclosure;

Fig. 10A-I illustrate an exemplary embodiment of a computer software routine for comb detection, in accordance with embodiments of the present disclosure;

Fig. 11A-M illustrate an exemplary embodiment of a computer software routine for sleep detection, in accordance with embodiments of the present disclosure; And

Fig. 12 is a block diagram of an example computing environment suitable for use in implementing an embodiment of the present disclosure.

Detailed Description of the Invention

The subject matter of the present disclosure is described herein with specificity in various aspects to satisfy mandatory requirements. However, the description itself is not intended to limit the scope of protection of this patent. The claimed subject matter may be carried out in other ways such that it includes various steps or combinations of steps similar to the steps or combinations described in this present disclosure, in combination with other current or future technologies. Moreover, although the terms "step" and/or "block" may be used herein to mean various elements of the methods used, the terms should not be interpreted as implying any distinct order for/between the various steps disclosed herein , unless and until the order of the individual steps is stated explicitly. Each method described herein may include a computation process that may be performed using any combination of hardware,

firmware and/or software. For example, various functions may be performed by a processor executing instructions stored in a storage device. The methods may also be implemented as computer-applicable instructions stored on computer storage media. The methods may be provided through, but not limited to, a stand-alone application, service, or hosted service (standalone or in combination with another hosted service) or a plug-in for another product.

Aspects of the present disclosure relate to computerized decision support tools for predicting scratching and blushing events. Affecting approximately 10% of adults and 12% of children in the United States, atopic dermatitis is a chronic, relapsing-remitting skin disease that is characterized by red, scratchy lesions on the skin with itching (itching). People who experience itching typically scratch the affected skin, which increases the inflammation that causes itching and exacerbates the itch and scratching cycle. For many people with atopic dermatitis, itching peaks at night, leading to sleep disturbances. Not only does the physical act of scratching interrupt sleep, but scratching has also been shown to initiate cognitive and behavioral changes that lead to and worsen insomnia and sleep interruptions. Additionally, epidermal damage treated with anti-scratch medications can lead to inflammatory reactions that interrupt the circadian rhythm.

Traditional assessments of itch-associated disease such as atopic dermatitis have traditionally been subjective, anecdotal, and provide poor measures of the impact of atopic dermatitis. For example, one traditional tool is the clinical outcome assessment (COA), which involves a physician's assessment of the total body surface area of the injury and the severity of the injury. COAs are subjective in that their assessments vary among physicians and are anecdotal in nature, as they can only be assessed while the individual is being seen by a physician. Another traditional instrument is the patient-reported outcome (PRO), which is a qualitative and subjective report from the patient regarding the severity of itch. Such PROs may include the Patient Global Impression Severity subscale (PGIS), Peak Pruritus Numeric Rating Scale (ppNRS), Severity of Itch Score (SPS), Dermatology Life Quality Index (DLQI), Family or Children's DLQI (FDLQI). /CDLQI), Medical Outcome Study (MOS) Sleep Disorder Severity Scale, Patient-Centered Eczema Assessment (POEM), PROMIS Pain Impact Scale, and PROMIS Anxiety Scale. PROs may lack accuracy due to treatment noncompliance, recall bias, and daily fatigue.

Attempts to provide an objective assessment are made through the use of recurrent neural networks to detect scratching from sensor data. However, these current instruments require two sensors (one on each wrist of the user or patient), thereby increasing patient burden, the potential for user non-compliance, and inaccurate results due to difficulties associated with timing alignment between the two sensors. and the likelihood that one of the sensors is not configured properly. Additionally, current machine learning systems' attempts to detect scratching do not focus on detecting scratching during sleep opportunities. As explained above, itching peaks at night and can interrupt sleep, and as such, traditional solutions that do not detect scratching events in the context of sleep may not provide an accurate assessment of the current itching state. Additionally, traditional instruments do not predict future scabies or erythema events and therefore have limited ability to provide preventative therapeutic measures.

To improve accuracy and reliability, embodiments of the present disclosure result in improved computer decision support tools by detecting scratching and, in some aspects, predicting bruising events that are likely to occur in the future from continuous sensor data invisibly acquired through sensing. device worn by the user. Due to this, the information used to detect scratching is not episodic in nature. Additionally, some embodiments of a sensor device, for example a wrist-worn device, are less invasive than traditional technologies requiring the user to sleep in a controlled, monitored environment, which results in a greater likelihood of compliance with treatment requirements by the user and, in particular, , is well adapted for use in populations that traditionally do not adhere strictly to treatment requirements, such as children. In some aspects, only one sensor device is worn by the user being tracked (interchangeably referred to herein as the "patient") to further reduce the potential burden on users.

Additionally, feature values extracted from the sensor data can be used to detect scratching using one or more machine learning classifiers, thereby eliminating subjectivity. Embodiments may detect scratching from sensor data acquired at night or while the user is sleeping, making it easier to track scratching during peak itch times or when the user is unaware of scratching. Additionally, the likelihood that a user will experience a certain level of scabies or redness event in the future can be predicted from patterns of detected scratching events. Detected scratching events and/or predicted future level of scabies and/or redness events can be fed into computerized decision support tools to accurately and timely monitor atopic dermatitis symptoms and initiate interventional and/or therapeutic treatments to alleviate or prevent worsening of symptoms .

At a high level, a sensor device worn by the user can receive sensor data in order to detect scratching. In exemplary aspects, the sensor data is accelerometer data captured through a wearable sensor located on or around the user's wrist. From the sensor data, a two-layer approach can be used to detect scratching. In some embodiments, a hand movement event may be detected, and sensor data detected in the hand movement event may then be classified as a scratching event.

In some aspects, before hand movement is detected, context is determined to narrow the scope of sensor data for hand movement analysis. In some aspects, the context includes detecting whether or not the sensing device is capable of properly acquiring data, which is more likely to result in accurate detection of hand movement and scratching events. For example, detecting whether or not a touch device is capable of properly receiving data may include determining whether a wearable touch device, such as a wrist-worn device, is being worn by the user or not. In some implementations, this step includes determining not only whether the sensor device is worn or not, but also whether the way the device is worn makes it easier to capture the intended data. As described herein, determining that a sensor device is properly configured to receive data may include using sensed temperature information (e.g., the temperature around the user's body) and comparing the sensed temperature information to a predetermined threshold to determine whether whether the device is worn or not. In other implementations, this determination is made by applying a set of heuristic rules to statistical features of the motion data, such as standard deviations and/or ranges of the X, Y and Z variables in the accelerometer data. In some embodiments, a combination of variables, such as temperature and motion data, may be used to detect that the device is not being worn.

Additionally, in some aspects, the amount of data used to detect hand movement may further be narrowed down to data captured within the sleep capability or the interval in which the user intends to sleep. In this regard, embodiments of this disclosure may determine the possibility of sleep. Sleep opportunity can be identified by comparing changes in forearm flexion angles extracted from the sensed motion data with a sleep opportunity threshold value in order to detect possible variations in sleep opportunity periods. In some embodiments, the longest group of possible sleep opportunity periods (which may exclude non-wearing periods) in a relevant time frame, eg, a 24-hour period, may be selected as the sleep opportunity.

Once a sleep opportunity is determined, motion data captured during a specific sleep opportunity can be used to detect hand movements and scratching events. Thus, embodiments may detect scratching at night (when the itching is at its peak), and/or when the user is asleep and less likely to be aware of the scratching. Fig. 3A illustrates an exemplary implementation of a scratch detection operation in which a scratch event is detected while the user is sleeping. As illustrated in FIG. 3A, a smart watch worn by a sleeping user can read motion data, detect a scratching event, and connect to a network such as a cloud to log the data.

In some embodiments, detecting hand movement includes segmenting sensor data within the user's sleep capability into time windows and applying a heuristic algorithm to each window to determine the presence of hand movement in each window. In some embodiments, a heuristic algorithm for detecting hand motion includes calculating a sliding coefficient of variation and determining whether or not that value satisfies a motion threshold.

Various embodiments of the disclosure may determine whether or not the movement of the hands corresponds to a scratching event. To detect a scratching event, feature values can be extracted from sensor data within windows defined as representing hand movement. In example aspects, the features are time domain features or frequency domain features. The extracted feature values may be passed through a scratch detector, which determines whether the detected hand movement represents a scratching event or not. In exemplary aspects, the scratch detector comprises an ensemble of machine learning models, for example, a random forest classifier. Aspects of entity discovery may include designing a scratch detector, which may include selecting and constructing features, and training one or more machine learning models. In some aspects, machine learning models are trained by using a leave-one-out-one-out (LOSO) ground truth process.

In some aspects, a detected scratch event may be recorded and an action may be initiated based on one or more detected scratch events. For example, an alert or notification may be provided to the user, through a user interface on the user device, to notify the user regarding the scratching event(s). Additionally, data from detected scratching events can be processed for computer-implemented decision making. In one embodiment, scratch endpoint data may be determined from detected scratch events. For example, the total number of detected scratching events over a period of time, such as a 24-hour time period and/or the total duration of scratching within that period, can be determined. The total number of scratching events and/or the total duration of scratching may be used to trigger recommendations for the monitored individual to seek medical treatment or consultation with a physician. Additionally or alternatively, the total number of scratching events and/or the total duration of scratching may be used to provide a notification to a user device associated with the monitored person's physician. The total number of scratching events and/or the total duration of scratching may be added to the tracking application or service to represent scratching endpoints as associated with the time period for which they are detected. A scratch score may further be calculated based on detected scratching events and/or scratching endpoints and may be presented to the monitored user or clinician. Additionally, embodiments may determine the total number of scratching events and/or the total duration of scratching for multiple time periods to identify the severity of scratching over time and/or changes in patterns, any of which may be used to trigger an action. The scratching endpoints disclosed herein represent new digital endpoints that are useful in quantitative and objective measurement of itch or, more specifically, atopic dermatitis. This new type of data may be generated using the disclosed technology for comb monitoring, which may be accomplished using one or more wearable devices for continuous monitoring. Thus, the disclosed method of collecting data for measuring scratching results in new scratching endpoint data that is more accurate and applicable than traditional technologies for monitoring and treating the user because it provides a quantitative, accurate and objective measure. As stated above, this method of obtaining data used in creating scratch endpoints is particularly useful in populations with typically lower rates of treatment compliance, such as children.

Some embodiments of the disclosure may include detecting whether the tracked user is asleep and/or awake during the sleep opportunity. In this regard, similar to some embodiments of scratch detection, sleep can be detected by using sensor data acquired during times in which the sensor configuration for proper acquisition of data is detected (eg, when the sensor is worn) and within a certain sleep opportunity. Sleep detection may include determining activity index values for time windows based on sensed motion data (eg, accelerometer data), and a combination of multiple activity index values, e.g., a weighted sum, may be compared to a sleep threshold in order to detect that , the user is asleep or has a very high probability of being asleep or not. Determining periods during which a user is awake or asleep in the user's sleep capability may be used to determine an overall sleep score that provides one or more measures of the user's sleep over a specified period of time, such as one night. In some aspects, the sleep score may further be determined based on the number of scratching events detected, since a greater number of scratching events during a user's sleep opportunity may indicate lower sleep quality.

Additional embodiments of the present disclosure use detected scratching events to predict the likelihood that a user has scabies in a future time interval. Comb patterns may be assembled based on statistical comb events over a period of time. Additional contextual information may be determined and used for this prediction, such as ambient air temperature and/or humidity levels at the user's location. This context information may be statistical context information such that it may provide insight such that a scabies or rash predictor may be trained and current or predicted context information may be input to the predictor. Based on the scratching pattern and contextual information, the likely level of scabies for a future time interval can be determined. Additionally, some embodiments may predict a likely flushing event for a user by determining whether or not the predicted level of scabies is of sufficient severity to rise to a flushing event level. Determining the likelihood of a future flushing event may include comparing the predicted scabies level to one or more scabies threshold levels, which may be based on a reference population or user-specific threshold(s) defined based on statistical user information and/or settings or preferences user or doctor.

Embodiments may trigger an action based on the user's predicted level of scabies and, in some cases, a flushing event, within a future time interval. Initiating action may include issuing a notification regarding the scabies or redness to the user or to a physician who is treating or expected to treat the user. Fig. ZV shows an example notice regarding redness provided in the implementation during operation. As illustrated in FIG. 3B, the user may receive an alert notification regarding redness indicating the likelihood of experiencing a particular level of scabies in the future and/or the risk of experiencing future redness. Receiving a notification regarding redness may prompt the user to go to a pharmacy to purchase medicinal products to treat or reduce potential redness.

Additionally or alternatively, triggering an action may include adding the detected scabies level and/or flushing event to an electronic calendar for a future time slot, thereby allowing the user to track predicted scabies levels and future flushing events. Additionally, the action may include providing one or more recommendations. The recommendation may be to initiate treatment, continue treatment, and/or modify existing treatment. For example, while at work, the user may accept a recommendation to purchase or refill medications to reduce or reduce the predicted risk of flushing. Additionally, the recommendation may be that the user schedule a consultation with a physician.

Among others, benefits of embodiments of the disclosure include providing an itch score (based on scratching) with greater accuracy and reliability (compared to traditional solutions) on a continuous (or semi-continuous, intermittent, on-demand or as available) data obtained in a manner that reduces user burden and increases user compliance with treatment requirements. For example, studies show that scabies, when measured subjectively, does not have a high correlation with nighttime scratching, and scabies has a lower correlation with the severity of atopic dermatitis than objective measures of scratching as determined in accordance with embodiments herein. In this regard, embodiments can be used to more effectively treat and comprehensively manage itch or atopic dermatitis compared to traditional subjective measures. Additionally, applying machine learning classifiers to sensor data to detect scratching events eliminates bias and subjectivity, further improving accuracy and reliability. These classifiers help provide reliable computer decision support tools that are based on detected scratching data, thereby improving recommendations for treatment and/or response to scratching. Compared to other approaches to scratch detection using recurrent neural network, some embodiments of this disclosure use a gradient boosting or random forest classifier and provide results that are more interpretable compared to recurrent neural network approaches, and in this makes them better able to be modified or refined for specific contexts. These embodiments may further be faster and less computationally intensive on computing systems. Additionally, embodiments provide predictions of scabies and, to some extent, erythema events in the future, so as to better help the monitored user make informed decisions regarding treatment, and/or to help the user's physician provide medical care according to the condition through preventive treating the skin in a way that reduces the risk of itchiness or redness. An additional benefit may result from embodiments that determine the user's sleep capability and measure scratching within the determined sleep capability. As stated above, scratching can very often interrupt a user's sleep, and as such, tracking scratching during sleep opportunities can more reliably lead to effective measures to improve the user's sleep.

It can be appreciated that embodiments of this disclosure may comprise a tracking application or service that tracks scratching events overnight in an accurate manner with limited user burden. Such tracking, which includes alerts, notifications and recommendations, can encourage better treatment compliance on the part of the user. Accurate and non-sporadic tracking over time can also enable the clinician to make informed decisions regarding the treatment of the person being tracked. Thus, embodiments of this disclosure may be required for both the person being tracked and the treating physician in the form of a tracking service. In addition, use of the tracking service may be part of a prescription and/or physician treatment plan for a person who suffers from itching or is prescribed a drug that lists itching as a known potential side effect. For example, a physician may prescribe a cream to a patient suffering from itching, with instructions to apply the cream every other day and to use an embodiment of the disclosed tracking application or service. Based on scratching event data obtained for the patient over the next few weeks, it may be determined that scratching is not improving and the physician may determine the need to change the prescribed course of treatment.

Turning now to FIG. 1, a block diagram is provided showing an exemplary operating environment 100 in which some embodiments of the present disclosure may be used. It should be understood that this and other arrangements described herein are provided as examples only. Other arrangements and elements (eg, machines, interfaces, functions, commands and function groupings) may be used in addition to or instead of the arrangements and elements shown in FIG. 1 as well as other drawings, and some elements may be omitted altogether for the sake of clarity. Additionally, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components and in any suitable combination and location. Various functions or operations described herein are performed by one or more entities including hardware, firmware, software, and combinations thereof. For example, certain functions may be performed by a processor executing instructions stored in a storage device.

Among other components (not shown), the exemplary operating environment 100 includes a number of user devices, such as user computer devices 102a, 102b, 102c-102n and physician user device 108; one or more decision support applications, for example, decision support applications 105a and 105b; electronic health record 104 (EHR); one or more data sources, for example, data warehouse 150; server 106; one or more sensors, for example, sensor(s) 103; and network 110. It should be understood that the operating environment 100 shown in FIG. 1 is an example of one suitable operating environment. Each of the components shown in FIG. 1, for example, may be implemented through any type of computing device, for example, through the computing device 1200 described in connection with FIG. 12. These components may communicate with each other through network 110, which may include, but is not limited to, one or more local area networks (LANs) and/or wide area networks (WANs). In exemplary implementations, network 110 comprises the Internet and/or a cellular network, among any of a variety of possible public networks and/or private networks.

It should be understood that any number of user devices, servers, decision support applications, data sources, and EHRs may be used in the operating environment 100 within the scope of the present disclosure. Each element may contain one device or component, or multiple devices or components interacting in a distributed environment. For example, server 106 may be provided through multiple devices hosted in a distributed environment that together provide the functionality described herein. Additionally, other components not shown herein may also be included in the distributed environment.

The user devices 102a, 102b, 102c-102n and the physician user device 108 may be client user devices on the client side of the operating environment 100, while the server 106 may be on the server side of the operating environment 100. The server 106 may include server software, designed to operate in conjunction with client software on user devices 102a, 102b, 102c-102n, and 108 so as to implement any combination of features and functionality explained in this disclosure. This separation of the operating environment 100 is provided to illustrate one example of a suitable environment, and it is not necessary that any combination of server 106 and user devices 102a, 102b, 102c-102n and 108 need to remain as separate entities.

User devices 102a, 102b, 102c-102n and 108 may comprise any type of computing device capable of being used by the user. For example, in one embodiment, user devices 102a, 102b, 102c-102n and 108 may be the type of computing devices described with respect to FIG. 12 herein. By way of example, and not limitation, the user device may be a personal computer (PC), a laptop computer, a mobile device or mobile device, a smartphone, a smart speaker, a tablet computer, a smart watch, a wearable computer, a personal digital device (PDA), music player or MP3 player, global positioning system (GPS) or GPS-based device, video player, handheld communications device, gaming device, entertainment system, vehicle computer system, integrated system controller, camera, remote control, appliance, consumer electronic device, workstation, or any combination of these specified devices, or as any other suitable computing device.

Some user devices, for example, user devices 102a, 102b, 102c-102n, may be designed for use by a user who is being monitored through one or more sensors, for example, through sensor(s) 103. In some embodiments, the user device may include incorporate an integrated sensor (similar to sensor 103) or operate in conjunction with an external sensor 103. In other exemplary aspects, sensor 103 may be positioned on or near the wrist of the user being tracked. It is contemplated that the sensor 103 may alternatively be positioned on or near a part of the body (eg, on or near the user's head, attached to the subject's clothing, worn around the subject's head, neck, leg, forearm, ankle, finger, etc.). In other aspects, the sensor 103 may be, for example, a skin patch sensor adhered to the skin of the subject; ingestible or subdermal sensor; sensor components integrated into the subject's living environment (including bed, pillow or bathroom); and sensors operating with or through a smartphone carried by the subject. In one embodiment, the user device comprises a sensor-integrated wrist-worn computing device, such as a smart watch or tablet computer, that is operably coupled to a source of sensor data.

In exemplary embodiments, sensor 103, such as a gyroscopic or accelerometer sensor, senses motion information. For example, sensor 103 may include a wearable accelerometric sensor, which may be implemented on a wristband device in the form of a fitness tracker, smart watch, and/or smart mobile device. Other types of sensors may also be integrated into or operate in conjunction with user devices, for example, sensors configured to detect ambient light (eg, a photodetector); sensors configured to detect the location of a user (eg, based on an indoor positioning system (IPS) or a global positioning system (GPS)); sensors configured to detect ambient air information (eg, a thermometer, hygrometer, or barometer); and physiological sensors (eg, sensors that detect pulse, blood pressure, core body temperature, surrounding body temperature, or galvanic skin response (GSR)). Some embodiments include multiple sensors 103, for example, three sensors, to receive accelerometer data, ambient light data, and temperature data (eg, temperature around the body). Some embodiments of sensors 103 may include sensors that measure information to be used to track fine movement of a finger, such as electromyography (EMG) to measure muscle activation, acoustic monitoring, and/or vibration transducers. However, it is contemplated that physiological information regarding the person being tracked, according to embodiments of the disclosure, may also be received from statistics of the person being tracked in EHR 104 or from measurements of the person's vital signs or observations of the person's vital signs.

Data may be acquired by sensor 103 continuously, periodically, as needed, or as available.

Additionally, data obtained by sensor 103 may be associated with time and date information and may be represented as one or more time series of measured variables. In an embodiment, sensor 103 collects raw sensor information and performs signal processing, variable decision statistics generation, cumulative summation, trending, wavelet processing, thresholding, computational decision statistics processing, decision statistics inferential processing, preprocessing and/or or signal conversion and matching. Alternatively, one or more of these functions may be performed by a user device, such as user device 102c or physician user device 108, server 106, and/or decision support applications 105a or 105b.

Some user devices, for example, physician user device 108, may be intended for use by a physician who is treating or otherwise monitoring a user associated with sensor 103. Physician user device 108 is operably connected via network 110 to EHR 104. Operating environment 100 illustrates indirect functional connection between the physician user device 108 and the EHR 104 via the network 110. However, it is contemplated that an embodiment of the physician user device 108 may be functionally connected to the EHR 104 directly. An embodiment of a physician user device 108 includes a user interface controlled by a software application or set of applications on the physician user device 108 . In an embodiment, the application is a web application or applet. In accordance with embodiments presented herein, an application for health care providers (physicians) may facilitate accessing and receiving information from a physician regarding a specific patient or set of patients for whom scratching events, future scabies levels, and/or sleep are being detected. Embodiments of physician user device 108 also facilitate accessing and receiving information from a physician regarding a specific patient or population of patients, including the patient's medical history; health resource data; physiological variables (eg, vital signs), measurements, time series, predictions (including illustration or display of a particular result and/or alarm) described herein; or other medical information. The physician user device 108, for example, further facilitates the display of results, recommendations, or prescriptions. In an embodiment, physician user device 108 facilitates patient prescriptions based on monitoring and prediction results.

The physician user device 108 may also be used to provide diagnostic services or evaluate the performance of the technology described herein in combination with various embodiments.

Embodiments of decision support applications 105a and 105b comprise a software application or set of applications (which may include programs, procedures, functions, or computer-executable services) residing on a client computing device, one or more servers in a cloud, distributed in a cloud environment or on a client computing device, such as a personal computer, laptop, smartphone, tablet computer, mobile computing device, or external interface terminals that communicate with internal interface computing systems. In an embodiment, decision support applications 105a and 105b include web applications or a set of applications useful for managing user services provided by

through an embodiment of the invention. For example, in an embodiment, each of the decision support applications 105a and 105b facilitates the processing, interpretation, access, storage, retrieval, and communication of information received from user devices 102a-n and 108, sensor 103, EHR 104, or data store 150. including predictions and estimates determined through embodiments of the invention.

Accessing and/or using information through decision support applications 105a and 105b or using associated functionality may require a user, such as a patient or physician, to log into an account with credentials. Additionally, decision support applications 105a and 105b may store and transmit data in accordance with privacy settings set by a physician, a patient, an associated healthcare facility or system, and/or applicable local and federal rules and regulations regarding the security of health information, for example, Health Insurance Portability and Accountability Act (HIPAA) rules and regulations.

In an embodiment, decision support applications 105a and 105b may send a notification (eg, an alarm or other indicator) directly to physician user device 108 or user devices 102a-n via network 110. Decision support applications 105a and 105b may also send maintenance indicators to the physician user device 108 or user devices 102a-n. Additionally, an interface component, for example, may be used in decision support applications 105a and 105b to facilitate user (including a physician/caregiver or patient) access to functions or information regarding the sensor 103, such as functional settings or parameters, user identification data, user data stored on the sensor 103, and diagnostic services or firmware updates for the sensor 103.

Additionally, embodiments of decision support applications 105a and 105b may collect sensor data directly or indirectly from sensor 103 and use sensor data to detect scratching events, future forecast scabies levels and flushing events and/or detect sleep, as described in more detail regarding Fig.2. As used herein, a erythema event may refer to an acute itching phase in which the level of scabies and/or one or more additional symptoms (eg, red skin, peeling skin, lesions) may exceed a threshold level. In one aspect, decision support applications 105a and 105b may display the results of such processes to the user through a user device, for example, through user devices 102a-n and 108, including through the exemplary graphical user interfaces (GUIs) illustrated in FIG. 8A. -F. Thus, the functionality of one or more of the components explained below with respect to FIG. 2 may be performed by computer programs, procedures, or services that are part of or otherwise controlled by decision support applications 105a and 105b. Additionally or alternatively, decision support applications 105a and 105b may include decision support tools, for example, decision support tool(s) 270 of FIG.

As mentioned above, the operating environment 100 includes one or more EHRs 104 that may be associated with the person being tracked. EHR 104 may directly or indirectly operably connect to user devices 102a-n and 108 via network 110. In some embodiments, EHR 104 represents medical information from other sources and may be implemented as various record storage systems, for example, as separate EHRs -systems for various user devices of the doctor (for example, 108). As a result, physician user devices can be tailored to physicians across different provider networks or care organizations.

Embodiments of the EHR 104 include one or more health record data stores, which may be stored in the data store 150, and may further include one or more computers or servers that facilitate storing and retrieving health records. In some embodiments, EHR 104 may be implemented as a cloud platform or may be distributed across multiple physical locations. EHR 104, for example, may further include chart storage systems that store patient (or user) information in real time or near real time, such as wearable, bedside, or home patient monitors.

Data store 150 represents one or more data sources and/or data communication and processing systems that are configured to make data available to any of the various components of the operating environment 100 or system 200 described in connection with FIG. 2. For example, in one embodiment, data store 150 provides (or makes available for access) sensor data that can be accessed by data acquisition component 210 of FIG. 2. The data store 150 may be discrete with respect to the user devices 102a-n and 108 and the server 106, or may be included and/or integrated with at least one of these components.

The operating environment 100 may be used to implement one or more components of the system 200 (described in FIG. 2), including components for collecting sensor data or user-related data; detection of scratching events; predicting future events of scabies and redness; sleep detection; and implementing one or more decision support tools. The operating environment 100 may also be used to implement aspects of methods 400 and 500, as described in conjunction with FIGS. 4A and 5, respectively.

Referring now to FIG. 2 and with further reference to FIG. 1, a block diagram is provided showing aspects of the architecture of an exemplary computing system suitable for implementing an embodiment of the present disclosure and referred to generally as system 200. System 200 represents only one example of a suitable computing system architecture. Other arrangements and elements may be used in addition to or instead of the arrangements and systems shown, and some elements may be omitted altogether for the sake of clarity. Additionally, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components and in any suitable combination and location.

An exemplary system 200 includes a network 110, which is described in connection with FIG. 1, and which operably connects components of a system 200 including a data acquisition component 210, a presentation component 220, a scratch detector 260, a sleep/wake detector 230, a blush predictor 290. , a decision support tool 270, a sensor monitor 280, and a data storage device 250. One or more of these components, for example, may be implemented as a set of compiled computer instructions or functions, program modules, computer program services, or a process arrangement running on one or more computer systems, such as the computing device 1200 described in connection with FIG. .12.

In one embodiment, functions performed by components of system 200 are associated with one or more decision support applications, services, or procedures (eg, decision support applications 105a-b of FIG. 1). In particular, such applications, services, or procedures may run on one or more user devices (eg, user computing device 102a and/or physician user device 108), servers (eg, server 106), distributed over one or more user devices and servers or implemented in a cloud environment (not shown). Additionally, in some embodiments, these components of the system 200 may be distributed over a network connecting one or more servers (eg, server 106) and client devices (eg, user computer devices 102a-n or physician user device 108), in cloud or may be permanently hosted on a user device, for example, on any of the user computing devices 102a-n or the physician user device 108. In addition, the functions performed by these components or the services performed by these components may be implemented at the appropriate abstraction level(s), for example, at the operating system level, at the application level, at the hardware level, and the like. computing system. Alternatively or in addition, the functionality of these components and/or embodiments described herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application standard products (ASSPs), systems on chip (SOCs), complex field programmable logic devices (CPLD), etc. Additionally, although functionality is described herein in relation to specific components shown in the exemplary system 200, it is contemplated that in some embodiments the functionality of these components may be shared or distributed among other components.

Continuing with FIG. 2, data acquisition component 210 may generally be responsible for accessing or receiving (and in some cases identifying) data from one or more data sources, for example, data from sensor 103 and/or data store 150. 1 to be used in embodiments of the present disclosure. In some embodiments, data collection component 210 may be used to facilitate the accumulation of sensor data obtained for a specific user (or in some cases, for multiple users, including crowdsourced data) for other components of system 200, such as detector 260 scratching, sleep/wake detector 230 and/or redness predictor 290. Data may be received (or accessed) and accumulated, reformatted and/or combined by data acquisition component 210 and stored in one or more data stores, such as data storage device 250, where it may be made available to other components of system 200 For example, user data may be stored in or associated with a personal card 240, as described herein. Additionally or alternatively, in some embodiments, any personally identifiable data (i.e., user data that specifically identifies individual users) is not downloaded, otherwise made available from one or more user data data sources, is not persistently stored, and/or is not become available to other components of the system 200. In some embodiments, the user may choose to begin or end the use of services provided through the technologies described herein and/or select which user data and/or which sources of user data should be used through these technologies.

Data used in embodiments of the present disclosure may be received from a variety of sources and may be available in a variety of formats. For example, in some embodiments, user data received through data collection component 210 may be sensed through one or more sensors (eg, sensor 103 of FIG. 1), which may be stored on or associated with one or more user devices ( for example, with user computing device 102a), servers (for example, with server 106) and/or other computing devices. As used herein, a sensor may include a function, procedure, component, or combination thereof for reading, detecting, or otherwise obtaining information, such as user data, from data store 150 and may be implemented as hardware, software, or both. , and more. As mentioned above, by way of example and not limitation, data that is read or determined from one or more sensors may include motion information, for example, accelerometer or gyroscope data; ambient lighting information, for example, photodetector information; location information, such as indoor positioning system (IPS) or global positioning system (GPS) data from a mobile device; ambient air information, such as temperature, humidity and/or air pressure; and physiological information, such as pulse, blood pressure, core body temperature, skin temperature or galvanic skin response. In some aspects, the sensor information collected by the data collection component 210 may include additional properties or characteristics of the user device (such as device status, charge data, date/time, or other information retrieved from the user device, such as a mobile device ); user activity information (e.g., application usage, online activities, online searches, voice data, such as automatic speech recognition, or transaction history), including, in some embodiments, user activity that occurs in more than one user account. device; user background; session logs; application data; contacts; calendar and schedule data; notification data; social media data; news (including popular or trending items in search engines or social networks); e-commerce activity (including data from online accounts such as Microsoft®, Amazon.com®, Google®, eBay®, PayPal®, etc.); user account(s) data (which may include data from user preferences or settings associated with an application or service in the form of a personal assistant); home sensor data; instrument data; vehicle signal data; traffic data; other wearable device data; other user device data (for example, device settings, profiles, network-related information (for example, network name or ID, domain information, workgroup information, connection data, Wi-Fi network data or configuration data, model number data, firmware, hardware, device pairings, for example when the user has a mobile phone paired with a Bluetooth headset, for example, or other network-related information)); payment or credit card usage data (which may include information from the user's PayPal® account); purchase history data (for example, information from Amazon.com® or the user's online pharmacy account); other sensor data that can be read or otherwise detected by the sensor component(s) (or other detector), including data extracted from the sensor component associated with the user (including location, motion, orientation, position, user access , user activity, network access, user device charge, or other data that can be provided by one or more sensor components); data derived from other data (for example, location data that may be derived from Wi-Fi, cellular, or Internet Protocol (IP) address data); and almost any other data source that can be read or determined as described herein.

In some aspects, data acquisition component 210 may provide data collected in the form of data streams or signals. A "signal" may be a feed or stream of data from a corresponding data source. For example, the user signal may be user data from a wearable device, a smartphone, a home sensor device, a GPS device (e.g., for location coordinates), a vehicle sensor device, a user device, a gyro sensor, an accelerometric sensor, a calendar service, an accounting email records, credit card accounts or other data sources. In some embodiments, data collection component 210 receives or accesses data continuously, periodically, or as needed. The data acquisition component 210 may acquire data at a predetermined sampling rate. In one example, data acquisition component 210 uses a sampling rate of 100 Hz for one or more data signals, such as an accelerometer signal, an ambient light signal, and a body temperature signal.

The sensor monitor 280 may generally be responsible for monitoring the collected data for information that may be used to detect scratching, predict redness (including predicting scabies), and/or detect sleep, which may include identifying and/or tracking symptoms (sometimes referred to herein as "variables"), such as motion or accelerometer data or other related contextual information. In an embodiment, sensor monitor 280 includes one or more applications or services that analyze information detected through one or more sensors integrated or operably coupled with user devices used by the user and/or cloud services associated with the user to determine the information movements and associated contextual information. For example, sensor monitor 280 may include a decision support application service, such as any of the decision support applications 105a-b of FIG. 1, or may be integrated as part of another application or program on a device operating in conjunction with the decision support application. decisions. Information regarding user devices associated with the user may be determined from user data defined accessible through data acquisition component 210 and provided to sensor monitor 280 or other components of system 200. In some embodiments, sensor monitor 280 operates on or in association with each user device. device associated with the person (or user) being tracked.

Additionally, sensor monitor 280 may determine current or near real-time information, such as motion information, and, in some embodiments, may also determine statistical motion information, which may be determined based on personal map 240. Additionally, in some embodiments, , the sensor monitor 280 may determine motion information, detected scratching data, predicted scabies/redness events, and detected sleep/wake periods (which may include statistical activity) from other similar users (i.e., crowdsourcing), as described above.

In some embodiments, information determined by sensor monitor 280 may be provided to scratch detector 260, redness predictor 290, and sleep/wake detector 230, including motion information obtained from a sensor (for example, from sensor 103 in FIG. 1 ), context (for example, current or future weather forecasts), and statistical context (statistical observations) for the person being tracked.

Some embodiments of sensor monitor 280 or subcomponents thereof may define a name or device identification (device identifier) for each device associated with a user. This information regarding the identified user device associated with the user may be stored in a user profile associated with the user, for example, in the user account(s)/device(s) 248 of the personal card 240. In an embodiment, the user devices may be queried, queried or otherwise analyzed to determine information regarding devices. This information may be used to determine a label or identification of the device (eg, a device ID) such that user interactions with the device may be recognized from the user data by the sensor monitor 280 . In some embodiments, users may advertise or register a device, for example, by logging into an account through the device, installing an application on the device, connecting to an online service that queries the device, or otherwise providing information regarding the device to the application or service. In some embodiments, devices that are logged into an account associated with the user, such as an email account, social network, or the like, are identified and determined to be associated with the user.

Continuing with the system 200 of FIG. 2, the brush detector 260 is generally responsible for using sensor data, for example, data accumulated by the data collection component 210 from the sensor 103, to detect the brushing of a person being tracked. As described herein, a scratch event detected by the scratch detector 260 may be stored in a tracked person's record, for example, statistical scratch events 244 of personal record 240. Statistical scratch events 244 may be used to make predictions regarding the person's future behavior. for example, a future level of scabies or a flushing event, by a flushing predictor 290 and/or may be provided to one or more decision support tools 270. In some embodiments, the scratch detector 260 may run on a client computing device, on a server, in a distributed application across multiple devices, or in a cloud environment.

At a high level, an embodiment of scratch detector 260 may use sensor data from a person being tracked to detect the movement of the person's hands and classify that hand movement as a scratching event or not. In some implementations, the sensor data considered for hand movement detection is data acquired during the period in which the sensor 103 is properly worn. Additionally, an embodiment of the scratch detector 260 detects nighttime scratching by detecting scratching events in the user's sleep opportunity, which is a period of time when the user intends to sleep.

As shown in FIG. 2, embodiments of the scratch detector 260 may include a sensor wearing detection module 261, a sleep capability detection module 262, a hand movement detector 264, a feature extraction module 266, and a scratching event classifier(s) 268. Sensor wear detection module 261 may generally be responsible for determining when a sensor (eg, 103) receiving motion data for embodiments of scratch detector 260 (or other components of system 200) is being worn by a tracked user. In exemplary embodiments, sensor wear detection module 261 specifically determines when sensor 103 is worn in a configuration to provide reliable data. Configuration to provide reliable data may include being appropriately located on or in close proximity to the person being tracked. For example, in an embodiment in which the sensor on the bracelet receives the wearer's motion data, the sensor wear detection module 261 may determine that the bracelet is being secured around the wearer's wrist. Determining when the sensor is properly worn helps provide embodiments of scratch detector 260 using motion data in the intended context (eg, around the user's wrist) to detect scratching events.

In exemplary embodiments, the sensor wearing detection module 261 may automatically detect when the sensor 103 is worn using data received from the sensor 103 or another sensor (not shown). For example, the sensor wearing detection module 261 can automatically detect when the motion data capturing sensor 103 is worn using motion data, physiological data such as human body temperature, pulse, blood pressure, pulse, galvanic skin response, etc. ., received from the sensor on the device receiving the motion data. Alternatively, the sensor wearing detection module 261 may determine when the device is being worn based on a hand-held indicator from the wearer. For example, the wearer may input an indicator when the device is being worn and when it is being removed. Alternatively, the wearer may enter times corresponding to these events.

Accordingly, in one embodiment, sensor wear determination module 261 determines a configuration of non-wear periods by comparing statistical measurements of motion data over time windows with a non-wear threshold. For example, accelerometer data, which may contain X-, Y-, and Z-axis measurements, can be divided into time windows, and statistical measurements can be calculated and used with one or more heuristic rules to determine a wearing configuration or a non-wearing configuration. In an exemplary embodiment, the accelerometer data may be divided into multiple one-hour windows with a 15-minute overlap. The non-wearing definition may be a vector of binary values representing the wearing/non-wearing configuration for each motion data window. The window in which a period of non-wear is not detected can be considered a period of wear.

In an exemplary embodiment, the sensor wear detection module 261 may determine whether the sensor 103 is in a wearable configuration or not during a time window by comparing statistical features of the motion data in the window with a predetermined threshold value. For example, in an embodiment, the sensor wearing determination module 261 determines whether or not the standard deviation of any of the three-axis (X-axis, Y-axis, or Z-axis) signals of the accelerometer data in the window satisfies the non-wearing motion threshold, and if Yes, this window is defined as "non-wearing". In an exemplary embodiment, the non-worn motion threshold is 0.001 g, and the sensor wear determination module 261 determines that the window is “not worn” if the standard deviation of the values of any axes is less than the non-worn motion threshold.

In another exemplary embodiment, sensor wear detection module 261 may determine whether sensor 103 is in a wearable configuration or not by comparing the temperature during a window (or interval) of time with a temperature threshold when not worn. In one exemplary embodiment, the non-wearing temperature threshold is 25 degrees Celsius (i.e., 77 degrees Fahrenheit), and the sensor wearing determination module 261 determines that the window is “non-wearing” if the temperature during that window is less than temperature threshold for non-wearing.

Additionally, in exemplary embodiments, sensor wear determination module 261 considers both motion data and temperature data to determine whether a time window should be classified as “worn” or “not worn.” In one exemplary embodiment, sensor wear determination module 261 determines that the window is “unworn” if the temperature is less than the unworn temperature threshold (e.g., 25 degrees Celsius), or if the standard deviation of the values of any motion data axes in the window is less than motion threshold when not worn (eg, 0.001 g).

In some embodiments, several

Statistical features can be calculated on the motion data and compared with thresholds to determine whether a window represents a non-wear period or not. In one exemplary embodiment, if any two axes have a standard deviation that satisfies (i.e., less than) the non-wear motion standard deviation threshold, the period is defined as the non-wear window, or if any two axes have a range that satisfies (i.e., less than) .e. less) than the non-wearing range of motion threshold, the period is detected as the non-wearing window. In the example, the non-worn standard deviation threshold value of motion is approximately 0.013 g, and the approximate non-worn range of motion threshold value is 0.15 g.

In additional aspects, the above processes may provide an initial wear/unworn determination, and sensor wear determination module 261 may apply heuristic rule(s) to re-quantify one or more windows. Repeated quantification may help identify times at which interruptions in the data indicate that the device is not being worn, but contextual information, such as the duration of that interruption and accelerometer data occurring before or after, may indicate otherwise (i.e., may indicate that that the device is worn).

In an exemplary embodiment, the heuristic rules consider the durations of the wearing and non-wearing blocks to determine whether or not to switch the wearing/non-wearing determination for any of the time blocks. When used herein with respect to re-quantification by sensor wear determination module 261, time blocks may be consecutive windows with identical wearing or non-wearing classification. For example, three consecutive one-hour windows initially defined as “non-wear” form a three-hour block of non-wear. In an exemplary embodiment, sensor wear detection module 261 applies the following to re-quantify one or more windows:

- Rules 1 and 2 can be executed a certain number of times sequentially, for example, three times, and rule 3 can be executed only if the sensor wearing detection unit 261 operates with a predetermined data time, for example, with the last 24 hours of data.

- According to rules 1, 2 and 3, "current" means the current wear block being analyzed; "prev" means the previous block of non-wear; and "post" means the next non-worn block.

Rule 1: If current<3 hours, and (current/(prev+post)))<80%, the block is re-quantified from "worn" to "not worn".

Rule 2: If current<6 hours, and (current/(prev+post)))<30%, the block is re-quantified from "worn" to "not worn".

Rule 3: If current<3 hours, and prev≥1 hour, the block is re-quantified from "worn" to "not worn".

Additional details regarding an embodiment of the sensor wearing detection module 261 may be implemented as described below in conjunction with FIG. 4B.

Additionally, before determining, by the sensor wearing determination unit 261, a wearing configuration, the motion data may be preprocessed and filtered. For example, motion data may first be downsampled, for example, from 100 Hertz (Hz) to 20 Hz. Additionally, the data can be segmented into relevant time periods for which scratch analysis is detected. For example, the data may be divided into 24-hour segments (from 12:00 today to 12:00 the next day). Additionally, in some embodiments, any 24 hour period that does not have a minimum amount of recording time, for example, 6 hours, may be discarded and no longer analyzed by the scratch detector 260.

As part of the scratch detector 260, the sleep capability determination module 262 may generally be responsible for determining the user's sleep capability. As used herein, sleep opportunity refers to the time interval in which a person intends to sleep, which may or may not be consistent with when the person actually sleeps. Accordingly, in some embodiments, sleep opportunity represents the time between when a person lies down in a motionless state and gets up from a motionless state. The user's ability to sleep within a predetermined period may also be referred to as "total sleep capability (TSO)". For example, for a 24-hour period, people typically intend to fall asleep only once (for example, at night), and sleep opportunity determination module 262 may determine total sleep opportunity as the longest interval during that 24-hour period in which the user intends to be motionless.

Determining whether a user is sleeping may be used to focus sensor data in the context of nighttime or sleep scratching for subsequent processing by scratch detector 260 . For example, scratching detector 260 may detect nighttime scratching by specifically detecting scratching events based on motion data captured during a period of time determined to represent the user's sleep capability by sleep capability detection module 262 . The term "night time" is used herein to represent the typical period in which a person assumes the longest period of immobility; however, it is contemplated that embodiments of this disclosure are not limited to nighttime scratch detection. For example, some people, such as people who work in the evenings or throughout the night, may remain immobile or sleep the longest during the day, and the opportunity for sleep for such people may be a daytime interval.

The sleep capability determination module 262 may determine the sleep capability of a user for motion data captured over a predetermined period, for example, a 24-hour period. Exemplary implementations of sleep opportunity determination module 262 may employ a heuristic approach based on changes in forearm flexion angle determined from motion data to determine possible sleep opportunity periods. The largest consecutive group of possible stillness periods within a predetermined period (eg, 24 hours) may be selected as the user's sleep opportunity. In exemplary aspects, sleep capability determining module 262 may determine sleep capability using only motion data within a predetermined period in which sensor wearing is detected by sensor wearing determination module 261 while periods of non-wearing are excluded by sleep capability determination module 262 when identification of the largest group of possible variants of periods of immobility.

In some aspects, the forearm flexion angle is calculated from the accelerometer signals (X-axis, Y-axis, and Z-axis measurements), and the absolute difference between successive forearm flexion angle values (i.e., the change in forearm flexion angle over time) can be compared with immobility threshold. In an exemplary embodiment, a running median of the raw signal values (X-axis, Y-axis, and Z-axis measurements) is calculated over an interval (eg, 5 seconds), and the sliding median of the raw signal values is used to calculate the forearm flexion angle at according to the following formula, where a _x , a _y and a _z mean the accelerometer values along the X-axis, Y-axis and Z-axis, respectively, and:

The average forearm flexion angle may be calculated for an interval (eg, consecutive 5 seconds), and the absolute difference between successive average forearm flexion angle values may be calculated. A running median of the difference between successive mean forearm flexion angles can be calculated for an interval (eg, 5 minutes), and a running median of the difference between successive mean forearm flexion angles can be compared to an immobility threshold. The immobility threshold may be set by forearm flexion angle values measured for the person being tracked. For example, in one embodiment, a possible immobilization period is determined when the average difference between successive mean forearm flexion angle values is less than or equal to the immobility threshold, which may be specified as 0.15 times the 10th percentile value of all angle differences forearm flexion within a 24-hour period.

The sleep opportunity determination module 262 may determine the sleep opportunity based on the intervals identified as candidate periods of immobility. In the example, candidate periods with periods of detected non-wear are removed. The remaining possible immobility periods can be compared with a threshold length. In one implementation, the threshold length is 30 minutes, and possible immobility periods are kept if they are longer than 30 minutes. Additionally, candidate periods can be grouped if the gaps between periods satisfy a maximum duration. For example, candidate periods less than 15 minutes apart may be grouped together. In one example, sleep capability determination module 262 may determine the user's sleep capability as the longest group of possible periods within a 24-hour period. Additional details regarding an embodiment of the sleep capability determination module 262 are explained in detail below in conjunction with FIG. 4C.

Reliably detecting the sleep capacity within which scratching can be measured helps to effectively determine how a person's sleep and nighttime scratching vary on a daily basis. Embodiments of this disclosure may utilize a sleep capability that addresses difficulty falling asleep by not restricting the sleep capability to times when the user is actually asleep.

Other implementations of sleep capability determination module 262 may determine sleep capability from other sensor data. For example, in one embodiment, sleep opportunity determining module 262 may determine sleep opportunity using lighting information from the photo detector, and sleep opportunity may be determined as a period of time in which the amount of light remains below a threshold level for a minimum time period. Alternatively, physiological data such as heart rate, core body temperature, surrounding body temperature, blood pressure and/or respiratory rate captured from the monitored individual may be used to determine sleep potential. Additionally, in some aspects, sleep capability determination module 262 may determine sleep capability from user input. For example, the user may enter times corresponding to the moment when the user intends to fall asleep and wake up, or times corresponding to the moment when the user actually falls asleep and wakes up.

As stated above, embodiments of the scratch detector 260 use a two-layer approach to detect scratching events. In some embodiments, hand movements may be detected, and each detected hand movement may be classified as a scratching event or a non-scratching event. Hand motion detector 264 is generally responsible for detecting hand motion using information from motion sensors. Exemplary embodiments of hand motion detector 264 may receive (from sensor 103) motion sensor information, such as accelerometer data and/or gyroscopic data. In one embodiment, hand motion detector 264 may output a hand motion indicator for received data.

In example aspects, hand movement detector 264 may apply a heuristic algorithm to motion sensor data captured during a sleep opportunity, which may be determined by sleep opportunity determination module 262 . Motion sensor data, such as accelerometer data, may be segmented into windows of predetermined lengths, and the motion sensor data for each window may be passed through a hand movement detection heuristic algorithm to determine the presence of hand movement. An exemplary embodiment uses three second non-overlapping windows within the sleep opportunity for a given 24 hour period. For example, it is contemplated that other windows may be used, eg, a one-second window or a two-second window. In exemplary aspects, the hand movement detection algorithm includes calculating the vector absolute magnitude of a motion sensor signal (e.g., ). A low pass filter may be applied to the vector absolute value signal, in accordance with some embodiments. In an exemplary embodiment, the low pass filter has a cutoff of 6 Hz. The hand movement detection algorithm may further include calculating a running coefficient of variation (CoV) and applying a threshold to the calculated CoV values. As used herein, CoV means relative standard deviation, or the ratio of the standard deviation to the mean. Any values that satisfy the threshold (eg, greater than or equal to) can be determined to be hand movement. In some embodiments, this threshold value used is the 25th percentile of all calculated CoV values from the test data. In an exemplary embodiment, the CoV threshold value is 0.023.

The rolling CoV can be calculated for each second in a non-overlapping 3-second window. For example, for accelerometer data at 20 Hz or 20 samples per second, hand motion detector 264 can make 60 hand motion classifications for each non-overlapping 3-second window.

In an embodiment, hand movement may be detected for a given window if it is present for every second in that window using a CoV threshold. For example, hand movement detector 264 may detect hand movement for a three second window if movement is detected for each of the three seconds in that window.

Additional details regarding the hand motion detector embodiment are described in conjunction with FIG. 4E. Additionally, exemplary findings of an embodiment of hand motion detector 264 are illustrated in conjunction with FIGS. 6A and 7A.

Once the hand movement detector 264 identifies a hand movement event, the motion sensor information corresponding to the detected hand movement event may be considered a potential scratching event. In some embodiments, determining whether a hand movement event constitutes a scratching event or not may involve analyzing features in the motion sensor data. In one such embodiment, feature extraction module 266 may generally be responsible for extracting feature information that may indicate a scratching motion. Features may be extracted from motion sensor data corresponding to hand movement detected by hand movement detector 264 . In feature extraction, feature values can be calculated for each window (eg, a 3-second window) for which hand movement is detected.

Features may be extracted from one or more motion sensor data components in the form of a motion signal. For example, in some embodiments, the vector absolute value, the first principal component, and the second principal component of the accelerometer signal are used for feature extraction. Additionally, in some embodiments, a filter is applied to the motion sensor data prior to feature extraction. In one case, a high-pass filter with a cutoff of 0.25 Hz can be applied before feature extraction, which can help eliminate parameter drift and gravity. Alternatively, in another case, a bandpass filter may be used.

In exemplary embodiments, the features fall in the time domain or frequency domain. Exemplary embodiments of feature extraction module 266 may extract or calculate one or more of the following features:

- Root Mean Square (RMS) vector absolute value - RMS is a measure of signal energy and can be correlated with the magnitude and intensity of traffic;

Vector Absolute Magnitude Signal Range The signal range is a measure of extreme motion values observed in a given time window of sensor data, where a higher range may indicate the occurrence of a large deviation in sensor values;

- Entropy of vector absolute magnitude signals, first principal component and second principal component - the entropy of signals can be calculated by estimating the Shannon entropy of the signal's mass distribution function. Signal entropy values close to zero may indicate that the signal is periodic and smooth, while large negative values may indicate that the signal is irregular and non-periodic;

- Interquartile range (IQR) of the autocovariance of the vector absolute value, the first principal component and the second principal component - The autocovariance IQR is a measure of the dependence or long-range periodicity of a signal and can capture whether the signal is periodic or irregular or not;

Skewness of vector absolute value, first principal component and second principal component - skewness is a measure of asymmetry in the signal;

- Dominant frequency value of the first principal component and the second principal component - the dominant frequency value represents the frequency value with the largest absolute value in the normalized power spectrum of the accelerometer signal and captures the fundamental frequency of the root motion generating the acceleration signal;

- Absolute value of the dominant frequency of the first principal component and the second principal component - the absolute value of the dominant frequency captures the percentage of the total energy of the signals at the dominant frequency;

- Ratio of the dominant frequency band to the total energy in the spectrum of the first principal component and the second principal component - this feature captures the periodicity of the signal by calculating the ratio of the energy in the dominant frequency component to the sum of the energy in the entire frequency spectrum of the signal;

- The average cross-tempo of the vector absolute value, the first principal component and the second principal component, the average cross-tempo calculates the number of times the signal changes from positive to negative, and can be normalized by the total length of the signals;

The ratio of the sharp deviations of the vector absolute value, the first principal component and the second principal component - the ratio of the sharp deviations may represent a calculation of motion smoothness;

- Logarithmic dimensionless sharp deviation of the vector absolute value, the first principal component and the second principal component - this feature can also represent a calculation of the smoothness of movement;

- Spectral arc length measure (SPARC) of vector absolute magnitude, first principal component and second principal component - this feature may also represent a calculation of motion smoothness;

The permutation entropy of the vector absolute value, the first principal component, and the second principal component permutation entropy is a measure of the complexity of the signal;

Spectral smoothness of the first principal component and the second principal component - spectral smoothness captures the amount of modulation or level of consistency and can range from 0 to 1; And

The spectral entropy of the first principal component and the second principal component spectral entropy can be calculated by estimating the Shannon entropy of the signal's power spectrum mass distribution function, with values closer to 1 indicating the presence of white noise and values closer to O indicating the presence of periodicity in the signal.

In exemplary embodiments, each of the above 36 time and frequency domain features (wherein the vector absolute magnitude, first principal component, and second principal component features are separate features) may be extracted during training of the scratching event classifier(s) 268, and a subset of the features is selected for extraction by feature extraction module 266 at run time. For example, one embodiment of feature extraction module 266 extracts the following 26 time and frequency domain features: RMS (vector absolute magnitude); entropy of signals (vector absolute value, first principal component and second principal component); Autocovariance IQR (vector absolute value, first principal component and second principal component); skewness (first principal component and second principal component); the value of the dominant frequency (first principal component); absolute value of the dominant frequency (first principal component and second principal component); average cross-tempo (second principal component); ratio of sharp deviations (vector absolute value and second principal component); logarithmic dimensionless sharp deviation (first principal component); SPARC (vector absolute value, first principal component and second principal component); permutation entropy (vector absolute value, first principal component and second principal component); spectral smoothness (first principal component and second principal component); spectral entropy (second principal component); and signal range (vector absolute value).

Alternative embodiments of feature extraction module 266 may extract values for various combinations of the above and/or other features. Specific features to be extracted by feature extraction module 266 may be determined from feature selection and feature engineering. An exemplary process for feature selection is described in connection with FIGS. 6A and 6B.

Continuing with the scratch detector 260, the scratch event classifier(s) 268 are generally responsible for determining whether or not to classify the motion signal as a scratch event. Embodiments of the scratch event classifier 268 may use at least the extracted motion signal features (determined by feature extraction module 266) to output a classification of the motion signal as a scratch event or a non-scratch event (i.e., a non-scratch event). As explained above, extracted features may be extracted from windows (eg, 3-second windows) of the motion signal corresponding to the detected hand movement, such that a classification may determine whether the hand movement represents a scratching event or not.

In some embodiments, the scratch event classifier 268 may use the scratch event detection logic 256 in the data storage device 250 to determine whether the motion signal represents a scratch event or not. Brushing event detection logic 256 may include rules, conditions, associations, machine learning models, or other criteria for inferring or detecting the probability of a combing event based on motion sensor data. For example, scratching event detection logic 256 may determine, from accelerometer data, the likelihood that the detected movement is caused by the user scratching their body. The scratching event detection logic 256 can take various forms depending on the mechanism(s) used to detect the scratching. In some embodiments, the scratch event detection logic 256 may comprise fuzzy logic, neural network(s), finite state machine, support vector machine, logistic regression, clustering, other machine learning technologies, similar statistical classification processes, or combinations thereof. to identify likely scratching events. In particular, some exemplary embodiments of scratch event detection logic 256 may include one or more binary machine learning classifiers. The brush event detection logic 256 may comprise an ensemble of machine learning models. In one embodiment, scratch event detection logic 256 may be a random forest classifier. In another embodiment, gradient boosting may be used.

The model(s) generating the scratch event detection logic 256 may be trained in accordance with embodiments of this entity discovery. In one embodiment, scratch event classifier 268 is trained on annotated training data and validated using a leave-one-out (LOSO) process. Additional information regarding training is disclosed with reference to the embodiments described in connection with FIGS. 6A-F.

The comb event classifier 268 outputs an indicator of whether or not a comb event occurs using comb event detection logic 256 . In some embodiments, the output of the scratch event classifier 268 is binary, i.e. as a combing event or a non-combing event. Additionally or alternatively, the output may have a corresponding quantitative or qualitative indicator, such as a degree, absolute value, or level associated with the detected scratching event. The output of the comb event classifier 268 may also be a “number of comb events”, where if the number exceeds a threshold of comb events, then it is considered a comb event, and if not, then it is not considered a comb event. In some embodiments, the output of the scratch event classifier 268 is stored in the personal record 240 of the person being tracked. In particular, this information may be stored as statistical comb events 244 (in personal card 240), as shown in FIG. 2. An exemplary embodiment of a scratch event classifier 268 in the form of a computer program routine

illustrated in Fig. 10A-I.

Based on the detected scratching events, a number of scratching endpoints may be determined for each time period (e.g., a 24-hour period) for use by other components of the system 200, for example, by a redness predictor 290 and/or a decision support tool 270, such as described in more detail in this document. As used herein, the term "combing endpoint" means a quantifiable measure of brushing behavior that can be extracted from raw sensor data. In one exemplary embodiment, the total number of scratching events may be determined by summing the number of detected scratching events within the sleep capability determined for a certain period of time. Additionally, in some embodiments, the total scratch duration may be determined by summing the durations of detected scratch events, which may be provided in minutes. Additionally, the duration between different scratching events can be determined by summing the time between scratching events within the sleep capability. The duration ratio between scratch events and the number of scratch events can also be calculated. Transformations, such as a logarithmic transformation, can be applied to one or more combing endpoints. For example, the total number of scratches and the total duration of scratching may be logarithmically transformed. In one example, logarithmic the transformation that is applied represents such that it includes possible null values. In some aspects, the comb endpoints for each period are stored and provided to other components in the form of, for example, spreadsheets in comma separated value (CSV) format.

Continuing with FIG. 2, some embodiments of the technologies described herein include functionality for determining when a user is asleep or awake. In this regard, the system 200 of FIG. 2 may include a sleep/wake detector 230, which may generally be responsible for detecting when a user is asleep or awake. In some embodiments, sleep/wake detector 230 may use sleep classification logic 253 (as shown in storage device 250 of FIG. 2) to determine intervals in which a user is asleep versus awake. Sleep classification logic 253 may include rules, conditions, associations, machine learning models, or other criteria for inferring or detecting the likelihood that a user is asleep based on received data, such as motion sensor data. For example, sleep classification logic 253 may determine whether a user is likely to be asleep or not based on accelerometer data. The sleep classification logic 253 can take different forms depending on the mechanism(s) used to detect the sleep. In some embodiments, sleep classification logic 253 may comprise fuzzy logic, neural network(s), finite state machine, support vector machine, logistic regression, clustering, other machine learning technologies, similar statistical classification processes, or combinations thereof to to identify likely sleep periods. An exemplary embodiment of a computer program routine for performing aspects of the sleep/wake classifier 234 using sleep classification logic 253 is described in conjunction with FIGS. 11A-11M.

In some embodiments, sleep classification logic 253 may determine periods of sleep or wakefulness based on motion sensor data. In one exemplary embodiment, activity values may be determined from motion sensor data within a sleep opportunity segmented into time windows, and activity values for these time windows may be used to classify periods within a sleep opportunity as “asleep” or “awake.” ". As illustrated in FIG. 2, embodiments of the sleep/wake detector 230 may include an activity index determination module 232 and a sleep/wake classifier 234. An exemplary embodiment of the processes performed by the sleep/wake detector 230 is illustrated in conjunction with FIG. 4D.

Activity index determination module 232 may generally be responsible for determining activity index levels, which may represent a metric for summarizing triaxial motion data. In an exemplary embodiment, motion sensor data captured during a user's sleep opportunity may be used to determine index activity levels. The sleep capability determining module 262 may determine the sleep capability, which may include determining whether the sensor is being worn as described above with respect to the sensor wearing determination module 261 . Additionally, any preprocessing steps explained with respect to sensor wear determination module 261 and/or sleep capability determination module 262 may be applied to the motion sensor data to determine activity index levels (via activity index determination module 232). For example, a high pass filter may be applied to motion sensor data, which may be accelerometer data, and the cutoff may be 0.25 Hz.

The sleep opportunity may be segmented into windows of predetermined lengths, and the activity index determination module 232 may calculate an activity index level for each window. In exemplary aspects, the predetermined length may be one minute such that an index activity level is determined for each minute within the sleep opportunity. In an exemplary embodiment, activity index determination module 232 determines an index activity level according to the following algorithm, wherein A _t is the activity level at time t for patient i and m is the x axis:

Embodiments of the sleep/wake classifier 234 may apply heuristic rules to activity index levels (or values) to classify windows as “sleeping” or “awake”. Some embodiments of the sleep/wake classifier 234 may calculate a statistical feature of the activity index values and apply a sleep threshold. An embodiment may determine a weighted sum of activity index values within a specific time period. For example, a weighted sum for a one-minute window may be calculated using activity index values over a 7-minute period, for example, at times t-4 to t+4. An example algorithm for determining the weighted sum of activity index values is provided below:

In some embodiments, sleep/wake classifier 234 may determine whether or not the weighted sum meets a sleep threshold. For example, the sleep threshold may be 0.5, and a window may be classified as a sleep period if the weighted sum for that period is less than 0.5.

Additional embodiments of the sleep/wake classifier 234 may apply one or more re-scoring rules for improved specificity. For example, in one embodiment, Webster's re-quantification rules may be similar to those described in Roger J. Cole, Daniel F. Kripke, William Gruen, Daniel J. Mullaney, J. Christian Gillin, "Automatic Sleep/Wake Identification From Wrist Activity, Sleep," Volume 15, Issue 5, September 1992, pages 461-469 (source: https://doi.org/10.1093/sleep/15.5.461).

The sleep/wake detector 230 may use other algorithms to detect whether the user is asleep or not, for example, algorithms that process physiological variables. For example, sleep/wake detector 230 may determine when a user is awake or asleep based on heart rate, blood pressure, core body temperature, surrounding body temperature, and/or galvanic skin response data.

Based on the detected sleep intervals, a number of sleep endpoints may be determined for each time period (e.g., a 24-hour period) for use by other components of the system 200, for example, by a flush predictor 290 and/or a decision support tool 270, such as described in more detail in this document. As used herein, the term "sleep endpoint" refers to a quantifiable measure of sleep behavior that can be extracted from raw sensor data. For example, total sleep time (TST) and, in some embodiments, time asleep as a percentage within sleep capability may be calculated. The number of awakening reactions, which may also be referred to as "waking bouts" or "waking periods" between periods of sleep, can be determined. Additionally, wake after sleep onset (WASO) and latency to sleep onset (SOL) can be determined. As used herein, WAS0 means the amount of time (eg, in minutes) the user is awake after initial sleep onset, while SOL means the amount of time (eg, in minutes) in the onset of sleep opportunity before the first sleep period. In some aspects, sleep endpoints during each period are stored and provided to other components of the system 200 in the form of CSV spreadsheets. In some aspects, a user's sleep capability, or more specifically a TSO, predetermined may also be stored as a sleep endpoint.

These endpoints may be used to generate a sleep score, in accordance with some embodiments. The sleep score may indicate one or more characteristics or qualities of a user's sleep for a particular evening or over a period of time. In some embodiments, scratch endpoints, as described with respect to scratch detector 260, may further be used with sleep endpoints to generate a sleep score. In this way, the effects of scratching while a person sleeps can be measured. Below, an exemplary embodiment of the output of the sleep/wake detector 230 including a sleep quantity is explained with respect to FIG. 8B.

Continuing with the system 200 of FIG. 2, the future flush predictor 290 may generally be responsible for determining a user's risk of having a flush over a future time interval. Embodiments of the redness predictor 290 may use scratching patterns for the user to predict future levels of scabies and determine whether or not the future levels of scabies rise to the severity of the redness. Exemplary embodiments of the redness predictor 290 include a scratching pattern assembler 292, a context data determiner 294, a scabies predictor 296, and a redness notification generator 298.

The comb pattern assembler 292 may assemble statistical comb information for the user, in accordance with some embodiments.

The statistical scratch information may include statistical scratch events detected by the scratch detector 260 and stored in the personal card 240 of the tracked user, as indicated by the statistical scratch events 244 . In some embodiments, the scratch statistics include scratch endpoints determined from detected scratch events, such as the total number of scratch episodes (or events), the total scratch duration, the duration between scratch events, and/or the ratio of the duration between scratch events and the number scratching events. Additionally, some embodiments of the comb pattern assembler 292 may also consider statistical sleep-related data including the sleep endpoints explained above with respect to the sleep/wake detector 230.

Context data determination module 294 may generally be responsible for determining context information for statistical scratch events and assembled scratch patterns, as well as context information for a future time slot, in accordance with some embodiments. This contextual data can provide insight into potential causes, signs or symptoms of future scabies or redness. For example, some embodiments of the context data determination module 294 may determine weather information, such as ambient temperature and/or humidity, that may influence the user's level of scabies. In some embodiments, weather information is determined by a location that may be entered by the user, or may be determined based on location information, such as GPS data obtained from a user device associated with the user. Weather information may also come from one or more smart devices associated with the user, such as a smart thermostat. Other contextual data may include the user's medical data, which may be determined from the profile/medical record 241 (e.g., EHR) in the personal record 240. This medical data may include, but is not limited to, age, weight, diagnosed conditions, previous recipes and/or the user's current recipes.

In addition, the context data determination module 294 may determine the context from the input user data. For example, the user may enter a user-defined scabies rating, notes, and/or photographs of the user's skin including skin lesions. In some aspects, the contextual information may include user input regarding previous treatment information, including date, etc. For example, the user may enter whether or not the user uses a prescribed ointment on a particular day. This information can be entered by the user into a tracking or monitoring application. Additional sources of contextual information may come from workout tracking apps, food logs, and/or water logs.

In some embodiments, context data determination module 294 may append or associate context information with template information determined from combing template assembler 292. In one exemplary embodiment, the association may be based on a common date and/or time. For example, an increase in brushing events for a particular week detected by the brushing pattern assembler 292 may be correlated with a high level of humidity detected by the context data detection module 294 during that same week. In this way, pattern data from the combing pattern assembler 292 can be enriched through contextual information.

Context data determination module 294 may also determine current and/or future context data. For example, context data determination module 294 may determine a weather forecast, such as predicted temperature and/or humidity, for a future time interval. Additionally, current medical information can be determined, for example, whether or not the user has a current prescription for atopic dermatitis, and the user's current weight.

The scabies predictor 296 may generally be responsible for predicting a user's scabies level within a future time interval. As used herein, the predicted scabies level may be represented as a scratching level indicating the amount of scratching that a user may engage in in a future time interval that may be due to scabies. The scabies predictor 296 may use the user's scratching patterns, as described with reference to the scratching patterns assembler 292 and the context data determiner 294, to predict the user's level of scabies in a future time interval. The future time interval may be the next one day, the next few days, the next week, this or the next month, etc.

The scabies predictor 296 may apply scabies prediction logic 259 to determine a future (or predicted) level of scabies. The scabies prediction logic 259 includes rules, conditions, thresholds, associations, machine learning models, or other criteria for inferring or detecting the likelihood of a particular scabies occurring in the future. The scabies prediction logic 259 can take different forms depending on the mechanism(s) used to predict scabies. In some embodiments, scabies prediction logic 259 may comprise fuzzy logic, neural network(s), finite state machine, support vector machine, logistic regression, clustering, other machine learning technologies, similar statistical classification processes, or combinations thereof to to determine the likelihood of scabies in a future time interval. The scabies prediction logic 259 may be applied to scratching patterns, statistical context, current context (including specific data, e.g., age, demographics, pre-existing conditions, etc.), and, in some embodiments, sleep-related data to determine the likelihood of scabies.

In some embodiments, the scabies prediction logic 259 may be a generalized reference data-based logic. In one exemplary embodiment, statistical scratching patterns for a reference population can be assembled, context information for the reference population can be determined, and this reference information can be used to define scabies prediction logic 259, for example, one or more heuristic rules or thresholds. . In some embodiments, this logic may be based on crowdsourced data or statistics from similar users (e.g., users with an identical diagnosed condition, in or near an identical geographic location, or with identical or similar demographics). Any such crowdsourced data may be pre-identified prior to use by embodiments of the redness predictor 290.

Additionally, in some aspects, the scabies prediction logic 259 is based on a particular user's statistical scratching patterns and, in some embodiments, sleep-related data as well as statistical contextual information. For example, one or more rules or thresholds or machine learning models may be compiled using information from the user being tracked. Thus, antecedent conditions such as increasing levels and tempo of scratching events, weather, whether or not the user is receiving treatment, etc., can be taken into account in determining the logic that should be applied to determine a particular level of scabies and/ or redness event. Additionally, this information can also be used to then predict likely future levels of scabies or redness events when similar patterns are observed again.

Although the scabies predictor 296 is described as predicting the level or severity of scabies, severe and/or persistent scabies may accompany redness. Thus, the predicted level of scabies may, itself, represent a predicted risk of redness in accordance with some embodiments. Additionally, in some aspects, the predicted level of scabies can be used to determine the likelihood of future redness. In some embodiments, scabies risk prediction uses scabies predictions for multiple future time periods.

The predicted level of scabies may be compared to one or more redness detection thresholds to determine whether or not the predicted level of scabies is of sufficient severity to constitute a risk of redness. A redness detection threshold can be predetermined based on a reference population such that the threshold can be used for a larger population. In other embodiments, the redness detection threshold may be determined for a specific person being tracked. For example, the redness detection threshold may be set based on statistical information of the user, including medical data, such as condition or age. The redness detection threshold may be set by the user's doctor/caregiver and/or adjusted by the user, which may be stored in settings 249 in the personal record 240. Thus, determining the redness prediction by applying the redness detection threshold may be individually customized for a particular user.

In some aspects, the output of the scabies predictor 296 may represent a scabies level or risk score for a future time interval. The scabies level or risk score may be a numerical level or score, or a categorical level or score, for example, indicating low, moderate, high and/or severe levels of risk. Additionally, in some embodiments, two predictions may be made for each future time interval, including one prediction based on an assumption regarding treatment for the itch or underlying condition causing the itch, and another prediction based on an assumption regarding the absence of treatment for the itch or underlying condition causing the itch. condition. The treatment guess prediction may be based on the determination of the current use of the correct treatment determined by the context data determination module 294 . Additionally or alternatively, this prediction may be based on determining information indicative of a potential treatment, which may be identified from reference information in the data storage device 250. The non-treatment guess prediction may be based on determining, through context data determination module 294, that the user is not undergoing treatment or cannot determine current treatment information. Additionally, even in the case that the context data determining unit 294 determines that the user is currently undergoing treatment, the non-treatment-based prediction may be based on the assumption that the user may stop undergoing treatment.

In some embodiments, the redness notification generator 298 of the redness predictor 290 may generally be responsible for generating a notification or alert indicating a user's risk of scabies and/or flushing. For example, if the level of scabies meets the redness detection threshold, the redness notification generator 298 may provide a notification representing this risk to the user device (eg, any of 102a-n) of the monitored user and/or to the physician user device 108 for the doctor treating the tracked user or recommended to treat the tracked user. Unless otherwise specified, the term “notification regarding redness” is used herein to include notification regarding the level of scabies, even if the level of scabies does not indicate that a redness event is likely.

Exemplary embodiments of a redness notification generated in accordance with embodiments of the redness notification generator 298 are described below with respect to FIGS. 8C-8D and above with respect to FIG. 3B. In some aspects, an emergency or fire icon may be presented on a monitored user device (eg, any of 102a-n), such as a smart watch. The redness notification may be supplemented with supporting information to allow the user to know why redness is predicted. For example, a notification regarding redness may indicate that the user's scratching event trend is increasing, the weather is expected to change, or other contextual information or statistical patterns (as described above) that may affect scratching. Additionally, in some aspects, the redness notification may include recommendations to initiate action along with the notification based on the level of scabies or risk of redness. As an example, recommendations to schedule a caregiver visit, refill prescriptions, and/or add over-the-counter (OTC) therapeutics to the user's shopping list may be included in or along with the notification.

Some embodiments of the redness notification generator 298 may define a time point or time interval that can be used to determine when to provide a blush notification. This determination may be based on user preferences, for example, preferences stored in settings 249. Alternatively or additionally, this determination may be based on location and/or time of day information so as to increase the likelihood that the user takes the desired action to in order to reduce the risk of redness. For example, in one embodiment, a notification regarding flushing is issued in the morning or at night, which may correspond to times when a person is more likely to apply home treatment and/or plan a trip to the store for medications. For one such case, the flush notification generator 298 may determine whether or not the user's location is in or near a store, such as a drug store, and may issue a notification with a recommendation to treat with over-the-counter drugs or refill the drugs at recipe.

Additionally, some embodiments of the redness notification generator 298 may reliably communicate the risk of redness and associated data, such as recent scratching data, to the user's caregiver. This notification regarding redness may be sent directly to a user device associated with the user's caregiver, for example, a physician user device 108. Additionally or alternatively, notification regarding flushing may be logged at regular intervals in a data source accessible by the user's caregiver, for example, in the user's EHR 241.

Decision support tool(s) 270 (as shown in FIG. 2) represent various computing applications, services, or functionality for consuming output from one or more other components of system 200, such as detected scratch events or scratch endpoints, sleep metrics, and /or sleep endpoints or prediction of scabies and/or redness. Decision support tool(s) 270 may use this information to provide therapeutic and/or preventive actions, in accordance with some embodiments. Thus, the decision support tool(s) 270 can be used by the tracked user and/or the tracked user's caregiver. This decision support tool(s) 270 may take the form of a standalone application on a client device, a web application, and/or a service within an existing application. In some embodiments, one or more decision support tools (e.g., 270) may be distributed across multiple devices of system 200.

Some embodiments of the decision support tool 270 may determine a daily/weekly scratching score and/or sleep score for a tracked user and/or, in some aspects, other related metrics. An exemplary user interface of a decision support tool 270 providing a nightly scratch score, sleep score, and related information is shown in FIG. 8 B. The scratch score, for example, may be based on scratch endpoints as explained above, including number of detected scratching events, average duration, longest scratching event. In some embodiments, the sleep score may be determined based on sleep-related data read or determined in connection with the user being tracked, such as the sleep metrics explained above, including TSO, TST, WASO, SOL, etc. In some implementations, the sleep score may also be based on scratch scores or scratch-related data, such as scratching events, for the user. For example, a higher number of scratching events or a higher number of scratching scores may reduce sleep scores. Thus, the sleep score for these embodiments is more meaningful than sleep-related scores provided through conventional technologies because the sleep score determined according to embodiments of this disclosure reflects the user's scratching behavior while sleeping.

One exemplary decision support tool 272 may include a comb tracking application or service. In some embodiments, decision support tool 272 may associate scratch event data with time periods, such as days, and present scratch event data in association with the relevant period. The decision support tool 272 may include a calendar in which each day of the calendar provides brushing event data for the user being tracked. This data may include scratch event statistics, which may include certain scratch endpoints such as the total number of scratch events and total scratch duration, as described with respect to scratch detector 260 . The decision support tool 272 may further allow the user to log additional information for each date, such as user-defined levels of scratching or scabies, notes/narratives, other symptoms, and/or photographs. An exemplary comb tracking application or service is further described in connection with FIG. 8A.

Another decision support tool 274 may include a flush risk predictor service and/or a scabies predictor, which may be determined as described above with respect to the flush predictor 290. The decision support tool 274 may provide a redness risk predictor or scabies level prediction as notification. Additionally or alternatively, the prediction of the risk of redness or level of scabies may be associated with future time intervals (eg, future dates and times) and presented in association with these dates, for example, on a calendar. An exemplary redness risk predictor service and/or scabies predictor is further described in connection with FIGS. 8C-8E.

Another exemplary decision support tool 276, shown in FIG. 2, can initiate and/or schedule a treatment recommendation, in accordance with an embodiment. A treatment recommendation may include a therapeutic agent (including a prescription or over-the-counter medication), consultation with a physician, and/or additional testing that is recommended to relieve scabies, treat scratching, and/or reduce the risk of future scabies or redness. For example, the decision support tool 276 may determine a treatment recommendation, such as long-term use of an existing prescription, a new drug, or scheduling a doctor's appointment, based on the current scratching event endpoints determined by the scratching detector 260. Additionally or alternatively, these recommendations may be based on a predicted scabies or flushing event determined by the flushing predictor 290. An exemplary embodiment of decision support tool 276 is described further in connection with FIG. 8C.

Some embodiments of the decision support tool 276 include aspects for treating a user's itch, which may present as atopic dermatitis, based on scratching detected from a wearable sensor device, such as sensor 103. Treatment may be targeted to to reduce the severity of the user's itching. Treatment determined based on detected scratching may be designed to prevent the user's itch from getting worse. Treating the user's itching based on detected scratching may include determining a new treatment protocol, which may include new therapeutic agent(s), a dosage of the new agent, or a new dosage of an existing agent being taken by the user, or a dosage of the new agent and/or a method of administering the new one. agent, or a new way to assign an existing agent, accepted by the user. A recommendation for a new treatment protocol may be provided to the user or caregiver for the user. In some embodiments, the prescription may be sent to the user, the user's caregiver, or the user's pharmacy. In some cases, treatment may involve refilling an existing prescription without changing it. Additional embodiments may include administering the recommended therapeutic agent(s) to the user in accordance with the recommended treatment protocol and/or monitoring the use or use of the recommended therapeutic agent(s). Thus, embodiments of the disclosure may better enable management, monitoring, and/or comprehensive management of the use or administration of therapeutic agents for the treatment of itch, which not only should be beneficial to the user's condition, but may also assist health care providers and drug manufacturers, as well as It is also better for others in the supply chain to comply with regulations and guidelines set through the Food and Drug Administration and other government agencies. In exemplary aspects, the treatment includes one or more therapeutic agents from the following:

- an agent for the treatment of autoimmune and/or inflammatory disorders, such as sulfasalazine, mesalanine, azathioprine, antibody (for example, infliximab, adalimumab, belimumab, tanezumab, ranibizumab, bevacizumab, certolizumab mepolizumab, natalizumab, ustekinumab and/or vedolizumab), 6-mercaptopurine , hydroxychloroquine, obeticholic acid, mofetil, mycophenolate sodium, leflunomide, Rituxan, solumedrol, depomedrol, a nonsteroidal anti-inflammatory drug (NSAID) (eg, aspirin, ibuprofen, celecoxib, valdecoxib, WBI-1001 and/or MRX-6) and/or a corticosteroid (eg, fluticasone, mometasone, budesonide, ciclesonide, beclamethasone, depomedrol, betamethasone, dexamethasone and/or prednisone);

- an agent for the treatment of dermatological conditions, such as an immunosuppressant (for example, cyclosporine, tacrolimus and/or pimecrolimus), an antibody (for example, infliximab, adalimumab, dupilumab, omalizumab, tralokinumab, etokimab, nemolizumab, tezepelumab, lebrikizumab, fezakinumab, anti-OX40 and /or efalizumab), a TNF inhibitor (eg, etanercept), a PDE4 inhibitor (eg, crisaborole) and/or a topical corticosteroid (eg, fluocinonide, mapracorate, hydrocortisone, desonide, alklometasone, triamcinolone and/or deoxymethasone);

- a histamine receptor antagonist, such as a histamine receptor antagonist type 1 and/or a histamine receptor antagonist type 2 (for example, loratadine, fexofenadine, desloratadine, levocetirizine, metapyrylene and/or cetirizine);

- corticosteroid (for example, budesonide, fluticasone, mometasone, dexamethasone, prednisolone, ciclesonide and/or beclomethasone); and/or

- an agent for the treatment of joint disorders, such as methotrexate, azathioprine and/or NSAID (for example, aspirin, ibuprofen, celecoxib, valdecoxib, WBI-1001 and/or MRX-6).

Some embodiments include a treatment that is one or more of the following therapeutic agents, which may be used in addition to or as an alternative to the agents listed above:

- JAK inhibitor such as abrocitinib, baricitinib, brepocitinib, cerdulatinib, decernotinib, delgocitinib, fedratinib, filgotinib, gandotinib, ilginatinib, itacitinib, lestaurtinib, momelotinib, oclacitinib, pacritinib, peficitinib, ritlecitinib, olitinib, tofacitinib, upadacitinib, THRX-212401 , PF-07055087, PF-06471658, PF-07055090, ATI-502, BMS-986165, JTE-052, PF-06826647, SNA-152 and/or SHR-0302;

- an aryl hydrocarbon receptor agonist such as tapinarof;

- interleukin-2-induced inhibitor of T-cell kinases;

- a retinoic acid derivative such as alitretinoin;

- antiviral agent; and/or

- vaccine.

In a preferred embodiment, the treatment includes the PDE4 inhibitor crisaborole and, in addition or alternatively, the JAK inhibitor abrocitinib.

These exemplary decision support tools 272, 274 and 276 may be used independently or in conjunction with each other. For example, one application may use all three decision support tools. Additional details of the decision support tools are explained in conjunction with FIGS. 8A-8E.

The presentation component 220 of the system 200 may generally be responsible for presenting detected scratching event information, detected sleep/wake information, scabies/redness predictions, and/or related information. Presentation component 220 may contain one or more applications or services on a user device, across multiple user devices, or in a cloud environment. For example, in one embodiment, presentation component 220 may control the presentation of information, such as notifications and alerts, to a user across multiple user devices associated with that user. Based on presentation logic, context, and/or other user data, presentation component 220 may determine on which user device the content is presented, as well as the presentation context, such as how (e.g., in what format and how much content, which may depend on the user device or context) it is presented, when it is presented, or other such aspects of the presentation.

In some embodiments, presentation component 220 may generate custom interface features associated with or used to facilitate the presentation of aspects of other components of system 200, such as scratch detector 260, sleep/wake detector 230, blush predictor 290, and tool(s). ) 270 decision support, user. Such features may include interface elements (for example, icons or indicators, graphical buttons, sliders, menus, audio prompts, alerts, alarms, vibrations, pop-ups, notification bar or status bar elements, in-app notifications, or other similar signs for communication using the user interface), queries and prompts. Examples of graphical user interfaces (GUIs) that may be generated and presented to a user by presentation component 220 are described in connection with FIGS. 8A-E.

The data storage device 250 of the exemplary system 200 may generally store information including data, computer instructions (e.g., program instructions, procedures, or services), logic, profiles, and/or models used in the embodiments described herein . In an embodiment, the data storage device 250 may include a data store (or computer data storage device), for example, a data store 150. Additionally, although illustrated as a single data store component, data storage device 250 may be implemented as one or more data stores or in a cloud environment.

As shown in the exemplary system 200, data storage device 250 includes sleep classification logic 253, scratch event detection logic 256, and scabies prediction logic 259, all of which are described above. Additionally, storage device 250 may include one or more personal cards 240, as shown in FIG. 2. The personal record 240 may include information associated with a particular person/user being tracked, such as profile/health data 241 (EHR), sensor data 242, statistical brush events 244, logs 246, user account(s)/device(s). a) 248 and settings 249. Information stored in the personal card 240 may be accessed by data acquisition component 210, sensor monitor 280, scratch detector 260, sleep/wake detector 230, blush predictor 290, or other components of the exemplary system 200, as described. in this document.

Profile/Health 241 (EHR) can provide information related to the health of the person being tracked. Embodiments of the profile/medical data 241 (EHR) may include part or all of a person's EHR, or only some medical data that is related to scratching or sleep. For example, profile/medical data 241 (EHR) may indicate previous or current diagnosed conditions such as atopic dermatitis, eczema, psoriasis, or similar conditions; medications associated with the treatment of itch-related conditions or potential side effects of scratching/scabies; weight; or age.

Sensor data 242 may include raw and/or processed sensor data, for example, from sensor 103 (shown in FIG. 1). This sensor data may include data used to detect scratching events, such as motion sensor data, and extract features. The sensor data may further include other types of information that may be stored on or in combination with the sensor device, such as ambient air information (eg, ambient air temperature or humidity) or physiological data (eg, ambient body temperature or heart rate). Other sensor data disclosed herein may be stored as sensor data 242.

Additionally, the statistical comb events 244 may comprise comb events determined by the comb event classifier 268 . In some embodiments, statistical scratching events 244 also include scratching endpoints such as the total number of scratching episodes, the total duration of scratching, the duration between scratching events, and/or the ratio of durations between scratching events and scratching episodes. Embodiments of the statistical scratch events 244 may also include scabies or redness predictions determined by the redness predictor 290 . Additionally, in some embodiments, statistical scratching events 244 may also include information regarding detected scratching events and/or previously predicted scabies or redness, for example, the date and time of the scratching or prediction event. In some aspects, other contextual data, such as weather, location, and the like, may be stored as statistical brush events 244. Additionally or alternatively, other contextual information extracted from user-provided observational data, such as user-defined scabies ratings, notes, and photographs, may be stored as statistical scratch events 244.

In some embodiments, logs 246 may include observation logs and/or reaction logs. The observation log may include user notes, photographs, or other observations that the user may provide through the comb monitor application, in accordance with one exemplary embodiment. These observations may be related to scabies, scratching, redness, sleep, and other contextual information described in this document, such as weather, temperature, etc. As discussed above, observation logs can be analyzed by contextual data module 294 to provide additional insight for future predictions.

Additionally, in some embodiments, the logs 246 may also include reaction logs indicating how the user reacts to a detected scratching event, a detected sleep/wake period, a prediction of scabies or redness, and/or a resulting notification. For example, the reaction log may indicate that the tracked user is scheduling a televised doctor's appointment in response to predicted future flushing. Alternatively, the user may add a recommended ointment to an electronic shopping list in response to detected scratching events. Additionally, the reaction log may indicate if the monitored user takes an acknowledgment action or selects an "ignore" flag in response to a notification or alarm generated based on detected scratching events or the prediction of scabies or redness. Some embodiments of this disclosure may use reaction logs to calibrate, improve scratch detection, sleep/wake detection, predict flushing or scabies, and/or improve decision support recommendations or initiated actions.

Additionally, in some embodiments, user account(s)/device(s) 248 may generally include information regarding the user device accessed, used, or otherwise associated with the user. Examples of such user devices may include user devices 102a-n of FIG. 1 and may generally include mobile phones, tablet computers, smart watches, or other wearable devices. Other smart devices and associated accounts, such as a home smart thermostat and/or hygrometer, may be included in the user account(s)/device(s) 248.

In one embodiment, user account(s)/device(s) 248 may include information associated with accounts associated with the user, such as online or cloud accounts (e.g., online medical records portals, network/ health care provider, online sites, decision support applications, social networking profiles, email, telephone, e-commerce sites, etc.). For example, user account(s)/device(s) 248 may include a tracked person account for a decision support application, such as decision support tool(s) 270; an account for a care provider's website (which, for example, could be used to enable electronic scheduling of appointments); and online e-commerce accounts, such as Amazon.com® or a pharmacy store (which, for example, can be used to facilitate online ordering of medical supplies).

Additionally, the user account(s)/device(s) 248 may also include the user's calendar, appointments, application data, other user accounts, and the like. Some embodiments of the user account/device 248 may store information in one or more databases, knowledge graphs or data structures. As described above, information stored in user account(s)/device(s) 248 may be determined from data collection component 210.

Additionally, in some embodiments, settings 249 may generally include user settings or preferences associated with one or more steps for scratch detection, sleep/wake detection, or scabies/redness prediction, or one or more support applications decision making, for example, with decision support tools 270. By way of example, and not limitation, such settings may include user notification tolerance thresholds, which may specify when and how the user wishes to be notified regarding predicted redness. In some aspects, settings 249 may include user preferences for applications, such as notifications, preferred caregivers, preferred pharmacy or other stores, and over-the-counter medications. In one embodiment, calibration, initialization, and settings of the sensor(s) may also be stored in settings 249.

Fig. 4A-E illustrate exemplary aspects of scratch detection. Fig. 4A, for example, illustrates a flowchart illustrating an example method 400 for detecting a comb and initiating an action based on the detected comb, in accordance with an embodiment of the disclosure. The method 400 may be implemented through embodiments of one or more components of the system 200, for example, the scratch detector 260 described in connection with FIG. 2. Additionally, each block or step of method 400 and other methods described herein includes a calculation process that can be performed using any combination of hardware, firmware and/or software. For example, various functions may be performed by a processor executing instructions stored in a storage device. The methods may also be implemented as computer-applicable instructions stored on computer storage media. The methods may be provided through, but not limited to, a stand-alone application, service, or hosted service (standalone or in combination with another hosted service) or a plug-in for another product. Accordingly, method 400 may be implemented through one or more computing devices, such as a smartphone or other user device, a server, or a distributed computing platform, such as in a cloud environment. Exemplary aspects of computer program procedures,

covering scratch detection implementations are illustratively shown in FIGS. 9A-11M and in particular in FIGS. 10A-10I.

At step 410, sensor data is received. The sensor data may include motion sensor data associated with the user (or patient) being tracked, for example, raw accelerometer data captured via a wrist-worn sensor or device. Other readable or defined data, such as user input, body temperature data, weather-related data, and the like, may also be received as sensor data. Embodiments of step 410 may include preprocessing operations, for example, applying frequency filters, segmenting the data into relevant windows, for example, 3-second windows, and extracting transformed signals, for example, vector absolute magnitude, first principal component, and second principal component. Step 410 may be performed by sensor 103 of FIG. 1 and/or data acquisition component 210 of FIG. 2.

Additionally, at step 420, it is determined whether the sensor(s) are capable of properly receiving data. This step may include detecting whether a sensor (eg, sensor 103) is being worn or not by the user being tracked, or is being worn or not in a manner that captures intended information. Step 420 may be performed by an embodiment of the sensor wearing detection module 261 of FIG. 2, and an exemplary process for performing step 420 is illustrated and described in conjunction with FIG. 4 B. One implementation of step 420 may measure physiological parameters of the tracked user indicative of whether or not a sensory device (or sensor) (for example, temperature around the body, pulse, blood pressure, galvanic resistance of the skin, etc.). For example, the temperature around the body may be compared to a non-wearing temperature threshold, which may be 25 degrees Celsius in one exemplary embodiment. In this case, it may be determined that the sensor is not being worn when the temperature is below the unworn temperature threshold. In another implementation, the tracked user may manually indicate that the sensor is being worn, for example, by pressing a button on the touch device, initiating a mode of the touch device and/or an application running or communicating with the touch device, or otherwise indicating that the sensor is being worn.

At step 430, the user's sleep capability is determined. A user's sleep capability may represent an interval of time during which the monitored user intends to sleep or is more likely to sleep, compared to times outside of that interval. This determination may be made using sensed motion information, such as accelerometer data. Step 430 may be performed by an embodiment of the sleep capability determination module 262 of FIG. 2. Additionally, some embodiments may determine total sleep capability (TSO), as described with respect to sleep capability determination module 262. One implementation of TSO determination is illustrated and described in conjunction with FIG. 4C. Other embodiments of step 430 may include determining whether the user is sleeping by determining that the lights have been turned off for a minimum amount of time (eg, 10 minutes) using a photodetector. In some other embodiments, sleep capability may be determined based on physiological readings or the user's ability to indicate to the sensor (e.g., using a button or entering sleep or wake mode) when the monitored user falls asleep and when the user wakes up from sleep.

Additionally, method 400 (more specifically, step 430) may further include determining periods of actual sleep (and/or periods of wakefulness) during the user's sleep opportunity. This aspect of step 430 may be performed by sleep/wake detector 230 or its subcomponents: activity index module 232 and/or sleep/wake classifier 234 in FIG. 2. Additionally, one exemplary process for determining sleep/wake periods is illustrated in FIG. 4D.

Sleep periods can be determined by calculating activity index values from accelerometer data captured within a certain total sleep opportunity (TSO). Thus, sleep/wake detection may involve applying a sequence of three algorithms. First, the full possibility of sleep can be detected. Second, activity index values can be calculated from accelerometer data captured during a specific TSO, and third, time periods within a specific TSO can be classified as sleep/wake periods based on the activity index values.

Other technologies for determining sleep in accordance with an embodiment of method 400 may be based on physiological parameters that can be read, such as brain activity determined by a head-worn sensor, or based on a combination of multiple physiological parameters and motion data. For example, block 430 may detect sleep during a period of less movement indicated in the movement data, along with changes in heart rate and/or respiration rate that are consistent with sleep. The sleep (or wake) detection output may be the endpoints shown in the example user interface illustrated in FIG. 8B.

Continuing with method 400, at block 440, a user's hand movement event (which may also be generally referred to as “hand movement”) may be detected. Exemplary embodiments of block 440 may detect hand movement events based on sensor data, such as accelerometer data, obtained from a wearable device, such as a wrist-worn or finger-worn device. Step 440 may be performed by an embodiment of the hand movement detector 264 of FIG. 2.

Additionally, at block 450, a probable scratching event may be detected. Step 450 may be determined from sensor data corresponding to the detected hand movement. Thus, embodiments of step 450 determine whether the detected hand movement represents a scratching event or not. In particular, feature values, for example, time domain and frequency domain feature values, can be extracted from sensor data corresponding to a detected hand movement event, and the feature values can be input to one or more machine learning classifiers, for example, a random forest classifier. to determine whether or not the detected hand movement is likely to represent a scratching event. Step 450 may be performed by embodiments of the feature extractor 266 and scratch event classifier 268 .

At step 460, the detected scratching event may be recorded. This step may include storing a classification of the scratching event and associated contextual information. The scratching event data may be stored in the personal record 240 and made available for decision support, for example, through a decision support tool 270 . Scratch event data may further be provided to the user and/or physician, as described with respect to presentation component 220 of FIG. 2.

At step 470, an action may be initiated based on the detected scratch event. Exemplary actions may include actions, recommendations and/or directives to relieve scabies and reduce scratching events. Step 470 may be performed by embodiments of the decision support tool 270 and/or presentation component of FIG. 2. For example, step 470 may include initiating steps for treating itch (or more specifically, atopic dermatitis) of the user using one or more therapeutic agents based on scratching events detected using a sensor on the wearable device, as described with respect to support tool 276 decision making. Method 400 may include tracking and/or monitoring the administration and use of a therapeutic agent according to the recommended or instructed treatment protocol provided at 470.

The action may include sending or otherwise electronically transmitting an emergency alert or notification to a user through a user device, such as through user devices 102a-n in FIG. 1, or to a physician through a physician user device, such as through physician user device 108 in Fig.1. The notification may indicate one or more detected scratch events and/or other scratch endpoints, such as the total number of scratch events, the total duration of scratches, the longest duration of a scratch event, and/or the ratio of durations between scratch events to the number of scratch events. Additionally, in some embodiments, the notification may include a scratch score that can be calculated using one or more of these scratch endpoints. In some aspects, in which a sleep/wake period is detected, the notification may also include sleep endpoints and/or a sleep quantification determined using the sleep endpoints.

In some embodiments, the action may further include processing scratch event data for additional decision making, which may include providing a recommendation for treatment and support based on the detected scratch events. Such a recommendation may include a recommendation to contact a health care provider, to continue taking a current prescription or over-the-counter medication, or to start using an over-the-counter medication (which may additionally include adding the medication to an electronic shopping list and/or online shopping cart) , adjust thermostat settings and/or continue to monitor brushing events. One or more of these actions may be performed automatically in response to detected scratching events and, in some embodiments, detected sleep/wake periods.

Fig. 4B illustrates a schematic representation of an example process 4200 for detecting wearing a sensor. Process 4200 may represent an exemplary process for performing step 420 of method 400 of FIG. 4A. An embodiment of this process may be performed by the sensor wearing detection module 261 of FIG. 2.

Fig. 4B illustrates a sequence of steps 4201 for detecting periods of wear and non-wear. In step 4201, at step 4210, raw triaxial motion data is received, for example, from an accelerometer. Triaxial motion data contains X-axis measurements, Y-axis measurements, and Z-axis measurements. This data may be preprocessed by applying one or more filters, as described above. Triaxial motion data can be divided into overlapping windows, for example, one-hour windows with a 15-minute overlap. At step 4230, the statistics for the X-axis, Y-axis, and Z-axis measurements for the window satisfy the non-wear threshold. As illustrated in FIG. 4B, an initial non-wear determination is made for the window at step 4240 if either of the standard deviations for any two axes is less than 0.13 Gs, or the ranges for any two axes are less than 0.15 Gs. If none of these non-wear thresholds are satisfied at step 4230, the window may initially be determined to be a wear window.

At step 4250, a set of re-scoring rules may be applied to determine whether or not the initial wearing or not wearing determination for a given window or block of windows should be changed. Additional details regarding the heuristics to be applied for requantification at step 4250 are explained in conjunction with the sensor wear determination module 261 of FIG. 2. At block 4260, one or more windows initially determined to be a window (or block of windows) to be worn may be re-quantified as "not worn" at block 4260. In other embodiments, the re-quantification may alternatively or additionally include re-quantification evaluation of a window or block of windows not being worn as a window or block of windows being worn.

Fig. 4B also includes a diagram 4270 illustrating the initial definitions of the wearing and non-wearing windows. In an example, block 4271 includes eight windows identified as wearing windows, followed by block 4273 containing four windows identified as non-wearing windows. Block 4273 is followed by block 4275 containing two wear windows, followed by block 4277 containing three non-wear windows. Block 4277 is followed by block 4279 containing six wear windows. As described in conjunction with the sensor determination module 261 of FIG. 2, the re-scoring rule may include re-scoring a block of windows with "worn" as "not worn" if the block is less than three hours, and the previous block is greater than one hour. In this regard, block 4275 may be written to a non-wear window block.

Fig. 4C illustrates a schematic representation of an example process 4300 for determining a user's sleep capability (eg, TSO). Process 4300 may represent an example process for performing step 430 of method 400 of FIG. 4A. Additionally, an embodiment of the process 4300 may be performed by the sleep capability determination module 262 of FIG. 2. Additionally, FIG. 6F illustrates the performance validation aspect of the algorithm described in process 4300 of FIG. 4C. As explained below, exemplary aspects use TSO to enable the user to sleep. TSO predominantly captures times when the user has difficulty sleeping, which may represent a consequence of scratching. Using accelerometer data to determine sleep potential may be even more advantageous than using lighting information alone, since people may be spending time on laptop computers or mobile devices while they are in a dark room and do not intend to sleep . Reliably detecting the sleep capacity within which scratching can be measured helps to effectively determine how a person's sleep and nighttime scratching behavior varies on a daily basis.

Process 4300 may generally include determining the user's overall sleep capability based on a change in forearm flexion angle measured from the motion data. At step 4310, moving medians of the raw triaxial motion signal measurements are determined. For example, 5-second sliding medians of the X-axis, Y-axis, and Z-axis measurements are determined at 4310, and the average measurements are used to determine forearm flexion angles at 4320.

At 4330, average forearm flexion angle values may be calculated for intervals (eg, consecutive 5 seconds), and absolute differences between successive average forearm flexion angle values may be calculated at 4340. At 4350, sliding medians of the differences between successive average flexion angle values can be calculated at 4340. forearms can be calculated for an interval (eg 5 minutes). At step 4360, candidate immobilization periods may be determined by comparing a running median of the difference between successive average forearm flexion angle values with a immobility threshold value. For example, a potential immobilization period may be detected when the average difference between consecutive mean forearm flexion angle values is less than or equal to 0.15 times the 10th percentile values of all differences in forearm flexion angle values within a 24-hour period.

At step 4370, candidate periods of immobility identified as "non-wearing" (which may be defined as described in conjunction with FIG. 4B) may be filtered out from consideration for the full sleep opportunity. At step 4380, the remaining motionless period candidates may be compared to a threshold length of, for example, 30 minutes, such that the motionless period candidates are retained if they are greater than 30 minutes. Additionally, at 4390, the period candidates may be grouped if the intervals between periods satisfy a threshold duration, for example, less than 15 minutes. At 4395, the longest group of possible periods within a given period of time (eg, a 24-hour period) may be determined to be the user's total sleep opportunity.

Fig. 4D illustrates a schematic representation of an exemplary process 4700 for detecting periods of wakefulness and periods of sleep of a user. Process 4800 may represent an example of a process for performing sleep and/or wake period detection step 430 in an embodiment of method 400, as described in conjunction with FIG. 4A. Additionally, an embodiment of the process 4800 may be performed by the sleep/wake detector 230 of FIG. 2 or subcomponents thereof.

Process 4800 may detect the user's sleep/wake periods using activity index values calculated from the motion data. At step 4810, a filter may be applied to the motion sensor data. For example, a high-pass filter with a cutoff of 0.25 Hz can be applied to motion. The sleep opportunity may be segmented into windows of predetermined length, and at step 4820, an index activity level may be calculated for each window, for example, one minute. Activity level values may be calculated as illustrated at step 4820 in FIG. 4D.

At step 4830, a weighted sum of the activity index values in a particular time period may be determined. For example, a weighted sum for a one-minute window may be calculated using activity index values over a 7-minute period, for example, at times t-4 to t+4.

At 4840, each weighted sum may be compared to a sleep threshold to determine whether or not the period should be initially classified as a sleep period. For example, the sleep threshold may be 0.5, and a window may be classified as a sleep period if the weighted sum for that period is less than 0.5. At step 4850, one or more rescoring rules may be applied to classify the period from sleep to wakefulness and/or from wakefulness to sleep. The resampling rules may be as described in conjunction with the sleep/wake classifier 234 of FIG. 2.

At step 4860, aggregated sleep endpoints may be determined for the full sleep capability. These sleep endpoints may include total sleep time (TST), percent time asleep (PTA), wake after sleep onset (WASO), sleep onset latency (SOL), and number of wakeful bouts (NWB). These sleep endpoints may be used as described with respect to decision support tool 270 in FIG. 2.

Fig. 4E illustrates a schematic representation of exemplary aspects of the scratch detection process 4001. Process 4001 may include classifying scratch events and may therefore be referred to herein as a “comb classifier pipeline.” Aspects of the process 4001 may be performed by one or more components of the system 200, for example, the comb detector 260 or subcomponents thereof.

Initially, at block 4010, sensor data may be received, which may include pre-formatting or pre-processing the raw accelerometer data. In some embodiments, the raw data may be in the form of an example signal 6410, as illustrated in FIG. 6C. In this regard, block 4010 may include segmenting accelerometer data during a detected total sleep opportunity (TSO) interval for a 24-hour period into 3-second non-overlapping windows, as shown in steps 4012 and 4014. In some embodiments, others window lengths, for example, 1 second and 2 seconds, can be used for segmentation. Block 4010 may be performed in accordance with embodiments of steps 410, 420 and/or 430 of FIG. 4A.

The remainder of the process 4001 may involve generating comb predictions through a two-layer approach. First, the presence of hand movement is determined (see block 4040), and then these periods of hand movement are classified as scratching events or non-brushing events (see block 4050). At block 4040, each 3 second window is run through the hand movement detection heuristic algorithm to determine the presence of hand movement. Steps 4042 and 4044 at block 4040 may be performed by the embodiment of hand motion detector 264 of FIG. 2 and in accordance with the embodiment of step 440 of FIG. 4A.

The hand movement detection algorithm includes calculating a sliding (1 second) coefficient of variation (CoV), as shown in step 4042. These calculated CoV values can be compared to a hand movement threshold value, in step 4044. Hand movement detection algorithm parameter (threshold value for the calculated moving coefficient of variation) can be tuned empirically based on the training data set. For example, it may be determined that the 25th percentile of all calculated coefficient of variation values in the training data set provides accurate results. In one embodiment, this CoV threshold value may be 0.023. In some embodiments, the hand movement detection algorithm may use an example hand movement prediction signal 6440, as illustrated in FIG. 6C. If hand movement is detected for the entire given 3 second window at step 4044, it is sent for scratch classification.

The scratch classification is represented by block 4050. The steps in block 4050 may be performed by feature extractor 266 and scratch event classifier 268 of FIG. 2 and may be performed in accordance with block 450 of FIG. 4A. In example embodiments, a binary machine learning (ML) classifier is trained to detect the presence of a comb. A classifier may be trained in accordance with an embodiment of pipeline 600 in FIG. 6A, as described below.

An example pipeline for comb prediction at block 4050 includes a preprocessing step 4052, feature extraction 4054, classification 4056, and endpoint computation 4058. A preprocessing step 4052 may generate three processed signals by applying filtering and dimensionality reduction to the raw accelerometer data. First, raw accelerometer data may

filtered using a high-pass filter such as a first-order Butterworth infinite impulse response (IIR) high-pass filter with a cutoff frequency of 0.25 Hz. Then, to reduce dependence on device orientation, the vector absolute value and the first and second principal components of the filtered signal can be calculated.

At step 4054, time and frequency domain features may be calculated from the processed accelerometer data. An embodiment of step 4054 may use the 26 features identified above with respect to the feature extraction module 266 of FIG. 2. These features may be selected during classifier training, as described with respect to FIGS. 6A-6B.

At step 4056, the calculated features may be passed through the trained comb classifier. In one embodiment, the scratch classifier is a random forest classifier. Additionally, the random forest classifier can include 50 evaluation units. The scratching classifier can determine, using the computed features, whether the detected hand movement represents a likely scratching event or not. Additional details regarding block 4056 may be described with respect to the scratch event classifier 268 in FIG. 2. In some embodiments, a scratch event classifier may predict a scratch based on the detected scratch event signal 6450, which is determined at step 4056 and illustrated in FIG. 6C.

At step 4058, digital nighttime scratching endpoints (also referred to as “brushing endpoints”) may be retrieved by processing scratching predictions during a certain sleep opportunity for each 24-hour period. The scratching endpoints may include the total number of scratching events and the total duration of scratching. A sleep capability, such as TSO, can also be included as a digital endpoint as it is used for scratch detection. The table below summarizes some of the digital endpoints retrieved in an embodiment of step 4058.

Implementations of process 4001 may be performed with only one sensor, such as a wrist-worn sensor device. However, some embodiments may also operate with two sensors, for example, when the user wears the device on each wrist. When there are two sensors, total scratch counts can be calculated by taking the sum of contiguous 3-second predicted scratching bouts detected from both wrists, and total scratching durations can be calculated by taking the sum of the durations of all predicted scratching bouts from both wrists.

Fig. 4F illustrates a flowchart illustrating an example method 4500 for providing decision support based on comb events, in accordance with an embodiment of the disclosure. The method 4500 may be implemented through embodiments of one or more components of the system 200, for example, the scratch detector 260 described in connection with FIG. 2. Exemplary aspects of computer program routines covering scratch detection implementations are illustrated illustratively in FIGS. 9A-11M and, in particular, FIGS. 10A-10I.

At step 4510, accelerometer data is received. Accelerometer data may be captured by a wearable device associated with a person (eg, a subject or patient being monitored) and located on a part of the person's body. For example, the wearable device may be located on a person's wrist, forearm, and/or finger. Other readable or defined data, such as user input, body temperature data, weather-related data, and the like, may also be received as sensor data. The wearable device may include a plurality of sensors for capturing different types of data, for example, accelerometer data and at least one of body temperature data and lighting data. Step 4510 may be performed by sensor 103 of FIG. 1 and/or data acquisition component 210 of FIG. 2. Some embodiments of step 4510 may be similar to step 410 of method 400 explained in conjunction with FIG. 4A. Additionally, some embodiments of method 4500 may include determining whether or not the sensor(s) are capable of properly receiving data, as described at step 420 of FIG. 4A.

At step 4520, hand movement is detected using accelerometer data. Step 4520 may be performed by the hand movement detector 264 embodiment of FIG. 2. Some embodiments of steps 4520 may be similar to embodiments of step 440 of method 400.

At step 4530, a computerized classification model is used to determine that the movement of the hands indicates a scratching event. This determination can be based on accelerometer data corresponding to hand movements. In some embodiments, step 4530 includes generating multivariate time series from accelerometer data corresponding to hand movements and determining feature values from the multivariate time series. The feature values may include at least one time domain feature value and at least one frequency domain feature value. Determining that hand movement indicates a scratching event can be based on feature values. Step 4530 may be performed by the embodiments described in connection with the scratch detector 260, and more specifically, the embodiments described in connection with the feature extractor module 266 and the scratch event classifier 268 of FIG. 2. Additionally, some embodiments of step 4530 may be similar to embodiments of step 450 of method 400. Some embodiments of method 4500 include recording a comb event definition, as described in more detail with respect to step 460 of method 400.

At step 4540, one or more response actions are initiated based on the determination that the movement of the hands indicates a scratching event. Exemplary actions may include actions, recommendations and/or directives to relieve scabies and reduce scratching events. Step 4540 may be performed by embodiments of the decision support tool 270 and/or presentation component of FIG. 2. For example, step 4540 may include initiating steps for treating itch (or more specifically, atopic dermatitis) of the user using one or more therapeutic agents based on scratching events detected using a sensor on the wearable device, as described with respect to support tool 276 decision making. Some embodiments of step 4540 may be similar to embodiments of step 470 of method 400.

In some embodiments, the response includes generating a graphical user interface element provided on the display of a user device, for example, computer user device 102a-c, patient user device 102p, or physician user device 108 of FIG. 1, which may be performed by or in combination with an embodiment of presentation component 220 of FIG. 2. The graphical user interface element may include at least one of an indicator of one or more scratching endpoints (e.g., total number of scratching events and total scratching duration) and an indicator recommending that the individual should seek clinical advice based on the determination that that hand movement indicates a scratching event.

Some embodiments of method 4500 may include determining full sleep capability based on accelerometer data. Total sleep capability can be the period of time during which a person lies down in a still state and when a person gets up from a still state. The hand movement detected at step 4520 may be detected using accelerometer data corresponding to full sleep capability only. Some embodiments of this process may be similar to step 430 in method 400 and/or may be performed by an embodiment of the sleep capability determination module 262 of FIG. 2. In embodiments of method 4500 in which the response includes providing a graphical user interface element indicating one or more scratch endpoints, the scratch endpoints may be limited to full sleep capabilities (one full sleep capability or multiple full sleep capabilities).

At least one of the body temperature and lighting data captured through the wearable device may be used, in addition to the accelerometer data, to determine overall sleep capability. Additionally, this determination of total sleep opportunity may further include determining periods of actual sleep (and/or periods of wakefulness) during the total sleep opportunity, which may be performed by sleep/wake detector 230 or subcomponents thereof, activity index determination module 232, and/or sleep/wake classifier 234, in FIG. 2. Additionally, an exemplary process for determining sleep/wake periods is illustrated in FIG. 4D.

Fig. 4G illustrates a flowchart illustrating an exemplary method 4600 for treating itching using a motion sensing device.

associated with the subject, in accordance with an embodiment of the disclosure. Method 4600 may be implemented through embodiments of one or more components of system 200, for example, scratch detector 260 and/or decision support tools 270 described in connection with FIG. 2. Exemplary aspects of computer program routines covering scratch detection implementations are illustrated illustratively in FIGS. 9A-11M and, in particular, FIGS. 10A-10I.

At step 4610, accelerometer data collected from the motion sensing device is received. Accelerometer data may be captured through a wearable device associated with the subject located on a part of the subject's body (eg, on the person's wrist, forearm and/or finger). Other sensed or determined data, such as user input, body temperature data, lighting data, weather-related data, and the like, may also be received from a motion sensing device or other device having sensor(s). The wearable device may include a plurality of sensors for capturing different types of data, for example, accelerometer data and at least one of body temperature data and lighting data. Step 4610 may be performed by sensor 103 of FIG. 1 and/or data acquisition component 210 of FIG. 2. Some embodiments of step 4610 may be similar to embodiments of step 410 of method 400 explained in conjunction with FIG. 4A. Additionally, some embodiments of method 4600 may include determining whether or not the sensor(s) are capable of properly receiving data, as described at step 420 of FIG. 4A.

At step 4620, hand movement is detected using accelerometer data. Step 4620 may be performed by the hand movement detector 264 embodiment of FIG. 2. Some embodiments of steps 4620 may be similar to embodiments of step 440 of method 400.

At step 4630, a computerized classification model is used to determine that the movement of the hands indicates a scratching event. This determination can be based on accelerometer data corresponding to hand movements. In some embodiments, step 4630 includes generating multivariate time series from accelerometer data corresponding to hand movement and determining feature values from the multivariate time series. The feature values may include at least one time domain feature value and at least one frequency domain feature value. Determining that hand movement indicates a scratching event can be based on feature values. Some embodiments of step 4603 may be performed by the embodiments described in connection with the scratch detector 260, and more specifically, the embodiments described in connection with the feature extractor module 266 and the scratch event classifier 268. Additionally, some embodiments of step 4630 may be similar to embodiments of step 450 of method 400. Some embodiments of method 4600 include recording a comb event definition, as described in more detail with respect to step 460 of method 400.

At step 4640, a treatment protocol for the itch being studied may be initiated based on at least a first determination that movement of the hands indicates a scratching event. Step 4640 may be performed by embodiments of decision support tool 270 (eg, tool 476) and/or presentation component 220 of FIG. Some embodiments of step 4640 may be similar to embodiments of step 470 of method 400. In some embodiments, the subject is diagnosed based on determining that hand movement indicates a scratching event, and the treatment protocol may be for the treatment of atopic dermatitis.

In some embodiments, the treatment protocol is further based on multiple definitions of multiple hand movements, each of which indicates a scratching event. For example, the treatment protocol may be based on a scratching pattern defined for the subject.

Some embodiments of step 4640 include determining at least one of a therapeutic agent, a dosage, and a route of administration of the therapeutic agent to determine a treatment protocol. In some aspects, the therapeutic agent is selected from the group consisting of the following: infliximab, adalimumab, belimumab, tanezumab, ranibizumab, bevacizumab, mepolizumab, certolizumab, natalizumab, ustekinumab, vedolizumab, 6-mercaptopurine, hydroxychloroquine, obeticholic acid, mycophenol, sodium lat, leflunomide, rituxan, solumedrol, depomedrol, betamethasone, prednisone, cyclosporine, tacrolimus, pimecrolimus, dupilumab, omalizumab, tralokinumab, etokimab, nemolizumab, tezepelumab, lebrikizumab, fezakinumab, anti-OX40, efalizumab, etanercept, crisaborole, ocinonide, mapracorate, hydrocortisone, desonide, aclomethasone, triamcinolone, deoxymethasone, loratadine, fexofenadine, desloratadine, levocetirizine, metapyrylene, cetirizine, budesonide, fluticasone, mometasone, dexamethasone, prednisolone, ciclesonide, beclomethasone, methotrexate, azathioprine, aspirin, ibuprofen, b, valdecoxib, WBI-1001 and /or MRX-6, abrocitinib, baricitinib, brepocitinib, cerdulatinib, decernotinib, delgocitinib, fedratinib, filgotinib, gandotinib, ilginatinib, itacitinib, lestaurtinib, momelotinib, oclacitinib, pacritinib, peficitinib, ritlecitinib, , tofacitinib, upadacitinib, THRX-212401, PF-07055087, PF-06471658, PF-07055090, ATI-502, BMS-986165, JTE-052, PF-06826647, SNA-152, SHR-0302, tapinarof and/or alitretinoin. In preferred embodiments, the therapeutic agent is crisaborole and/or abrocitinib.

In some embodiments, initiating a treatment protocol assignment includes generating a graphical user interface element provided for display on the user device. The graphical user interface element may indicate a treatment protocol recommendation that is based on the first determination that the movement of the arms represents a combing element. In one example, the user device is separate from the motion sensing device. For example, the motion sensing device may be an example of the computer user device 102a-c or the patient user device 102p of FIG. 2, while the user device may be the physician user device 108 of FIG. 2. Alternatively, the user device may be another computer user device 102a-c or the patient user device 102 of FIG. 2. Generating a graphical user interface element may be performed by or in combination with the embodiment of presentation component 220 of FIG. 2. Some embodiments of method 4600 further include applying a treatment protocol to a study subject based on the recommendation. Some embodiments of method 4600 may include determining full sleep capability based on accelerometer data, as described in more detail with respect to step 430 in method 400, and hand movement used to determine a scratching event may be detected from accelerometer data corresponding to full sleep capability. sleep.

Fig. 4H shows a flowchart illustrating an example method 4700 using scratch detection, in accordance with an embodiment of the disclosure. Method 4700 may be implemented through embodiments of one or more components of system 200, for example, scratch detector 260 and/or decision support tools 270 described in connection with FIG. 2. Exemplary aspects of computer program routines covering scratch detection implementations are illustrated illustratively in FIGS. 9A-11M and, in particular, FIGS. 10A-10I.

At step 4710, accelerometer data is received for the subject. The accelerometer data may be captured by a motion sensing device, which may be a wearable device associated with the subject located on a portion of the subject's body (eg, a person's wrist, forearm, and/or finger). Other sensed or determined data, such as user input, body temperature data, lighting data, weather-related data, and the like, may also be received from a motion sensing device or other device having sensor(s). The wearable device may include a plurality of sensors for capturing different types of data, for example, accelerometer data and at least one of body temperature data and lighting data. Step 4710 may be performed by sensor 103 of FIG. 1 and/or data acquisition component 210 of FIG. 2. Some embodiments of step 4710 may be similar to embodiments of step 410 of method 400 explained in conjunction with FIG. 4A. Additionally, some embodiments of method 4700 may include determining whether or not the sensor(s) are capable of properly receiving data, as described at step 420 of FIG. 4A. In some embodiments, accelerometer data is captured through a sensor integrated into a first wearable device and a second wearable device worn simultaneously by the subject. For example, the subject may wear a wrist-worn motion sensing device on each of the subject's wrists.

[0001] At step 4620, one or more comb endpoints for the subject are provided for display on the user device. Brushing endpoints are based on determining that one or more hand movements detected from accelerometer data indicate scratching events. Detecting one or more hand movements from accelerometer data may be performed by the hand movement detector 264 embodiment of FIG. 2, and as described with respect to step 440 of method 400. Additionally, determining one or more hand movements indicates that scratching events may be performed using computerized classification model through the embodiment described in connection with the scratch detector 260, or more specifically, the feature extraction module 266 and the scratch event classifier 268, and/or as described in more detail with respect to step 450 of the method 400. The scratch endpoints may include a general the number of scratching events and/or the total duration of scratching, among others. The scratching endpoints may be limited by the subject's sleep capacity (e.g., full sleep capacity), as described in more detail with respect to step 430 in method 400.

A graphical user interface element may be provided for display on a user device that is operably coupled to a wearable device having sensors that capture accelerometer data. For example, the user device may be a smartphone that connects to a wearable device that captures accelerometer data. Exemplary embodiments of the user device and wearable device include the computer user device 102a-c, the patient user device 102n, and the physician user device 108 of FIG. 1.

Some embodiments of method 4700 include providing, for display, on a user device, a treatment protocol for an atopic dermatitis being studied for treatment. The treatment protocol may include a therapeutic agent, dosage and/or route of administration and may be based on one or more scratching endpoints. Exemplary therapeutic agents that may be included in method 4700 include the therapeutic agents described at step 4640 in method 4600.

FIG. 5 is a flowchart illustrating a method 500 for predicting redness, in accordance with an embodiment of the disclosure. Method 500 may be implemented by one or more components of system 200, such as redness predictor 290, including subcomponents thereof. Similar to method 400, each block or step of method 500 contains a computation process that can be performed using any combination of hardware, firmware and/or software. For example, various functions may be performed by a processor executing instructions stored in a storage device. The method may also be implemented as computer-usable instructions stored on computer storage media. The method may be provided through, but not limited to, a stand-alone application, service, or hosted service (standalone or in combination with another hosted service), or a plug-in for another product. Accordingly, method 500 may be implemented through one or more computing devices, such as a smartphone or other user device, a server, or through a distributed computing platform, such as in a cloud environment.

At block 510, the user's scratching patterns may be determined. Step 510 may be performed by an embodiment of the combing pattern assembler 292 of FIG. 2. Brushing patterns may be determined from statistical data of user scratching events, for example, statistical scratching events 244 stored in the user's personal record 240, as described in conjunction with FIG. 2. The scratching event statistics include scratching endpoints determined from detected scratching events, such as total numbers of scratching events, total scratching durations, durations between scratching events, and/or the ratio of durations between scratching events and number of scratching events. The scratching pattern may indicate a change in the endpoints of scratching events, for example, an increase in the number of weekly scratching episodes or a decrease in the duration between scratching events.

At block 520, context information may be determined. Step 520 may be performed by an embodiment of context data determination module 294. Certain contextual information may include weather information, for example, ambient temperature and/or humidity; the user's medical information, such as the user's age, weight, diagnosed conditions, previous prescriptions or therapeutic agents, and the user's current medications; and user input data, such as user-defined scabies ratings, notes, photographs of the user's skin, and/or treatment seeking logs. In some embodiments, the user's medical data may be determined from the user's profile/health record (EHR) 241 stored in the personal record 240 of FIG. 2.

At step 530, the user's scabies may be determined for a future time slot. Step 530 may be performed by an embodiment of a scabies predictor 296. The determined future scabies represents the probability of future scabies within a future time frame, for example, tomorrow, the next day, or five days in advance. The determined future scabies may include a level or absolute value that may represent the severity level of the predicted or future scabies.

Future scabies may be determined at step 530 using the user's scratching patterns and contextual information determined at steps 510 and 520, respectively. Various types of logic may be used at step 530 to determine the user's scabies in the future. As described with respect to the scabies prediction logic 259 of FIG. 2, future scabies may be determined using rules, conditions, thresholds, associations, machine learning models, or other criteria to infer or detect the likelihood of scabies (either overall or level/severity of scabies ) arising in the future. For example, fuzzy logic, neural network(s), finite state machine, support vector machine, logistic regression, clustering, other machine learning techniques, similar statistical classification processes, or a combination thereof may be used at step 530.

It can be appreciated that the user's scabies may be determined for several future time frames, and the predicted level of scabies may vary in different time frames. For example, at step 530, the user may be determined to have a "low" level of scabies after two days, but may be determined to have a "high" level of scabies after five days.

At step 540, the probability of a redness event within a future time interval can be determined. Step 540 may be performed by an embodiment of a scabies predictor 296 or, more generally, a redness detector 290 . Determining the likelihood of a future flushing event may include comparing the predicted level of scabies to one or more redness detection thresholds to determine whether or not the predicted level of scabies is of sufficient severity to constitute a risk of flushing. In some embodiments, the redness detection threshold(s) may be predetermined based on the reference population such that the redness detection threshold(s) can be used for the population as a whole. In other embodiments, the redness detection threshold(s) are determined for each person being tracked. For example, the redness detection threshold may be set based on statistical information of the user, including medical data such as condition and age. Additionally, the redness detection threshold(s) may be set by the user's physician/caregiver and/or adjustable by the user. This predetermined threshold may be stored in the settings 249 of the personal card 240, as described in FIG. 2.

At step 550, an action may be triggered based on the determined probability of the user's redness and/or scabies event. In this regard, step 550 may be performed by an embodiment of a redness notification generator 298 and/or a decision support tool 270, such as a tool 272, 274, or 276. In some embodiments, a redness notification or emergency an alert indicating the user's risk of scabies and/or redness may be generated. In one exemplary embodiment, in which the level of scabies meets a redness detection threshold, a notification regarding redness indicating a risk may be sent to the user device of the monitored user. In another exemplary embodiment, a notification regarding redness is sent to the doctor's user device, accordingly, for appropriate treatment of the monitored user by the doctor. Exemplary embodiments of a redness notification generated in accordance with embodiments of step 550 are described below with respect to FIGS. 8D-8F and above with respect to FIG. 3B. For example, a notification regarding blushing may provide contextual or statistical information.

Initiating an action at step 550 may also include generating recommendations or directives, or initiating actions based on the level of scabies or risk of redness. As an example, a recommendation to schedule a caregiver visit, refill a prescription, and/or add over-the-counter therapeutics to the user's shopping list may be generated and presented to the user. Additionally, in some embodiments, initiating an action may include adding the prediction to the user's electronic calendar, for example, in a monitoring or tracking application, or modifying a user interface element on the user's device to indicate the predicted risk in the electronic calendar. Some embodiments of step 550 include initiating steps for treating the user's itching (or more specifically, atopic dermatitis) using one or more therapeutic agents, for example, crisaborole and/or abrocitinib, based on a redness prediction generated using the data obtained using a sensor on a wearable device, as described with respect to decision support tool 276. Method 500 may include tracking and/or monitoring the administration and use of a therapeutic agent according to the recommended or instructed treatment protocol provided at 470.

Additionally, some embodiments of step 550 may include the use of a response log, for example, logs 246 in FIG. 2, indicating how the user responds to a notification regarding the predicted risk of scabies or redness, and/or maintaining a recommendation that to improve the scabies/redness predictor. For example, subsequent scratching, scabies prediction, and/or flushing prediction events may be correlated with a prior scabies or flushing prediction and response, which may indicate whether or not the generated response results in an increase or decrease in scratching events and/or an increase or decrease in the predicted level of scabies. or risk of redness.

Fig. 6A-F illustrate aspects of example embodiments of sleep detector training. Fig. 6A provides a schematic representation of an example process 600 for training a scratch detector. The exemplary process 600 is a supervised learning process that generates and uses labeled data based on video annotations of accelerometer data. An exemplary pipeline for training a comb classifier may include steps for preprocessing (including data preprocessing at block 610 and signal preprocessing at block 620), feature engineering at block 630, and feature selection, model training, and model evaluation at block 640. .

Data preprocessing at block 610 includes, at step 612, combining the video commentary with the accelerometer data. To generate labels for training a scratching classifier, comments on nighttime scratching and restless (other than scratching) movements can be created by human commenters who watch thermal videos of the subject's clinic visits. Comments may be completed by two human comment writers and reviewed for accuracy by an arbitrator. Each comment may include metadata indicating which hand is being moved (right, left, or both) in embodiments in which the sensors are worn on both hands; affected location of the body; as well as the severity (soft, medium, heavy) of scratching. To accurately use reference video annotations, all annotations may be time-aligned with accelerometer data at step 612. Alignment of video annotations and accelerometer data may be performed manually based on a prescribed hand clapping event (i.e., subjects may be instructed to clap their hands in front of the camera while wearing accelerometer devices ) during each clinic visit.

Data preprocessing further includes, 614, downsampling accelerometer data to 20 Hertz (Hz), which helps maximize battery life. Data preprocessing further includes comment filtering, at block 616. In example aspects, comments of three seconds or more may be used in training a binary classifier. If the comment is longer than three seconds, it may be segmented into three second windows, at step 616. In some embodiments, the windows may overlap, for example, with 50% overlap in three second windows. Step 616 may also include determining whether or not hand movement is present throughout the annotated three second window, and filtering out data that does not have hand movement therein.

The preprocessed data from block 610 may then be passed to block 620 for signal preprocessing. Signal preprocessing steps in block 620 may be similar to preprocessing step 4052 described in connection with FIG. 4E and may include segmenting and applying filtering and dimensionality reduction to the raw accelerometer data. First, the X, Y, and Z axis signal segments may be segmented into 3 second windows (similar to video commentary), at step 622. At step 624, the X, Y, and Z axis data may be filtered using a high pass filter such as a first-order IIR high-pass Butterworth filter with a cutoff frequency of 0.25 Hz. Next, to reduce dependence on device orientation, the transformed signals can be extracted from the filtered signal at step 626. For example, the vector magnitude and the first and second principal components of the filtered signal can be calculated.

The converted signals can then be passed to block 630 for feature engineering. At step 632, a total of 36 time and frequency domain features are extracted from the transformed signals for each window. These 36 signs may include, but are not limited to, the following:

- Root Mean Square (RMS) vector absolute value - RMS is a measure of signal energy and can be correlated with the magnitude and intensity of traffic;

Vector Absolute Magnitude Signal Range The signal range is a measure of extreme motion values observed in a given time window of sensor data, where a higher range may indicate the occurrence of a large deviation in sensor values;

- Entropy of vector absolute magnitude signals, first principal component and second principal component - the entropy of signals can be calculated by estimating the Shannon entropy of the signal's mass distribution function. Signal entropy values close to zero may indicate that the signal is periodic and smooth, while large negative values may indicate that the signal is irregular and non-periodic;

Interquartile range (IQR) of autocovariance of vector absolute value, first principal component and second principal component—IQR of autocovariance is an indicator of the dependence or long-range periodicity of a signal and can capture whether a signal is periodic or irregular or not;

Skewness of vector absolute value, first principal component and second principal component - skewness is a measure of asymmetry in the signal;

- Dominant frequency value of the first principal component and the second principal component - the dominant frequency value represents the frequency value with the largest absolute value in the normalized power spectrum of the accelerometer signal and captures the fundamental frequency of the root motion generating the acceleration signal;

- Absolute value of the dominant frequency of the first principal component and the second principal component - the absolute value of the dominant frequency captures the percentage of the total energy of the signals at the dominant frequency;

- Ratio of the dominant frequency band to the total energy in the spectrum of the first principal component and the second principal component - this feature captures the periodicity of the signal by calculating the ratio of the energy in the dominant frequency component to the sum of the energy in the entire frequency spectrum of the signal;

- The average cross-tempo of the vector absolute value, the first principal component and the second principal component, the average cross-tempo calculates the number of times the signal changes from positive to negative, and can be normalized by the total length of the signals;

- Ratio of the sharp deviations of the vector absolute value, the first principal component and the second principal component - the ratio of the sharp deviations may represent a calculation of motion smoothness;

- Logarithmic dimensionless sharp deviation of the vector absolute value, the first principal component and the second principal component - this feature can also represent a calculation of the smoothness of movement;

- SPARC of vector absolute value, first principal component and second principal component - this feature may also represent a motion smoothness calculation;

- The permutation entropy of the vector absolute value, the first principal component and the second principal component permutation entropy is an indicator of the complexity of the signal;

- Spectral smoothness of the first principal component and the second principal component - spectral smoothness captures the amount of modulation or level of consistency and can vary from 0 to 1; And

Spectral entropy of the first principal component and the second principal component - Spectral entropy can be calculated by estimating the Shannon entropy of the mass distribution function of the signal's power spectrum, with values close to 1 indicating the presence of white noise and values close to 0 indicating the presence of periodicity in the signal .

At step 634, principal component analysis (PCA) is used to determine the importance of features in indicating whether the movement represents a scratching event or not, and the 36 features may be ranked according to their relative importance. In one embodiment, data from a random subset of 15 subjects may be selected to analyze the importance of features in the scratching classifier. Feature importance can be determined from summary values based on the Shapley Additive Explanatory Principle (SHAP), which ranks the top 20 features based on their importance for comb detection.

In an exemplary embodiment, it is determined that signal periodicity, smoothness, and dominant frequency may represent the predominant features of a scratch classifier. Specifically, in one embodiment, the average cross-tempo of the second principal component signal may be determined as the most influential feature for the example classifier. Additionally, higher values of this feature may result in higher SHAP values, which in turn indicates a higher probability that the model should predict combing for a given window. Measures of smoothness (spectral arc length measure (SPARC)) and dominant frequency may also provide influential cues to distinguish scratching movements, since higher SPARC values (i.e., smoother signal) and lower dominant frequency values tend to result in a lower probability of predicting scratching by the classifier.

Once feature importance has been determined, feature selection and machine learning model training may be performed in accordance with a leave-one-out (L0S0) validation process, as illustrated by block 640. At block 642, observations may be randomly sampled to balance positive and negative classes before feature selection. At block 644, feature selection may be performed using recursive feature elimination with cross-validation (RFECV) using a decision tree estimator. In one embodiment, a subset of the following 26 features may be selected during step 644: RMS (vector absolute magnitude); entropy of signals (vector absolute value, first principal component and second principal component); Autocovariance IQR (vector absolute value, first principal component and second principal component); skewness (first principal component and second principal component); the value of the dominant frequency (first principal component); absolute value of the dominant frequency (first principal component and second principal component); average cross-tempo (second principal component); ratio of sharp deviations (vector absolute value and second principal component); logarithmic dimensionless sharp deviation (first principal component); SPARC (vector absolute value, first principal component and second principal component); permutation entropy (vector absolute value, first principal component and second principal component); spectral smoothness (first principal component and second principal component); spectral entropy (second principal component); and signal range (vector absolute value).

Fig. 6B illustrates a graphical illustration 6300 of another embodiment of a feature constructor 630. As illustrated by graphical representation 6301, principal component analysis (PCA) is used to determine features that are most likely to be used with a classifier to indicate a likely scratching event. Additionally, graphical representation 6351 illustrates ranking of features based on feature importance. A subset 6255 of features may be selected from the highest ranked features according to importance and as such used for training and executing the classifier. The particular subset 6255 illustrated in FIG. 6B is one exemplary subset, but it is contemplated that other subsets, such as the 26 features listed above, may be selected in other embodiments. In another embodiment, for example, the highest ranking features corresponding to importance and used for training and execution of the classifier may be average cross rate (principal component 2), SPARC (vector absolute value), dominant frequency value (principal component 1), flare ratio (vector absolute value), flare ratio (principal component 2), logarithmic dimensionless sharp deviation (principal component 1), interquartile range (principal component 2), permutation entropy (principal component 2), root mean square (vector absolute value) ) and SPARC (principal component 2).

Continuing with FIG. 6A, at step 646, a classifier may be trained according to a selected subset of features. For example, a random forest classifier with 50 scoring units can be trained with the above 26 features. As the classifier is trained, a validation of the classifier's performance is performed at step 648.

The performance of the binary classifier (ie, accuracy, sensitivity, specificity, F1 score, and area under the receiver operating characteristic (ROC) curve) can be assessed using a LOSO validation procedure. Additionally, during training, several adjustments to the number of scoring units in the random forest classifier can be made and evaluated to determine effects on performance. In one embodiment, the classifier may be trained with 25, 50, 75, or 100 scoring units.

Performance aspects of an embodiment of the trained model are illustrated in FIGS. 6C-D. Fig. 6C provides a graphical illustration 6400 of a performance validation of an exemplary trained scratch detector, in accordance with an embodiment of the present disclosure. In FIG. 6C, signal 6410 may be an example triaxial accelerometer data signal that may be obtained from the sensor(s) of the user being tracked over time. Signal 6440 may be a hand movement detection signal that, when combined with signal 6410, indicates portions of the accelerometer data that correspond to detected hand movements. In FIG. 6C, the shaded areas in signal 6440 indicate the location at which hand movement is detected. Signal 6450 may be a scratch prediction signal that, when combined with signal 6410, indicates portions of the accelerometer data that correspond to predicted scratch events. Finally, signal 6405 may be a reference video signal that, when combined with signal 6410, indicates portions of the accelerometer data that correspond to times at which the reference video data is annotated as a scratching event. Thus, signal 6405 serves as a reference, and a comparison of signal 6450 with signal 6405 indicates the accuracy of the scratch prediction model.

Fig. 6D illustrates the statistical performance of 6480 example trained scratch detectors, in accordance with some embodiments of the disclosure, actually reduced in practice. Fig. 6D includes 6482 feature metrics that show the sensitivity and specificity of a first model (e.g., a scratching event classifier) trained to detect periods of scratching and no scratching association, compared to an annotated video. Fig. 6D further includes a graphical illustration 6484 of characteristics in the form of a receiver operating characteristic (ROC) curve for the first trained brush event classifier. The area under the curve (AUC) for the trained classifier is 0.85, according to Figure 6D. Fig. 6D also shows metrics of the 6486 features and a graphical illustration of the 6488 features in the form of a ROC curve for the second model trained to detect scratching. It is further contemplated that any model fitting procedure or technique known to those skilled in the art can be used to verify the validity of the model.

Fig. 6E illustrates sleep-related signal time series 6500 and signal analysis, in accordance with an exemplary sleep/wake detection embodiment. The accelerometer signal 6510 is a triaxial accelerometer data signal that may be received from a sensor, for example, sensor 103 of FIG. 1. Temperature signal 6520 indicates the temperature around the body of the monitored user. The body signal(s) 6580 indicates when the sensor is being worn and may be output by an embodiment of the sensor wearing detection module 261 of FIG. The body signal(s) 6580 may be derived from the accelerometer signal 6510, as described in connection with FIG. 4B. Additionally or alternatively, temperature signal 6520 may be used to generate body signal(s) 6580, as described at step 420 of FIG. 4A. Fig. 6E illustrates two body signals 6580; “wearable” may represent the initial signal, and “wearable (re-quantification)” may illustrate the signal after re-quantification, as described in connection with the sensor wear detection module 261 of FIG. 2.

Additionally, in FIG. 6E, lighting signal 6530 indicates amounts of ambient lighting detected by the sensor. The forearm flexion angle signal 6550 indicates the change in the forearm position signal over time and may be extracted from the accelerometer signal 6510, as described in connection with FIG. 4C. The forearm flexion angle signal 6550 may be an output of an embodiment of the sleep capability determination module 262 of FIG. 2. The immobility signal 6570 indicates periods in which it is determined that the user is immobile or intends to sleep. In this regard, the immobility signal 6570 may represent a sleep opportunity and may be output by the sleep opportunity determination module 262 of FIG. 2. The immobility signal 6570 may be derived from the forearm flexion angle signal 6550, as described in FIG. 4C. In other embodiments, the immobility signal 6570 may be derived from the lighting signal 6530, alone or in combination with the accelerometer signal 6510 or the forearm flexion angle signal 6550.

Additionally, in FIG. 6E, activity signal 6540 indicates activity index values and may be extracted from accelerometer signal 6510, as described in connection with FIG. 4D. The activity signal 6540 may be an output of an embodiment of the activity index determination module 232 of FIG. 2. Additionally, the wake signal 6560 indicates periods during which the user is detected as awake, which also indicates when the user is asleep, according to periods when the wake signal 6560 is not observed in FIG. 6E. The wake signal 6560 may be extracted from the activity signal 6540 and may be the output of an embodiment of a sleep/wake detector 230 or, more specifically, a sleep/wake classifier 234 .

Fig. 6F illustrates a performance check 6501 of an exemplary sleep capability determination algorithm, for example, the algorithm described in connection with FIG. 4C, and some embodiments of the sleep capability determination module 262 of FIG. 2 and step 430 of FIG. 4A.

In this performance validation 6501, determinations of immobility using the Total Sleep Opportunity (TSO) algorithm disclosed herein are compared with determinations of immobility using polysomnography (PSG), which is reported as PSG TSO. PSG definitions represent a basis or reference that is compared with the TSO determined by embodiments of the present disclosure, for example, with the TSO discovered by process 4300 of FIG. 4C.

Plots 6502 and 6504 indicate the performance of the disclosed TSO algorithm as determined by sensor data from the left wrist and right wrist, respectively. Plot 6506 shows the agreement between the left wrist and right wrist TSO determinations. In particular, plot 6506 indicates that the agreement is strong or correlated, which means that the TSO algorithm disclosed herein can be accurate enough to work with a single wrist: either a left wrist-based detection or a right wrist-based detection ( dominant or non-dominant) TSO. Using this technology, embodiments of the present disclosure can be used more accurately for single-wrist operation, which represents an improvement over traditional technologies that require dual-wrist operation. Additionally, since the algorithm for TSO detection can also be used in scratch detection, as described with respect to FIG. 4A, by confirming the accuracy of the TSO through the performance validation shown in plots 6502, 6504, and 6506, the disclosed night scratch detection algorithm (e.g., as described in 4A and 4E) is more accurate.

Fig. 7A exemplarily shows a plot 7400 of accelerometer signals indicating detected hand movement. The accelerometer signals are divided into three-axis signals (X, Y and Z) and are similar to the accelerometer signal 6510 of FIG. 6E. The vertical bars in plot 7400 (at approximately 21:53:13.5 and 21:53:19 in FIG. 7A) represent the start and end, respectively, of detected hand movement. In this regard, vertical bars indicating hand movement may represent an exemplary output of hand movement detector 264 in FIG. 2, from step 440 in FIG. 4A, and/or from step 4040 in FIG. 4E.

Fig. 7B illustrates exemplary scratch detection results of 7,500 over five days using exemplary embodiments of the algorithms described in connection with FIGS. 4A, 4C, 4E, and 4D. Fig. 7B includes a summary table 7510 of the determination results and a graphical representation 7520. The results in FIG. 7B are for detecting nighttime scratching over a 5-day sensor data record. As described with respect to FIGS. 4A and 4E, scratching events are detected during sleep opportunities and therefore represent nighttime scratching. Additionally, sleep/wake periods can be detected by the sleep/wake detector embodiment 230 of FIG. 2. The 7510 summary table includes digital sleep endpoints as well as scratching endpoints. In some embodiments of the comb monitor application shown in FIG. 8 B, the “charts” tab 8230 may include tables, charts, or graphs, such as a summary table 7 510 or a graph 7520.

Fig. 8A-8E illustratively show various exemplary screenshots from a computing device showing aspects of exemplary graphical user interfaces (GUIs) for a computer software application or application. In particular, the exemplary GUI embodiments illustrated in the screenshots of FIGS. 8A-8E are for a computer decision support application, referred to in these examples as a “combing monitor application.” The comb monitor application 8101 (computer software application) may include an implementation of a decision support application 105a or 105b and/or may include an implementation of one or more decision support tools 270, as described in connection with FIGS. 1 and 2. respectively.

With reference to FIG. 8A, illustrative aspects of GUI 8100 are provided showing an exemplary embodiment of a computer software application 8101 (sometimes referred to herein as a “scratch monitor application”) for providing decision support for users having atopic dermatitis, itch, or a similar condition. An exemplary computer software application 8101 may run (and a GUI 8100 may be displayed) on a user computing device 8102a, which may be implemented as the user device 102a-102n described in connection with FIG. 1. At a high level, the exemplary scratch monitor application 8101 may be used, among other purposes, to access, view, monitor, augment, and/or report scratch detection and/or sleep related data to a user that is detected by embodiments of technologies described in this document. Some embodiments of the scratch monitor application 8101 may additionally or alternatively provide functionality related to redness prediction and scabies prediction.

In some embodiments, it is contemplated that the prescribed or recommended standard of care for a patient diagnosed with atopic dermatitis (or a similar condition) may comprise the use of an embodiment of a scratch monitor application 8101 that may run on the user/patient's own computing device, such as a smart watch, mobile device, or other user device 102a-102n, or may be provided to the user/patient through the patient's healthcare provider or pharmacy.

In particular, as described herein, traditional solutions for monitoring and tracking user scratching, such as the need for users to track and report scratching behavior, may suffer from subjectivity and inconsistency, less accuracy, inconsistent capture, and other shortcomings. However, embodiments of the technologies described herein may provide an objective and/or uniform, consistent and more accurate means of monitoring, detecting and tracking scratching (and sleep) related data for the user. As a result, these embodiments thereby enable reliable use of these technologies for patients prescribed certain medications. Thus, a doctor or health care provider may issue a prescription that involves the patient taking the medication and using a computer decision support application (eg, scratch monitor application 8101) to, among other things, monitor and determine the exact effectiveness of the prescribed treatment. In addition, the use of a computer decision support application (eg, scratch monitor application 8101) as part of the standard of care for a patient who is assigned or prescribed a particular medication supports effective treatment of the patient. Effective treatment, in some embodiments, is achieved by allowing the health care provider to better understand the effectiveness of a prescribed medication, modify the dosage, change a specific prescribed medication, or instruct the patient to discontinue use of it because it is no longer needed due to improvement in the patient's condition.

Additionally, continuing with FIG. 8A, the comb monitor application 8101 illustrated in the GUI 8100 includes an icon menu 8110 containing various user selectable icons 8111, 8112, 8113, 8114 and 8115 that correspond to various additional functionality provided through the application 8101 comb monitors. In particular, selecting these icons may navigate the user to various services or tools provided through the comb monitor application 8101. By way of example and without limitation, the home screen icon 8111 may navigate the user to a home screen, which may include a calendar view 8105 illustrated in GUI 8100, one of the example GUIs described in connection with FIGS. 8B, 8C, 8D or 8E, a welcome screen (not shown), which may include one or more commonly used services or tools provided through the comb monitor application 8101, or any other view (not shown).

Selecting the log icon 8112 may navigate the user to a scratch log tool (which may be indicated by a handle to the scratch log 8201) that contains functionality to facilitate scratch or sleep-related detection, tracking, and/or monitoring. In an embodiment, the brush log 8201 includes a calendar view 8105 or an alternative calendar view 8505 illustrated in FIG. 8E. The functionality associated with the brush log 8201 or the log icon 8112 may also include a GUI and tools or services for daily tracking and monitoring, for example, the GUI and tools or services described in connection with FIG. 8B. Selecting the prediction icon 8113 may navigate the user to a scratch prediction-related or scabies prediction-related GUI, which may include one or more scabies prediction-related tools and services. Additional details of the prediction functionality associated with prediction icon 8113 are described in connection with FIG. 8C. Selecting the reports icon 8114 may navigate the user through the GUI to view and generate various reports about scratch detection and/or sleep related data detected by the embodiments described herein. Selecting the settings icon 8115 may navigate the user to a user settings configuration mode, which may allow the user to specify various user preferences, settings or configurations of the scratch monitor application 8101, aspects of sleep and scratch detection, user care/treatment, or other settings. In some embodiments, at least a portion of the settings may be configured by the user's healthcare provider or physician. Some of the settings available through the settings icon 8115 may include the settings explained in connection with settings 249 of FIG. 2.

The example comb monitor application 8101 illustrated in the GUI 8100 includes a header area 8109 located near the top of the GUI 8100. Specifically, this example header area 8109 includes a hamburger icon 8103, a handle 8201 indicating "Comb Log", sharing icon 8104, stethoscope icon 8106, and cycling icon 8108. Selecting the hamburger icon 8103 may provide the user with access to a menu of other services, features, or functionality of the comb monitor application 8101 and may further include access to help, application version information, and access to secure user account login/logout functionality. The Comb Log display handle 8201 indicates to the user the mode, feature set, or aspect of the Comb Monitor application 8101 that the user is navigating. Here, the descriptor 8201 indicates that the user is in the comb log functionality of the comb monitor application 8101, which may be accessed by selecting the log icon 8112. The sharing icon 8104 can be selected to share various data, reports, user-provided comments, or observations (eg, notes or photographs). For example, the sharing icon 8104 may facilitate the ability for a user to email a report of recent nights' scratching events to the user's caregiver. In some embodiments, the sharing icon 8104 may facilitate sharing aspects of various data captured, displayed, or accessible through the comb monitor application 8101, on social networks, or with other similar users. Selecting the stethoscope icon 8106 may provide the user with various options to communicate or connect with the user's healthcare provider. For example, selecting a stethoscope icon 8106 may trigger functionality to facilitate scheduling a televisit, sharing or uploading data to a user's medical record (e.g., profile/health 241 (EHR)) for access by the user's healthcare provider, or accessing an online healthcare provider portal for additional services. In some embodiments, selecting the stethoscope icon 8106 may trigger functionality for the user to communicate specific data, such as the data the user is currently viewing, to the user's healthcare provider, or may check the reach of the user's healthcare provider to prompt the user to review the user's data. . Finally, selecting the looping icon 8108 may cause an update or adjustment to the views and/or data displayed via the comb monitor application 8101 so that the view is current relative to the available data. In some embodiments, selecting the loop icon 8108 may update data retrieved from a sensor (or from a computer application associated with collecting data from a sensor, e.g., sensor 103 in FIG. 1) and/or from a cloud data store (e.g. , online data account) associated with the user.

The brush monitor application 8101 illustrated in GUI 8100 may also include a calendar view 8105. Embodiments of the calendar view 8105 may facilitate accessing or displaying detected and interpreted sleep and/or brush related data to a user. For example, by selecting a particular date on calendar view 8105, the user may be presented with a daily (or nightly) summary of data for that date, for example, provided through the GUI 8200 described in connection with FIG. 8B. In some embodiments of calendar view 8105, indicators or the information may be displayed by calendar date, indicating scratch-related or sleep-related information associated with that date. For example, the alternative calendar view 8505 described in FIG. 8E illustrates flame indicators on dates associated with redness.

Turning now to FIG. 8B, another aspect of the brush monitor application 8101 is illustrated, including the GUI 8200. The GUI 8200 includes user interface (UI) elements for displaying or receiving brush-related or sleep-related data and corresponds to log functionality. indicated by the log icon 8112. In particular, GUI 8200 illustrates an example of a daily data summary 8202 for a user and may be an example of information that is displayed to the user when a specific calendar date is selected from the calendar view 8105 (FIG. 8A), or information that is presented to the user when the log icon 8112 is selected. from menu 8110. The GUI 8200 includes a descriptor 8203 indicating that the nightly summary 8202 is set for the date Sunday, January 12th.

As shown in this example GUI 8200 of the comb monitor application 8101, the log functionality includes five selectable tabs: metrics 8210, charts 8230, photos 8240, notes 8250, and treatments 8260. According to the GUI 8200, as shown in FIG. 8 B, a tab 8210 for metrics is selected and thereby various metrics and metrics are presented to the user. In particular, metrics 8210 may include scratching metrics 8212, sleep metrics 8216, and a visual summary 8218 (of detected user activity and scratching events, as shown in FIG. 8B) corresponding to user data detected overnight on Sunday, January 12th. . In some embodiments, scores may be represented as numbers, categories, colors, or a combination of these features. For example, here the scratch score 8212 is "36" and may be colored green to indicate that it represents a desired score for the user. The sleep score 8216 is presented as a "Very Good" category, but may alternatively be presented as a number or color.

In some embodiments, the scratch score 8212 may be displayed with various scratch-related analytics data 8213. By way of example and without limitation, the data 8213 may include: a scratch trend, which indicates whether the user's scratching behavior is increasing, decreasing, or remaining the same over time. recent nights (for example, the previous 3 nights, 5 nights or week); number of weekly or daily scratching events detected (e.g., 12 scratching events); total scratching time, which represents the accumulated total amount of time of detected nightly scratching events (eg, 84 seconds); average duration of detected scratching events (e.g., 7 seconds); and the duration of the longest scratching detected (e.g., 12 seconds). Likewise, the sleep score 8216 may be displayed with various sleep-related analytics data 8217. By way of example and without limitation, the data 8217 may include: sleep percentage, which represents the ratio of the user's detected sleep time per time interval (here shown as 86 %) sleep capabilities (eg TSO); total sleep time (TST), sleep onset latency (SOL, measured in minutes); wakefulness after sleep onset (WASO, measured in minutes); and number of awake bouts (NWB). Other sleep-related metrics may also be presented, and in some embodiments, the user may customize the information that is displayed, including scores, metrics, and visual summary 8218, by configuring settings (eg, through a settings icon 8115). Likewise, in some embodiments, other related data, such as temperature or humidity data, may be displayed along with the score(s).

Continuing with the GUI 8200 shown in FIG. 8B, a chart tab 8230 may be selected by the user to create or display various charts, graphs, or interpreted scratch-related or sleep-related data (eg, summaries and trend analyses) for the user. Examples of charts that may be presented via charts 8230 are illustrated in FIG. 8F, which shows various sleep analytics data as a table 8600 and charts 8700. Another example of charts that may be created or displayed via charts 8230 is provided in FIG. 7B .

Continuing with FIG. 8B, selecting the tabs for photos 8240 and notes 8250 may navigate the user to functionality for the comb monitor application 8101 (or more specifically, to the log functionality associated with the log icon 8112) for receiving and displaying observation data. from the user or caregiver for that specific date. Examples of observational data may include notes and/or photographs documenting or relating to the user's brushing or sleeping behavior. In some embodiments, notes 8250 includes a UI for receiving text (or audio or video) from the user. In some aspects, the notes UI functionality 8250 may comprise a GUI displaying a human body configured to receive input from a user indicating areas of the user's body affected by scabies or scratching. In addition or alternatively, some embodiments of notes 8250 may include UI input functionality for a user to indicate a subjective rating of scabies or scratching they experience over a nightly time interval.

In some embodiments, users may enter other contextual information such as their location, weather, and any physical activity they engage in during the day, for example, into notes 8250. In some cases, data such as the user's location and weather , may be determined automatically, for example, by using location sensors on the user computing device 8102a and retrieving weather information for the location of the user device. In some embodiments, as described in connection with context data determination module 294 (FIG. 2), these user-provided observations may be analyzed for contextual information, which may then be used to generate predictions or decision support information for the user.

In some embodiments, photos 8240 may include a UI for receiving photos or videos from a user. Photos 8240 may also include functionality for snapshotting photos or videos on a user computing device 8102a running the comb monitor application 8101. For example, for a given day, the user may select notes 8250 to add a note indicating that the user did not sleep well and was itching all night. The user may also or alternatively snap a photo on the user computing device 8102a to log this data after selecting the photo tab 8240. The photograph may contain a lesion or otherwise affected area of the user's skin.

Selecting a treatment indicating tab 8260 on the GUI 8200 may navigate the user to the UI in the comb monitor application 8101 with functionality for the user to indicate information such as whether the user is (or is) not administering a treatment on that date. For example, a user may indicate that their prescription topical drug is to be applied to an affected area of the user's body. It is also contemplated that in some embodiments, smart pill boxes or smart containers, which may include so-called Internet of Things (IoT) functionality, can automatically detect that a user is accessing medication stored in the container and can transmit in the scratch monitor application 8101, an indicator indicating that the user is applying treatment on a given date. In some embodiments, the treatment tab 8260 may include a UI allowing the user to indicate their treatment, for example, by selecting check boxes indicating the type of treatment the user is following as of that date (e.g., applying OS lotion, taking a bath, avoiding sun exposure, is using a prescription drug for topical use (or oral administration, etc.).

Turning now to FIG. 8C, another aspect of an exemplary scratch monitor application 8101 is illustrated, including a GUI 8300. The GUI 8300 includes various UI elements for displaying the scabies prediction(s) and related information to the user. As described herein, some embodiments may determine a scabies prediction representing the user's expected scabies (or scratching) to occur at a future time or over a future time interval (e.g., as described in connection with FIG. 5 and the redness predictor 290 Fig.2). As described in more detail herein, the scabies prediction may be personalized to the user and may be based on the user's statistical scratching pattern. In some cases, scabies prediction may additionally be based on contextual data, such as weather, user observations, medical or physiological data, or other contexts. Alternatively, according to other embodiments described herein, the scabies prediction may be determined according to predefined rules or conditions and therefore not be personalized for a particular user. Alternatively, according to other embodiments, the scabies prediction may be determined based on data from other users that are similar to a particular user of the scratch monitor application 8101. Additional information on scabies prediction determination is provided in connection with the redness predictor 290 of FIG. 2 and the method 500 of FIG. 5.

The exemplary GUI 8300 includes a handle 8303 indicating the current date when the user accesses the prediction functionality of the scabies monitor application 8101 (e.g., today, Tuesday, March 17, 2020) and the user's scabies prediction 8301 . As shown in FIG. 8C, menu 8110 indicates that a prediction icon 8113 is selected, which may present the user with a GUI 8300 illustrating the user's scabies prediction 8301. The exemplary scabies prediction 8301 illustrated in GUI 8300 may include information that predicts scabies or scratching by a user for one or more future time intervals. Specifically, in the GUI example 8300, the scabies prediction 8301 includes a daily (or nightly) scabies prediction 8310 for the next 3 days. As shown in Figure 8C, low scabies is predicted for Wednesday, March 18, medium scabies is predicted for Thursday, March 19, and high scabies is predicted for Friday, March 20. The exemplary scabies prediction 8301 may further include a scabies prediction trend 8320 indicating a trend for the user's scabies (or scratching) in the near future. As shown in this example, the user's scabies prediction trend 8320 is increasing, which is consistent with the daily (or weekly) scabies prediction 8310.

In some embodiments, and in the exemplary embodiment illustrated in GUI 8300, the scabies prediction 8301 further includes a user recommendation 8330. Here, the recommendation advises the user to “Use topical treatment every day as directed.” User recommendation 8330 may include recommendations and/or guidelines for treating itch using one or more therapeutic agents, such as those explained with respect to decision support tool 276. In some cases, the user may select or click on a custom recommendation 8330 to view the recommendation or additional information regarding the recommendation. The recommendation displayed or accessible through the user recommendation 8330 may correspond to a specific scabies prediction for the user and/or information available from the user's behavior or treatment regimen. This information may be provided by the user, the user's caregiver, or health care provider, or accepted as observational or treatment-related data, for example, as described in connection with FIG. 8 B. In some embodiments, the recommendation may be determined using rules, conditions, and /or input received from the user's healthcare professional.

In some embodiments, and in the exemplary embodiment illustrated in GUI 8300, scabies prediction 8301 further includes view functionality 8340 for viewing alternative predictions (with or without treatment). For example, by selecting the treatment button 8341, a daily scabies prediction 8310 may be determined and presented to the user based on the user's use of treatment for a future time interval. Likewise, by selecting the no-treatment button 8343, a daily scabies prediction 8310 can be determined and presented to the user based on the user's non-use of treatment for a future time interval. In particular, the user's treatment may be determined as part of the context data (for example, through the context data determination module 294, explained in connection with the system 200 of FIG. 2) from the user's profile/health data (EHR) 241, information entered through the tab 8260 treatment either specified by the user or caregiver/health professional (for example, in 8110 settings). Different and alternative predictions may be determined based on the user's statistics, whether the user is using or not using the treatment, based on similar users' use or non-use of the treatment, or may be first calculated based on available data and then modified accordingly. For example, a prediction of scabies for a user, with or without treatment, may be determined and then modified, for example, by upscaling or downscaling the predicted number of scratching events by a multiplier (e.g., up to a forty percent increase in scratching events, within 48 hours, if the user stops use of treatment). Thus, the browsing functionality 8340 can determine and present alternative scabies predictions to the user.

Turning now to FIG. 8D, another aspect of an exemplary comb monitor application 8101 is illustrated, including a GUI 8400. The GUI 8400 includes various UI elements for displaying a blushing alert notification (eg, a blushing notification 8401). In some cases, related information is displayed additionally or alternatively. As described herein, a redness notification 8401 may indicate to a user that predicted future scabies (or scratching) events for the user are likely to exceed a threshold such that they become a redness. As described above in connection with the method 500 of FIG. 5 and the blush predictor 290 of FIG. 2, some embodiments may determine a future probability of a blush event for a user.

The exemplary GUI 8,400 includes a descriptor 8403 indicating the current date (eg, today, Monday, May 4) and a blush notification 8401 alerting the user to a likely future blush event. In the exemplary embodiment illustrated in GUI 8400, additional information may be presented in addition to the redness notification 8401, such as a recommendation (not shown, e.g., avoid exposure to sunlight) and/or redness notification details 8410. Specifically, in this example, the redness notification information 8410 indicates when a redness occurs with a high probability (eg, a future time interval between next day and Thursday), the likelihood of a redness event occurring (for example, a 74% probability, which may be determined as described in connection with the redness predictor 290 of FIG. 2 or the method 500 of FIG. 5) and/or the severity or level of the redness (eg, "severe"). In some cases, although the severity may vary within a future time interval, the severity may represent the greatest possible severity predicted for the user to allow the user to prepare for the worst possible outcome.

In the exemplary embodiment illustrated in GUI 8400, the blush notification 8401 further includes one or more response options 8420 to facilitate a user's response to the blush notification. For example, response options 8420 may include option 8422 for checking/refilling a user's prescription, option 8424 for scheduling a teleappointment (or in-person appointment) with the user's healthcare provider; or option 8426 to automatically add over-the-counter (OTC) therapeutic agents (e.g., cortisone cream, calamine lotion, etc.) to the user's electronic shopping list. In embodiments in which shopping or store account information is specified in the user account(s)/device(s), selecting option 8426 allows the item to be automatically purchased for the user and delivered to the user's address or made available for pickup. In some embodiments, specific therapeutic OC agents may be specified by the user or health care provider. For example, OS therapeutics may be specified via treatment tab 8260, settings 8115, profile/health data 241 (EHR) of the user (FIG. 2), or based on the user's previous purchases, which may be determined as context data from context data determination module 294 and/or from user accounts/devices 248 such as purchase history or the user's mail/email receipts. As shown in FIG. 8D, embodiment 8428 may delay notification 8401 regarding blushing for a certain period of time or trigger functionality to remind the user regarding blushing at a future time. In some embodiments, notification 8401 regarding flushing is provided to the user in the morning or evening to increase the likelihood that the user can take action to reduce the flushing event (eg, putting the medication on at night or scheduling a time to go to the pharmacy or have a discussion with a health professional during that day).

Selecting response option 8424 to schedule a televised appointment assumes that in many cases the user may not have time to schedule a physical (in-person) appointment after receiving the blushing notification 8401 before the blushing event occurs. Therefore, teleconference, which may include initiating a video conference with the user's health care provider using a camera on the user computing device 8102a, provides a more timely solution for the user. However, some embodiments of redness prediction can predict redness several weeks in advance, and as such, physical therapy may be performed as an alternative solution.

Turning now to FIG. 8E, another aspect of the exemplary comb monitor application 8101 is illustrated, including the GUI 8500. The GUI 8500 illustrates an aspect of the comb log 8502, which may be an additional or alternative illustration of the comb log 8201 of the GUI 8100 (described in FIG. 8A). In particular, the GUI 8500 includes a calendar view 8505 that illustrates a current date indicator 8503 (indicating the current date as May 27). The calendar view 8505 also includes indicators of redness events, including indicators of future redness events 8510 (shown as occurring on May 28 and May 29) and an indicator of previous redness events 8512 (shown as occurring from May 5 to May 7). Some embodiments (not shown) of the calendar view 8505 or GUI 8500 may also illustrate past or statistical events based on whether the user is or is not using a treatment, similar to the alternative scabies prediction views described in conjunction with FIG. 8C. For example, the alternative view of basis when the user does not use treatment may show additional redness that the user is more likely to experience without treatment.

Fig. 8F illustrates exemplary analytics for sleep detection that includes digital sleep endpoints that may be presented to the user via a chart tab 8230, as described in connection with FIG. 8B. Specifically, the exemplary analytics includes an exemplary table 8 600. including sleep-related data 8610 for a sequence of days, including total sleep time 8620 (TST), percent sleep time 8630 (PTA), wake 8640 after sleep onset (WASO), sleep onset latency 8650 (SOL), and number of 8660 awake bouts (NWB). The exemplary analytics in FIG. 8F further includes a set of charts 8700. Charts 8700 include graphical illustrations of sleep-related data shown in table 8600 for each day of the list 8610 of days. As shown in FIG. 8F, charts 8700 illustrate total sleep time 8720 (TST), percent sleep time 8730 (PTA), wakefulness after sleep onset 8740 (WASO), sleep onset latency 8750 (SOL), and number of wakefulness bouts 8760 ( NWB). Table 8600 and charts 8700 may be presented to the user one at a time or simultaneously.

Fig. 9A-11M illustrate exemplary embodiments of computer program routines for detecting scratch-related and sleep-related data for a user, as described herein. In particular, FIGS. 9A-9I illustrate aspects of an example computer program for managing sleep detection-related and scratch detection-related procedures. In this regard, the computer program routine of FIGS. 9A-9I may be used to implement method 400 of FIG. 4A, method 4800 of FIG. 4D, and/or method 4001 of FIG. 4E. Fig. 10A-10I illustrate aspects of an example computer program for detecting scratching events and related information that may be used to implement method 400 of FIG. 4A and/or method 4001 of FIG. 4E. Fig. 11A-11M illustrate aspects of an example computer program for detecting sleep-related information, including Total Sleep Opportunity (TSO), that may be used when performing some embodiments of step 430 of FIG. 4A, method 4300 of FIG. 4C, and/or method 4800 in Fig. 4D.

Accordingly, various aspects of technology are provided directed towards systems and methods for detecting scratching and predicting redness. It should be understood that various features, subcombinations and modifications of the embodiments described herein are useful and may be used in other embodiments without regard to other features or subcombinations. Moreover, the order and sequence of steps shown in the exemplary methods or process are not intended to in any way limit the scope of the present disclosure, and in fact the steps may occur in a variety of different sequences within embodiments of this document. Such variations and combinations thereof are also expected to be within the scope of embodiments of this disclosure.

Having described various implementations, an exemplary computing environment suitable for implementing embodiments of the disclosure is described below. With reference to FIG. 12, an exemplary computing device is provided and is generally referred to as "computing device 1200".

Computing device 1200 represents one example of a suitable computing environment and is not intended to impose limitations on the scope of use or functionality of embodiments of the disclosure. The computing device 1200 should under no circumstances be interpreted as having any dependency or requirement associated with any one or combination of the illustrated components.

Embodiments of the disclosure may be described in the general context of machine code or computer-usable instructions, including computer-usable or computer-executable instructions, for example, program modules executed by a computer or other machine, such as a personal digital device, a smartphone, tablet PC or other pocket or wearable device, such as a smart watch. Typically, software modules, including procedures, programs, objects, components, data structures, and the like, refer to code that performs specific tasks or implements specific abstract data types. Embodiments of the disclosure may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general purpose computers, or specialized computing devices. Embodiments of the disclosure may also be practiced in distributed computing environments in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located on both local and remote computer storage media, including storage devices.

Referring to FIG. 12, computing device 1200 includes a bus 1210 that directly or indirectly connects various devices, including storage device 1212, one or more processors 1214, one or more presentation components 1216, one or more input ports 1218 -output, one or more I/O components 1220, and an exemplary power source 1222. Some embodiments of computing device 1200 may further include one or more radios 1224. Bus 1210 represents one or more buses (eg, an address bus, a data bus, or a combination of the above). Although the various blocks of FIG. 12 are shown with lines for clarity, in reality, these blocks represent logical, and not necessarily actual, components. For example, a presentation component, such as a display device, may be considered to be an input/output component. In addition, the processor may have a storage device. Fig. 12 illustrates only an exemplary computing device that may be used in connection with one or more embodiments of the present disclosure. No distinction is made between categories such as “workstation”, “server”, “laptop computer”, or “handheld device”, since all of them are presumably within the scope of FIG. 12 and refer to “computing device”.

Computing device 1200 typically includes a variety of computer-readable media. Computer readable media can be any available media that can be accessed by computing device 1200 and includes both volatile and nonvolatile, removable and non-removable media. By way of example, and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media includes 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. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other storage device technology, compact read-only memory discs (CD-ROMs), digital versatile discs (DVDs) or other optical disk storage device, magnetic cassettes, magnetic tape, magnetic disk storage device or other magnetic storage devices, or any other media that can be used for in order to store the required information and may be accessed by the computing device 1200. Computer storage media do not inherently contain signals. Communication media typically implement computer-readable instructions, data structures, program modules, or other data on a modulated data signal, such as a carrier or other transport mechanism, and include any information delivery media. The term "modulated data signal" means a signal that has one or more characteristics specified or changed in such a way as to encode information in the signal. By way of example, and not limitation, communications media include wired media, such as a wired network or direct wired connection, and wireless media, such as acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above elements should also be included within the scope of computer-readable media.

Storage device 1212 includes computer storage media in the form of volatile and/or non-volatile storage. The storage device may be removable, non-removable, or a combination of the above. Exemplary hardware devices include, for example, semiconductor storage devices, hard disk drives, and optical disk drives. Computing device 1200 includes one or more processors 1214 that read data from various devices, such as storage device 1212 or input/output components 1220. Presentation components 1216 present data indicators to a user or other device. Exemplary presentation components 1216 may include a display device, a speaker, a printing component, a vibrating component, or the like.

I/O port(s) 1218 enable computing device 1200 to logically connect to other devices including I/O components 1220, some of which may be embedded. Exemplary components include a microphone, joystick, gaming pad, satellite dish, scanner, printer, or wireless device. I/O components 1220 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological input generated by the user. In some cases, inputs may be passed to the appropriate network element for further processing. The NUI can implement any combination of speech recognition, touch and stylus recognition, facial recognition, biometric recognition, gesture recognition (both on-screen and near-screen), air gestures, head and eye tracking, and touch recognition associated with on-screen displays. computing device 1200. Computing device 1200 may be equipped with depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, and combinations thereof, to detect and recognize gestures. Additionally, computing device 1200 may be equipped with accelerometers or gyroscopes that provide motion detection. The output of the accelerometers or gyroscopes may be provided to the display of the computing device 1200 to render an immersive augmented reality or virtual reality experience.

Some embodiments of computing device 1200 may include one or more radios 1224 (or similar wireless communication components). Radios 1224 transmit and receive radio or wireless communications. The computing device 120 may be a wireless terminal adapted to receive communications and multimedia over various wireless networks. Computing device 1200 may communicate through wireless protocols such as Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), or other wireless means to communicate with other devices. . The radio link may be a short-range connection, a long-range connection, or a combination of the above. In this document, "short" and "long" connection types do not imply a spatial relationship between two devices. Instead, these connection types generally refer to short-range and long-range as different categories or types of connections (ie, primary connection and secondary connection). A short-range connection may include, by way of example and not limitation, a Wi-Fi® connection to a device (e.g., a mobile hotspot) that provides access to a wireless communications network, such as a wireless local area network (WLAN) connection using the 802.11 protocol; A Bluetooth connection with another computing device is another example of a short-range connection; or short-range communications. A long-range connection may include a connection using, by way of example and not limitation, one or more of CDMA, General Packet Radio Service (GPRS), GSM, TDMA, and 802.16-based protocols.

The following embodiments represent exemplary aspects of the concepts contemplated by the disclosure herein. Any of the following embodiments may be combined in a manner dependent on the others such that they depend on one or more other embodiments. Additionally, any combination of embodiments that are clearly dependent on the previous embodiment may be combined while staying within the scope of aspects contemplated herein. The following embodiments are illustrative in nature and not limiting.

In some embodiments, a system for providing decision support based on combing events, for example, the systems described in any of the embodiments disclosed herein, comprises: a processor; and a computer storage device having stored computer-executable instructions for performing operations when executed by the processor. The operations contain: receiving accelerometer data for a person; hand motion detection using accelerometer data; using a computerized classification model to determine, based on accelerometer data corresponding to hand movement, that hand movement indicates a scratching event; and initiating one or more response actions at least based on determining that the movement of the hands indicates a scratching event. Among other advantages, these embodiments can provide an itch assessment with greater accuracy and reliability (compared to traditional solutions) based on accelerometer data acquired in a manner that reduces user burden and increases user compliance. Using computerized classification models with accelerometer data to detect scratching events helps eliminate bias and subjectivity, further improving accuracy and reliability. These classifiers help provide reliable computer decision support tools that are based on detected scratching data, thereby improving recommendations for treatment and/or response to scratching.

In the above embodiment of the system, operations performed by the processor executing computer-executable instructions further comprise: generating multivariate time series from accelerometer data corresponding to hand movements; and determining a set of feature values from multivariate time series. The plurality of feature values include at least one time domain feature value and at least one frequency domain feature value. The determination that a hand movement constitutes a scratching event is based on multiple feature values.

In any combination of the above system embodiments, accelerometer data is captured by a wearable device located on a part of the human body. For example, the wearable device may be located on the wrist, finger, and/or forearm. The use of a wearable device allows for continuous (or semi-continuous, intermittent, as needed or as available) data capture that is less intrusive than other types of monitoring, which may be advantageous when monitoring people in populations with typically lower rates of treatment adherence , such as children.

In any combination of the above system embodiments, operations performed by the processor executing computer-executable instructions further comprise determining the overall sleep capability based on the accelerometer data. The total possibility of sleep contains the period of time between when a person lies down in a motionless state and when a person gets up from a motionless state. Hand movement is detected using accelerometer data corresponding to full sleep capability. Thus, a detected scratching event may be considered nighttime scratching or scratching during a period in which the individual intends to sleep. This detection helps track scratching during peak itch times or even when the person is unaware of scratching. In this regard, detected scratching events, in accordance with embodiments of this disclosure, can provide more accurate indicators of a person's current condition (eg, itch and atopic dermatitis).

In any combination of the above system embodiments, accelerometer data is captured by a wearable device having a plurality of sensors, wherein the wearable device further captures at least one of body temperature data and lighting data. Full sleep capability is further determined based on at least one of ambient body temperature data and lighting data.

In any combination of the above system embodiments, the computerized classification model used to determine that hand movement indicates a scratching event comprises at least one of an ensemble of machine learning models and a random forest classifier. For example, a computerized classification model may be an ensemble of machine learning models in which at least one model is a random forest classifier. Compared to other scratch detection approaches, these embodiments produce results that are more interpretable than recurrent neural network approaches, and therefore better modifiable or granular for specific contexts. Additionally, they can be faster and less computationally intensive than other approaches.

In any combination of the above system embodiments, the one or more responses comprise generating a graphical user interface element provided for display on the user device. The graphical user interface element includes at least one of an indicator of one or more comb endpoints comprising a total number of comb events and a total comb duration; and an indicator recommending that the individual should seek clinical advice based on the determination that hand movement indicates a scratching event. Scratching endpoints may represent new digital endpoints that are useful in quantitative and objective measurement of itch or, more specifically, atopic dermatitis. Additionally, generating a graphical user interface element to provide a display on a user device, with indicators of scratching endpoints and/or a recommendation for a clinical consultation, encourages better treatment compliance for the monitored individual and allows the clinician to make informed treatment decisions.

In any combination of the above system embodiments, the total number of scratching events and the total duration of scratching are determined for the total sleep capability, which is determined based on the accelerometer data received for the person. The total possibility of sleep contains the period of time between when a person lies down in a motionless state and when a person gets up from a motionless state. Thus, a detected scratching event may be considered nighttime scratching or scratching during a period in which the individual intends to sleep. This detection helps track scratching during peak itch times or even when the person is unaware of scratching. In this regard, detected scratching events, in accordance with embodiments of this disclosure, can provide more accurate indicators of a person's current condition (eg, itch and atopic dermatitis).

In some embodiments, a method is provided for treating itching using a motion sensing device associated with a test subject. The study subject may contain a study subject for whom a treatment for itch is being sought. The method may comprise: receiving accelerometer data collected from a motion sensing device; hand motion detection using accelerometer data; using a computerized classification model to determine, based on accelerometer data corresponding to hand movement, that hand movement indicates a scratching event; and, based on at least the first determination that the movement of the hands indicates a scratching event, initiating a treatment protocol for the subject to treat the itch. Among other advantages, these embodiments can provide an itch assessment with greater accuracy and reliability (compared to traditional solutions) based on accelerometer data acquired in a manner that reduces user burden and increases user compliance. Using computerized classification models with accelerometer data to detect scratching events helps eliminate bias and subjectivity, further improving accuracy and reliability. These classifiers help provide reliable computer decision support tools that are based on detected scratching data, thereby improving recommendations for treatment and/or response to scratching. In this regard, these embodiments can more effectively treat and take comprehensive measures to combat itching (including in the form of atopic dermatitis) than traditional indicators.

In the above embodiment of the method, initiation of the treatment protocol is further based on a plurality of determinations that a plurality of hand movements indicate a scratching event. Initiating a treatment protocol includes determining at least one of a therapeutic agent, a dosage, and a route of administration of the therapeutic agent.

In any combination of the above method embodiments, the therapeutic agent is selected from the group consisting of the following: infliximab, adalimumab, belimumab, tanezumab, ranibizumab, bevacizumab, mepolizumab, certolizumab, natalizumab, ustekinumab, vedolizumab, 6-mercaptopurine, hydroxychloroquine, obeticholic acid, mofetil , mycophenolate sodium, leflunomide, Rituxan, solumedrol, depomedrol, betamethasone, prednisone, cyclosporine, tacrolimus, pimecrolimus, dupilumab, omalizumab, tralokinumab, etokimab, nemolizumab, tezepelumab, lebrikizumab, fezakinumab, anti-OX40, efalizumab, cept, crisaborole, fluocinonide, mapracorate, hydrocortisone, desonide, alklometasone, triamcinolone, deoxymethasone, loratadine, fexofenadine, desloratadine, levocetirizine, metapyrylene, cetirizine, budesonide, fluticasone, mometasone, dexamethasone, prednisolone, ciclesonide, beclomethasone, methotrexate, azathioprine, , ibuprofen, celecoxib, valdecoxib, WBI-1001 and/or MRX-6, abrocitinib, baricitinib, brepocitinib, cerdulatinib, decernotinib, delgocitinib, fedratinib, filgotinib, gandotinib, ilginatinib, itacitinib, lestaurtinib, momelotinib, oclacitinib, pacritinib, peficitinib, , zuxolitinib, tofacitinib, upadacitinib, THRX-212401, PF-07055087, PF-06471658, PF-07055090, ATI-502, BMS-986165, JTE-052, PF-06826647, SNA-152, SHR-0302, tapinarof and/or alitretinoin.

In a preferred embodiment of any combination of the above embodiments, the therapeutic agent is selected from the group consisting of the following: crisaborole and abrocitinib.

In any combination of the above method embodiments, initiating the administration of a treatment protocol includes generating a graphical user interface element provided for display on the user device. The graphical user interface element indicates a treatment protocol recommendation based on the first determination that the movement of the hands represents a scratching event. This embodiment helps to encourage better compliance with treatment requirements for the subject and allows the physician to make informed decisions regarding the treatment protocol for the subject.

In any combination of the above method embodiments, the user device is separate from the motion sensing device. For example, the user device may be a user computing device that is separate from the motion sensing device. One advantage of this embodiment allows the motion sensing device to be more portable and less bulky, as it may be desirable if the display on the user device is larger than what is permitted by the wearable device. Additionally, in some aspects, the user device may be a physician user device, and being separate from the motion sensing device allows for data collection outside of the clinical setting, thereby improving data quality and patient compliance.

In any combination of the above method embodiments, the method further comprises applying a treatment protocol to the study subject based on the recommendation.

In any combination of the above method embodiments, the motion sensing device comprises a wearable device worn on a part of the subject's body. For example, the motion sensing device may be a wearable device worn on the subject's finger, wrist, or forearm. The use of a wearable device allows for continuous (or semi-continuous, intermittent, as needed or as available) data capture that is less intrusive than other types of monitoring, which may be advantageous when monitoring people in populations with typically lower rates of treatment adherence , such as children.

In any combination of the above method embodiments, the subject is diagnosed with atopic dermatitis based on the determination that hand movement indicates a scratching event, and the treatment protocol is designed to treat atopic dermatitis.

In some embodiment, one or more computer storage media has computer-executable instructions that, when executed by one or more processors, instruct one or more processors to perform operations. The operations contain: receiving accelerometer data for the subject; and causing the user device to display one or more scratching endpoints for the subject based on determining that one or more hand movements detected from the accelerometer data indicate scratching events. The study subject may contain a study subject for whom a treatment for itch is being sought. Among other advantages, these embodiments can provide an itch assessment with greater accuracy and reliability (compared to traditional solutions) based on accelerometer data acquired in a manner that reduces user burden and increases user compliance. Using computerized classification models with accelerometer data to detect scratching events helps eliminate bias and subjectivity, further improving accuracy and reliability. These classifiers help provide reliable computer decision support tools that are based on detected scratching data, thereby improving recommendations for treatment and/or response to scratching. Additionally, scratching endpoints may represent new digital endpoints that are useful in quantitative and objective measurement of itch or, more specifically, atopic dermatitis. A graphical user interface element provided for display on the user's device with scratch endpoint indicators encourages better treatment compliance for individual tracking and allows the clinician to make informed treatment decisions.

In the above embodiment of computer storage media, accelerometer data is received from one or more sensors integrated into a wearable device that is operably coupled to the user device. The use of a wearable device allows for continuous (or semi-continuous, intermittent, as needed or as available) data capture that is less intrusive than other types of monitoring, which may be advantageous when monitoring people in populations with typically lower rates of treatment adherence , such as children.

In any combination of the above embodiments of computer storage media, accelerometer data is captured through sensors integrated into a first wearable device and a second wearable device worn simultaneously by the subject.

In any combination of the above embodiments of computer storage media, the operations further comprise instructing to display, on the user device, a treatment protocol for the atopic dermatitis being studied for treatment, wherein the treatment protocol is based on one or more scratching endpoints.

Many illustrated different arrangements of various components, as well as components not shown, are possible without departing from the scope of the claims below. Embodiments of the disclosure are described with the intention of being illustrative and not limiting. Alternative embodiments should become apparent to readers of this disclosure upon and as a result of reading it. Alternative means of implementing the above may be accomplished without departing from the scope of the claims below. Certain features and subcombinations have utility and can be used independently of other features and subcombinations and are intended to be within the scope of the claims.

Claims (24)

1. A system for providing decision support based on combing events, the system comprising: a processor; and a computer storage device having stored computer-executable instructions for performing operations when executed by the processor, the operations comprising: receiving human accelerometer data; hand motion detection using accelerometer data; using a computerized classification model to determine, based on accelerometer data corresponding to hand movement, that hand movement indicates a scratching event; and initiating one or more response actions based on at least determining that the movement of the hands indicates a scratching event, wherein the operations performed by the processor executing computer executable instructions comprise determining total sleep capability based on the accelerometer data, wherein total sleep capability comprises a period of time between when the person lies down in a still state and when the person gets up from the still state , wherein hand movement is detected using accelerometer data corresponding to full sleep capability, wherein the accelerometer data is captured by a wearable device having more than one sensors, wherein the wearable device further captures at least one of body temperature data and lighting data, wherein overall sleep capability is further determined based on at least one of body temperature data and lighting data. 2. The system of claim 1, wherein the operations performed by the processor executing computer-executable instructions further comprise: generating multivariate time series from accelerometer data corresponding to hand movements; and determining more than one feature value from the multivariate time series, wherein the more than one feature value includes at least one time domain feature value and at least one frequency domain feature value, wherein determining that the movement of the hands constitutes a scratching event, based on more than one characteristic value. 3. The system of claim 1, wherein the accelerometer data is captured by a wearable device located on a part of the human body. 4. The system of claim 1, wherein the computerized classification model used to determine that hand movement indicates a scratching event comprises at least one of an ensemble of machine learning models and a random forest classifier. 5. The system of claim 1, wherein the one or more responses comprise generating a graphical user interface element provided for display on the user device, wherein the graphical user interface element includes at least one of: an indicator of one or more comb endpoints , containing the total number of combing events and the total duration of combing; and an indicator recommending that the individual should seek clinical advice based on the determination that hand movement indicates a scratching event. 6. The system of claim 5, wherein the total number of scratching events and the total duration of scratching are determined for a total sleep opportunity, which is determined based on accelerometer data received for the person, wherein the total sleep opportunity comprises the period of time between the person lying down motionless state, and when a person gets up from a motionless state. 7. A method for treating itching using a motion sensing device associated with a subject, the method comprising the steps of: receiving accelerometer data collected from the motion sensing device; detect hand movement using accelerometer data; using a computerized classification model to determine, based on the accelerometer data corresponding to the movement of the hands, that the movement of the hands indicates a scratching event; and based on at least the first determination that the movement of the hands indicates a scratching event, initiating a treatment protocol for the itch being studied, wherein the operations performed by the processor executing the computer executable instructions further comprise determining the total sleep capability based on the accelerometer data, wherein the total sleep capability comprises a period of time between when the person lies down in a stationary state and when the person rises from a stationary state state, whereby hand movement is detected using accelerometer data corresponding to full sleep capability, wherein the accelerometer data is captured by a wearable device having more than one sensors, wherein the wearable device further captures at least one of body temperature data and lighting data, wherein overall sleep capability is further determined based on at least one of body temperature data and lighting data. 8. The method of claim 7, wherein initiation of the treatment protocol is further based on more than one determination that each of the more than one hand movements indicates a scratching event, and wherein initiation of the treatment protocol includes determining at least one of a therapeutic agent, dosage and route of administration of the therapeutic agent. 9. The method of claim 8, wherein the therapeutic agent is selected from the group consisting of the following: infliximab, adalimumab, belimumab, tanezumab, ranibizumab, bevacizumab, mepolizumab, certolizumab, natalizumab, ustekinumab, vedolizumab, 6-mercaptopurine, hydroxychloroquine, obeticholic acid , mofetil, mycophenolate sodium, leflunomide, rituxan, solumedrol, depomedrol, betamethasone, prednisone, cyclosporine, tacrolimus, pimecrolimus, dupilumab, omalizumab, tralokinumab, etokimab, nemolizumab, tezepelumab, lebrikizumab, fezakinumab, anti-OX40, , etanercept, crisaborole, fluocinonide, mapracorate, hydrocortisone, desonide, alklometasone, triamcinolone, deoxymethasone, loratadine, fexofenadine, desloratadine, levocetirizine, metapyrylene, cetirizine, budesonide, fluticasone, mometasone, dexamethasone, prednisolone, ciclesonide, beclomethasone, methotrexate, thioprine, aspirin, ibuprofen, celecoxib, valdecoxib, WBI-1001 and/or MRX-6, abrocitinib, baricitinib, brepocitinib, cerdulatinib, decernotinib, delgocitinib, fedratinib, filgotinib, gandotinib, ilginatinib, itacitinib, lestaurtinib, momelotinib, oclacitinib, pacritinib, , ritlecitinib, zuxolitinib, tofacitinib, upadacitinib, THRX-212401, PF-07055087, PF-06471658, PF-07055090, ATI-502, BMS-986165, JTE-052, PF-06826647, SNA-152, SHR-0302, tapinarof and/or alitretinoin. 10. The method of claim 8, wherein the therapeutic agent is selected from the group consisting of the following: crisaborole and abrocitinib. 11. The method of claim 7, wherein initiating a treatment protocol assignment includes generating a graphical user interface element provided for display on a user device, wherein the graphical user interface element indicates a treatment protocol recommendation based on the first determination that moving the arms represents the scratching event. 12. The method of claim 11, wherein the user device is separate from the motion sensing device, and wherein the motion sensing device comprises a wearable device worn on a part of a person's body. 13. The method according to claim 11, further comprising the step of applying a treatment protocol to the subject based on the recommendation. 14. The method of claim 7, wherein the subject is diagnosed with atopic dermatitis based on determining that hand movement indicates a scratching event, and wherein the treatment protocol is intended to treat atopic dermatitis. 15. A computer storage medium having computer executable instructions embodied therein that, when executed by one or more processors, instruct one or more processors to perform operations comprising: receiving accelerometer data for a subject; and causing the user device to display one or more scratch endpoints for the subject based on determining that one or more hand movements detected from the accelerometer data indicate scratch events, wherein the operations performed by the processor executing the computer executable instructions further comprise determining the total sleep capability based on the accelerometer data, wherein the total sleep capability comprises a period of time between when the person lies down in a stationary state and when the person rises from a stationary state state, whereby hand movement is detected using accelerometer data corresponding to full sleep capability, wherein the accelerometer data is captured by a wearable device having more than one sensors, wherein the wearable device further captures at least one of body temperature data and lighting data, wherein overall sleep capability is further determined based on at least one of body temperature data and lighting data. 16. The computer storage medium of claim 15, wherein the accelerometer data is received from one or more sensors integrated into the wearable device that is operably coupled to the user device. 17. The computer storage medium of claim 15, wherein the accelerometer data is captured through sensors integrated into the first wearable device and the second wearable device worn simultaneously by the subject. 18. The computer storage medium of claim 15, wherein the operations further comprise instructing to display, on the user device, a treatment protocol for the atopic dermatitis being studied for treatment, wherein the treatment protocol is based on one or more scratching endpoints.