How to Build a Parkinson’s Care App: Features, Architecture, and Compliance

According to the Parkinson’s Foundation, Parkinson’s disease (PD) affects roughly 1.1 million Americans today, with about 90,000 new US diagnoses a year. PD is also the world’s fastest-growing neurological disorder, per WHO. Progressive. Incurable. Serious daily care load: medication multiple times a day, motor monitoring, therapy adherence, care coordination.

Yet most Parkinson’s care app development today stops at a symptom journal or a medication reminder. The next layer up is the app that closes the clinical loop. The one that ties medication timing to motor state, with symptom pattern overlaid, in a view a neurologist can use.

Here’s the part we keep coming back to. The Apple Movement Disorder API has been live on Apple Watch since 2018. Eight years. In that time, only two products have shipped FDA-cleared on top of it: Rune Labs’ StrivePD (K213519, June 2022, the first) and h2o therapeutics’ Parky (K220820, November 2022). For a population of around 12 million people worldwide, that’s a thin product layer over a mature substrate. And patients show up. The Michael J. Fox Foundation’s Fox Insight study has 54,000+ enrolled.

If you’re scoping a Parkinson’s build, read this before your first design sprint.

What’s involved in Parkinson’s care app development?

Four archetypes (patient self-management, motor monitoring, gait/exercise therapy, care coordination). The required integration stack is the Apple Movement Disorder API (watchOS 5+), HealthKit, Google Health Connect, and FHIR for EHR write-back. Motor-accessible UX shapes the build, with 60–80pt touch targets plus auto-save and no swipe nav as defaults. The SaMD pathway via 510(k) is open, with StrivePD and Parky as cleared examples.

Key takeaways

• Building a Parkinson’s care app is its own product discipline. The clinical loop (how medication timing interacts with motor state and symptom pattern) is unique to PD, and the UX accommodations and compliance questions follow from that clinical reality.
• Design for the patient’s worst motor day. The app that holds up during active tremor, in an off motor state, mid-freezing episode, on a shaking phone is the product. If a medication log or SOS can’t be hit in that state, the app fails at the moment it matters most. Build for that user from the first sprint.
• The Apple Movement Disorder API is the highest-leverage integration and the fastest path to FDA classification today. Two products have shipped FDA-cleared on top of it: Rune Labs’ StrivePD (K213519, June 2022) and h2o therapeutics’ Parky (K220820, November 2022). The API has been live since watchOS 5 in September 2018. Two products in nearly eight years for ~12 million patients globally. That’s the actual market signal.

Table of Contents

1. The four Parkinson’s app archetypes: choose your product category before you choose your features
2. Core features: what every Parkinson’s app needs, and what differentiates
3. Technical integrations: the Parkinson’s-specific stack
4. Motor-accessible UX: designing for the Parkinson’s user
5. Data architecture: building around the clinical loop
6. The compliance stack for Parkinson’s app development
7. The build roadmap in three stages
8. Why choose Topflight for Parkinson’s app development

The four Parkinson’s app archetypes: choose your product category before you choose your features

Not all Parkinson’s apps are the same product. The buyer, the feature set, the technical integrations, and the compliance load shift across these four archetypes.

Archetype 1: the patient self-management app

• Buyer: patient (B2C) or patient support program (B2B2C via pharma or one of the major Parkinson’s foundations).
• Core: symptom tracker, medication management, therapy reminders, motor diary.
• Regulatory: non-device when wellness-scoped. SaMD if the app generates clinical assessments from the logged data.
• Build complexity: low-to-moderate.

This is the most common Parkinson’s app and the fastest to MVP. Daily use by the patient, optional sharing with caregiver or care team.

Archetype 2: the motor monitoring platform

• Buyer: neurologist or movement disorder specialist clinic, plus pharma and research institutions running clinical trials.
• Core: passive or active motor assessment via wearable sensors and/or the Apple Movement Disorder API. Objective tremor and dyskinesia measurement, plus gait analysis. Clinician dashboard with trend data.
• Regulatory: high SaMD risk.
• Build complexity: high. Requires sensor integration and clinical validation of the measurement methodology.

Two FDA-cleared digital biomarker products in this archetype, both built on the Apple Movement Disorder API: StrivePD and Parky (cites StrivePD as predicate). The pathway is repeatable.

Archetype 3: the gait and exercise therapy app

