cloudUPDRS: a smartphone medical device for Parkinson's
Read the paper →Most people with Parkinson’s see a specialist only once or twice a year — yet their motor symptoms can fluctuate dramatically within a single day. cloudUPDRS closes that gap by turning an ordinary smartphone into a certified medical device that measures those symptoms objectively, at home, as often as the patient wants.
The problem
Parkinson’s Disease is a degenerative neurological condition marked by tremor, slowness of movement, muscular stiffness and poor postural stability. There is no cure, so care is a life-long process of managing symptoms and adjusting medication — and because the disease progresses at different rates in different people, that adjustment depends on regular, accurate monitoring.
In practice, monitoring is anything but frequent. There are over 130,000 people with Parkinson’s in the UK and as many as one million in the US, and each is typically seen by a specialist doctor or nurse only once or twice a year. The reason is cost: applying clinical measures of disease progression is laborious and requires the direct involvement of a member of the clinical team.
The instrument those clinicians use is the Unified Parkinson’s Disease Rating Scale (UPDRS) — more precisely its modern revision, the MDS-UPDRS, the most commonly used protocol in the clinical study of the disease. It is detailed and formally structured, but it has two inherent limitations. First, it is coarse-grained: it assesses performance without specialised measurement instrumentation. Second, despite good internal consistency, it still depends on the clinician’s subjective estimation of how the patient performed. Together, these factors restrict opportunities to precisely quantify how the disease is progressing and to adapt care to the individual. What was missing was a way to measure motor symptoms objectively, frequently, and outside the clinic.
Figure 1. cloudUPDRS: from at-home phone tests to an objective motor score.
What we built
cloudUPDRS is the first smartphone app to achieve certification as a Class I medical device — an active transient non-invasive instrument — from the Medicines and Healthcare products Regulatory Agency (MHRA) in the UK, for the clinical assessment of the motor symptoms of Parkinson’s. It received medical device status in the UK, and thus the EU, in May 2016.
The app follows closely Part III of the MDS-UPDRS, the motor examination, which is widely regarded as the most objective and reliable part of the scale — the European Medicines Agency recognises it for measuring the efficacy of a drug for Parkinson’s. Patients and their carers use the app at home or in the community, unsupervised. It guides them through a carefully orchestrated sequence of simple actions — tapping the screen to assess bradykinesia, holding the phone at rest on the lap to capture resting tremor, leg-agility and gait tasks — while the phone’s accelerometer and touchscreen record the movement. The full test comprises 17 individual observations, each recorded over 60 seconds, followed by a short questionnaire that tracks the most recent medication intake.
The raw sensor data is then sent to a cloud-based data-management and analytics service, which applies a biomedical signal-processing pipeline to calculate an objective UPDRS score and supports longitudinal trend analysis and patient stratification. A clinician dashboard lets care teams compare the app’s objective measurements against self-reported assessments and medication times over weeks at a time. In short: an objective, repeatable motor score, generated at home, that augments — rather than replaces — the standard clinical pathway.
Making it work
Moving the UPDRS out of the clinic created two hard engineering challenges. The paper addresses both.
Challenge one: data quality without a supervisor. In the clinic, an expert ensures the patient performs each movement correctly. At home there is no such supervisor, and a movement done wrong produces a signal that is not representative of the intended tremor type — which would lead to an erroneous score. cloudUPDRS tackles this with two mechanisms working in tandem. The first is the bespoke user-experience design itself: by requiring specific action sequences, the app constrains the degrees of freedom of movement and disambiguates context, so the recorded signal can be interpreted accurately. The second is a deep learning quality-control layer that replaces expert supervision. The team frames data verification as a binary classification problem — high-quality versus low-quality recording — and trains a Recurrent Convolutional Neural Network (RCNN) to detect when the prescribed protocol was not followed. The convolutional layers capture the local features of the acceleration signal while the recurrent structure exploits its temporal evolution across the full trace, and the model runs on the phone itself (implemented in TensorFlow) to flag a bad recording in real time and ask the patient to repeat it. Crucially, the design prioritises catching genuinely poor recordings while keeping false positives low — so the system does not needlessly reject usable data.
Challenge two: making the test short enough to actually use. The full procedure takes about 25 minutes even for an experienced patient. That matters because field testing showed compliance collapses at that length: of 12 participants in the initial three-month trial, most tested regularly in the first week, but by the third week the rate had dropped sharply, and only one was still testing at the end of three months. User research pointed the same way — most patients wanted a test of five minutes or less. The team first checked whether each 60-second observation could simply be shortened, and found it could not: cutting an observation to 20 seconds changed the tremor power by more than 10% for 60% of patients, corresponding to errors of 1 to 2.5 points on the MDS-UPDRS scale — the equivalent of six to twelve months of disease progression. So instead of shortening observations, cloudUPDRS shortens the list of them. Drawing on clinical findings that a small group of factors correlates strongly with the overall motor score, the team uses machine learning to personalise the test: after a patient completes the full test at least five times during a first calibration week, a feature-importance analysis (an ensemble of randomised decision trees) ranks the observations and selects the smallest subgroup that accounts for at least 80% of the variance in the overall UPDRS score. The result is a personalised “quick test” tailored to each patient’s own symptom profile.
Figure 2. Deep learning guards data quality; personalisation cuts a ~25-minute test to under 4.
What it achieves
The two techniques deliver on the goals that make at-home assessment viable.
On data quality, the RCNN outperformed every benchmark the team tested — including tree-ensemble methods (Random Forest, Extra Trees, Gradient Boosting, AdaBoost, Bagging), Naive Bayes classifiers, and the Deep Multilayer Perceptron from the team’s earlier work. Evaluated with ten cycles of leave-one-session-out cross-validation, the RCNN reached 0.78 accuracy, an F1-score of 0.82, and an area under the precision-recall curve (AUC) of 0.87 — the best on all three metrics. More importantly than the headline accuracy, it was the only method that reliably distinguished good recordings from bad ones on an unbalanced dataset: the simpler classifiers achieved high true-positive rates only by waving through low-quality recordings as usable, whereas the RCNN produced balanced performance and a lower false-positive rate — exactly the property you need when the cost of accepting a bad recording is a wrong clinical score.
On efficiency, the personalisation method worked across every patient examined: in all cases, features from only three or fewer observations were enough to account for the target variance, even for patients at medium and advanced stages of the disease. For one representative patient at an advanced stage, just three observations (yielding seven features) captured roughly 90% of the variation in their motor score — and system logs confirmed that patient completed the quick test in under 4 minutes, more than 50 times across two months. That sub-4-minute threshold is the headline result, because it was identified as critical for sustained clinical compliance: it is what turns a once-or-twice-a-year snapshot into something a patient can do daily.
Figure 3. The headline outcomes.
Why it matters
cloudUPDRS shows that a regulated, objective clinical measurement can live on a device patients already own. The implications run in three directions. For clinical trials, an objective, frequently sampled Part III score — the very marker the EMA accepts for measuring drug efficacy — offers a richer and more consistent signal than sparse in-clinic ratings. For remote and continuous care, daily measurement enables earlier detection of problems such as medication side-effects, better tracking of individual symptom trends, and more effective patient stratification. And for patients themselves, it supports a shift toward ownership of their own care: in the team’s user research, the experience of using the app and the sense of control it gave over the disease mattered as much as the data it produced.
This is precisely the kind of work stm.ai’s MedTech practice is built around: AI that is evidence-linked rather than free-floating, and that keeps a human-in-the-loop by design. cloudUPDRS does not try to replace the clinician — it replaces the supervision overhead that kept objective measurement locked inside the clinic, while keeping clinical judgement, regulatory rigour, and the patient at the centre. The result is not a gadget but a certified instrument, validated against the regulatory standards medical devices must meet, and engineered so that high-quality data and a frictionless patient experience reinforce each other rather than compete.
C. Stamate, G.D. Magoulas, S. Kueppers, E. Nomikou, et al. — “The cloudUPDRS app: A Medical Device for the Clinical Assessment of Parkinson’s Disease”, Pervasive and Mobile Computing (2018). Read the paper.