Automated classification of severity of symptoms associated with neurodegenerative diseases

Abstract

A method of classifying severity of symptoms associated with neurological disorders, including receiving sensor data from a device that includes one or more sensors; extracting data features from the received sensor data; generating a context of a patient's state based on the extracted data features; determining a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient's state; predicting using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient's state; and outputting the determined symptom and the predicted severity of the determined symptom.

Description

AUTOMATED CLASSIFICATION OF SEVERITY OF SYMPTOMS ASSOCIATED WITHNEURODEGENERATIVE DISEASESCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to U.S. Provisional Application No. 63 / 491,640, filed March 22, 2023, which is incorporated herein by reference in its entirety for all purposes.BACKGROUNDFIELD OF THE DISCLOSURE

[0002] The present disclosure relates to automatic identification and classification of change in motor function.DESCRIPTION OF THE RELATED ART

[0003] Parkinson’s disease is one of the most common neurodegenerative diseases affecting adults and is characterized by a gradual, chronic, and incurable decline in motor functions. The decline in motor functions is associated with low dopamine levels and can be manifest in typical motor- related and non-motor-related symptoms. The severity and presentation of each symptom can vary over time. Therefore, it is important to monitor a patient’s symptoms in order to assess the progression of Parkinson’s disease for that patient. The progression of Parkinson’s disease can be used to determine treatment for a patient, including titration of medication.

[0004] The foregoing “Background” description is for the purpose of generally presenting the context of the disclosure. Work of the inventors, to the extent it is described in this backgroundsection, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present disclosure.SUMMARY

[0005] The foregoing paragraphs have been provided by way of general introduction, and are not intended to limit the scope of the following claims. The described embodiments, together with further advantages, will be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

[0006] In one embodiment, the present disclosure is related to a method of classifying severity of symptoms associated with neurological disorders, the method comprising receiving sensor data from a device that includes one or more sensors; extracting, via processing circuitry, data features from the received sensor data; generating, via the processing circuitry, a context of a patient’s state, based on the extracted data features; determining, via the processing circuitry, a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predicting, via the processing circuitry, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and outputting the determined symptom and the predicted severity of the determined symptom.

[0007] In one embodiment, the present disclosure is related to a non-transitory computer- readable storage medium for storing computer readable instructions that, when executed by a computer, cause the computer to perform a method, the method comprising receiving sensor datafrom a device that includes one or more sensors; extracting data features from the received sensor data; generating a context of a patient’s state based on the extracted data features; determining a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predicting, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and outputting the determined symptom and the predicted severity of the determined symptom.

[0008] In one embodiment, the present disclosure is related to a device, comprising processing circuitry configured to receive sensor data from a device that includes one or more sensors; extract data features from the received sensor data; generate a context of a patient’s state based on the extracted data features, determine a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predict, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and output the determined symptom and the predicted severity of the determined symptom.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0010] FIG. l is a schematic for evaluating symptom severity, according to one embodiment of the present disclosure;

[0011] FIG. 2 is a schematic of a production pipeline, according to one embodiment of the present disclosure;

[0012] FIG. 3 is a workflow of a sub-classifier, according to one embodiment of the present disclosure;

[0013] FIG. 4 is a workflow of a sub-classifier, according to one embodiment of the present disclosure;

[0014] FIG. 5 is a workflow of a sub-classifier, according to one embodiment of the present disclosure;

[0015] FIG. 6 is a workflow of a bradykinesia severity classifier, according to one embodiment of the present disclosure;

[0016] FIG. 7 is a workflow of a dyskinesia severity classifier, according to one embodiment of the present disclosure;

[0017] FIG. 8 is a workflow of a tremor severity classifier, according to one embodiment of the present disclosure;

[0018] FIG. 9 is a schematic of a user device for performing a method, according to one embodiment of the present disclosure; and

[0019] FIG. 10 is a schematic of a hardware system for performing a method, according to one embodiment of the present disclosure.DETAILED DESCRIPTION

[0020] The terms “a” or “an”, as used herein, are defined as one or more than one. The term “plurality”, as used herein, is defined as two or more than two. The term “another”, as used herein, is defined as at least a second or more. The terms “including” and / or “having”, as used herein, aredefined as comprising (i.e., open language). Reference throughout this document to "one embodiment", “certain embodiments”, "an embodiment", “an implementation”, “an example” or similar terms means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of such phrases or in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments without limitation.

[0021] Identifying and assessing symptoms of Parkinson’s disease typically involves direct patient observation and extensive physical examinations in a clinical setting. For example, the Unified Parkinson’s Disease Rating Scale (UPDRS) is a quantitative method for assessing patient livelihood and grading symptoms as mild, moderate, or severe but is typically only administered by a medical professional during an in-person office visit. Physical examinations can be timeconsuming and require the expertise of a medical professional to rate the severity of symptoms. Symptoms of Parkinson’s disease can include, but are not limited to, tremors, bradykinesia, dyskinesia, rigidity, postural instability, changes in gait, micrographia, dystonia, hypophonia, and masked facies. A motor examination, e.g., one found in section three of the UPDRS (UPDRS-FH), can include a number of physical activities and tasks for a patient to execute while being observed by a medical professional. The medical professional assigns categorical ratings for one or more symptoms based on the patient’s ability to perform the physical activities. Certain symptoms are evaluated directly through during the motor examination, while others are assessed based on a combination of observed behaviors.

[0022] Continuous monitoring of symptoms is necessary in order to accurately track the progression of Parkinson’s disease and adjust treatment if necessary. However, frequent clinical visits are costly and impractical and can negatively impact a patient’s livelihood. Outside of a clinical setting, symptoms are usually monitored by patient self-reporting (e.g., questionnaires, motor diaries), which is subjective and can be subject to inaccurate reporting due to fatigue, poor adherence, recall bias, limited time resolution, and lack of understanding or evaluation of the magnitude of symptom severity. The inability to accurately and frequently track Parkinson’s disease symptoms has led to a significant healthcare burden, including delayed diagnosis, ineffective treatment, and decreased quality of life for patients. There is therefore a clear need to provide patients with ways to continuously and accurately assess symptoms of Parkinson’s disease outside of a clinical setting in order to improve diagnosis and treatment of Parkinson’ s and reduce burden on both patients and healthcare professionals.

[0023] In one embodiment, the present disclosure is related to systems and methods for automatic collection and analysis of patient data, including movement data, activity data, physiological data, location data, environmental data, and / or demographic data, in order to identify and classify symptoms of neurological disorders such as Parkinson’s disease. The classification of the symptoms can include determining a severity of the symptoms according to known rating scales. The systems and methods related herein can enable repeated assessment of symptoms over time without requiring professional input or even active self-reporting from patients. The patient data can be continuously evaluated using the same systems and methods to reduce any variation or subjectivity in classification. Notably, the systems and methods disclosed herein can identify and classify a number of symptoms of Parkinson’s disease based on a single set of patient data. The patient data can include sensor data that can be collected via wearable sensors and can thus bemeasured objectively and in a repeatable and reliable manner. Examples of patient data will be presented in greater detail herein.

[0024] In one embodiment, the present disclosure is directed towards one or more statistical models for analysis of patient data in order to classify symptoms of Parkinson’s disease (PD). A statistical model can include a machine learning (ML) model and can be trained with patient data to identify and classify the severity of PD symptoms. For example, the statistical model can include one or more neural networks used in artificial intelligence (Al) models. The statistical model can be trained for deep learning, or representational learning using one or more network layers. In some embodiments, the statistical model can include a rules-based classifier. The statistical model can include one or more classifiers, wherein a classifier can map input data (e.g., patient data) to a category as an output. In one embodiment, the category can be a type of movement or activity. In one embodiment, the category can be a PD symptom and a severity of the PD symptom. A categorical severity can provide multi-class classification or stratification of symptoms rather than a mere binary indication of whether the symptom is present.

[0025] In one embodiment, the present disclosure can include more than one classifier. For example, a symptom severity classifier can predict a severity of a PD symptom. The input to the symptom severity classifier can include patient data as well as additional metrics, classifications, description, and / or statistical measures derived from the patient data. The additional data can improve the accuracy of the symptom severity classifier in evaluating PD symptoms when compared to an evaluation that is solely based on the initial patient data. The additional data can describe or quantify a context of a patient’s state. The context of the patient’s state can be useful in identifying changes or abnormalities in a patient’s motor function based on the patient data. The context of the patient’s state can include, but is not limited to, a movement, an activity,demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data related to the patient. For example, the context of the patient’s state can include a classification of a type of movement and / or a type of activity that a patient is performing when the patient data is collected. In one example, the movement type can include a description or categorization of a patient’s movement based on the patient data. Further examples of context data will be provided herein. In some embodiments, the context of the patient’s state can be generated by one or more separate classifiers, e.g., a sub-classifier, based on the patient data. The sub-classifiers can be statistical models (e.g., a machine learning classifier) and can provide additional methods for analyzing the patient data without interfering with or confounding the model used for classification of symptom severity. The sub-classifiers can also be trained and adjusted independently of the classifier of symptom severity. In some embodiments, the movement type classification and the activity type classification can be output to a user or a medical professional so that the context can be reviewed independently of the classification of symptom severity.

[0026] In some embodiments, the systems and methods of the present disclosure can further include reporting of symptoms, risk-based assessment and monitoring, and prediction of next steps or treatment based on the patient data and the classification of PD symptom severity. In one embodiment, risk-based assessment can include the identification of risks specific to a patient at a current or future time and a current or future location.