• Buyer: patient (B2C) or physical therapy practice (B2B).
• Core: structured exercise and gait training, rhythmic auditory stimulation, balance training, LSVT BIG-style sessions with real-time or session feedback.
• Regulatory: non-device for general exercise guidance. SaMD if the app claims to treat or mitigate Parkinson’s motor symptoms.
• Build complexity: moderate.

Most rehabilitation app development-adjacent of the four. LSVT BIG and LSVT LOUD are trademarked clinical protocols. Using either name in an app requires LSVT-certified PTs or SLPs on the loop. Design exercises independently if you don’t have the certifications, but skip the brand names.

Archetype 4: the care coordination platform

• Buyer: health system, neurology practice, ACO, or Parkinson’s care navigator program.
• Core: multi-user platform connecting patient, caregiver, care team, and Parkinson’s care navigator. Care plan management, medication changes, symptom escalation, telehealth, EHR write-back.
• Regulatory: non-device for coordination. SaMD if any feature generates clinical recommendations.
• Build complexity: high. Multi-role access model and EHR integration.

Rune Labs’ StrivePD integrates with Medtronic’s Percept PC deep brain stimulator, bringing DBS data, wrist motor data, medication logs, and patient self-report into one clinician dashboard. That’s the production reference for multi-modal data.

Choosing your archetype

Most Parkinson’s patient app development starts at Archetype 1: it’s the fastest to market and B2C revenue is possible. Add Archetype 4 features as the enterprise buyer emerges.

Archetype 2 needs clinical validation infrastructure from day one and a clinical research co-founder or pharma partnership.

Archetype 3 needs a licensed PT or movement disorder specialist on the founding team. The same archetype-first thinking applies to mental health app development and other neurological-condition apps: the buyer drives the build before the features do.

Core features: what every Parkinson’s app needs, and what differentiates

The core Parkinson’s disease app features split into two layers: table-stakes features that land in every archetype, and a differentiating layer that varies by buyer and use case. Both are mapped below, with regulatory risk and complexity attached to the features where they shift the build the most.

The table stakes: features every Parkinson’s app needs

The differentiating features by archetype

A note on the Apple Movement Disorder API and FDA classification

The single feature most likely to define your product and your regulatory pathway. The Apple Movement Disorder API outputs a tremor presence breakdown and a dyskinesia time fraction as digital biomarker.

Display either as a clinical assessment of disease status, and you’ve generated a clinical output from a software analysis of physiological signals. That’s the exact pattern FDA has classified as SaMD. StrivePD took this pathway and shipped 510(k) clearance in June 2022.

Technical integrations: the Parkinson’s-specific stack

A digital health app for Parkinson’s integrates with a different stack than a general health app. The divergence shows up at four points:

• passive motor data
• clinical-grade sensor platforms
• EHR write-back of motor and medication data
• movement-disorder-aware telehealth

The Apple Movement Disorder API: what it returns and where it has shipped

The class is CMMovementDisorderManager, part of Core Motion. It does passive tremor detection and dyskinesia monitoring on Apple Watch Series 4 and later, available since watchOS 5.

Methods:

• monitorKinesias(forDuration:)
• queryTremor(from:to:withHandler:)
• queryDyskineticSymptom(from:to:withHandler:)
• isAvailable()
• authorizationStatus()

Results:

• CMTremorResult
• CMDyskineticSymptomResult (in one-minute windows)

CMTremorResult breaks out tremor across six buckets:

• percentNone
• percentSlight
• percentMild
• percentModerate
• percentStrong
• percentUnknown

The API detects resting tremor only, surfacing Apple’s clinically validated MM4PD algorithm. Data flows into HealthKit, accessible via standard authorization. StrivePD and Parky, both cite MM4PD in their 510(k) summaries.

The alternative path: raw IMU plus your own ML

New Touch Digital’s NeuroRPM (K221772, March 2023) runs on Apple Watch but skips CMMovementDisorderManager. It consumes raw accelerometer and gyroscope data and runs proprietary ML.

Predicate is PKG (K161717, Global Kinetics), a different substantial-equivalence path. The tradeoff is honest. You give up Apple’s MM4PD validation work. You gain algorithm control and the ability to train on signals the API doesn’t measure (action tremor, gait analysis), plus the option to run your own dyskinesia model.

Worth doing if you have the clinical validation infrastructure.

Clinical-grade wearable platforms beyond the Apple Watch

Three platforms come up when the Apple Watch isn’t the right fit. Empatica E4 and EmbracePlus are medical-grade wrist wearables with accelerometer, EDA, PPG, and temperature sensing, BAA available.

