Automatic classification of the severity of symptoms associated with neurodegenerative diseases

Abstract

A method for classifying the severity of symptoms associated with a neurological disorder, comprising: receiving sensor data from a device including one or more sensors; extracting data features from the received sensor data; generating a patient condition status based on the extracted data features; determining symptoms associated with a neurological disorder based on the extracted data features and the patient condition status; predicting the severity of the determined symptoms using a symptom severity classifier based on the extracted data features and the patient condition status; and outputting the determined symptoms and the predicted severity of the determined symptoms.

Description

Cross - reference to related applications

[0001] This application claims priority to U.S. Provisional Application No. 63 / 491,640, filed on March 22, 2023, which is hereby incorporated by reference in its entirety and made available for all purposes.

Technical Field

[0002] This disclosure relates to the automatic identification and classification of changes in motor function.

Background Art

[0003] Parkinson's disease is one of the most common neurodegenerative diseases affecting adults, characterized by a gradual, chronic, and incurable decline in motor function. The decline in motor function is associated with a decrease in dopamine concentration and can manifest as typical motor - related symptoms and non - motor - related symptoms. The severity and manifestation of each symptom can vary over time. Therefore, it is important to monitor the symptoms of a patient in order to evaluate the progression of Parkinson's disease in that patient. The progression of Parkinson's disease can be used to determine the treatment of the patient, including the escalating administration of therapeutic drugs.

[0004] The foregoing description of the "Background Art" is intended to present a general overview of the background of the present disclosure. The research of the inventors within the scope described in this Background Art section, as well as aspects of the description that may not be eligible as prior art at the time of filing, do not explicitly or implicitly admit to being prior art to the present disclosure.

Summary of the Invention

[0005] The foregoing paragraphs are provided as a general introduction and are not intended to limit the claims set forth below. The described embodiments will be best understood by reference to the following detailed description in conjunction with the accompanying drawings, along with further advantages.

[0006] In one embodiment, the present disclosure relates to a method for classifying the severity of symptoms associated with a neurological disorder, the method comprising: receiving sensor data from a device including one or more sensors; extracting data features from the received sensor data via a processing circuit; generating a patient condition status via the processing circuit based on the extracted data features; determining symptoms associated with a neurological disorder via the processing circuit based on the extracted data features and the patient condition status; predicting the severity of the determined symptoms using a symptom severity classifier via the processing circuit based on the extracted data features and the patient condition status; and outputting the determined symptoms and the predicted severity of the determined symptoms.

[0007] In one embodiment, the Disclosure relates to a non-temporary 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 comprising one or more sensors; extracting data features from the received sensor data; generating a situation relating to a patient's condition based on the extracted data features; determining symptoms associated with a neurological disorder based on the extracted data features and the situation relating to the patient's condition; predicting the severity of the determined symptoms using a symptom severity classifier based on the extracted data features and the situation relating to the patient's condition; and outputting the determined symptoms and the predicted severity of the determined symptoms.

[0008] In one embodiment, the disclosure relates to a device comprising a processing circuit configured to receive sensor data from a device including one or more sensors, extract data features from the received sensor data, generate a patient condition status based on the extracted data features, determine symptoms associated with a neurological disorder based on the extracted data features and the patient condition status, predict the severity of the determined symptoms using a symptom severity classifier based on the extracted data features and the patient condition status, and output the determined symptoms and the predicted severity of the determined symptoms. [Brief explanation of the drawing]

[0009] A more complete understanding of this disclosure, and the many benefits associated therewith, will be readily attainable as the disclosure becomes more readily apparent, by referring to the following detailed description, when considered in conjunction with the accompanying drawings. [Figure 1] This is a schematic diagram for evaluating the severity of symptoms according to one embodiment of the present disclosure. [Figure 2] This is a schematic diagram of a generation pipeline according to one embodiment of the present disclosure. [Figure 3] This is a workflow for a subclassifier according to one embodiment of the present disclosure. [Figure 4] This is a workflow for a subclassifier according to one embodiment of the present disclosure. [Figure 5] This is a workflow for a subclassifier according to one embodiment of the present disclosure. [Figure 6] This is a workflow for a hypodynamic severity classifier according to one embodiment of the present disclosure. [Figure 7] This is a workflow for a dyskinesia severity classifier according to one embodiment of the present disclosure. [Figure 8] This is a workflow for a tremor severity classifier according to one embodiment of the present disclosure. [Figure 9] This is a schematic diagram of a user device for carrying out a method according to one embodiment of the present disclosure. [Figure 10]This is a schematic diagram of a hardware system for carrying out a method according to one embodiment of the present disclosure. [Modes for carrying out the invention]

[0010] As used herein, the terms “a” or “an” are defined as one or more. As used herein, the term “plural” is defined as two or more. As used herein, the term “another” is defined as at least a second or more. As used herein, the terms “including” and / or “having” are defined as “comprising” (i.e., open language). Throughout this document, any reference to “a particular embodiment,” “a specific embodiment,” “embodiment,” “example,” or similar terms means that at least one embodiment of this disclosure includes a particular feature, structure, or characteristic described in relation to that embodiment. Thus, every occurrence of such phrase or in different places within this specification does not necessarily refer to the same embodiment. Furthermore, any particular feature, structure, or characteristic may be combined in any suitable way in one or more embodiments, without limitation.

[0011] The identification and assessment of Parkinson's disease symptoms typically involve direct observation of the patient in a clinical setting and a thorough physical examination. For example, the Unified Parkinson's Disease Rating Scale (UPDRS), a quantitative method for assessing a patient's quality of life and grading symptoms as mild, moderate, or severe, is typically administered only by healthcare professionals during face-to-face consultations. Physical examinations can be time-consuming and require the expertise of a healthcare professional to assess the severity of symptoms. Parkinson's disease symptoms may include, but are not limited to, tremor, bradykinesia, dyskinesia, muscle rigidity, postural instability, gait changes, micrographia, dystonia, lisp, and mask-like facies. Motor tests, such as those found in Part III of the UPDRS (UPDRS-III), may include a number of physical activities and tasks performed by the patient under the observation of a healthcare professional. The healthcare professional assigns a categorical rating to one or more symptoms based on the patient's ability to perform the physical activities. Some symptoms are directly assessed through motor tests, while others are assessed based on combinations of observed behaviors.

[0012] Accurate tracking of Parkinson's disease progression and adjustment of treatment as needed requires continuous monitoring of symptoms. However, frequent clinical visits are costly and impractical, and can negatively impact patients' lives. Outside the clinical setting, symptoms are typically monitored through patient self-reporting (e.g., questionnaires, exercise diaries), which is subjective and can lead to inaccurate reporting due to fatigue, poor adherence, recall bias, limited temporal resolution, and a lack of understanding or assessment of the magnitude of symptom severity. The inability to accurately and frequently track Parkinson's disease symptoms leads to a significant healthcare burden, including delayed diagnosis, ineffective treatment, and a reduced quality of life for patients. Therefore, there is a clear need to provide patients with means of continuously and accurately assessing their Parkinson's disease symptoms outside the clinical setting in order to improve the diagnosis and treatment of Parkinson's disease and reduce the burden on both patients and healthcare providers.

[0013] In embodiments, this disclosure relates to systems and methods for the automated collection and analysis of patient data, including motion data, activity data, physiological data, location data, environmental data, and / or demographic data, for the identification and classification of symptoms of neurological disorders such as Parkinson's disease. Symptom classification may include determining the severity of symptoms according to known rating scales. The systems and methods relating to this specification may enable repeated assessment of symptoms over time without requiring expert opinion or active self-reporting from the patient. Patient data can be continuously assessed using the same systems and methods to reduce variability or subjectivity in classification. In particular, 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. Patient data may include sensor data that can be collected via wearable sensors and can therefore be measured in an objective, reproducible, and reliable manner. Examples of patient data are presented in more detail herein.

[0014] In one embodiment, this disclosure is directed to one or more statistical models for analyzing patient data to classify symptoms of Parkinson's disease (PD). The statistical model may include a machine learning (ML) model that can be trained on patient data to identify and classify the severity of PD symptoms. For example, the statistical model may include one or more neural networks used in artificial intelligence (AI) models. The statistical model may be trained for deep learning or representation learning using one or more network layers. In some embodiments, the statistical model may include a rule-based classifier. The statistical model may include one or more classifiers that can map input data (e.g., patient data) to categories as outputs. In one embodiment, the categories may be types of behavior or activity. In one embodiment, the categories may be PD symptoms and the severity of PD symptoms. Categorical severity can provide a multi-class classification or stratification of symptoms rather than a simple binary representation of whether symptoms are present or not.

[0015] In one embodiment, the disclosure may include multiple classifiers. For example, a symptom severity classifier may predict the severity of PD symptoms. Input to the symptom severity classifier may include patient data, as well as additional indicators, classifications, descriptions, and / or statistical measures derived from the patient data. The additional data may improve the accuracy of the symptom severity classifier in assessing PD symptoms compared to an assessment based solely on the initial patient data. The additional data may describe or quantify circumstances relating to the patient's condition. Circumstances relating to the patient's condition may be useful in identifying changes or abnormalities in the patient's motor function based on the patient data. Circumstances relating to the patient's condition may include, but are not limited to, motion, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data related to the patient. For example, circumstances relating to the patient's condition may include classifications of the types of motions and / or activities the patient is performing when the patient data is collected. In one embodiment, motion types may include descriptions or classifications of the patient's motions based on the patient data. Further examples of situational data are provided herein. In some embodiments, the patient's status can be generated based on patient data by one or more separate classifiers, e.g., subclassifiers. Subclassifiers may be statistical models (e.g., machine learning classifiers) and can provide additional methods for analyzing patient data without interfering with or confusing the models used for symptom severity classification. Subclassifiers can also be trained and tuned independently of the symptom severity classifier. In some embodiments, behavior type and activity type classifications can be output to the user or healthcare professional, allowing them to review the situation independently of the symptom severity classification.