[0027] Tn one embodiment, the methods disclosed herein can be executed by one or more electronic devices including processing circuitry. The one or more electronic devices can include, but are not limited to, a wearable device (e.g., a smartwatch, smart ring), a mobile device (e.g., a smartphone, a tablet), a computer (e.g., a laptop, a personal computer), or a server. In oneembodiment, a remote electronic device, such as a server, can receive input data such as the patient data from an electronic device (e.g., a patient device), process and / or analyze the received input data to evaluate symptom severity, and transmit output data to the patient device. The output data can be, for example, the evaluation of symptom severity based on the patient data. In some embodiments, the methods disclosed herein can be distributed across the one or more electronic devices.

[0028] FIG. l is a schematic of a system for evaluating PD symptom severity, according to one embodiment of the present disclosure. The patient data can be collected from one or more patient devices. The patient devices can include, for example, a wearable device 100 including sensors configured to collect sensor data and a mobile device 200. The mobile device 200 can be configured to collect patient data as well as present output data to a patient. Sensor data from the wearable device 100 and patient data from the mobile device 200 can be transmitted to one or more remote devices 300. A remote device 300 can be, for example, a cloud-based computing device, such as a server. The wearable device 100 and the mobile device 200 can access the one or more remote device 300 via a wireless network connection. The remote device 300 can process the sensor data from the wearable device 100 in order to evaluate PD symptom severity according to the methods presented herein. For example, the remote device 300 can classify a movement type and an activity type based on the patient data and can input the patient data, the movement type, and the activity type into a symptom severity classifier to evaluate PD symptom severity. In some embodiments, the wearable device 100 and / or the remote device 300 can pre-process the sensor data, as will be described herein. The remote device 300 can transmit PD symptom reports based on the evaluation of the sensor data to the wearable device 100 and / or the mobile device 200. In some embodiments, the remote device 300 can transmit PD symptom reports to one or morereporting devices 400. The reporting devices 400 can be, for example, electronic devices (e g., mobile devices, computers) that can be used by the patient or a medical professional. The PD symptom reports can be referred to herein as symptom summary reports. The reporting devices 400 can also transmit data, such as an input from the patient based on the PD symptom reports, to the remote device 300. The data transmitted between the wearable device 100 and the remote device 300, between the mobile device 200 and the remote device 300, and between the remote device 300 and the reporting devices 400 can be compressed via lossless or lossy compression methods in order to reduce transmission times. In some embodiments, data can be continuously streamed between devices.

[0029] FIG. 2 is a schematic of a production pipeline, according to one embodiment of the present disclosure. A wearable device 100, such as a watch, can be configured to run a wearable application, wherein the wearable application enables collection and transmission of sensor data to a cloud storage unit 110, such as a server. The cloud storage unit 110 can be managed by a data storage application. For example, the wearable device 100 can collect sensor data, including accelerometer data and gyroscope data, while a patient is wearing the wearable device 100. The wearable device 100 can transmit the sensor data as well as patient identifiers and device identifiers to the cloud storage unit 110. The sensor data can be used to predict PD symptom severity of a patient wearing the wearable device 100. The device identifiers can include a hardware or software version of the wearable device 100. The patient identifiers and the device identifiers can include unique identifiers for storing and updating patient records in the cloud storage unit 110 and / or a patient database 120. The patient database 120 can store patient records, wherein the patient records can be identified by a unique patient identifier (ID). The patient database 120 can generate a unique patient ID for each new patient. A new patient can transmit new patient information tothe patient database 120, and the patient database 120 can store the new patient information and a unique patient ID corresponding to the new patient. The patient records can be updated with new information about a patient, including updated medical records and PD symptoms as determined by the methods disclosed herein. In one embodiment, the cloud storage unit 110 can transmit the wearable device data to a remote device, such as a machine learning server 300. The machine learning server 300 can store and run one or more machine learning applications and algorithm backends associated with the methods described herein. The machine learning server 300 can receive the wearable device data, including motion sensor data, from the cloud storage unit 110. The machine learning server 300 can also receive patient information, including the unique patient ID, from a patient database 120. The unique patient ID can be configured in the wearable application, the cloud storage unit 110, and / or the machine learning server 300. In one embodiment, the data from the watch device 100 can be associated with the unique patient ID from the patient database 120. For example, the sensor data from the watch device 100 can include the unique patient ID. The data transmitted from the cloud storage unit 110 to the machine learning server 300 can be secured via Hypertext Transfer Protocol Secure (HTTPS). Data can be transmitted from the watch device 100 to the cloud storage unit 110 cover a wireless connection, such as WIFI or Bluetooth. Similarly, data can be transmitted from the patient database 120 to the machine learning server 300 over a wireless connection such as WIFI or Bluetooth.

[0030] The machine learning server 300 can classify the severity of PD symptoms using one or more classifiers based on the wearable device data received from the cloud storage unit 110. The machine learning server 300 can then output user symptom summary reports. In one embodiment, the machine learning server 300 can output symptom summary reports at fixed intervals. The summary reports can include the severity of PD symptoms and additional patient informationassociated with the patient. The patient can be identified by the unique patient TD transmitted to the machine learning server 300 by the patient database 120. In some embodiments, the machine learning server 300 can transmit the summary reports to a user device. In some embodiments, the summary reports can be stored in the patient database 120. A history of summary reports can be stored for a patient in the patient database 120. The history of summary reports and symptom severity can be used to assess the progression of PD in the patient and generate new summary reports for the patient.

[0031] The patient data can include or can be based on sensor data collected by wearable sensors. The wearable sensors can be attached to, worn by, or otherwise in contact with a patient or can be on the patient’s person, e.g., being held by a patient or placed in a patient’s pocket or bag. In one embodiment, the wearable sensors can be embedded in one or more wearable devices, such as the wearable device 100 of FIG. 1, and / or can be distributed in different devices and locations of the body. The wearable sensors can include, but are not limited to, optical sensors (e.g., infrared sensors), electrical sensors, motion sensors, location / position sensors, chemical sensors, and the like. Optical sensors and electrical sensors can be used to measure physiological readings such as a heart rate, a heart rhythm, an electrocardiogram (ECG), a blood oxygen level, and cardiovascular activity. The motion sensors can include accelerometers (e.g., triaxial accelerometers), gyroscopes, magnetometers, and alternatives or combinations thereof for measuring linear and angular orientation and movement.

[0032] Tn one embodiment, the sensor data can be passively collected by the wearable sensors. For example, the wearable sensors can be embedded in a wearable device such as a smartwatch, smart ring, chest strap, or the like. The wearable sensors can collect sensor data automatically from a patient’s body while the patient is wearing the wearable device without alerting the patient orprompting the patient to input data in order to proceed with collection. In one embodiment, the wearable sensors can collect sensor data at a regular frequency. The passive collection of sensor data provides an advantage over manual self-reporting in reducing the need for direct patient interaction with a device while the device is acquiring sensor data.

[0033] The sensor data can be processed in a pre-processing step to create a set of patient data in a standardized format that can be used as an input into a classifier or similar statistical model. In one embodiment, the pre-processing can include transforming the sensor data. For example, the pre-processing can include removing noise from the sensor data (e.g., via low-pass filtering), removing bias or offset from the sensor data (e.g., via high-pass filtering), applying additional filtering to isolate frequency ranges within the sensor data, normalizing the sensor data, and / or transforming the sensor data from the time domain to the frequency domain or vice versa. In one embodiment, the processing can include fusing sensor data. For example, the sensor data can include motion sensor data collected by motion sensors, wherein each motion sensor is configured to collect data along a single directional axis. The motion sensor data for each directional axis can be fused to create multidimensional motion sensor data that describes how the patient is moving in multidimensional (e.g., three-dimensional) space. The fusion of sensor data can be a combination of inertial measurement unit (IMU) data collected across different axes. In one embodiment, fusion of sensor data can include the identification and combination or association of certain wavelet types in the sensor data. In one embodiment, the fusion of sensor data can include fusing different types of sensor data from different sensors. For example, a fusion of sensor data, including acceleration data, gyroscope data, and location data, can be used to determine if a patient is in motion and the speed at which they are moving. In another example, a fusion of motion sensor data and heart rate data can be used to determine if a patient is awake or asleep or a sleepstage of the patient. The patient data can include the pre-processed sensor data from each wearable sensor as well as sensor data that has been fused. For example, the patient data can include individual sensor data such as accelerometer data and gyroscope data as well as a fused sensor data. The sensor data can be pre-processed by the wearable device 100 or by the remote device 300. In one embodiment, the patient data can further include demographic information and medical information, including, but not limited to, age, gender, PD diagnosis date, use of physical assistance, height and weight, anthropometric data, past symptom evaluation or presentation, medication history, and other medical history. The demographic information and medical information can be input into a patient device, such as the mobile device 200, or can be retrieved from data storage, such as the patient database 120 of FIG. 2. The demographic information and medical information can be used in the classification of PD symptom severity. For example, the severity of a patient’s symptoms can depend on the patient’s age because some loss of motor function is normal with age for people who do not have PD.

[0034] In one embodiment, the remote device 300 can extract data features from the patient data. The data features can include statistical metrics and patterns of the patient data. In some embodiments, the data features can describe a probability distribution of the patient data. For example, the data features can include a count, a sum, a mean, a median, a mode, a minimum, a maximum, a standard deviation, a variance, a skew, kurtosis, percentiles and percentile ranks, quartiles, proportions, an amplitude, or a duration of the patient data. In some embodiments, the data features can be patterns or characteristics of the data that may or may not map to known descriptors or labels. For example, a data feature can be a certain waveform within the patient data or can be related to a recurrence of a waveform. In one embodiment, the data features can be extracted for each type of patient data. For example, the remote device 300 can extract a meanacceleration from a set of acceleration data, a mean heartbeat from a set of heartbeat data, etc. The data features can be used as inputs to the statistical model used for classification of PD symptom severity. The use of data features can reduce the amount of patient data that is stored and input into the statistical model, thus reducing the computational requirements of the statistical model while preserving defining attributes of the patient data.