Actigraph is the research-grade accelerometry standard, used in FDA-reviewed studies. Verily Study Watch is pharma and research only. No consumer distribution. These are where BLE wearable platforms live, and where the wearable sensor integration work lands when you need medical device companion app capabilities or clinical-grade wearable technology in healthcare more broadly.

HealthKit and Google Health Connect for consumer wearable data

HealthKit (iOS) and Google Health Connect (Android) are the standard paths for consumer-grade wearable data such as Apple Watch heart rate, step count, sleep. Both authorize per data type. Apply minimum-necessary on the types you request. In PD apps, that’s a data-architecture principle as much as a HIPAA principle.

EHR integration via FHIR R4 and SMART on FHIR

Four FHIR R4 resources do the heavy lifting:

• MedicationStatement for medication logs
• Observation for motor symptom data and UPDRS scores
• Condition to read the PD diagnosis and comorbidity context
• CarePlan for the care coordination workflow

For Epic EHR integration or Cerner, SMART on FHIR launch embeds your app in the neurologist’s workflow.

Telehealth for movement disorder visits

Standard WebRTC stacks work fine: Daily.co or Zoom SDK, both with HIPAA BAA. The PD-specific UX detail is camera framing guidance built into the patient-side interface. Movement disorder visits need the neurologist to see enough of the patient’s body for visual motor assessment. Build that as a feature. The same stack supports remote patient monitoring app development on the passive side.

Motor-accessible UX: designing for the Parkinson’s user

Motor-accessible UX for Parkinson’s is a translation exercise. General motor accessibility guidelines don’t carry over. Each clinical symptom (resting tremor, bradykinesia, dyskinesia, freezing of gait, on/off motor fluctuations) drives a specific UX decision that diverges from general mobile best practice.

Resting tremor and touch target sizing

PD resting tremor oscillates at 4–6Hz (MDS consensus brackets pathological tremor at 4–8Hz). The one peer-reviewed PD-specific UI guideline study (Nunes et al., 2016, 39 PD participants) found tap accuracy peaked at 14mm targets, with 10.5mm acceptable when space is tight.

WCAG 2.2 sets a 24×24 CSS px touch target size floor (AA, 44×44 at AAA). Our Topflight defaults (60pt primary, 80pt critical like SOS) extrapolate from Nunes 14mm with tremor compensation margin. These are engineering defaults from clinical reasoning. You should validate with your PD users.

Skip swipe as primary navigation. WCAG 2.2 also mandates single-pointer alternatives to drag. For severe tremor, iOS accessibility surfaces switch access and dwell selection.

Bradykinesia and timing and input design

Bradykinesia slows every motor action. Skip double-tap. Skip timed UI like countdown screens and auto-advancing content. Skip multi-finger gestures. Skip standard keyboard as primary text entry. On iOS and Android, long press defaults to 500ms.

Best practice: respect the user’s OS-level touch & hold delay setting. When hard-coding, 750–1000ms is a defensible engineering default. Offer voice input as a primary alternative (caveats below) and structured selection (dropdown, slider) to support one-handed use, common with asymmetric tremor.

On/off motor fluctuations: design for the worst motor state

Build for the worst point in the on/off motor state cycle. The app must work during “off” states (tremor active, bradykinesia severe), because that’s when the patient most needs to log a symptom or hit SOS.

De Vleeschhauwer et al. (2021) measured PD-OFF touchscreen performance directly: significantly longer sliding-task times, with dopaminergic medication not normalizing multi-direction sliding. If a critical task can’t be completed in an active off state, the app fails at the worst possible moment.

Freezing of gait and session recovery

Sessions get interrupted in PD without warning. Freezing episodes and off-state collapse from the patient side, caregiver interruption from outside.x Build session auto-save into every interaction. Resume where the patient left off. No flow restarts. No penalty for abandonment.

Two timeout layers exist: OS-level screen auto-lock (user-controlled, outside your app’s scope) and app-level idle timeout (entirely app-defined). WCAG 2.2.1 (Level A) and 2.2.6 (AAA) frame timeout requirements. A 10-minute floor on active logging screens is defensible for bradykinetic users.

Cognitive considerations for later-stage Parkinson’s

Later-stage PD raises cognitive load: slower processing, executive function shifts.

• reduce visual load with large text and high contrast
• one primary action per screen
• text labels on every icon
• stable navigation
• confirmation dialogs for irreversible actions
• minimal metaphor or non-standard iconography

Voice input caveats: hypophonia and dysarthria