[0016] In some embodiments, the systems and methods of this disclosure may further include reporting symptoms, risk-based assessment and monitoring, and predicting the next steps or treatments based on patient data and classification of PD symptom severity. In one embodiment, risk-based assessment may include identifying patient-specific risks at present or future points in time and at present or future locations.

[0017] In one embodiment, the method disclosed herein can be performed by one or more electronic devices including a processing circuit. These one or more electronic devices may include, but are not limited to, wearable devices (e.g., smartwatches, smart rings), mobile devices (e.g., smartphones, tablets), computers (e.g., laptops, personal computers), or servers. In one embodiment, a remote electronic device, such as a server, can receive input data, such as patient data, from an electronic device (e.g., a patient's device), process and / or analyze the received input data to assess symptom severity, and transmit output data to the patient's device. The output data may, for example, be an assessment of symptom severity based on patient data. In some embodiments, the method disclosed herein can be distributed across one or more electronic devices.

[0018] Figure 1 is a schematic diagram of a system for evaluating the severity of PD symptoms according to one embodiment of the present disclosure. Patient data can be collected from one or more patient devices. The patient devices may include, for example, a wearable device 100 and a mobile device 200 that include sensors configured to collect sensor data. In addition to being configured to collect patient data, the mobile device 200 may also be configured to present output data to the 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. The remote devices 300 may be, for example, cloud-based computing devices such as servers. The wearable device 100 and the mobile device 200 can access one or more remote devices 300 via a wireless network connection. The remote devices 300 may process sensor data from the wearable device 100 to evaluate the severity of PD symptoms according to the methods presented herein. For example, the remote device 300 may classify behavioral types and activity types based on patient data and input the patient data, behavioral types, and activity types into a symptom severity classifier to evaluate the severity of PD symptoms. In some embodiments, the wearable device 100 and / or the remote device 300 can preprocess sensor data as described herein. The remote device 300 can transmit a PD symptom report based on an 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 the PD symptom report to one or more reporting 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 healthcare professional. The PD symptom report may be referred to herein as a symptom summary report. The reporting devices 400 can also transmit data to the remote device 300, such as input from the patient based on the PD symptom report.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 device 400 can be compressed via a reversible compression method or an irreversible compression method in order to shorten the transmission time. In some embodiments, the data can be continuously streamed between the devices.

[0019] Figure 2 is a schematic diagram of a generation pipeline according to one embodiment of the present disclosure. A wearable device 100, such as a wristwatch, can be configured to run a wearable application, which enables the 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 the data storage application. For example, while a patient is wearing the wearable device 100, the wearable device 100 can collect sensor data, including accelerometer and gyroscope data. In addition to sensor data, the wearable device 100 can also transmit a patient identifier and a device identifier to the cloud storage unit 110. The sensor data can be used to predict the severity of PD symptoms in a patient wearing the wearable device 100. The device identifier may include the hardware or software version of the wearable device 100. The patient identifier and device identifier may include unique identifiers for storing and updating patient records in the cloud storage unit 110 and / or patient database 120. The patient database 120 can store patient records, which 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 submit new patient information to the patient database 120, which can store the new patient information and the unique patient ID corresponding to the new patient. Patient records can be updated with new information about the patient, including updated medical records and PD symptoms, determined by the methods disclosed herein. In one embodiment, the cloud storage unit 110 can transmit 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 wearable device data, including motion sensor data, from the cloud storage unit 110. The machine learning server 300 can also receive patient information, including a unique patient ID, from the patient database 120. The unique patient ID can be set within the wearable application, the cloud storage unit 110, and / or the machine learning server 300. In one embodiment, data from the watch device 100 can be associated with a unique patient ID from the patient database 120. For example, sensor data from the watch device 100 may include a unique patient ID. Data transmitted from the cloud storage unit 110 to the machine learning server 300 can be protected via Hypertext Transfer Protocol Secure (HTTPS). Data can be transmitted from the watch device 100 to the cloud storage unit 110 via a wireless connection such as Wi-Fi or Bluetooth®. Similarly, data can be transmitted from the patient database 120 to the machine learning server 300 via a wireless connection such as Wi-Fi or Bluetooth®.

[0020] Based on the wearable device data received from the cloud storage unit 110, the machine learning server 300 can classify the severity of PD symptoms using one or more classifiers. The machine learning server 300 can then output a user symptom summary report. In one embodiment, the machine learning server 300 can output the symptom summary report at fixed intervals. This summary report can include the severity of PD symptoms and additional patient information associated with the patient. The patient can be identified by a unique patient ID sent to the machine learning server 300 by the patient database 120. In some embodiments, the machine learning server 300 can send the summary report to the user device. In some embodiments, the summary report can be stored within the patient database 120. The history of the summary report can be stored for each patient within the patient database 120. The history of the summary report and the symptom severity can be used to evaluate the progression of PD in the PD in the patient and to generate a new summary report for the patient.

[0021] Patient data may include, or be based on, sensor data collected by wearable sensors. Wearable sensors may be attached to, fitted to, or otherwise in contact with the patient, or may be present on something the patient is wearing, such as being held in the patient's hand or placed in the patient's pocket or bag. In one embodiment, wearable sensors may be embedded in one or more wearable devices, such as wearable device 100 in Figure 1, and / or distributed across different devices and body positions. Wearable sensors may include, but are not limited to, optical sensors (e.g., infrared sensors), electrical sensors, motion sensors, position / orthography sensors, and chemical sensors. Optical and electrical sensors can be used to measure physiological measurements such as heart rate, heart rhythm, electrocardiogram (ECG), blood oxygen saturation, and cardiovascular activity. Motion sensors may include accelerometers (e.g., 3-axis accelerometers), gyroscopes, magnetometers, and alternatives, or combinations thereof, to measure linear and angular orientation and motion.

[0022] In one embodiment, sensor data can be passively collected by a wearable sensor. For example, the wearable sensor can be embedded in a wearable device such as a smartwatch, smart ring, or chest strap. The wearable sensor can automatically collect sensor data from the patient's body while the patient is wearing the wearable device, without issuing warnings to the patient or prompting the patient to input data to proceed with collection. In one embodiment, the wearable sensor can collect sensor data at a certain frequency. Passive collection of sensor data offers advantages over manual self-reporting in that it reduces the need for direct interaction between the patient and the device while the device is acquiring sensor data.

[0023] Sensor data can be processed in a preprocessing step to create a set of patient data in a standardized format that can be used as input to a classifier or a similar statistical model. In one embodiment, preprocessing may include transforming the sensor data. For example, preprocessing may 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 separate 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, processing may include fusing the sensor data. For example, the sensor data may include motion sensor data collected by motion sensors, each motion sensor 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 a multidimensional (e.g., 3D) space. The fusion of sensor data may be a combination of inertial measurement unit (IMU) data collected across different axes. In one embodiment, the fusion of sensor data may include identifying and combining or associating certain wavelet types within the sensor data. In one embodiment, sensor data fusion may include fusing different types of sensor data from different sensors. For example, fusion of sensor data including acceleration data, gyroscope data, and position data can be used to determine whether a patient is moving and at what speed. In another example, fusion of motion sensor data and heart rate data can be used to determine whether a patient is awake or asleep, or the stage of sleep the patient is in. Patient data may include fused sensor data in addition to pre-processed sensor data from each wearable sensor.For example, patient data may include fused sensor data in addition to individual sensor data such as accelerometer data and gyroscope data. Sensor data can be preprocessed by a wearable device 100 or a remote device 300. In one embodiment, patient data may further include demographic and medical information, which may include, but are not limited to, age, sex, date of PD diagnosis, use of physical aids, height and weight, anthropometric data, past symptom assessments or symptom onset, medication history, and other medical history. Demographic and medical information can be entered into the patient's device, such as a mobile device 200, or obtained from a data storage device, such as the patient database 120 in Figure 2. Demographic and medical information can be used in classifying the severity of PD symptoms. For example, since some decline in motor function with age is normal even in people without PD, the severity of a patient's symptoms may depend on the patient's age.

[0024] In one embodiment, the remote device 300 can extract data features from patient data. These data features may include statistical indicators and patterns of the patient data. In some embodiments, the data features may describe the probability distribution of the patient data. For example, the data features may include counts, sums, mean, median, mode, minimum, maximum, standard deviation, variance, skewness, kurtosis, percentiles and percentile ranks, quartiles, ratios, amplitude, or duration of the patient data. In some embodiments, the data features may or may not map to known descriptors or labels; they may or may not map to known descriptors or labels. For example, the data features may be a specific waveform within the patient data, or they may be related to the recurrence of waveforms. In one embodiment, the data features may be extracted for each type of patient data. For example, the remote device 300 may extract mean acceleration from a set of acceleration data, or mean heart rate from a set of heart rate data. The data features can be used as input to a statistical model used for classifying the severity of PD symptoms. The use of data features can reduce the amount of patient data stored and input into statistical models, thereby lowering the computational requirements of the statistical models while preserving the characteristic attributes of the patient data.

[0025] The extracted data features can have various usefulness and relevance in classifying the severity of PD symptoms. In some embodiments, the remote device 300 can identify and select data features relevant to the classification of symptom severity. The most relevant data features can be determined during the training of the symptom severity classifier. As an exemplary model, the symptom severity classifier can be trained using a machine learning method with labeled symptom data. The labeled symptom data may include collected patient data corresponding to a number of PD symptoms, where the severity of each PD symptom is identified and labeled. The severity score for each symptom may be based on an index or scale specific to that symptom. The symptom severity classifier can be trained to predict symptom severity based on 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.

[0026] In one embodiment, the remote device 300 can process and analyze patient data, including extracted data features, to generate a context relating to the patient's condition. As an exemplary and non-limiting example, the remote device 300 can generate data related to the patient's movements. This 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 movement data is collected can refer to the type of movement quantified by the sensor data, the cause, purpose, or result of the movement. For example, motion sensor data from a motion sensor located at the patient's wrist may indicate the displacement and rotation of the patient's hand. Displacement and rotation of the patient's hand, indicated solely by motion sensor data and without further analysis, does not provide information about what the patient is doing at the time the motion sensor data is collected. By analyzing and classifying the sensor data collected while the patient's hand was moving, the context of the type of movement or motion of the patient's hand can be identified. In one embodiment, the remote device 300 can classify the patient's movements using one or more subclassifiers based on the patient data, including extracted data features. The classification may include, for example, types of movements such as gestures or hand movements. In one embodiment, the type of motion may be a motion associated with a region or part of the body. In one embodiment, the classification of motion types may include the degree or other characteristics of the motion, such as speed, duration, amplitude, displacement, or force. The degree of motion may be qualitative or quantitative. In one embodiment, the situation relating to the patient's condition may include a combination of motions, for example, a number of motions performed in sequence.

[0027] In one embodiment, the remote device 300 can use subclassifiers to assign one or more motion type classifications to a set of patient data. For example, a first subclassifier can classify a set of patient data as one or more gestures. A second subclassifier can classify a set of patient data according to the type of motion of a body region, such as a hand movement. Subclassifiers 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 as a situation relating to the patient's condition based on one or more motion type classifications of the patient data. An activity can consist of a number of actions or combinations of motion types. In one embodiment, an activity may be a known activity used in motor tests or similar neurological assessments, such as a speech task, a facial expression task, a muscle rigidity test, fingertip tapping, hand movements, toe tapping, agility tests, sitting and standing, balance tests, posture tests, touching a part of the body, or walking a certain distance. In some embodiments, the type of activity may include interactions with an object, such as picking up an object or opening or closing an object. In one embodiment, predicting an activity may be based on mapping one or more action type classifications to an activity in combination with each other. In one embodiment, the remote device 300 may predict an activity using an activity type subclassifier, the input to which this activity type subclassifier is one or more action type classifications, and the output from the activity type subclassifier is the predicted activity. The activity type subclassifier may be, for example, a rule-based classifier.

[0028] In one embodiment, the remote device 300 can segment patient data over time in order to process the patient data. The remote device 300 can analyze the patient data to determine situational data corresponding to time windows. For example, a patient may perform numerous actions over time, and the timing of these actions may indicate the patient's mobility. In one embodiment, the remote device 300 can use a movement window or rolling window to process the patient data, which is a continuous time range with a lower limit (start point / start time) and an upper limit (end point / end time). The rolling window may encompass a subset of patient data acquired over a continuous time range (e.g., several seconds). The remote device 300 can analyze a first subset of patient data in the rolling window at a first location to classify action types and / or predict activity based on the subset of patient data. The rolling window can then shift to a second location in the patient data and encompass a second subset of patient data at the second location. The nature of the rolling window can result in 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 and width of the rolling window. For example, if the rolling window shifts by 1 second at a time, the overlap between the first subset and the second subset will be t w It becomes equal to -1, and in the formula, t w is the width of the rolling window. If the rolling window shifts by 2 seconds at a time, the overlapping portion between the first subset and the second subset is t w It is equal to -2.

[0029] In an exemplary embodiment, at a first position, the rolling window may encompass a first subset of patient data collected between t=1 and t=5 seconds. The remote device 300 can use a subclassifier to classify one or more behavioral types based on the first subset of patient data. At a second position, the rolling window may shift by one second, encompassing a second subset of patient data collected between t=2 and t=6 seconds. The remote device 300 can use a subclassifier to classify one or more behavioral types based on the second subset of patient data. In addition to the continuous classification of patient data, the use of a rolling time window can provide a more accurate determination of how behavioral types relate to each other and when the patient started and finished the behavior. In one embodiment, the length of the rolling window and the time shift of the rolling window may be set based on the amount of patient data required for the subclassifier to accurately classify the behavioral types. In some embodiments, the length of the rolling window and the time shift may vary based on the PD symptoms being classified.

[0030] Alternatively or additionally, the remote device 300 can process patient data over a fixed, specific time frame. For example, the remote device 300 can extract data features based on patient data collected over a fixed time frame and classify symptom severity. The remote device 300 can identify and classify one or more behavioral types within a fixed period. In some embodiments, the remote device 300 can apply a rolling window to classify behavioral types within a fixed period. The use of a fixed time frame can standardize and / or limit the amount of patient data used to classify symptom severity. In some embodiments, the length of the fixed time frame can be determined based on the time or the optimal amount of patient data required to classify PD symptom severity. For example, a very long fixed period (e.g., several hours) results in excessive patient data that consequently increases the computational load but does not improve the accuracy of symptom severity classification. A fixed period that is too short (e.g., several seconds) may not contain enough patient data to accurately classify symptom severity. In one embodiment, the length of a fixed period can be determined during training of the statistical model of this disclosure.

[0031] Figure 3 is a schematic diagram of a subclassification workflow 1000 according to one embodiment of the present disclosure. The workflow 1000 may include one or more processing functions and can be used to classify behavior types as situations relating to a patient's condition based on a set of patient data. Processing in the workflow 1000 can be performed by a remote device 300 using sensor data received from a wearable device 100. First, the remote device 300 may preprocess the sensor data to remove noise and standardize the sensor data to create patient data, as shown in the function block 1100. In one embodiment, the preprocessing may include extracting relevant data features from the patient data, as shown in the function block 1200. The patient data features can be used in addition to, or instead of, the preprocessed patient data. The remote device 300 may use a rolling window to divide the patient data into subsets of patient data. The remote device 300 can then classify the subsets of patient data using one or more behavior type subclassifiers 1300. The behavior type subclassifiers may be non-exclusive. The remote device 300 can output a predicted movement type, such as a predicted hand movement type, as an example of a situation related to the patient's condition when sensor data is collected.

[0032] In some embodiments, the remote device 300 can calculate and extract feature summaries over a fixed time frame. This fixed time frame can be longer than the duration of the rolling window. As a non-limiting example, the fixed time frame can be several minutes, while the rolling window can be less than one minute or about one minute in duration. The feature summary can include data features extracted from patient data over the fixed time frame. In some embodiments, the feature summary can include data features determined to be relevant to classification in a pre-training step of the symptom severity classifier.

[0033] The remote device 300 can predict activity types using an activity type classifier by using a combination of action type classification and data features, as shown in the schematic diagram of the subclassifier workflow 1500 in Figure 4. This activity type is also referred to herein as an exemplary example of a situation relating to the patient's condition. The activity type classifier can predict activities performed over a time frame longer than a single rolling window. For example, the activity type identified by the activity type classifier may consist of a combination of action types. The activity type can be predicted based on the type(s), duration, and sequence of actions classified in Figure 3. As shown in Figure 4, the remote device 300 can extract data features within a rolling window by performing the same preprocessing steps. The remote device 300 can then classify the activity type using the activity type classifier 1400, using the data features and predicted action types referenced in Figure 3. The remote device 300 can output the predicted activity type.

[0034] In one embodiment, the remote device 300 can predict one or more activity types performed over one or more fixed time frames. In one embodiment, the predicted activity types may be performed multiple times within a fixed time frame. In one embodiment, the remote device 300 can predict multiple activity types within a fixed time frame based on patient data. In some embodiments, a subclassification workflow 1000 can be used to predict activity types based on patient data collected over one or more movements. For example, a patient may perform a number of activities commonly used in assessing motor function. Patient data may include data collected during those numerous activities. Activity types identified and classified based on patient data can be used to appropriately identify the progression of PD. In some embodiments, the remote device 300 can classify patient data over fixed periods of different durations. In some embodiments, the length of a fixed period may correspond to the typical length of one or more activities. The predicted activity types can provide context regarding the type of movement or other factors that will result in the patient exhibiting PD symptoms. Predictions of one or more activity types based on patient data can be used to classify the severity of PD symptoms. For example, activity type can be used to identify deviations in a patient's movement from typical movements when performing that activity, and these deviations can be associated with symptoms of Parkinson's disease and / or decreased motor function.

[0035] In addition to predicted activity types, patient data in workflow 1000 and any additional classifications derived therefrom can also be used to assess the severity of a patient's PD symptoms. In one embodiment, the symptom severity classifier may be a classifier trained to classify symptom severity at least partially based on data features selected via a feature selection technique, as described herein. The symptom severity classifier may be trained on a large dataset of labeled training data, which includes PD symptoms assessed for severity levels. For example, severity levels may be assigned by a clinician based on the patient's assessment. The training data may further include sensor data collected from each patient. For example, sensor data may be collected during a motor examination in which the patient performs a number of activities. The patient's PD symptoms may be exhibited / manifested during the motor examination. The training data may include activities performed by the patient. The training data may include associations (e.g., temporal alignment) between data features extracted from the set of sensor data and the activities being performed when the sensor data was collected. In one embodiment, the training data may include activity type classifications. In one embodiment, the training data may include demographic and medical information associated with the symptoms. In this way, the symptom severity classifier can be trained to predict severity based on the patient's general health status, in addition to sensor data collected during the patient's activities.

[0036] In one embodiment, the symptom severity classifier can classify patient data based on extracted data features, behavioral classifications, and predicted activity types. In one embodiment, the remote device 300 can input a summary of data features, a summary of behavioral 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 particular PD symptom. In one embodiment, the remote device 300 can input the same input data to multiple symptom severity classifiers, each classifier being able to identify different symptoms and symptom severity levels. In one embodiment, the input data can be summary data for a fixed time frame. 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.

[0037] Figure 5 is a schematic diagram of a clinical assessment classification workflow 2000 according to one embodiment of the present disclosure. The workflow 2000 can be performed by a remote device 300. The remote device 300 can receive sensor data and additional patient data from other devices such as the wearable device 100 and mobile device 200 in Figure 1. The remote device 300 can first extract data features from the patient data and, using one or more subclassifiers, can determine the status of the patient's condition based on the patient data, as has been described herein with reference to workflow 1000 in Figure 3 and workflow 1500 in Figure 4. The remote device 300 can generate summaries of data features and status data for the motion and patient data collection sessions, as shown in the summary function block 2100. The remote device 300 can then input the summaries of data features and status data, such as motion classification and predicted activity type, into the clinical assessment classifier 2200. Based on the data features and status data, the clinical assessment classifier 2200 can determine whether the patient data was collected during the patient's clinical assessment. In one embodiment, the classification of clinical assessments can also be used as a status relating to the patient's condition. In one embodiment, the input data can correspond to a large number of activity sessions. Each activity session can include one or more activity types identified by a subclassifier. In some embodiments, each activity session can include different sets of activities. There may be partial overlap, complete overlap, or non-overlap in the activities of each activity session. In one embodiment, the symptom severity classifier can predict symptom severity based on each activity session. Multiple activity sessions can provide a larger sample of patient data across a broader range of activities for a more accurate prediction of symptom severity.

[0038] The symptom severity classifier can predict a PD symptom severity score based on input data, including extracted data features and patient status, including classifications described with reference to Figures 3-5. In some embodiments, the severity score may be a score associated with an assessment scale, such as UPDRS. In one embodiment, the severity score may be a categorical score associated with a severity descriptor, such as mild, moderate, or severe. The severity score may be a score of the same type as the scores present in the training data for the symptom severity classifier. In some embodiments, the symptom severity classifier can predict a first severity score based on predicted activity from a first period of patient data collection, and a second severity score based on predicted activity from a second period of patient data collection. In embodiments where the symptom severity classifier can predict multiple severity scores from a set of patient data, the remote device 300 may take the average of the predicted scores. In one embodiment, this average may be based on a rolling average or a moving average. Alternatively or additionally, the average may be a weighted average of the predicted scores. Next, the symptom severity classifier can output an average predicted severity score.

[0039] The remote device 300 can determine a number of symptom severity scores for different PD symptoms using one or more classifiers. The classifiers can be trained to predict the severity of one or more PD symptoms. In some embodiments, symptoms can be evaluated in combination with each other. Exemplary embodiments of the symptom severity classifier described herein are shown below. It should be understood that the PD symptoms highlighted herein are a non-limiting example of symptoms that can be identified and evaluated by the symptom severity classifier.

[0040] In one embodiment, a remote device 300 can evaluate patient data to assess the severity of bradykinesia in a patient. Bradykinesia (BK) is a characteristic motor symptom of Parkinson's disease (PD) and can refer to slowness in initiating and performing movements. In addition to delay or hesitation in movements, BK can also be observed as a decrease in the amplitude of movements, a decrease in overall movement, and a decrease in spontaneous gestures. BK is represented in an overall assessment, for example, according to the UPDRS or the Movement Disorders Society's revised version of the UPDRS (MDS-UPDRS). BK can be measured directly through the UPDRS-III examination, including while performing hand movement-related tasks. Figure 6 is a schematic diagram of a BK severity classification workflow according to one embodiment of the present disclosure. This classification workflow may include one or more subclassifiers. Classifications from one or more subclassifiers can be used as input to a BK severity classifier.

[0041] In one embodiment, a patient can perform a number of activities, such as those enumerated in UPDRS-III, while wearing a wearable device that includes a wearable sensor. An activity can be performed over one or more activity sessions, each of which may include a predetermined number of activities or a set of activity types. In some embodiments, the activity may be one not enumerated in UPDRS-III. For example, an activity may include everyday actions performed by the patient outside the framework of exercise assessment, such as walking, carrying objects, cooking, or grooming. The wearable device may be, for example, a wristband including one or more accelerometers, gyroscopes, position sensors, and a heart rate monitor. The wearable sensor can collect sensor data while the patient is performing an activity. The wearable sensor can then transmit the sensor data to a remote device, such as a server, via a communication network. The server can receive the sensor data, as well as additional patient data, such as the patient's medical history and demographic information. The medical history may include, for example, medications the patient is taking and the date the patient last took those medications. The additional patient data may be entered into and transmitted from another patient device, such as the patient's mobile device.

[0042] The server can create patient data by preprocessing sensor data to remove noise and other anomalies and standardize the format of the sensor data. Preprocessing may include fusing sensor data, such as accelerometer and gyroscope data. The server may divide the patient data into subsets of patient data captured within a rolling window of time. The duration of the rolling window may be, for example, less than one minute. The server may analyze the subset of patient data to extract data features from the patient data. The server may then use one or more subclassifiers to determine situational data, including motion type, activity type, and clinical evaluation classification, based on the extracted data features and / or the preprocessed patient data. The motion type may be, for example, the movement of a body part during a motion test. In some embodiments, the subclassifiers may map patient data, including the extracted data features, to motion types. In some embodiments, the subclassifiers may identify motion types based on rule-based classification, which may be determined during training of the subclassifiers. The server may predict activity types based on the motion type classification of the patient data. The activity type can be, for example, an activity associated with the UPDRS-III motor test. The activity type can consist of a number of actions identified based on patient data. The server can further predict whether patient data was collected during the clinical evaluation.

[0043] The server can use subclassifiers to classify patient data into numerous action types and predicted activity types over a fixed time frame, for example, longer than one minute. The server can then generate summaries of extracted data features over the fixed time frame, as well as summaries of situational data, which include summaries of action type classification over the fixed time frame, summaries of activity type classification over the fixed time frame, and summaries of clinical assessment predictions over the fixed time frame. In some embodiments, the summaries of extracted data features may include selected data features that have been shown to be relevant to BK severity classification during training of a BK severity classifier. The server can input the summary data into a BK severity classifier. The BK severity classifier can be a classifier trained to identify BK in a patient's action and assess the severity of BK according to an overall assessment. For example, a BK severity score may be a rating between 1 and 3 or between 1 and 4. The BK severity classifier can predict BK severity scores for one or more action sessions. In some embodiments, distinctions between activity sessions can be identified in summary data input to the BK severity classifier. In one embodiment, activity sessions can be of different lengths, e.g., 5 minutes and 15 minutes. The BK severity classifier can then take the average of the BK severity scores for each activity session. The BK severity classifier can output a single BK severity score as an assessment based on the activity sessions. The server can send the BK severity score and report to the patient's wearable device or mobile device.

[0044] In one embodiment, a remote device 300 can evaluate patient data to assess the severity of dyskinesia in a patient. Dyskinesia (DK) is a motor symptom that may occur as a side effect of medications used to treat Parkinson's disease (PD) and can be characterized by abnormal involuntary movements such as writhing, twisting, and convulsions. DK can be measured by the Abnormal Involuntary Movement Rating Scale (AIMS), the Clinical Dyskinesia Rating Scale (CDRS), and the Integrated Dyskinesia Rating Scale (UDysRS). Figure 7 is a schematic diagram of a DK severity classification workflow according to one embodiment of the present disclosure. This classification workflow may include one or more subclassifiers. Classifications from one or more subclassifiers can be used as input to a DK severity classifier.

[0045] In one embodiment, a patient can perform a number of activities, such as those listed in UPDRS-III, while wearing a wearable device that includes a wearable sensor. An activity can be performed over one or more activity sessions, each containing a predetermined number of activities or a set of activity types. In some embodiments, the activity may be one not listed in UPDRS-III. For example, activities may include everyday actions performed by the patient outside the framework of exercise assessment, such as walking, carrying objects, or cooking. Abnormal actions can occur and be identified in various everyday activities. The wearable device may be, for example, a wristband containing one or more accelerometers, gyroscopes, position sensors, and a heart rate monitor. The wearable sensor can collect sensor data while the patient is performing an activity. The wearable sensor can then transmit the sensor data to a remote device, such as a server, via a communication network. The server can receive the sensor data, as well as additional patient data, such as the patient's medical history and demographic information. The medical history may include, for example, medications the patient is taking and the date of the last dose. Additional patient data can be entered into and transmitted via another patient's device, such as the patient's mobile device.

[0046] The server can create patient data by preprocessing sensor data to remove noise and other anomalies and standardize the format of the sensor data. Preprocessing may include fusing sensor data, such as accelerometer and gyroscope data. The server may divide the patient data into subsets of patient data captured within a rolling window of time. The duration of the rolling window may be, for example, less than one minute. The server may analyze the subset of patient data to extract data features from the patient data. The server may then use one or more subclassifiers to determine situational data, including motion type, activity type, and clinical evaluation classification, based on the extracted data features and / or the preprocessed patient data. The motion type may be, for example, the movement of a body part during a motor examination. In some embodiments, the subclassifiers may map patient data containing the extracted data features to motion types. In some embodiments, the subclassifiers may identify motion types based on rule-based classification, which may be determined during training of the subclassifiers. The server may predict activity types based on the motion type classification of the patient data. The activity types may be, for example, activities associated with a motor examination. The server can also predict whether patient data was collected during the clinical evaluation.

[0047] The server can use subclassifiers to classify patient data into numerous action types and predicted activity types over a fixed time frame, for example, longer than one minute. The server can then generate summaries of extracted data features over the fixed time frame, as well as summaries of situational data, which include summaries of action type classification over the fixed time frame, summaries of activity type classification over the fixed time frame, and summaries of clinical assessment predictions over the fixed time frame. In some embodiments, the summaries of extracted data features may include selected data features that have been shown to be relevant to DK severity classification during training of the DK severity classifier. The server can input the summary data into the DK severity classifier. The DK severity classifier may be a classifier trained to identify DK in a patient's action and to assess the severity of DK according to one or more of the above-described scales. For example, a DK severity score may be a rating of 1 or 2. The DK severity classifier can predict DK severity scores for one or more action sessions. In some embodiments, distinctions between action sessions can be identified in the summary data input to the DK severity classifier. The DK severity classifier can take the average of the DK severity scores for each activity session. The DK severity classifier can output a single DK severity score as an assessment based on activity sessions. The server can send the DK severity score and report to the patient's wearable device or mobile device.

[0048] In one embodiment, a remote device 300 can evaluate patient data to assess the amplitude and severity of tremors. Tremors are a prominent symptom of PD and can be defined as involuntary, rhythmic vibrations between muscle contractions and relaxations. There are many types of tremors, including resting tremors, motion tremors, and postural tremors, which are the dominant types. A tremor can occur when the patient is at rest (e.g., sitting) and may be an involuntary movement of the body or part of the body of a given amplitude or greater. Tremors can also occur when the patient is in motion or when some body parts are moving and others are at rest. In one embodiment, the patient can perform a number of activities, such as those enumerated in UPDRS-III, while wearing a wearable device including a wearable sensor. Activities can be performed over one or more motion sessions, which may include a predetermined number of activities or a set of activity types. Tremors frequently occur and are assessed in the hands and arms and may be observed during the motion tests of UPDRS-III. In some embodiments, activities may be those not enumerated within UPDRS-III. For example, activities may include everyday actions performed by the patient outside the framework of exercise assessment, such as walking, carrying objects, or cooking. In some embodiments, the patient may be stationary. The wearable device may be, for example, a wristband including one or more accelerometers, gyroscopes, position sensors, and a heart rate monitor. The wearable sensor can collect sensor data while the patient is performing an activity or while stationary. The wearable sensor can then transmit the sensor data to a remote device, such as a server, via a communication network. The server can receive the sensor data, as well as additional patient data, such as the patient's medical history and demographic information. The medical history may include, for example, medications the patient is taking and the date the patient last took those medications. The additional patient data may be entered into and transmitted from another patient device, such as the patient's mobile device.

[0049] Figure 8 is a schematic diagram of a tremor severity classification workflow according to one embodiment of the present disclosure. The server can create patient data by preprocessing sensor data to remove noise and other anomalies in the sensor data and standardizing the format of the sensor data. Preprocessing may include fusing sensor data, such as accelerometer data and gyroscope data. The server may divide the patient data into subsets of patient data captured within a rolling window of time. The duration of the rolling window may be, for example, less than one minute. The server may analyze the subset of patient data to extract data features from the patient data. The server may then use one or more subclassifiers to determine situational data, including motion type, activity type, and clinical assessment classification, based on the extracted data features and / or the preprocessed patient data. The motion type may be, for example, the movement of a body part during a motion test. In some embodiments, the subclassifiers may map patient data, including the extracted data features, to motion types. In some embodiments, the subclassifiers may identify motion types based on rule-based classifications, which may be determined during training of the subclassifiers. The server can predict the activity type based on the classification of the patient data's behavioral type. The activity type could be, for example, an activity associated with a motor test. The server can further predict whether the patient data was collected during a clinical assessment.

[0050] In one embodiment, the server may further classify tremors into amplitude categories based on extracted data features and contextual data using a tremor amplitude subclassifier. Tremor amplitude may refer to the displacement (e.g., of a body part) generated by the tremor from a fixed position or plane. Tremors can be classified as micro-tremors, moderate tremors, or coarse tremors based on their amplitude. Coarse tremors result in larger displacements, while micro-tremors result in smaller displacements. The tremor amplitude subclassifier can determine the tremor amplitude within each rolling window of time. Tremors can occur continuously, and tremor amplitudes can change within relatively short timeframes. Therefore, determining the amplitude of individual tremors may be useful for assessing the overall severity of a patient's tremors. The tremor amplitude subclassifier can identify tremors and assign amplitude classifications to tremors across the entire rolling window according to any known scale for tremor assessment, including, but not limited to, logarithmic or displacement-based scales. As an example, a tremor amplitude subclassifier can determine displacement and arbitrary angular rotation of a patient's body part (e.g., an arm). Displacement and angular rotation can be rapid movements. If a body part is stationary before a movement and returns to a stationary state after the movement, the displacement and angular rotation may indicate a resting tremor. The tremor amplitude subclassifier can identify tremors within a rolling window based on contextual data and determine the amplitude of the tremor based on the extracted data features that appear within the rolling window. The tremor amplitude subclassifier can output the tremor amplitude for each rolling window in which the tremor is detected by the subclassifier.

[0051] The server can then generate summaries of extracted data features over a fixed time frame, as well as summaries of situational data, which may include summaries of action type classification over a fixed time frame, summaries of activity type classification over a fixed time frame, and summaries of clinical assessment predictions over a fixed time frame. The server can also generate summaries of tremor amplitude classification over a fixed time frame. The summaries may be edits or aggregates of the outputs of the subclassifiers for each rolling window. In some embodiments, the summaries of extracted data features may include selected data features that have been shown to be relevant to tremor severity classification during training of the tremor severity classifier. The server can input the data summaries into the tremor severity classifier. The tremor severity classifier may be a classifier trained to assess tremor severity according to a numerical scale. For example, the tremor severity score may be a rating from 0 to 3. In some embodiments, the tremor severity score may be associated with a body part, such as an arm or a leg. The tremor severity classifier can predict tremor severity scores for one or more action sessions. In some embodiments, distinctions between activity sessions can be identified in summary data input to a tremor severity classifier. The tremor severity classifier can then average the tremor severity scores for each activity session. The tremor severity classifier can output a single tremor severity score as an assessment based on activity sessions. The server can transmit the tremor severity score to the patient's wearable device or mobile device.

[0052] In the above examples, the server can use the same set of patient data to assess BK, DK, and tremor severity. A symptom severity classifier for each symptom can identify whether or not the symptom will occur during the process of classifying symptom severity. Therefore, using a symptom severity classifier can reduce false positives that occur when a symptom is assumed to occur during analysis, even if it does not actually occur. Situational data, such as activity type classification and movement type classification, can improve the accuracy of severity classification by indicating the expected range or type of movement corresponding to the activity type or movement type. Deviations from expected movement can then be identified from the data features and classified based on severity. In one embodiment, additional situational data, including demographic data and medical history, can also influence symptom severity classification. For example, the assessment of tremor severity as a result of Parkinson's disease may depend on the patient's age. In one embodiment, a tremor severity classifier can distinguish between tremor as a symptom of PD and essential tremor, which is an adult-onset tremor disorder that can occur in patients without PD. In one embodiment, the patient's medical history, combined with the predicted symptom severity, can be used to determine the effectiveness of any Parkinson's disease (PD) treatment drug on the patient.

[0053] It should be understood that the symptom severity classifier can be used to classify symptoms associated with PD in addition to, or instead of, the exemplary symptoms described above. For example, the symptom severity classifier according to this disclosure can classify muscle rigidity, postural impairment, bradykinesia, gait changes, gait freezing, shuffling (walking), accelerated gait, motor variability, micrographia, dystonia, lisp, mask-like facies, akinesia, fatigue, changes in arm swing during walking, difficulty initiating movement, or fine motor skill difficulties. In addition, the indices used for classifying symptom severity may vary. For example, server 300 can calibrate the output of the symptom severity classifier based on the patient's or healthcare provider's preferred scale. By using a trained classifier, PD symptoms can be detected before they are noticed by the patient or observer, which can result in early detection and treatment of PD. The trained classifier can use sensor data that can reflect changes in the patient's movements that are not readily observable. In addition, a trained classifier can predict symptom severity using a wide range of sensor data, such as heart rate and acceleration, as well as data features (e.g., patterns) extracted from the sensor data, whereas a typical clinical assessment is based only on observable behavior, not objective measurements. Furthermore, to better identify changes in motor function over time, the classifier can establish baseline values ​​for the patient's movements by using the patient's own patient data. Generally, when new patient data is collected, the patient's medical history and past symptoms can be used in predicting symptom severity. The patient's medical history and previously classified symptoms can be stored in or accessed by the remote device 300. For example, a patient's record, including medical history and previously classified symptoms, can be stored in a patient database, as shown in Figure 2. In one embodiment, new patient data received and classified by the symptom severity classifier can then be included in training data that can be retrained and updated using the classifier. The predictions of the symptom severity classifier can be reviewed or adjusted, for example, by a healthcare professional, before being used as training data to improve the accuracy of the severity classifier.

[0054] A remote device 300, such as a server, can report the predicted symptom severity to a patient or a user, such as a healthcare professional, by sending a PD symptom report to a user-accessible device, such as the patient's mobile device 200 or a reporting device 400. The mobile device 200 and / or reporting device 400 can view the PD symptom report. The PD symptom report may include a symptom severity classification for one or more PD symptoms determined based on patient data. In one embodiment, PD symptoms may be displayed in a static format, which may include retrospective symptom data and / or future symptom data. Retrospective symptom data may include the patient's medical history, including past symptom severity classifications and assessments of changes in symptom severity over time. Future symptom data may include predictions of future changes in symptom severity, including the progression of motor function decline based on current and / or past symptom severity. In some embodiments, the remote device 300 can predict future symptom data for a patient based on the progression of symptoms in patients with similar symptom occurrences and / or medical histories. In one embodiment, the PD symptom report may include a two-dimensional (2D) and / or three-dimensional (3D) display of PD symptoms. The display of PD symptoms may be dynamic, for example, changing over time or being adjusted based on user input. In one embodiment, the PD symptom report may include tracking the effectiveness of therapeutic drugs, including PD medications. For example, the PD symptom report may include the progression of a patient's PD symptoms over time. If a patient is taking PD medications, the PD symptom report may display the changes in the patient's PD symptoms over time in parallel with the patient's PD medication use history. The patient's medication use history may include the type and dosage of the medication, as well as the time(s) the patient takes the medication and other conditions. The combination of PD symptom severity and medication history may show a correlation between the medication and the onset of symptoms.In some embodiments, the remote device 300 can determine the effectiveness of the drug by comparing the severity of the patient's symptoms immediately after taking the drug with the severity of the patient's symptoms before taking the drug.

[0055] In one embodiment, the remote device 300 and / or mobile device 200 can assess the level of health risk to the patient based on patient data and the severity of the patient's symptoms. For example, the remote device 300 may determine that the patient is at risk of accident or injury, given the severity of the patient's PD symptoms. This risk may depend on actions or activities that the patient may perform, such as driving a car or climbing stairs. In one embodiment, the risk may be related to the patient's level of independence. For example, the severity of the patient's PD symptoms may indicate that the patient's risk increases when the patient performs certain actions without assistance from the device or caregiver. The risk may change over time based on changes in the patient's symptom severity. In one embodiment, the risk may further depend on environmental factors. For example, the mobile device 200 or server 300 may have access to weather data corresponding to the patient's location. Weather data may include, for example, temperature and precipitation. The patient's sensitivity to temperature changes may increase due to PD, and temperature changes may also increase the severity of the patient's PD symptoms. The PD symptom report may include the patient's health risks to various activities, taking into account the patient's current environment or potential future environments (e.g., based on weather forecasts). In one embodiment, the remote device 300 or mobile device 200 may directly transmit a signal to a second mobile device, such as a caregiver's mobile device, as a result of the health risk assessment. For example, the remote device 300 may send an alert to the caregiver's mobile device if the patient's health risk has increased based on the severity of the patient's PD symptoms, or if it is detected that the patient has fallen or been injured based on patient data.

[0056] In one embodiment, the PD symptom report may include one or more medical recommendations for the patient based on patient data and PD symptom severity. Examples of medical recommendations include, but are not limited to, physical therapy (e.g., specific exercise or activity), pharmacotherapy, whether to seek medical assistance, lifestyle changes such as diet and rest, and the use of physical aids such as walking aids or home care. In one embodiment, the remote device 300 can determine medical recommendations based on a set of patient data, which may include the patient's general medical history in addition to symptom severity data for a large number of patients. The remote device 300 can generate medical recommendations for a patient based on patients with similar medical conditions and histories. In one embodiment, the remote device 300 can generate one or more medical recommendations based on scientific research or known medical guidance. The medical recommendations can be generated according to each patient's specific patient data and can therefore be customized to each patient's unique needs and disease progression, providing more accurate and tailored therapeutic recommendations that lead to better disease management and improved quality of life.

[0057] The output of the PD symptom report can be configured based on user input received by the user device. User input can include input to device peripherals such as a keyboard or mouse, input to a touchscreen interface, voice commands, biometric data, and camera data. For example, the user device may include a user interface, and input to the user interface may include the option to include and / or exclude report data. In one embodiment, the user device can modify the displayed PD symptom report based on the received input. In one embodiment, the user device can send a request for report data corresponding to the received input to a remote device and receive report data to be included in the PD symptom report. In one embodiment, the reporting device 400 can analyze the input using, for example, natural language processing (NLP) to determine additional information to be displayed to the patient or otherwise output. In one embodiment, the additional information can be generated via an automated voice or text generator in response to the input. The automated voice or text generator may include an artificial intelligence language model trained for automated conversation with human users. In one embodiment, the PD symptom report can be output to the patient via a voice 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 overlaid on image data captured by the device's camera. In one embodiment, the PD symptom report can be displayed using a VR device such as a headset.

[0058] In one embodiment, the remote device 300 can update the contents of the PD symptom report based on user input. In one embodiment, the user input can be received by the reporting device 400. The user input may be additional patient data, including, but not limited to, symptom reports or patient outcome measures. Symptom reports may include direct reports of symptom occurrence and / or symptom severity. Patient outcome measures may include, for example, assessments of the patient's quality of life and functional status. In some embodiments, the received additional patient data can be used to update the symptom severity classification, including retrospective and future symptom data. In some embodiments, the received additional patient data can be used to update the patient's assessed health risks or medical recommendations for the patient. For example, additional patient data may include the patient's preferences for types of therapeutic drugs. The remote device 300 can update medical recommendations for the patient based on the patient's preferred therapeutic drugs or the availability of those therapeutic drugs. In one embodiment, the PD symptom report can be distributed to the patient in the form of an interactive user interface. For example, the 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 input such as additional patient data, the reporting device 400 can update the PD symptom report.

[0059] It should be understood that the methods and functions described herein can be implemented by one or more devices. In some embodiments, the methods can be distributed across multiple devices. For example, a wearable device 100 can perform several preprocessing steps on sensor data to remove noise from the sensor data or to fuse the sensor data. In some embodiments, training of the statistical models described herein, including subclassifiers and symptom severity classifiers, can be distributed across multiple devices, e.g., multiple computers or servers. In one embodiment, the statistical models can be trained prior to and independently of the evaluation of new patient data. In one embodiment, a reporting device 400 can update the PD symptom report based on user input to include or exclude data, and vice versa, rather than the remote device 300 updating the PD symptom report. In some embodiments, the reporting device 400 and the patient's mobile device 200 can perform the same function. In some embodiments, the processing of the mobile device 200 can be distributed across the mobile device 200 and the wearable device 100. For example, a mobile device 200 can send a warning to a wearable device 100 based on a PD symptom report. The wearable device 100 can generate passive / active tactile warnings to attract the wearer's attention.

[0060] In one embodiment, the systems and methods described herein can be integrated with a telemedicine platform. Integration with a telemedicine platform allows input from multiple devices when predicting 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 about the patient (e.g., demographic information, medical history) into the reporting device 400, which can then transmit this data to a remote device 300, such as a server. The patient can wear a wearable device 100 and perform one or more activities based on instructions from the healthcare provider. The wearable device 100 can transmit sensor data acquired while the patient is performing one or more activities to the remote device 300. The remote device 300 can use the sensor data from the wearable device 100 and the input data from the reporting device 400 to assess the severity of the patient's PD symptoms. The remote device 300 can also send PD symptom reports to the healthcare provider's reporting device 400, in addition to the patient's mobile device 200. The display of the PD symptom report can be controlled by input from both the mobile device 200 and the reporting device 400. In response to the PD symptom report, care recommendations from the healthcare provider can be entered into the reporting device 400 and sent to the mobile device 200. The remote device 300 can also receive care recommendations and incorporate them into the next iteration of the PD symptom report.

[0061] The electronic user device 20 shown in Figure 9 may be an example of one or more devices described herein, including a patient mobile device 200 or a reporting device 400. In some embodiments, the electronic user device 20 may be a smartphone. However, those skilled in the art will understand that the features described herein may be adapted for implementation on other devices (e.g., laptops, tablets, servers, e-readers, cameras, navigation devices, etc.). The features described herein may also be adapted for implementation on a wearable device 100 presented in Figure 1. The exemplary user device 20 in Figure 9 includes a processing circuit, as discussed above. The processing circuit includes one or more of the elements discussed below with reference to Figure 9. The electronic user device 20 may include other components not explicitly shown in Figure 9, such as a CPU, GPU, and frame buffer. 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.

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

[0063] 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 used as working memory by the controller 410 while the processes and algorithms of this disclosure are being executed. In addition, the memory 450 may be used for long-term storage of image data and related information, for example.

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

[0065] Antenna 401 transmits and receives electromagnetic signals between base stations to implement wireless-based communications, such as various forms of cellular communication. Wireless communication processor 402 controls communications between the user device 20 and other external devices via antenna 401. For example, wireless communication processor 402 may control communications between base stations for cellular communication.

[0066] Speaker 404 emits an audio signal corresponding to the audio data supplied by voice processor 403. Microphone 405 detects ambient sounds and converts the detected sounds into an audio signal. The audio signal is then output to voice processor 403 for further processing. Voice processor 403 demodulates and / or decodes audio data read from memory 450 or audio data received by wireless communication processor 402 and / or short-range wireless communication processor 407. In addition, voice processor 403 can decode the audio signal acquired by microphone 405.

[0067] An exemplary user device 20 may also include a display 420, a touch panel 430, operation keys 440, and a short-range communication processor 407 connected to an antenna 406. The display 420 may be a liquid crystal display (LCD), an organic electroluminescent display panel, or another display screen technology. In addition to displaying still image and video data, the display 420 may also display operation inputs such as numbers or icons that can be used to control the user device 20. The display 420 may also display a GUI for the user to control elements of the user device 20 and / or other devices. Furthermore, the display 420 may display characters and images received by the user device 20 and / or stored in 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 sent from a web server.

[0068] 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 input operations on the operating surface of the touch panel display screen. The touch panel 430 also detects touch shape and touch area. As used herein, the term “touch operation” refers to an input operation performed by touching the operating surface of the touch panel display with an object such as a finger, thumb, or stylus. When a stylus is used for touch operation, the stylus may include a conductive material at least in its tip portion, so that sensors within the touch panel 430 can detect (similar to when a finger is used for touch operation) that the stylus is approaching / contacting the operating surface of the touch panel display.

[0069] In certain embodiments of this disclosure, the touch panel 430 may be positioned adjacent to (e.g., stacked with) the display 420, or it may be integrally formed with the display 420. For simplicity, this disclosure assumes that the touch panel 430 is integrally formed with the display 420, and therefore, in the examples considered herein, touch operations may be described as being performed on the surface of the display 420 rather than the touch panel 430. However, those skilled in the art will understand that this is not limiting.

[0070] For simplicity, this disclosure assumes that the touch panel 430 is a capacitive touch panel technology. However, it should be understood that aspects of this disclosure can be readily applied to other types of touch panels having alternative structures (e.g., resistive touch panels). In certain embodiments of this disclosure, the touch panel 430 may include transparent electrode touch sensors arranged in the XY direction on the surface of a transparent sensor glass.

[0071] A touch panel driver may be included within the touch panel 430 to perform control processing related to the touch panel 430, such as scan control. For example, the touch panel driver may scan each sensor in the capacitive transparent electrode pattern in the X and Y directions, detect the capacitance value of each sensor, and determine when a touch operation was performed. The touch panel driver may output the coordinates and corresponding capacitance values ​​for each sensor. The touch panel driver may also output a sensor identifier that can be mapped to coordinates on the touch panel display screen. In addition, the touch panel driver and touch panel sensor may detect when an object to be pointed to, such as a finger, is within a predetermined distance from the operating surface of the touch panel display screen. That is, the object to be pointed to does not necessarily need to be in direct contact with the operating surface of the touch panel display screen in order for the touch sensor to detect the object to be pointed to and perform the processing described herein. For example, in one embodiment, the touch panel 430 may detect the position of the user's finger around the edge of the display panel 420 (e.g., gripping the protective case surrounding the display / touch panel). A touch panel driver may transmit signals, for example, in response to the detection of a touch operation, or in response to an inquiry from another element based on time-based data exchange.

[0072] The touch panel 430 and the display 420 may be enclosed by a protective casing, which may also house other elements contained within the user device 20. In one embodiment, the position of the user's fingers on the protective casing (but not directly touching the surface of the display 420) may be detected by a sensor on the touch panel 430. Thus, the controller 410 may perform the display control processing described herein based on the detected position of the user's fingers gripping the casing. For example, elements within the interface may be moved to a new position within the interface (e.g., closer to one or more fingers) based on the detected finger position.

[0073] Furthermore, in one embodiment, the controller 410 may be configured to detect which hand is holding the user device 20 based on the position of the detected fingers. For example, the sensor on the touch panel 430 may detect multiple fingers on the left side of the user device 20 (e.g., on the edge of the display 420 or on the protective casing) and one 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 their right hand because the detected gripping pattern corresponds to the pattern expected if the user device 20 were held only with the right hand.

[0074] The operation keys 440 may include one or more buttons or similar external control elements that can generate operation signals based on user-detected input. In addition to the output from the touch panel 430, these operation signals may be supplied to the controller 410 to perform related processing and control. In certain embodiments of this disclosure, processing and / or functions associated with external buttons, etc., may be performed by the controller 410 in response to input operations on the display screen of the touch panel 430, rather than by external buttons, keys, etc. In this way, external buttons on the user device 20 can be eliminated by replacing them with input via touch operation, thereby improving water resistance.

[0075] Antenna 406 can transmit and receive electromagnetic signals from / to other external devices, and short-range wireless communication processor 407 can control wireless communication conducted with other external devices. Bluetooth, IEEE 802.11, and Near Field Communication (NFC) are non-limiting examples of wireless communication protocols that may be used for device-to-device communication via the short-range wireless communication processor 407.

[0076] The user device 20 may include a motion sensor 408. The motion sensor 408 may detect characteristics of the motion (i.e., one or more actions) 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 geolocation sensor to detect position, or a combination thereof, in order to detect the motion of the user device 20. In one embodiment, the motion sensor 408 may generate a detection signal containing data representing the detected motion. For example, the motion sensor 408 may determine the number of individual actions in the motion (e.g., within a predetermined time interval from the start to the stop of a series of actions), the number of physical impacts on the user device 20 (e.g., vibration, shock, etc. of an electronic device), the velocity and / or acceleration of the motion (instantaneous and / or temporal), or other characteristics of the motion. The detected characteristics of the motion may be included in the generated detection signal. The detection signal may be transmitted to a controller 410, for example, where further processing may be performed based on the data included in the detection signal. The motion sensor 408 can operate in conjunction with the Global Positioning System (GPS) unit 460. The current location information detected by the GPS unit 460 is transmitted to the controller 410. The antenna 461 is connected to the GPS unit 460 to receive and transmit signals to and from GPS satellites.

[0077] The user device 20 may include a camera unit 409, which includes a lens and shutter for taking photographs of the area around the user device 20. In one embodiment, the camera unit 409 photographs the area opposite to the user device 20 as seen from the user. The images of the photographs taken can be displayed on the display panel 420. The memory unit stores the photographs taken. The memory unit may reside within the camera unit 109 or may be part of the memory 450. The camera unit 409 may be a separate function attached to the user device 20 or may be a built-in camera function.

[0078] Next, with reference to Figure 10, a hardware description of device 601 according to an exemplary embodiment will be given. In Figure 10, device 601 may be any of the above-described devices, including a remote device 300 (e.g., a server) or a reporting device 400, and includes a processing circuit. The processing circuit includes one or more of the elements discussed below with reference to Figure 10. 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 remotely. Furthermore, the claimed inventive step is not limited by the form of the computer-readable medium in which the process instructions of the present invention are stored. For example, instructions may be stored on a CD, DVD, FLASH® memory, RAM, ROM, PROM, EPROM, EEPROM®, hard disk, or any other information processing device with which device 601 communicates, such as a server or computer.

[0079] Furthermore, the claimed inventive step may be provided as a utility application, background daemon, or operating system component, or a combination thereof, running in combination with the CPU600 and an operating system such as Microsoft Windows®, UNIX®, Solaris, LINUX®, Apple MAC-OS, and other systems known to those skilled in the art.

[0080] The hardware elements for realizing device 601 can be achieved by various circuit elements known to those skilled in the art. For example, CPU 600 may be an Intel Xenon or Core processor, or an AMD Opteron processor, or other processor types known to those skilled in the art. Alternatively, CPU 600 may be implemented on an FPGA, ASIC, PLD, or using discrete logic circuits, as known to those skilled in the art. Furthermore, CPU 600 may be implemented so that multiple processors work together in parallel to execute the instructions of the process described above.

[0081] Device 601 in Figure 10 also includes a network controller 606, such as an Intel Ethernet® PRO network interface card from Intel Corporation, which interfaces with network 650 and communicates with other devices. As can be understood, network 650 can be a public network such as the Internet, or a private network such as a LAN or WAN network, or any combination thereof, and may also include PSTN or ISDN lower-level networks. Network 650 can also be wired, such as an Ethernet® network, or wireless, such as a cellular network, including EDGE, 3G, 4G, and 5G wireless cellular systems. Wireless networks can also be WiFi, Bluetooth, or any other known form of wireless communication.

[0082] Device 601 further includes a display controller 608, such as an NVIDIA GeForce GTX or Quadro graphics adapter from NVIDIA, for interface connection to a display 610, such as an LCD monitor. A general-purpose I / O interface 612 interfaces to a keyboard and / or mouse 614, as well as a touchscreen panel 616, either on or separate from the display 610. The general-purpose I / O interface also connects to various peripherals 618, including printers and scanners.

[0083] A sound controller 620 is also provided within device 601 and interfaces with speaker / microphone 622, thereby providing sound and / or music.

[0084] The general-purpose storage controller 624 connects to the storage medium disk 604 using a communication bus 626, which may be ISA, EISA, VESA, PCI, or similar, and is intended to interconnect all components of device 601. In this specification, a general description of the 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 for simplicity, as these features are known.

[0085] While this specification includes details of many specific embodiments, these should not be interpreted as limitations on the scope of claims, but rather as descriptions of features that may be specific to particular embodiments.

[0086] Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable partial combination. Furthermore, features may be described above as acting in a particular combination, and may even be initially claimed as such, but in some cases one or more features may be removed from the claimed combination, and the claimed combination may be subject to partial combinations or variations of partial combinations.

[0087] Similarly, while operations are depicted in a specific order in the drawings, this should not be understood as requiring that such operations be performed in a specific or sequential order, or that all illustrated operations be performed, in order to achieve the desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, 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.

[0088] We have described specific embodiments of the subject matter. Other embodiments are within the scope of the following claims. For example, the actions enumerated in the claims can be performed in a different order and still achieve the desired results. As an example, the process depicted in the accompanying diagram does not necessarily require the specific order shown, i.e., a sequential order, to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous.

[0089] Clearly, numerous modifications and variations are possible in light of the above teachings. Therefore, it should be understood that embodiments of this disclosure may be practiced within the scope of the appended claims in ways other than those specifically described herein.

[0090] Embodiments of this disclosure may also be as described in the following parenthetical-numbered embodiments.

[0091] (1) A method for classifying the severity of symptoms associated with a neurological disorder, the method comprising: receiving sensor data from a device including one or more sensors; extracting data features from the received sensor data via a processing circuit; generating a patient condition status via the processing circuit based on the extracted data features; determining symptoms associated with a neurological disorder via the processing circuit based on the extracted data features and the patient condition status; predicting the severity of the determined symptoms using a symptom severity classifier via the processing circuit based on the extracted data features and the patient condition status; and outputting the determined symptoms and the predicted severity of the determined symptoms.

[0092] (2) The method according to (1), wherein the receiving step includes receiving sensor data from a wearable device.

[0093] (3) The method according to (1) to (2), wherein the received sensor data includes at least one of accelerometer data, gyroscope data, physiological data, positional data, geographical data, and / or environmental data.

[0094] (4) The method according to (1) to (3), further comprising preprocessing the sensor data, which includes filtering the sensor data and fusing the sensor data.

[0095] (5) The method according to (1) to (4), wherein the patient's condition includes at least one of the following: movement, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data.

[0096] (6) The method according to (1) to (5), further comprising changing the circumstances relating to the patient's condition.

[0097] (7) The method according to (1) to (6), further comprising determining the effect of a therapeutic agent on the predicted severity of the determined symptoms.

[0098] (8) The method described in (1) to (7), including the determination of clinical activities related to the patient's condition, which are associated with the neurological assessment.

[0099] (9) The method according to (1) to (8), further comprising determining the amplitude of a tremor if the symptom determined to be a tremor.

[0100] (10) The method according to (1) to (9), wherein the symptom severity classifier is a trained artificial intelligence model or a trained machine learning model.

[0101] (11) The method according to (1) to (10), wherein the symptom severity classifier includes a trained neural network.

[0102] (12) The method according to (1) to (11), further comprising training a symptom severity classifier using a deep learning method and training data.

[0103] (13) The method according to (1) to (12), further comprising determining a symptom which is a symptom associated with Parkinson's disease, and which is one of the following: tremor, bradykinesia, dyskinesia, muscle rigidity, postural impairment, bradykinesia, shuffling gait, altered gait, frozen gait, motor variability, micrographia, dystonia, lisp, masked facies, akinesia, fatigue, altered arm swing, difficulty initiating movement, and difficulty with fine motor skills.

[0104] (14) The method described in (1) to (13) wherein the determined symptoms are associated with essential tremor.

[0105] (15) The method according to any one of (1) to (14), further comprising receiving symptom data via a processing circuit and predicting the severity of the symptoms based on the received symptom data.

[0106] (16) The method according to (1) to (15), further comprising generating a symptom report based on the predicted severity of the symptoms via a processing circuit.

[0107] (17) A non-temporary computer-readable storage medium for storing computer-readable instructions that, when executed by a computer, cause a computer to perform a method, wherein the method includes: receiving sensor data from a device including one or more sensors; extracting data features from the received sensor data; generating a situation relating to a patient's condition based on the extracted data features; determining symptoms associated with a neurological disorder based on the extracted data features and the situation relating to the patient's condition; predicting the severity of the determined symptoms based on the extracted data features and the situation relating to the patient's condition using a symptom severity classifier; and outputting the determined symptoms and the predicted severity of the determined symptoms.

[0108] (18) A non-temporary computer-readable storage medium as described in (17), wherein the information relating to the patient's condition includes at least one of motion, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data.

[0109] (19) A device comprising a processing circuit configured to receive sensor data from a device including one or more sensors, extract data features from the received sensor data, generate a situation relating to the patient's condition based on the extracted data features, determine symptoms associated with a neurological disorder based on the extracted data features and the situation relating to the patient's condition, predict the severity of the determined symptoms using a symptom severity classifier based on the extracted data features and the situation relating to the patient's condition, and output the determined symptoms and the predicted severity of the determined symptoms.

[0110] (20) The device according to (19), wherein the patient's condition includes at least one of motion, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data.

[0111] Thus, the foregoing discussions merely disclose and describe exemplary embodiments of the present disclosure. As those skilled in the art will understand, the present disclosure can be embodied in other specific forms without departing from its spirit. Accordingly, the disclosures of this disclosure are illustrative and do not limit the scope of the present disclosure or any other claims. The present disclosure includes any readily recognizable variations of the teachings herein, partially defining the scope of the terms of the aforementioned claims, and thereby not making any subject matter of any invention available to the public.

Claims

1. A method for classifying the severity of symptoms associated with neurological disorders, wherein the method is Receiving sensor data from a device containing one or more sensors, The process involves extracting data features from the received sensor data via a processing circuit, The processing circuit generates a situation regarding the patient's condition based on the extracted data features, Based on the extracted data features and the circumstances relating to the patient's condition, the processing circuit determines the symptoms associated with the neurological disorder. Through the processing circuit, a symptom severity classifier is used to predict the severity of the determined symptoms based on the extracted data features and the circumstances relating to the patient's condition. Outputting the determined symptoms and the predicted severity of the determined symptoms, Methods that include...

2. The method according to claim 1, wherein the receiving step includes receiving the sensor data from a wearable device.

3. The method according to 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 according to claim 1, further comprising preprocessing the sensor data, which includes filtering the sensor data and fusing the sensor data.

5. The method according to claim 1, wherein the circumstances relating to the patient's condition include at least one of motion, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data.

6. The method according to claim 1, further comprising converting the situation relating to the patient's condition.

7. The method according to claim 5, further comprising determining the effect of a therapeutic agent on the predicted severity of the symptoms determined.

8. The method according to claim 1, wherein the circumstances relating to the patient's condition include determining clinical activities associated with neurological evaluation.

9. The method according to claim 1, further comprising determining the amplitude of the tremor if the symptom determined to be a tremor.

10. The method according to claim 1, wherein the symptom severity classifier is a trained artificial intelligence model or a trained machine learning model.

11. The method according to claim 1, wherein the symptom severity classifier includes a trained neural network.

12. The method according to claim 1, further comprising training a symptom severity classifier using a deep learning method and training data.

13. The method according to claim 1, further comprising determining a symptom associated with Parkinson's disease, which is one of the following: tremor, bradykinesia, dyskinesia, muscle rigidity, postural impairment, bradykinesia, shuffling gait, gait changes, gait freeze, motor variability, micrographia, dystonia, lisp, mask-like facies, akinesia, fatigue, changes in arm swing, difficulty initiating movement, and difficulty with fine motor skills.

14. The method according to claim 1, wherein the symptoms determined are associated with essential tremor.

15. The processing circuit receives symptom data, The method according to claim 1, further comprising predicting the severity of the symptoms based on the received symptom data.

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

17. A non-temporary computer-readable storage medium for storing computer-readable instructions that cause the computer to perform a method, wherein the method is Receiving sensor data from a device containing one or more sensors, Extracting data features from the received sensor data, Based on the extracted data features, generate a situation regarding the patient's condition. Based on the extracted data characteristics and the circumstances relating to the patient's condition, the symptoms associated with neurological disorders are determined. Using a symptom severity classifier, predict the severity of the determined symptoms based on the extracted data features and the circumstances relating to the patient's condition, Outputting the determined symptoms and the predicted severity of the determined symptoms, Non-temporary computer-readable storage media, including [specific type of storage medium].

18. The non-temporary computer-readable storage medium according to claim 17, wherein the circumstances relating to the patient's condition include at least one of motion, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data.

19. It is a device, A processing circuit, Receiving sensor data from a device containing one or more sensors, Extracting data features from the received sensor data, Based on the extracted data features, generate a situation regarding the patient's condition. Based on the extracted data characteristics and the circumstances relating to the patient's condition, the symptoms associated with neurological disorders are determined. Using a symptom severity classifier, predict the severity of the determined symptoms based on the extracted data features and the circumstances relating to the patient's condition, Outputting the determined symptoms and the predicted severity of the determined symptoms, A processing circuit configured to perform the following: A device equipped with the following features.

20. The device according to claim 19, wherein the circumstances relating to the patient's condition include at least one of motion, activity, demographic data, physiological data, environmental data, medical data, posture data, location data, and / or geographic data.

Images