[0035] The extracted data features can have varying utility and relevance in classifying PD symptom severity. In some embodiments, the remote device 300 can identify and select the data features that are relevant for classification of symptom severity. The most relevant data features can be determined during the training of the symptom severity classifier. As an exemplary model, a symptom severity classifier can be trained using a machine learning method with labeled symptom data. The labeled symptom data can include patient data that is collected and corresponds to a number of PD symptoms, wherein the severity of each PD symptom has been identified and labeled. The severity score of each symptom can be based on a metric or scale that is specific to that symptom. The symptom severity classifier can be trained to predict symptom severity based on the patient data and / or data features extracted from the patient data. In some embodiments, the symptom severity classifier can be trained by the remote device 300.

[0036] In one embodiment, the remote device 300 can process and analyze patient data, including the extracted data features, in order to generate a context of a patient’s state. As an illustrative and non-limiting example, the remote device 300 can generate data related to the patient’s movement. The movement data can be quantitative and / or qualitative and can describe the context in which the patient data is collected. The context in which the data is collected can refer to a type of movement, a cause, a purpose, or a result of a movement that is quantified by sensor data. For example, motion sensor data from motion sensors located on a patient’s wrist can indicate adisplacement and a rotation of a patient’ s hand. The displacement and rotation of the patient’s hand, as indicated solely by the motion sensor data without further analysis, does not provide information about what the patient is doing at the time that the motion sensor data is collected. The context of the type of motion or movement of the patient’s hand can be identified by analyzing and classifying the sensor data collected while the patient’s hand was moving. In one embodiment, the remote device 300 can classify a patient’s movement based on the patient data, including the extracted data features, using one or more sub-classifiers. The classification can include, for example, a type of movement, such as a gesture or a hand movement. In one embodiment, the type of movement can be a movement associated with a region or part of the body. In one embodiment, the classification of the type of movement can include a degree or other characteristic of the movement, such as a speed, duration, amplitude, displacement, or force. The degree of movement can be qualitative or can be quantitative. In one embodiment, the context of the patient’s state can include a combination of movements, e.g., a number of movements executed in sequence.

[0037] In one embodiment, the remote device 300 can use sub-classifiers to assign one or more movement type classifications to a set of patient data. For example, a first sub-classifier can classify the set of patient data as one or more gestures. A second sub-classifier can classify the set of patient data according to a type of movement of a region of the body, such as a hand movement. The sub-classifiers can classify the same set of patient data in parallel. In one embodiment, the remote device 300 can predict an activity or type of activity based on the one or more movement type classifications of the patient data as a context of the patient’s state. An activity can be comprised of a number of movements or movement types in combination. In one embodiment, the activity can be a known activity used in a motor examination or similar neurological evaluation, such as a speech task, a facial expression task, a rigidity test, finger tapping, hand movements, toetapping, an agility test, sitting and standing, a balance test, a posture test, touching a part of the body, or walking a certain distance. In some embodiments, the type of activity can include an interaction with an object, such as picking an object up, opening or closing an object, or the like. In one embodiment, the prediction of the activity can be based on a mapping of the one or more movement type classifications in combination with each other to an activity. In one embodiment, the remote device 300 can predict the activity using an activity type sub-classifier, wherein the input to the activity type sub-classifier is the one or more movement type classifications and the output of the activity type sub-classifier is a predicted activity. The activity type sub-classifier can be, for example, a rules-based classifier.

[0038] In one embodiment, the remote device 300 can segment the patient data overtime in order to process the patient data. The remote device 300 can analyze the patient data to determine context data corresponding to a window of time. For example, a patient can execute a number of movements over time, and the timing of the movements can be indicative of the patient’ s mobility. In one embodiment, the remote device 300 can use a moving or rolling window to process the patient data, wherein the rolling window is a continuous span of time with a lower bound (start point / time) and upper bound (end point / time). The rolling window can encompass a subset of the patient data acquired over the continuous span of time, e.g., a number of seconds. The remote device 300 can analyze a first subset of patient data within the rolling window at a first position to classify movement type and / or predict an activity based on the subset of the patient data. The rolling window can then shift to a second position in the patient data to encompass a second subset of patient data at the second position. The nature of a rolling window can result in an overlap between the first subset of patient data and the second subset of patient data. The overlap between the first subset of patient data and the second subset of patient data can vary based on the shift andwidth of the rolling window. For example, if the rolling window shifts by one second at a time, the overlap between the first subset and the second subset will be equal tow-1, wherein twis the width of the rolling window. If the rolling window shifts by two seconds at a time, the overlap between the first subset and the second subset will be equal to tv-2.