Hypokinetic dysarthria, often paired with hypophonia, affects close to 90% of Parkinson’s patients. Cloud ASR runs ~27% higher WER on PD speech vs controls. On low-intelligibility dysarthric speech, IBM Watson, Google Cloud, and Microsoft Azure hit 80–90% WER versus 15–25% on typical speech.

The implications: voice input needs PD-speaker validation across disease stages. Prefer personalized or fine-tuned models (Project Euphonia, Speech Accessibility Project) over off-the-shelf cloud APIs. Build a graceful fallback to typed or structured input.

Data architecture: building around the clinical loop

Every meaningful Parkinson’s app is built around one query: how does this patient’s medication schedule relate to their on/off motor fluctuations, and where are the gaps? Build the data model to answer it efficiently.

The five core entity types of a Parkinson’s data model

A Parkinson’s symptom tracking app development effort lives or dies on these five entities:

• Medication event: drug name, dose, timestamp, adherence status (taken / missed / late). This is what populates the medication diary.
• Motor state event: on / off / dyskinesia label, timestamp, severity if self-reported.
• Symptom log: structured entries with timestamps, severity ratings, optional free text.
• Objective motor data: Apple Movement Disorder API output, wearable sensor data, gait session data, all timestamped against the medication and symptom timeline.
• Clinical assessment: MDS-UPDRS scores and PRO responses (PDQ-39, FOG-Q).

Everything else (e.g., telehealth visits or EHR write-back) hangs off these five.

The clinician correlation view

The data view that earns a place in a neurology appointment: medication timeline and motor state diary stacked, with objective sensor data overlaid, in 1-week and 1-month windows.

That’s the chart a neurologist uses to adjust levodopa or dopamine agonist timing. Build the schema for it from day one.

The same model carries the patient-reported outcomes (PROs) you need for clinical use and the real-world evidence (RWE) pharma partners ask for.

Session architecture for motor-impaired users

Optimistic writes. Every interaction commits to local store at the moment of entry, syncs immediately, with conflict resolution for offline. No save buttons. No batch commits. Session auto-save is the data-layer enforcement of the UX rule we discussed above.

Sessions get interrupted in this population in ways they don’t in other apps, and the model has to recover state without losing anything.

Notification architecture for medication reminders

A missed levodopa dose causes motor deterioration within 30–60 minutes (oral immediate-release plasma half-life is roughly 90 minutes). Treat medication reminders as clinical events with a delivery contract.

• Delivered on time. Use iOS 15+ time-sensitive notifications to escape Focus / Do Not Disturb batching.
• Multi-channel. Audio plus haptic plus visual delivery, so a missed channel doesn’t mean a missed dose.
• Acknowledged. Track whether the reminder was dismissed or the dose logged. Escalate to the caregiver on miss.
• Adjustable. PD medication schedules change frequently. Push notification timing edits live in the same motor-accessible UX as the rest of the app.

The compliance stack for Parkinson’s app development

Five pieces sit on this stack: FDA classification, IEC 62366 human factors, IEC 62304 lifecycle, HIPAA, and state health data laws. Two reshape the standard work for PD: the Parkinson’s app compliance FDA pathways and the HFE requirement.

FDA classification examples for Parkinson’s apps

The classification depends on what the app does with the data. Full framework in our Is my health AI a medical device? breakdown. PD-specific examples:

• Medication diary + on/off log, no clinical output: non-device.
• Gait training exercise library, no clinical assessment: non-device.
• Apple Movement Disorder API output as a raw trend for a neurologist’s independent interpretation: CDS-exempt.
• Apple Movement Disorder API output analyzed into a motor severity score for the patient: SaMD. Two 510(k)-cleared examples: StrivePD (Rune Labs, K213519, June 2022) and Parky (h2o therapeutics, K220820, November 2022, predicate is StrivePD).
• Medication timing recommendations from wearable motor data: SaMD.

Digital biomarker FDA review runs via 510(k) where there’s a predicate (StrivePD, Parky) or De Novo for novel categories without one. FDA Breakthrough Device Designation can apply to either pathway when the condition is serious.

Once a pathway is open, the second mover cites substantial-equivalence and ships faster; Parky did exactly this. More on when an RPM app becomes a medical device if motor monitoring is your archetype.

Human factors engineering with Parkinson’s patients across disease stages

FDA’s IEC 62366 / HFE guidance requires usability testing with the actual intended user population. For a PD app classified as SaMD, that means PD patients across disease stages running the prototype.

PD-specific UX decisions don’t verify on a non-PD population. Plan formative usability from the first prototype and a summative usability study for submission. HFE built at the end is a submission artifact a reviewer can spot.