[0039] As an exemplary implementation, in a first position, the rolling window can encompass a first subset of patient data collected between time (0 t= and Z=5 seconds. The remote device 300 can use the sub-classifiers to classify one or more movement types based on the first subset of patient data. In the second position, the rolling window can shift by one second and can encompass a second subset of patient data collected between t=2 and t=6 seconds. The remote device 300 can use the sub-classifiers to classify one or more movement types based on the second subset of patient data. The use of rolling time windows can provide a continuous classification of the patient data and a more accurate determination of how movement types are related to each other, as well as when a patient begins and terminates a movement. In one embodiment, the length of the rolling window and the time shift of the rolling window can be set based on an amount of patient data that is needed for the sub-classifier to accurately classify a movement type. In some embodiments, the length of the rolling window and the time shift can vary based on the PD symptom that is being classified.

[0040] Alternatively or additionally, the remote device 300 can process the patient data over a fixed and distinct period of time. For example, the remote device 300 can extract data features and classify symptom severity based on patient data collected over the fixed period of time. The remote device 300 can identify and classify one or more movement types within the fixed period. In some embodiments, the remote device 300 can apply a rolling window to classify the movement types within the fixed period. The use of a fixed period of time can standardize and / or limit the amountof patient data used to classify symptom severity. Tn some embodiments, the length of the fixed period of time can be determined based on an optimal amount of time or patient data that is needed to classify PD symptom severity. For example, a fixed period that is very long (e.g., several hours) can result in an excess of patient data that increases computational intensity but does not improve the accuracy of symptom severity classification. A fixed period that is too short (e.g., a few seconds) may not include enough patient data to accurately classify symptom severity. In one embodiment, the length of the fixed period can be determined during the training of the statistical models of the present disclosure.

[0041] FIG. 3 is a schematic of a sub-classification workflow 1000, according to one embodiment of the present disclosure. The workflow 1000 can include one or more processing functions and can be used to classify movement types as a context of a patient’s state based on a set of patient data. The processing in the workflow 1000 can be performed by the remote device 300 using sensor data received from wearable device 100. Initially, the remote device 300 can pre-process the sensor data to remove noise and standardize the sensor data to create patient data, as in function block 1100. In one embodiment, the pre-processing can include the extraction of relevant data features from the patient data, as in function block 1200. The patient data features can be used in addition to or in place of the pre-processed patient data. The remote device 300 can separate the patient data into subsets of patient data using rolling windows. The remote device 300 can then classify the subsets of patient data using one or more movement type sub-classifiers 1300. The movement type sub -classifiers can be non-exclusive. The remote device 300 can output a predicted movement type, e.g., a predicted hand movement type, as one example of the context of the patient’s state when sensor data is collected.

[0042] Tn some embodiments, the remote device 300 can calculate and extract a feature summary over a fixed period of time. The fixed period of time can be longer than the duration of the rolling windows. As a non-limiting example, the fixed period of time can be a number of minutes, while the rolling windows can be less than a minute or approximately one minute in duration. The feature summary can include data features that are extracted from the patient data over the fixed period of time. In some embodiments, the feature summary can include data features that have been determined to be relevant to classification in prior training steps of the symptom severity classifier.

[0043] The remote device 300 can use the combination of the movement type classifications and the data features to predict an activity type using an activity type classifier, as in the schematic of the sub-classifier workflow 1500 of FIG. 4. The activity type is also referenced herein as an illustrative example of a context of a patient’s state. The activity type classifier can predict activities being performed over a longer period of time than a single rolling window. For example, an activity type identified by the activity type classifier can be comprised of a combination of movement types. The activity type can be predicted based on the type(s), duration, and sequence of the movements that are classified in FIG. 3. As illustrated in FIG. 4, the remote device 300 can perform the same pre-processing steps to extract data features in rolling windows. The remote device 300 can then use the data features and the predicted movement type referenced in FIG. 3 to classify an activity type using an activity type classifier 1400. The remote device 300 can output the predicted activity type.

[0044] Tn one embodiment, the remote device 300 can predict one or more activity types being performed over one or more fixed periods of time. In one embodiment, a predicted activity type can be one that is performed more than once within the fixed period of time. In one embodiment, the remote device 300 can predict more than one activity type within the fixed period of time basedon the patient data. In some embodiments, the sub-classification workflow 1000 can be used to predict activity types based on patient data collected over one or more movements. For example, a patient can execute a number of activities that are commonly used in assessing motor function. The patient data can include data collected during the number of activities. The activity types that are identified and classified based on the patient data can be used to properly identify progression ofPD. In some embodiments, the remote device 300 can classify the patient data over fixed periods of different durations. In some embodiments, a length of a fixed period can correspond to a typical length of one or more activities. The predicted activity type can provide context as to a type of movement or other factors that result in a patient exhibiting PD symptoms. The prediction of one or more activity types based on the patient data can be used to classify PD symptom severity. For example, the activity type can be used to identify deviation in the patient’s movement from typical movement when performing the activity, wherein the deviation can be associated with a symptom of PD and / or a decline in motor function.

[0045] The predicted activity type, as well as the patient data and additional classifications derived therefrom in the workflow 1000, can be used to evaluate the severity of the patient’s PD symptoms. In one embodiment, the symptom severity classifier can be a classifier that is trained to classify symptom severity based at least in part on the data features that were selected via feature selection techniques, as has been described herein. The symptom severity classifier can be trained on a large dataset of labeled training data, wherein the labeled training data includes PD symptoms that have been assessed for a severity level. For example, the severity levels can be assigned by clinicians based on an assessment of a patient. The training data can further include sensor data that is collected from each patient. For example, the sensor data can be collected during a motor examination wherein a patient performs a number of activities. The patient’s PD symptoms can beexhibited / present during the motor examination. The training data can include the activities that were performed by the patient. The training data can include an association (e.g., a temporal alignment) between data features extracted from a set of sensor data and the activity that was being performed when the sensor data was collected. In one embodiment, the training data can include movement type classifications. In one example, the training data can include demographic information and medical information that are also associated with the symptoms. In this manner, the symptom severity classifier can be trained to predict a severity based on the patient’s general health in addition to the sensor data that is collected during their activities.

[0046] In one embodiment, the symptom severity classifier can classify the patient data based on the extracted data features, the movement classifications, and the predicted activity type. In one embodiment, the remote device 300 can input a summary of data features, a summary of movement classifications, and a summary of predicted activity types as input data to the symptom severity classifier. The symptom severity classifier can then determine the severity of a certain PD symptom. In one embodiment, the remote device 300 can input the same input data into a number of symptom severity classifiers, wherein each classifier can identify a different symptom and the severity of the symptom. In one embodiment, the input data can be summary data over a fixed period of time. The fixed period can include one or more predicted activities. In some embodiments, the symptom severity classifier can output a prediction of symptom severity in the form of a numerical score.

[0047] FIG. 5 is a schematic of a clinical evaluation classification workflow 2000, according to one embodiment of the present disclosure. The workflow 2000 can be executed by a remote device 300. The remote device 300 can receive sensor data and additional patient data from other devices, such as wearable device 100 and mobile device 200 of FIG. 1. The remote device 300 can firstextract data features from the patient data and can use one or more sub-classifiers to determine context of the patient’s state based on the patient data, as has been described herein with reference to workflow 1000 of FIG. 3 and the workflow 1500 of FIG. 4. The remote device 300 can generate a summary of the data features and the context data for a session of movement and patient data collection, as in the summary function block 2100. The remote device 300 can then input the summary of data features and context data, such as movement classifications and predicted activity types, to a clinical evaluation classifier 2200. The clinical evaluation classifier 2200 can determine whether the patient data was collected during a clinical evaluation of a patient based on the data features and the context data. In one embodiment, the classification of a clinical evaluation can also be used as a context of a patient’s state. In one example, the input data can correspond to a number of movement sessions. Each movement session can include one or more activity types that have been identified by a sub-classifier. In some implementations, each movement session can include a different set of activities. There can be some overlap, full overlap, or no overlap in the activities of each movement session. In one embodiment, the symptom severity classifier can predict a symptom severity based on each movement session. A plurality of movement sessions can provide more samples of patient data across a wider range of activities for more accurate prediction of symptom severity.

[0048] The symptom severity classifier can predict a severity score for a PD symptom based on the input data including the extracted data features and the context of the patient state, including the classifications described with reference to FTGs. 3 through 5. Tn some embodiments, the severity score can be, for example, a score associated with a rating scale, such as the UPDRS. In one embodiment, the severity score can be a categorical score that is associated with a descriptor of severity, such as mild, moderate, severe, etc. The severity score can be the same type of scorethat is present in the training data for the symptom severity classifier. Tn some embodiments, a symptom severity classifier can predict a first severity score based on predicted activities from a first period of patient data collection and a second severity score based on predicted activities from a second period of patient data collection. In embodiments wherein the symptom severity classifier can predict more than one severity score from a set of patient data, the remote device 300 can take an average of the predicted scores. In one embodiment, the average can be based on a rolling or moving average. Alternatively or additionally, the average can be a weighted average of the predicted scores. The symptom severity classifier can then output the average predicted severity score.

[0049] The remote device 300 can determine a number of symptom severity scores for different PD symptoms using one or more classifiers. A classifier can be trained to predict severity of one or more PD symptoms. In some embodiments, symptoms can be evaluated in conjunction with each other. The following are presented as exemplary implementations of the symptom severity classifiers described herein. It can be appreciated that the PD symptoms highlighted herein are non-limiting examples of the symptoms that can be identified and assessed by the symptom severity classifiers.

[0050] In one embodiment, the remote device 300 can evaluate patient data in order to assess severity of bradykinesia in a patient. Bradykinesia (BK) is a defining motor symptom in PD and can refer to slowness in initiating and executing movements. BK can be observed as delays or hesitation in movement, as well as reduced amplitude of movement, reduced overall movement, and reduction in spontaneous gestures. BK is represented in a global rating, e.g., according to the UPDRS or the Movement Disorder Society-Sponsored Revision of the UPDRS (MDS-UPDRS). BK can be directly measured through the UPDRS-III examination, including during tasks relatedto hand movement. FIG. 6 is a schematic of a BK severity classification workflow, according to one embodiment of the present disclosure. The classification workflow can include one or more sub-classifiers. The classifications from the one or more sub-classifiers can be used as inputs into a BK severity classifier.

[0051] In one embodiment, a patient can perform a number of activities, such as those listed in the UPDRS-III, while wearing a wearable device including wearable sensors. The activities can be performed over one or more movement sessions, wherein a movement session can include a set number of activities or a set of activity types. In some embodiments, the activities can be ones that are not listed in the UPDRS-III. For example, the activities can include everyday behaviors that the patient performs outside of the context of a motor evaluation, such as walking, carrying objects, cooking, personal hygiene, etc. The wearable device can be, for example, a wristband including one or more accelerometers, gyroscopes, location sensors, and heart rate monitors. The wearable sensors can collect sensor data while the patient is performing the activities. The wearable sensors can then transmit the sensor data to a remote device, such as a server, over a communication network. The server can receive the sensor data and additional patient data, such as the patient’s medical history and demographic information. The medical history can include, for example, medication that the patient is taking and when they last took the medication. The additional patient data can be inputted into and transmitted by another patient device, such as the patient’s mobile device.

[0052] The server can pre-process the sensor data to remove noise and other anomalies in the sensor data and to standardize the format of the sensor data, thereby creating the patient data. The pre-processing can include fusing sensor data, e.g., the accelerometer data and the gyroscope data. The server can divide the patient data into subsets of patient data captured within a rolling window15of time. The duration of the rolling window can be, for example, less than one minute. The server can analyze the subsets of patient data to extract data features from the patient data. The server can then use one or more sub-classifiers to determine context data, including movement types, activity types, and clinical evaluation classification based on the extracted data features and / or the pre- processed patient data. A movement type can be, for example, a movement of a body part during a motor examination. In some embodiments, the sub-classifier can map the patient data, including the extracted data features, to a movement type. In some embodiments, the sub-classifier can identify the movement type based on a rules-based classification, wherein the rules can be determined during the training of the sub-classifier. The server can predict an activity type based on the movement type classifications of the patient data. The activity type can be, for example, an activity associated with the UPDRS-III motor examination. The activity type can be comprised of a number of movements that were identified based on the patient data. The server can further predict whether the patient data was collected during a clinical evaluation.

[0053] The server can use the sub-classifier to classify the patient data into a number of movement types and predicted activity types over a fixed period of time, e.g., more than one minute. The server can then generate a summary of extracted data features over the fixed period of time and a summary of context data, including a summary of movement type classifications over the fixed period of time, a summary of activity type classifications over the fixed period of time, and a summary of clinical evaluation predictions over the fixed period of time. In some embodiments, the summary of extracted data features can include select data features that have been shown to be relevant to classification of BK severity in training of a BK severity classifier. The server can input the summary data into the BK severity classifier. The BK severity classifier can be a classifier that is trained to identify BK in patient movements and evaluate the severity of BK according to aglobal rating For example, the BK severity score can be a rating between 1 -3 or 1 -4. The BK severity classifier can predict a BK severity score for one or more movement sessions. In some embodiments, the distinction between movement sessions can be identified in the summary data that is input into the BK severity classifier. In one embodiment, the movement sessions can be different lengths, e.g., 5 minutes and 15 minutes. The BK severity classifier can then take an average of the BK severity scores for each of the movement sessions. The BK severity classifier can output a single BK severity score as a rating based on the movement sessions. The server can transmit the BK severity score and a report to the wearable device of the patient or the mobile device of the patient.

[0054] In one embodiment, the remote device 300 can evaluate patient data in order to assess severity of dyskinesia in a patient. Dyskinesia (DK) is a motor symptom that can occur as a side effect of medication used to treat PD and can be characterized by abnormal, involuntary movements, such as writhing, twisting, or twitching. DK can be measured by the Abnormal Involuntary Movement Scale (AIMS), the Clinical Dyskinesia Rating Scale (CDRS), and the Unified Dyskinesia Rating Scale (UDysRS). FIG. 7 is a schematic of a DK severity classification workflow, according to one embodiment of the present disclosure. The classification workflow can include one or more sub-classifiers. The classifications from the one or more sub-classifiers can be used as inputs into a DK severity classifier.

[0055] In one embodiment, a patient can perform a number of activities, such as those listed in the UPDRS-ITI, while wearing a wearable device including wearable sensors. The activities can be performed over one or more movement sessions, wherein a movement session can include a set number of activities or a set of activity types. In some embodiments, the activities can be ones that are not listed in the UPDRS-III. For example, the activities can include everyday behaviors thatthe patient performs outside of the context of a motor evaluation, such as walking, carrying objects, cooking, etc. Abnormal movements can occur and be identified in various everyday behaviors. The wearable device can be, for example, a wristband including one or more accelerometers, gyroscopes, location sensors, and heart rate monitors. The wearable sensors can collect sensor data while the patient is performing the activities. The wearable sensors can then transmit the sensor data to a remote device, such as a server, over a communication network. The server can receive the sensor data and additional patient data, such as the patient’s medical history and demographic information. The medical history can include, for example, medication that the patient is taking and when they last took the medication. The additional patient data can be inputted into and transmitted by another patient device, such as the patient’s mobile device.

[0056] The server can pre-process the sensor data to remove noise and other anomalies in the sensor data and to standardize the format of the sensor data, thereby creating the patient data. The pre-processing can include fusing sensor data, e.g., the accelerometer data and the gyroscope data. The server can divide the patient data into subsets of patient data captured within a rolling window of time. The duration of the rolling window can be, for example, less than one minute. The server can analyze the subsets of patient data to extract data features from the patient data. The server can then use one or more sub-classifiers to determine context data, including movement types, activity types, and clinical evaluation classification based on the extracted data features and / or the pre- processed patient data. A movement type can be, for example, a movement of a body part during a motor examination. Tn some embodiments, the sub-classifier can map the patient data, including the extracted data features, to a movement type. In some embodiments, the sub-classifier can identify the movement type based on a rules-based classification, wherein the rules can be determined during the training of the sub-classifier. The server can predict an activity type basedon the movement type classifications of the patient data. The activity type can be, for example, an activity associated with a motor examination. The server can further predict whether the patient data was collected during a clinical evaluation.

[0057] The server can use the sub-classifier to classify the patient data into a number of movement types and predicted activity types over a fixed period of time, e.g., more than one minute. The server can then generate a summary of extracted data features over the fixed period of time and a summary of context data, including a summary of movement type classifications over the fixed period of time, a summary of activity type classifications over the fixed period of time, and a summary of clinical evaluation predictions over the fixed period of time. In some embodiments, the summary of extracted data features can include select data features that have been shown to be relevant to classification of DK severity in training of a DK severity classifier. The server can input the summary data into the DK severity classifier. The DK severity classifier can be a classifier that is trained to identify DK in patient movements and evaluate the severity of DK according to one or more of the scales described above. For example, the DK severity score can be a rating of 1 or 2. The DK severity classifier can predict a DK severity score for one or more movement sessions. In some embodiments, the distinction between movement sessions can be identified in the summary data that is input into the DK severity classifier. The DK severity classifier can then take an average of the DK severity scores for each of the movement sessions. The DK severity classifier can output a single DK severity score as a rating based on the movement sessions. The server can transmit the DK severity score and a report to the wearable device of the patient or the mobile device of the patient.

[0058] In one embodiment, the remote device 300 can evaluate patient data in order to evaluate amplitude and severity of tremors. Tremors are a hallmark symptom of PD and can be defined asinvoluntary, rhythmic oscillations between muscle contraction and relaxation. There are many types of tremors, including resting tremor, which is a predominant type; action tremor; and postural tremor. A tremor can be an involuntary movement of the body or a part of the body at or above a given amplitude that can occur when a patient is at rest (e.g., sitting). A tremor can also occur when the patient is moving or when some body parts are in motion and other body parts are at rest. In one embodiment, a patient can perform a number of activities, such as those listed in the UPDRS-III, while wearing a wearable device including wearable sensors. The activities can be performed over one or more movement sessions, wherein a movement session can include a set number of activities or a set of activity types. Tremor is frequently present and evaluated in the hand and / or arm and can be observed during the activities of the UPDRS-III motor examination. In some embodiments, the activities can be ones that are not listed in the UPDRS-III. For example, the activities can include everyday behaviors that the patient performs outside of the context of a motor evaluation, such as walking, carrying objects, cooking, etc. In some embodiments, the patient can be at rest. The wearable device can be, for example, a wristband including one or more accelerometers, gyroscopes, location sensors, and heart rate monitors. The wearable sensors can collect sensor data while the patient is performing the activities or at rest. The wearable sensors can then transmit the sensor data to a remote device, such as a server, over a communication network. The server can receive the sensor data and additional patient data, such as the patient’s medical history and demographic information. The medical history can include, for example, medication that the patient is taking and when they last took the medication. The additional patient data can be inputted into and transmitted by another patient device, such as the patient’s mobile device.

[0059] FIG. 8 is a schematic of a tremor severity classification workflow, according to one embodiment of the present disclosure. The server can pre-process the sensor data to remove noise and other anomalies in the sensor data and to standardize the format of the sensor data, thereby creating the patient data. The pre-processing can include fusing sensor data, e.g., the accelerometer data and the gyroscope data. The server can divide the patient data into subsets of patient data captured within a rolling window of time. The duration of the rolling window can be, for example, less than one minute. The server can analyze the subsets of patient data to extract data features from the patient data. The server can then use one or more sub-classifiers to determine context data, including movement types, activity types, and clinical evaluation classification based on the extracted data features and / or the pre-processed patient data. A movement type can be, for example, a movement of a body part during a motor examination. In some embodiments, the sub-classifier can map the patient data, including the extracted data features, to a movement type. In some embodiments, the sub-classifier can identify the movement type based on a rules-based classification, wherein the rules can be determined during the training of the sub-classifier. The server can predict an activity type based on the movement type classifications of the patient data. The activity type can be, for example, an activity associated with a motor examination. The server can further predict whether the patient data was collected during a clinical evaluation.

[0060] In one embodiment, the server can further use a tremor amplitude sub-classifier to classify a tremor into an amplitude category based on the extracted data features and the context data. An amplitude of a tremor can refer to a displacement (e g., of a body part) produced by a tremor from a fixed location or plane. A tremor can be classified as a fine, medium, or coarse tremor based on the amplitude. A coarse tremor results in a larger displacement, while a fine tremor can result in a smaller displacement. The tremor amplitude sub-classifier can determine a tremor amplitudewithin each rolling window of time. Tremors can occur in sequence, and tremor amplitude can change within a relatively short window of time. Thus, it can be useful to determine the amplitude of individual tremors in order to assess the severity of a patient’s tremor as a whole. The tremor amplitude sub-classifier can identify a tremor and assign an amplitude classification to tremors across rolling windows according to any known scale for tremor rating, including, but not limited to, a logarithmic scale or a displacement-based scale. As an example, the tremor amplitude subclassifier can determine the displacement of a patient’s body part (e.g., the arm) and any angular rotation of the body part. The displacement and angular rotation can be a sudden movement. If the body part was previously at rest and returns to rest after the movement, the displacement and angular rotation can indicate a resting tremor. The tremor amplitude sub-classifier can identify the tremor during a rolling window based on the context data and can determine an amplitude of the tremor based on the extracted data features present during the rolling window. The tremor amplitude sub-classifier can output a tremor amplitude for each rolling window wherein tremor is detected by the sub-classifier.

[0061] The server can then generate a summary of extracted data features over the fixed period of time and a summary of context data, including a summary of movement type classifications over the fixed period of time, a summary of activity type classifications over the fixed period of time, and a summary of clinical evaluation predictions over the fixed period of time. The server can also generate a summary of tremor amplitude classifications over the fixed period of time. The summary can be a compilation or aggregation of the sub -classifier outputs for each rolling window. In some embodiments, the summary of extracted data features can include select data features that have been shown to be relevant to classification of tremor severity in training of a tremor severity classifier. The server can input the summary of data into the tremor severity classifier. The tremorseverity classifier can be a classifier that is trained to evaluate tremor severity according to a numerical scale. For example, a tremor severity score can be a rating from 0 to 3. In some embodiments, the tremor severity score can be associated with a body part, such as the arm or the leg. The tremor severity classifier can predict a tremor severity score for one or more movement sessions. In some embodiments, the distinction between movement sessions can be identified in the summary data that is input into the tremor severity classifier. The tremor severity classifier can then take an average of the tremor severity scores for each of the movement sessions. The tremor severity classifier can output a single tremor severity score as a rating based on the movement sessions. The server can transmit the tremor severity score to the wearable device of the patient or the mobile device of the patient.

[0062] In each of the above examples, the server can use the same set of patient data to evaluate BK, DK, and tremor severity. The symptom severity classifier for each symptom can identify whether the symptom is present in the process of classifying symptom severity. Therefore, the use of symptom severity classifiers can reduce false positives that would occur when a symptom is assumed to be present during analysis even when it is not really present. The context data, e.g., the activity type classifications and the movement type classifications, can improve the accuracy of severity classification by indicating an expected range or type of movement corresponding to an activity or movement type. Deviations from the expected movements can then be identified from the data features and classified based on severity. In one embodiment, the additional context data, including the demographic data and medical history, can also affect the classification of symptom severity. For example, the rating of tremor severity as a result of Parkinson’s can depend on the age of a patient. In one embodiment, the tremor severity classifier can distinguish between tremor as a symptom of PD and essential tremor, which is an adult-onset tremor disorder that can bepresent in patients who do not have PD. Tn one example, a patient’s medical history can be used in conjunction with the predicted symptom severity to determine the effect of any PD medication on the patient.

[0063] It can be appreciated that a symptom severity classifier can be used to classify symptoms associated with PD in addition to or in place of the exemplary symptoms described above. For example, a symptom severity classifier according to the present disclosure can classify rigidity, postural instability, slowness of movement, changes in gait, freezing of gait, shuffling (gait), festination, motor fluctuations, micrographia, dystonia, hypophonia, masked facies, akinesia, fatigue, changes in arm swing when walking, difficulty initiating movement, or difficulty with fine motor tasks. In addition, the metrics used for classification of symptom severity can vary. For example, the server 300 can calibrate an output of a symptom severity classifier based on a preferred scale of a patient or a healthcare provider. The use of trained classifiers can provide detection of PD symptoms before they are noticeable to a patient or an observer, which can result in earlier detection and treatment of PD. The trained classifiers can use sensor data that can reflect changes in patient movement that are not easily observable. In addition, the trained classifiers can use a broad range of sensor data, such as heart rate and acceleration, and data features (e.g., patterns) extracted from the sensor data to predict symptom severity, whereas typical clinical evaluations are based only on observable behaviors rather than objective measures. In addition, a patient’s own patient data can be used by a classifier to establish a baseline for the patient’s movements in order to better identify changes in motor function over time. Tn general, a patient’s medical history and prior symptoms can be used in the prediction of symptom severity when new patient data is collected. The patient’s medical history and previously classified symptoms can be stored at the remote device 300 or accessed by the remote device 300. For example, the patient’srecords, including medical history and previously classified symptoms can be stored in a patient database, as is illustrated in FIG. 2. In one embodiment, new patient data that is received and classified by a symptom severity classifier can then be included in training data that can be used to retrain and update the classifier. The prediction of the symptom severity classifier can be confirmed or adjusted, e g., by a medical professional, before being used as training data to improve the accuracy of the severity classifier.

[0064] A remote device 300 such as a server can report predicted symptom severity to a user, such as a patient or a medical professional, by transmitting a PD symptom report to a user- accessible device such as the mobile device 200 of a patient or a reporting device 400. The mobile device 200 and / or the reporting device 400 can display the PD symptom report. A PD symptom report can include a symptom severity classification for one or more PD symptoms as determined based on the patient data. In one embodiment, the PD symptoms can be displayed in a static format, wherein the static format can include retrospective and / or prospective symptom data. The retrospective symptom data can include medical history of the patient, including previous symptom severity classifications and evaluation of changes in symptom severity over time. The prospective symptom data can include projections of future changes in symptom severity, including progression of motor function decline, based on present and / or past symptom severity. In some embodiments, the remote device 300 can predict prospective symptom data for one patient based on symptom progression in patients with similar symptom presentation and / or medical histories. Tn one embodiment, the PD symptom report can include a two-dimensional (2D) and / or a three-dimensional (3D) display of PD symptoms. The display of PD symptoms can be dynamic, e.g., can change over time or be adjusted based on a user input. In one embodiment, the PD symptom report can include a tracking of the effectiveness of medication, including PD medication.For example, the PD symptom report can include the progression of a patient’s PD symptoms over time. If the patient has been taking PD medication, the PD symptom report can display the change in the patient’s PD symptoms over time in parallel with the patient’s history of PD medication usage. The patient’s history of medication usage can include types of medication and dosages, as well as the time(s) of day and other conditions during which the patient takes medication. The combination of the PD symptom severity and the medication history can indicate a correlation between medication and symptom presentation. In some embodiments, the remote device 300 can compare the patient’ s symptom severity shortly after taking medication with the patient’ s symptom severity prior to taking medication to determine an effect of the medication.

[0065] In one embodiment, the remote device 300 and / or the mobile device 200 can assess a patient’s level of health risk based on the patient data and the patient’s symptom severity. For example, the remote device 300 can determine that a patient is at risk of accident or injury given the severity of the patient’s PD symptoms. The risk can depend on movements or activities that the patient may perform, such as driving or walking up / down a staircase. In one embodiment, the risk can be related to the self-sufficiency of the patient. For example, the severity of the patient’s PD symptoms can indicate that the patient is at increased risk if they perform certain actions without assistance from a device or a caretaker. The risk can change over time based on changes in the patient’s symptom severity. In one embodiment, the risk can further depend on environmental factors. For example, the mobile device 200 or the server 300 can access weather data corresponding to the patient’s location. The weather data can include, for example, temperature and precipitation. The patient’s sensitivity to changes in temperature can increase due to PD, and changes in temperature can also increase the severity of a patient’s PD symptoms. The PD symptom report can include a patient’s health risk for various activities given their presentenvironment or a potential future environment (e g., based on a weather forecast). Tn one embodiment, the remote device 300 or the mobile device 200 can directly transmit a signal to a second mobile device, such as a mobile device of a caretaker, as a result of the health risk assessment. For example, the remote device 300 can transmit an alert to the mobile device of a caretaker if the patient’ s health risk has increased based on a severity of the patient’ s PD symptoms or if it is detected that a patient has fallen or sustained an injury based on the patient data.

[0066] In one embodiment, the PD symptom report can include one or more medical recommendations for a patient based on the patient data and the PD symptom severity. Examples of a medical recommendation can include, but are not limited to, physical therapy (e.g., a specific exercise or activity), medication, whether or not to seek medical assistance, lifestyle changes such as diet and rest, and the use of a physical aid such as a walking aid or in-home care. In one embodiment, the remote device 300 can determine the medical recommendation based on a body of patient data, wherein the body of patient data can include symptom severity data for a number of patients as well as the patients’ general medical history. The remote device 300 can generate a medical recommendation for a patient based on patients with similar medical conditions and histories. In one embodiment, the remote device 300 can generate the one or more medical recommendations based on scientific studies or known medical guidance. The medical recommendations can be generated according to each patient’s specific patient data, thus providing a more precise and tailored treatment recommendation that can be customized to each patient’s unique needs and disease progression and leading to better disease management and quality of life.

[0067] The output of the PD symptom report can be configurable based on user input received by a user device. The user input can include input to a device peripheral, such as a keyboard or a mouse; input to a touch screen interface; voice commands; biometric data; and camera data. Forexample, a user device can include a user interface wherein input into the user interface can include a selection of report data to include and / or exclude. In one example, the user device can modify the displayed PD symptom report based on the received input. In one example, the user device can transmit a request to a remote device for report data corresponding to the received input and can receive the report data for inclusion in the PD symptom report. In one embodiment, the reporting device 400 can analyze input, e.g., using natural language processing (NLP), in order to determine the additional information that should be displayed or otherwise output to the patient. In one embodiment, the additional information can be generated via an automated speech or text generator in response to the input. The automated speech or text generator can include an artificial intelligence language model that has been trained for automated conversation with a human user. In one embodiment the PD symptom report can be output to a patent via a voice generator or text generator. In one embodiment, the PD symptom report can be compatible with augmented reality (AR) or virtual reality (VR) technologies. For example, the PD symptom report can be overlayed on image data that is captured by a device camera. In one example, the PD symptom report can be displayed by a VR device, such as a headset.

[0068] In one embodiment, the remote device 300 can update the contents of the PD symptom report based on user input. In one example, the user input can be received by a reporting device 400. The user input can be additional patient data, including, but not limited to, symptom reporting or patient outcome measures. Symptom reporting can include a direct report of an occurrence of symptoms and / or a severity of symptoms. The patient outcome measures can include, for example, an assessment of the patient’s quality of life and functional status. In some embodiments, the additional patient data that is received can be used to update the symptom severity classification, including retrospective and prospective symptom data. In some embodiments, the additionalpatient data that is received can be used to update an assessed health risk of a patient or a medical recommendation for a patient. For example, the additional patient data can include a patient’s preference for a type of medication. The remote device 300 can update a medical recommendation for the patient based on their preferred medication or an accessibility of the medication. In one embodiment, the PD symptom report can be distributed to a patient in the form of an interactive user interface. For example, a reporting device 400 can display data from the PD symptom report. The reporting device 400 can prompt the patient for input related to the PD symptom report. Upon receiving the input, such as additional patient data, the reporting device 400 can update the PD symptom report.

[0069] It can be appreciated that the methods and functions described herein can be performed by one or more devices. In some embodiments, the methods can be distributed across a number of devices. For example, a wearable device 100 can perform some pre-processing steps on the sensor data in order to remove noise or fuse the sensor data. In some embodiments, the training of the statistical models described herein, including the sub-classifiers and the symptom severity classifiers, can be distributed across more than one device, e.g., more than one computer or server. In one embodiment, the statistical models can be trained prior to and independently of the evaluation of new patient data. In one example, a reporting device 400 can update a PD symptom report based on a user input to include or exclude data rather than the remote device 300 updating the PD symptom report, and vice versa. In some embodiments, the reporting device 400 and the mobile device 200 of the patient can perform the same functions. Tn some embodiments, the processes of the mobile device 200 can be distributed across the mobile device 200 and the wearable device 100. For example, the mobile device 200 can transmit an alert to the wearabledevice 100 based on the PD symptom report. The wearable device 100 can generate a tactile / haptic alert to catch a wearer’s attention.

[0070] In one embodiment, the systems and methods described herein can be integrated with a telemedicine platform. The integration with the telemedicine platform can enable input from more than one device in the prediction of symptom severity. For example, a patient can use a mobile device 200 to communicate with a healthcare provider using a reporting device 400 via a wireless connection between the mobile device 200 and the reporting device 400. The healthcare provider can input data (e.g., demographic information, medical history) to the reporting device 400 about the patient, and the reporting device 400 can transmit the data to a remote device 300 such as a server. The patient can be wearing a wearable device 100 and can perform one or more activities based on instructions from the healthcare provider. The wearable device 100 can transmit sensor data to the remote device 300 that is captured while the patient is performing the one or more activities. The remote device 300 can use the sensor data from the wearable device 100 and the input data from the reporting device 400 to evaluate the severity of the patient’s PD symptoms. The remote device 300 can transmit a PD symptom report to the mobile device 200 of the patient as well as the reporting device 400 of the healthcare provider. Input from the mobile device 200 and from the reporting device 400 can both control the display of the PD symptom report. Care recommendations from the healthcare provider in response to the PD symptom report can be input to the reporting device 400 and transmitted to the mobile device 200. The remote device 300 can also receive the care recommendations and can incorporate the recommendations into a next iteration of the PD symptom report.

[0071] Electronic user device 20 shown in FIG. 9 can be an example of one or more of the devices described herein, including the patient mobile device 200 or the reporting device 400. In anembodiment, the electronic user device 20 may be a smartphone. However, the skilled artisan will appreciate that the features described herein may be adapted to be implemented on other devices (e.g., a laptop, a tablet, a server, an e-reader, a camera, a navigation device, etc.). The features described herein may also be adapted to be implemented on the wearable device 100 presented in FIG. 1. The exemplary user device 20 of FIG. 9 includes processing circuitry, as discussed above. The processing circuitry includes one or more of the elements discussed next with reference to FIG. 9. The electronic user device 20 may include other components not explicitly illustrated in FIG. 9 such as a CPU, GPU, frame buffer, etc. The electronic user device 20 includes a controller 410 and a wireless communication processor 402 connected to an antenna 401. A speaker 404 and a microphone 405 are connected to a voice processor 403.

[0072] The controller 410 may include one or more processors / processing circuitry (CPU, GPU, or other circuitry) and may control each element in the user device 20 to perform functions related to communication control, audio signal processing, graphics processing, control for the audio signal processing, still and moving image processing and control, and other kinds of signal processing. The controller 410 may perform these functions by executing instructions stored in a memory 450. Alternatively or in addition to the local storage of the memory 450, the functions may be executed using instructions stored on an external device accessed on a network or on a non-transitory computer readable medium.

[0073] The memory 450 includes but is not limited to Read Only Memory (ROM), Random Access Memory (RAM), or a memory array including a combination of volatile and non-volatile memory units. The memory 450 may be utilized as working memory by the controller 410 while executing the processes and algorithms of the present disclosure. Additionally, the memory 450 may be used for long-term storage, e.g., of image data and information related thereto.

[0074] The user device 20 includes a control line CL and data line DL as internal communication bus lines. Control data to / from the controller 410 may be transmitted through the control line CL. The data line DL may be used for transmission of voice data, displayed data, etc.

[0075] The antenna 401 transmits / receives electromagnetic wave signals between base stations for performing radio-based communication, such as the various forms of cellular telephone communication. The wireless communication processor 402 controls the communication performed between the user device 20 and other external devices via the antenna 401. For example, the wireless communication processor 402 may control communication between base stations for cellular phone communication.

[0076] The speaker 404 emits an audio signal corresponding to audio data supplied from the voice processor 403. The microphone 405 detects surrounding audio and converts the detected audio into an audio signal. The audio signal may then be output to the voice processor 403 for further processing. The voice processor 403 demodulates and / or decodes the audio data read from the memory 450 or audio data received by the wireless communication processor 402 and / or a short-distance wireless communication processor 407. Additionally, the voice processor 403 may decode audio signals obtained by the microphone 405.

[0077] The exemplary user device 20 may also include a display 420, a touch panel 430, an operation key 440, and a short-distance communication processor 407 connected to an antenna 406. The display 420 may be a Liquid Crystal Display (LCD), an organic electroluminescence display panel, or another display screen technology. Tn addition to displaying still and moving image data, the display 420 may display operational inputs, such as numbers or icons which may be used for control of the user device 20. The display 420 may additionally display a GUI for a user to control aspects of the user device 20 and / or other devices. Further, the display 420 maydisplay characters and images received by the user device 20 and / or stored in the memory 450 or accessed from an external device on a network. For example, the user device 20 may access a network such as the Internet and display text and / or images transmitted from a Web server.

[0078] The touch panel 430 may include a physical touch panel display screen and a touch panel driver. The touch panel 430 may include one or more touch sensors for detecting an input operation on an operation surface of the touch panel display screen. The touch panel 430 also detects a touch shape and a touch area. Used herein, the phrase “touch operation” refers to an input operation performed by touching an operation surface of the touch panel display with an instruction object, such as a finger, thumb, or stylus-type instrument. In the case where a stylus or the like is used in a touch operation, the stylus may include a conductive material at least at the tip of the stylus such that the sensors included in the touch panel 430 may detect when the stylus approaches / contacts the operation surface of the touch panel display (similar to the case in which a finger is used for the touch operation).

[0079] In certain aspects of the present disclosure, the touch panel 430 may be disposed adjacent to the display 420 (e.g., laminated) or may be formed integrally with the display 420. For simplicity, the present disclosure assumes the touch panel 430 is formed integrally with the display 420 and therefore, examples discussed herein may describe touch operations being performed on the surface of the display 420 rather than the touch panel 430. However, the skilled artisan will appreciate that this is not limiting.

[0080] For simplicity, the present disclosure assumes the touch panel 430 is a capacitance-type touch panel technology. However, it should be appreciated that aspects of the present disclosure may easily be applied to other touch panel types (e.g., resistance-type touch panels) with alternatestructures. Tn certain aspects of the present disclosure, the touch panel 430 may include transparent electrode touch sensors arranged in the X-Y direction on the surface of transparent sensor glass.

[0081] The touch panel driver may be included in the touch panel 430 for control processing related to the touch panel 430, such as scanning control. For example, the touch panel driver may scan each sensor in an electrostatic capacitance transparent electrode pattern in the X-direction and Y-direction and detect the electrostatic capacitance value of each sensor to determine when a touch operation is performed. The touch panel driver may output a coordinate and corresponding electrostatic capacitance value for each sensor. The touch panel driver may also output a sensor identifier that may be mapped to a coordinate on the touch panel display screen. Additionally, the touch panel driver and touch panel sensors may detect when an instruction object, such as a finger is within a predetermined distance from an operation surface of the touch panel display screen. That is, the instruction object does not necessarily need to directly contact the operation surface of the touch panel display screen for touch sensors to detect the instruction object and perform processing described herein. For example, in an embodiment, the touch panel 430 may detect a position of a user’s finger around an edge of the display panel 420 (e.g., gripping a protective case that surrounds the display / touch panel). Signals may be transmitted by the touch panel driver, e.g. in response to a detection of a touch operation, in response to a query from another element based on timed data exchange, etc.

[0082] The touch panel 430 and the display 420 may be surrounded by a protective casing, which may also enclose the other elements included in the user device 20. Tn an embodiment, a position of the user’s fingers on the protective casing (but not directly on the surface of the display 420) may be detected by the touch panel 430 sensors. Accordingly, the controller 4T0 may perform display control processing described herein based on the detected position of the user’s fingersgripping the casing. For example, an element in an interface may be moved to a new location within the interface (e.g., closer to one or more of the fingers) based on the detected finger position.

[0083] Further, in an embodiment, the controller 410 may be configured to detect which hand is holding the user device 20, based on the detected finger position. For example, the touch panel 430 sensors may detect fingers on the left side of the user device 20 (e.g., on an edge of the display 420 or on the protective casing), and detect a single finger on the right side of the user device 20. In this exemplary scenario, the controller 410 may determine that the user is holding the user device 20 with his / her right hand because the detected grip pattern corresponds to an expected pattern when the user device 20 is held only with the right hand.

[0084] The operation key 440 may include one or more buttons or similar external control elements, which may generate an operation signal based on a detected input by the user. In addition to outputs from the touch panel 430, these operation signals may be supplied to the controller 410 for performing related processing and control. In certain aspects of the present disclosure, the processing and / or functions associated with external buttons and the like may be performed by the controller 410 in response to an input operation on the touch panel 430 display screen rather than the external button, key, etc. In this way, external buttons on the user device 20 may be eliminated in lieu of performing inputs via touch operations, thereby improving watertightness.

[0085] The antenna 406 may transmit / receive electromagnetic wave signals to / from other external apparatuses, and the short-distance wireless communication processor 407 may control the wireless communication performed between the other external apparatuses. Bluetooth, IEEE 802.11, and near-field communication (NFC) are non-limiting examples of wireless communication protocols that may be used for inter-device communication via the short-distance wireless communication processor 407.

[0086] The user device 20 may include a motion sensor 408. The motion sensor 408 may detect features of motion (i.e., one or more movements) of the user device 20. For example, the motion sensor 408 may include an accelerometer to detect acceleration, a gyroscope to detect angular velocity, a geomagnetic sensor to detect direction, a geo-location sensor to detect location, etc., or a combination thereof to detect motion of the user device 20. In an embodiment, the motion sensor 408 may generate a detection signal that includes data representing the detected motion. For example, the motion sensor 408 may determine a number of distinct movements in a motion (e.g., from start of the series of movements to the stop, within a predetermined time interval, etc.), a number of physical shocks on the user device 20 (e.g., a jarring, hitting, etc., of the electronic device), a speed and / or acceleration of the motion (instantaneous and / or temporal), or other motion features. The detected motion features may be included in the generated detection signal. The detection signal may be transmitted, e.g., to the controller 410, whereby further processing may be performed based on data included in the detection signal. The motion sensor 408 can work in conjunction with a Global Positioning System (GPS) section 460. The information of the present position detected by the GPS section 460 is transmitted to the controller 410. An antenna 461 is connected to the GPS section 460 for receiving and transmitting signals to and from a GPS satellite.

[0087] The user device 20 may include a camera section 409, which includes a lens and shutter for capturing photographs of the surroundings around the user device 20. In an embodiment, the camera section 409 captures surroundings of an opposite side of the user device 20 from the user. The images of the captured photographs can be displayed on the display panel 420. A memory section saves the captured photographs. The memory section may reside within the camera section 109 or it may be part of the memory 450. The camera section 409 can be a separate feature attached to the user device 20 or it can be a built-in camera feature.

[0088] Next, a hardware description of a device 601 according to exemplary embodiments is described with reference to FIG. 10. In FIG. 10 the device 601, which can be any of the above described devices, including the remote device 300 (e.g., a server) or the reporting device 400, includes processing circuitry. The processing circuitry includes one or more of the elements discussed next with reference to FIG. 10. The process data and instructions may be stored in memory 602. These processes and instructions may also be stored on a storage medium disk 604 such as a hard drive (HDD) or portable storage medium or may be stored remotely. Further, the claimed advancements are not limited by the form of the computer-readable media on which the instructions of the inventive process are stored. For example, the instructions may be stored on CDs, DVDs, in FLASH memory, RAM, ROM, PROM, EPROM, EEPROM, hard disk or any other information processing device with which the device 601 communicates, such as a server or computer.

[0089] Further, the claimed advancements may be provided as a utility application, background daemon, or component of an operating system, or combination thereof, executing in conjunction with CPU 600 and an operating system such as Microsoft Windows, UNIX, Solaris, LINUX, Apple MAC -OS and other systems known to those skilled in the art.

[0090] The hardware elements in order to achieve the device 601 may be realized by various circuitry elements, known to those skilled in the art. For example, CPU 600 may be a Xenon or Core processor from Intel of America or an Opteron processor from AMD of America, or may be other processor types that would be recognized by one of ordinary skill in the art. Alternatively, the CPU 600 may be implemented on an FPGA, ASIC, PLD or using discrete logic circuits, as one of ordinary skill in the art would recognize. Further, CPU 600 may be implemented as multipleprocessors cooperatively working in parallel to perform the instructions of the processes described above.

[0091] The device 601 in FIG. 10 also includes a network controller 606, such as an Intel Ethernet PRO network interface card from Intel Corporation of America, for interfacing with network 650. and to communicate with the other devices. As can be appreciated, the network 650 can be a public network, such as the Internet, or a private network such as an LAN or WAN network, or any combination thereof and can also include PSTN or ISDN sub-networks. The network 650 can also be wired, such as an Ethernet network, or can be wireless such as a cellular network including EDGE, 3G, 4G and 5G wireless cellular systems. The wireless network can also be WiFi, Bluetooth, or any other wireless form of communication that is known.

[0092] The device 601 further includes a display controller 608, such as aNVIDIA GeForce GTX or Quadro graphics adaptor from NVIDIA Corporation of America for interfacing with display 610, such as an LCD monitor. A general purpose I / O interface 612 interfaces with a keyboard and / or mouse 614 as well as a touch screen panel 616 on or separate from display 610. General purpose I / O interface also connects to a variety of peripherals 618 including printers and scanners.

[0093] A sound controller 620 is also provided in the device 601 to interface with speakers / microphone 622 thereby providing sounds and / or music.

[0094] The general purpose storage controller 624 connects the storage medium disk 604 with communication bus 626, which may be an ISA, EISA, VESA, PCI, or similar, for interconnecting all of the components of the device 601 . A description of the general features and functionality of the display 610, keyboard and / or mouse 614, as well as the display controller 608, storage controller 624, network controller 606, sound controller 620, and general purpose I / O interface 612 is omitted herein for brevity as these features are known.

[0095] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments.

[0096] Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

[0097] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0098] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, orsequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

[0099] Obviously, numerous modifications and variations are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, embodiment of the present disclosure may be practiced otherwise than as specifically described herein.[000100] Embodiments of the present disclosure may also be as set forth in the following parentheticals.[000101] (1) A method of classifying severity of symptoms associated with neurological disorders, the method comprising: receiving sensor data from a device that includes one or more sensors; extracting, via processing circuitry, data features from the received sensor data; generating, via the processing circuitry, a context of a patient’s state based on the extracted data features; determining, via the processing circuitry, a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predicting, via the processing circuitry, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and outputting the determined symptom and the predicted severity of the determined symptom. [000102] (2) The method of (1), wherein the receiving step comprises receiving the sensor data from a wearable device.[000103] (3) The method of (1) to (2), wherein the received sensor data includes at least one of accelerometer data, gyroscope data, physiological data, location data, geographical data, and / or environmental data.[000104] (4) The method of (1) to (3), further comprising pre-processing the sensor data, including fdtering the sensor data and fusing the sensor data.[000105] (5) The method of (1) to (4), wherein the context of the patient’s state includes at least one of a movement, an activity, demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data.[000106] (6) The method of (1) to (5), further comprising transforming the context of the patient’s state.[000107] (7) The method of (1) to (6), further comprising determining an effect of medication on the predicted severity of the determined symptom.[000108] (8) The method of (1) to (7), wherein the context of the patient’s state includes a determination of a clinical activity associated with a neurological evaluation.[000109] (9) The method of (1) to (8), further comprising determining, when the determined symptom is a tremor, an amplitude of the tremor.[000110] (10) The method of (1) to (9), wherein the symptom severity classifier is a trained artificial intelligence model or a trained machine learning model.[000111] (11) The method of (1) to (10), wherein the symptom severity classifier includes a trained neural network.[000112] (12) The method of (1) to (11), further comprising training the symptom severity classifier using a deep-learning method and training data.[000113] (13) The method of (1) to (12), wherein the determining step further comprises determining the symptom, which is a symptom associated with Parkinson’s disease and is one of a tremor, bradykinesia, dyskinesia, rigidity, postural instability, slowness of movement, shuffling gait, change in gait, freezing of gait, motor fluctuation, micrographia, dystonia, hypophonia,masked facies, akinesia, fatigue, change in arm swing, difficulty initiating movement, and difficulty with fine motor tasks.[000114] (14) The method of (1) to (13), wherein the determined symptom is associated with an essential tremor.[000115] (15) The method of (1) to (14), further comprising receiving, via the processing circuitry, symptom data; and predicting the severity of the symptom based on the received symptom data.[000116] (16) The method of (1) to (15), further comprising generating, via the processing circuitry, a symptom report based on the predicted severity of the symptom.[000117] (17) A non-transitory computer-readable storage medium for storing computer readable instructions that, when executed by a computer, cause the computer to perform a method, the method comprising: receiving sensor data from a device that includes one or more sensors; extracting data features from the received sensor data; generating a context of a patient’s state based on the extracted data features; determining a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predicting, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and outputting the determined symptom and the predicted severity of the determined symptom.[000118] (18) The non-transitory computer-readable storage medium of (17), wherein the context of the patient’s state includes at least one of a movement, an activity, demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data.[000119] (19) A device, comprising processing circuitry configured to receive sensor data from a device that includes one or more sensors; extract data features from the received sensor data; generate a context of a patient’s state based on the extracted data features; determine a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predict, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and output the determined symptom and the predicted severity of the determined symptom.[000120] (20) The device of (19), wherein the context of the patient’s state includes at least one of a movement, an activity, demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data.[000121] Thus, the foregoing discussion discloses and describes merely exemplary embodiments of the present disclosure. As will be understood by those skilled in the art, the present disclosure may be embodied in other specific forms without departing from the spirit thereof. Accordingly, the disclosure of the present disclosure is intended to be illustrative, but not limiting of the scope of the disclosure, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive subject matter is dedicated to the public.