IEC 62304 lifecycle requirements for SaMD-classified features

Any PD app classified as SaMD needs IEC 62304 software lifecycle documentation, paired with ISO 14971 risk management. Motor monitoring built on the Apple Movement Disorder API is likely Class B or Class C, depending on the harm severity analysis. A software failure producing an incorrect motor score that leads to a medication change is at minimum Class B. Full breakdown in IEC 62304 compliance.

HIPAA, neurological data privacy, and the Washington MHMDA layer

Standard HIPAA applies when a covered entity or BA handles PD diagnosis and symptom data. The PD-specific layer: neurological condition data carries heightened sensitivity for employment and insurance discrimination. Tremor waveforms and gait signatures are biometric in practice and hard to de-identify; factor that into retention. Full framework in HIPAA compliant software development.

Outside HIPAA’s reach, Washington’s My Health My Data Act covers non-HIPAA health data, effective March 31, 2024 (geofencing prohibition since July 23, 2023). Private right of action. Consumer deletion right with no statutory exception. That’s the operational risk. Nevada and Connecticut have followed.

Related: Healthcare App Development Guide

The build roadmap in three stages

How to build a Parkinson’s app comes in three stages: V1 patient self-management, V2 clinical data and wearables, V3 care coordination. Your archetype decides how deep down the stack you go.

V1: patient self-management core (12–16 weeks)

• Medication diary with flexible reminder scheduling (iOS 15+ time-sensitive notifications)
• On/off motor state diary, one-tap entry, timestamped
• Symptom tracker, MDS-UPDRS-aligned on the key motor and non-motor entries
• Caregiver portal (view-only access, notification routing)
• Motor-accessible UX from day one (touch target sizing, auto-save, no swipe nav)
• HIPAA-compliant infrastructure (BAA chain, encryption, access controls, audit logging). Full framework in HIPAA compliant app development.
• iOS first (Apple Watch + Apple Movement Disorder API opportunity; PD population skews iOS in practice)

V2: clinical data and wearable integration (3–6 months post-V1)

• Apple Movement Disorder API integration (tremor + dyskinesia passive monitoring)
• HealthKit on iOS, Google Health Connect on Android (sleep and activity correlation)
• Basic clinician dashboard, trend view of medication timeline × motor state × sensor data
• PRO collection: PDQ-39, FOG-Q for validated patient-reported outcomes
• Correlation visualization (the clinical value view from the data architecture section)
• Android build to expand population reach

V3: care coordination and enterprise (6–12 months post-V2)

• EHR write-back via FHIR (MedicationStatement, Observation for motor data)
• SMART on FHIR launch for Epic and Cerner neurologist workflow
• Telehealth integration for remote movement disorder visits
• Exercise therapy library (gait training, balance exercises)
• Multi-patient dashboard for neurology practice panel management
• FDA regulatory pathway assessment if V2 motor monitoring features cross into SaMD

Timelines assume a non-SaMD V1. SaMD scope at V2 extends the V2 window materially. Experienced healthcare app developers familiar with PD-specific UX and the Apple Movement Disorder API can compress these timelines meaningfully.

Why choose Topflight for Parkinson’s app development

Topflight builds HIPAA-compliant health apps for specific clinical populations, Parkinson’s included. The patient’s clinical reality determines UX requirements, sensor integrations, data architecture, and the compliance stack. That’s a different starting point than general mobile app best practices, and it’s where neurological condition app development diverges from the standard health app stack.

What we bring to Parkinson’s app development

• Motor-accessible UX design: touch target sizing for tremor compensation, on/off state UX, session auto-save architecture, and tremor-aware interaction patterns built for the patient’s worst motor day.
• Apple Movement Disorder API integration and watchOS development on Apple Watch Series 4 and later.
• HealthKit and wearable data integration for motor correlation, including clinical-grade third-party platforms.
• HIPAA-compliant architecture with the neurological data sensitivity protections PD diagnosis data warrants.
• EHR integration (FHIR R4, SMART on FHIR) for clinical coordination platforms and neurologist workflow embedding.
• IEC 62304-compliant development paired with ISO 14971 risk management for SaMD-classified features.
• Human factors engineering coordination for FDA submissions requiring PD patient usability studies across disease stages.

Building a Parkinson’s care app? Talk to Topflight about your archetype and target buyer before your first design sprint. Bring the compliance picture specific to your feature set too. That’s how we approach movement disorder app development across both consumer-facing and clinical-grade builds.