Claims

CLAIMS1. A method of classifying severity of symptoms associated with neurological disorders, the method comprising: receiving sensor data from a device that includes one or more sensors; extracting, via processing circuitry, data features from the received sensor data; generating, via the processing circuitry, a context of a patient’s state based on the extracted data features; determining, via the processing circuitry, a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predicting, via the processing circuitry, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and outputting the determined symptom and the predicted severity of the determined symptom.

2. The method of claim 1, wherein the receiving step comprises receiving the sensor data from a wearable device.

3. The method of claim 1, wherein the received sensor data includes at least one of accelerometer data, gyroscope data, physiological data, location data, geographical data, and / or environmental data.

4. The method of claim 1 , further comprising pre-processing the sensor data, including fdtering the sensor data and fusing the sensor data.

5. The method of claim 1, wherein the context of the patient’s state includes at least one of a movement, an activity, demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data.

6. The method of claim 1, further comprising transforming the context of the patient’s state.

7. The method of claim 5, further comprising determining an effect of medication on the predicted severity of the determined symptom.

8. The method of claim 1, wherein the context of the patient’s state includes a determination of a clinical activity associated with a neurological evaluation.

9. The method of claim 1, further comprising determining, when the determined symptom is a tremor, an amplitude of the tremor.

10. The method of claim 1 , wherein the symptom severity classifier is a trained artificial intelligence model or a trained machine learning model.1 1 . The method of claim 1 , wherein the symptom severity classifier includes a trained neural network.

12. The method of claim 1, further comprising training the symptom severity classifier using a deep-learning method and training data.

13. The method of claim 1, wherein the determining step further comprises determining the symptom, which is a symptom associated with Parkinson’s disease and is one of a tremor, bradykinesia, dyskinesia, rigidity, postural instability, slowness of movement, shuffling gait, change in gait, freezing of gait, motor fluctuation, micrographia, dystonia, hypophonia, masked facies, akinesia, fatigue, change in arm swing, difficulty initiating movement, and difficulty with fine motor tasks.

14. The method of claim 1, wherein the determined symptom is associated with an essential tremor.

15. The method of claim 1, further comprising: receiving, via the processing circuitry, symptom data; and predicting the severity of the symptom based on the received symptom data.

16. The method of claim 1, further comprising generating, via the processing circuitry, a symptom report based on the predicted severity of the symptom.

17. A non -transitory computer-readable storage medium for storing computer readable instructions that, when executed by a computer, cause the computer to perform a method, the method comprising: receiving sensor data from a device that includes one or more sensors; extracting data features from the received sensor data; generating a context of a patient’s state based on the extracted data features; determining a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predicting, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and outputting the determined symptom and the predicted severity of the determined symptom.

18. The non-transitoiy computer-readable storage medium of claim 17, wherein the context of the patient’s state includes at least one of a movement, an activity, demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data.

19. A device, comprising: processing circuitry configured to receive sensor data from a device that includes one or more sensors; extract data features from the received sensor data; generate a context of a patient’s state based on the extracted data features;determine a symptom associated with a neurological disorder, based on the extracted data features and the context of the patient’s state; predict, using a symptom severity classifier, a severity of the determined symptom, based on the extracted data features and the context of the patient’s state; and output the determined symptom and the predicted severity of the determined symptom.

20. The device of claim 19, wherein the context of the patient’s state includes at least one of a movement, an activity, demographic data, physiological data, environmental data, medical data, position data, location data, and / or geographic data.

Images