Proposed web application · supports Phase I–III of the thesis
PRĀṆA–PD Research Platform
A web application that turns the thesis's 24-week schedule, minimum data dictionary and safety requirements into one coded, auditable data pipeline: a participant app, a clinician dashboard, and a research console, all fed by the research device kit. It measures and displays. It does not diagnose, advise treatment, or change anything about a person's care.
What exists today, and what does not. The clinician dashboard, the signed device-ingest API, scoring with intervals, alert rules, CSV export, and a signed-device simulator are built and tested on synthetic data. The participant app, clinician accounts and roles, consent workflow, and the hardware are designs only. The prototype must not receive real participant data until the gaps listed at the bottom are closed and an ethics committee has approved the study.
Design rules taken from the thesis
- Five domain scores, never one. Each with an interval and a completeness figure. No headline number is computed.
- Respiration counted once. Resting respiratory rate and SpO2 feed Prāṇa only; Udāna uses voice and swallowing indicators, avoiding the double-counting the thesis warns about.
- Ayurvedic constructs stay separate. They are entered by trained assessors after standardisation and are not folded into any score.
- Medication state is a first-class field (ON / OFF / not applicable) on every motor and voice reading, with a filter in the dashboard.
- No treatment advice. No medication, herb, or exercise-intensity suggestions anywhere. Alerts go to a clinician, not to the participant as instructions.
- MDS-UPDRS is not reproduced. The platform has a field to record a total and part scores entered by a licensed, trained rater; it never displays or administers the items. Licensing with the International Parkinson and Movement Disorder Society is required before any digital use of the scale.
- Coded identifiers and minimal data. Study ID such as PRA001; no names, phone numbers or addresses in the research database; every admin read and action is written to an audit table.
- Hypotheses drive what is stored. Fields exist because H1–H7 need them, not because a sensor can produce them.
Three surfaces
1 · Participant app (PWA)
Designed — only the Sākṣī mirror exists (open it).
- Large-type, high-contrast, low-tap flows; usable with tremor; caregiver-assist mode.
- Weekly Sākṣī mirror: five self-ratings, kept separate from measurements.
- Short diaries: bowel and nocturia, GI burden, EAT-10 swallowing screen, choking events, ON/OFF state, falls, patient-defined goal.
- Guided tasks with plain-language steps: 2-minute seated rest, sustained "aaah", weekly walk-and-turn, standing blood-pressure routine only if cleared by the clinician.
- Always-visible "Contact the study team" and "If you choke, fall, faint or feel very unwell, get urgent medical help" panel. The app is not an emergency service and says so.
- Offline-first: entries queue on the phone and sync later; the phone is also the Bluetooth gateway for the kit.
- Consent shown in simple language; withdrawal in two taps; data-handling choice follows the signed consent.
2 · Clinician dashboard
Built as a read-only prototype: open the demo.
- Five domain scores with intervals, completeness, and the medication-state filter.
- 24-week trend and the four thesis visit windows (baseline, weeks 8, 16, 24).
- Measured versus felt: Sākṣī self-rating against measured domain, flagged at a 25-point gap as a discussion prompt only.
- Alert queue with acknowledge-and-note; alerts are rules, not predictions.
- Data-quality strip: device last seen, stale days, share of low-quality readings.
- Designed, not built: accounts with roles, visit-note entry, licensed-rater score entry, goal tracking, printable visit summary.
3 · Research console
Partly built (provisioning, withdrawal, seed, CSV export).
- Provision a coded participant and a set of devices with per-device keys (shown once).
- Withdraw a participant: ingest stops and devices are revoked.
- CSV export with units, medication state, quality flag and score-algorithm version in every row.
- Designed, not built: data-dictionary editor with versioning, rater-agreement forms, missing-data reports per domain, adverse-event register, locked-dataset snapshots, stage-gate reports.
Architecture
Wrist/gait sensor ─┐ ┌────────── Clinician dashboard (web)
Home station ──────┤ BLE HTTPS + HMAC │ five domains + CI, alerts,
Smart scale ───────┼──► Phone ──────────────────────► Edge API ──┤ ON/OFF filter, measured-vs-felt
Pillbox ───────────┤ (PWA signed batches (Hono / │
Diary + Sākṣī ─────┘ gateway, seq numbers, Workers) ├────────── Research console (provision, export)
offline idempotent │
queue) D1 (coded participants, readings, alerts, audit)
R2 (optional: derived feature files, exports)
Cloudflare Workers with D1 (and optionally R2) is enough for this load: readings are small, batches are signed JSON, and scoring is arithmetic done at read time. Heavy signal processing (gait, tremor, voice features) happens on the device or the phone, so the server only receives derived indicators with a quality flag — which is also what keeps raw voice and raw motion traces off the server.
Mapping to the thesis schedule (Appendix B)
| Thesis element | Platform support | Status |
|---|---|---|
| Consent, eligibility, demographics | Consent record with version and time; minimal demographics only when justified | Schema field only |
| Medication list, timing, ON/OFF state | Pillbox timing, per-reading ON/OFF, dose-delay context; LED-equivalent supplied by clinician, not computed here | Built (readings); entry UI designed |
| Five-domain clinical measures | Device and diary indicators between visits; clinic measures entered at visits for comparison | Device side built; clinic entry designed |
| MDS-UPDRS / PDQ-39 | Result entry by licensed rater only; no item display | Designed; licence required |
| Ayurvedic construct assessment | Separate assessor form after standardisation; excluded from scoring | Designed |
| Adverse events and falls | Fall candidate, choking report, alert rules R1–R6, acknowledge-with-note; formal AE register | Alerts built; AE register designed |
| Rehabilitation and adjunct exposure | Type, frequency, adherence log (participant and therapist) | Designed |
| Patient-defined goal | Goal capture and review prompts at weeks 8 and 16 | Designed |
What each hypothesis needs from the platform
| Hypothesis | Platform output |
|---|---|
| H1 Feasibility | Completion, missingness and wear-time per domain and per week; device uptime; retention. This is the platform's first and most important job. |
| H2 Construct validity | Clean long-format export with indicator, unit, instrument and algorithm version for factor analysis outside the platform |
| H3 Clinical association | Domain scores beside licensed-rater clinical scores in one export |
| H4 Coordination validity | Weekly repeated measures with timestamps and recorded disturbances (falls, illness, medication changes) — the regressors the identification study showed are needed |
| H5 Prediction | Locked dataset snapshots with a frozen algorithm version for out-of-sample testing |
| H6 Adjunct feasibility | Adherence, adverse events, protocol deviations, retention |
| H7 Exploratory benefit | Not addressed by this platform; needs a later adequately powered trial |
The platform does not estimate the coordination reserve ρ or the coupling matrix. That belongs in offline analysis after Phase I, using the identification caveats on the code page.
Alert rules (research defaults, clinician-configurable)
| Rule | Trigger | Severity |
|---|---|---|
| R1 | Standing systolic drop ≥ 20 mmHg | review |
| R2 | Nocturnal mean SpO2 below 90 % | review |
| R3 | Possible fall detected | urgent |
| R4 | Participant reports choking or coughing at a meal | urgent |
| R5 | Weight ≥ 5 % below the median of ~4 weeks earlier | review |
| R6 | Resting respiratory rate above 25 per minute | review |
These thresholds are placeholders for the study clinicians to set in the protocol. "Urgent" means a clinician sees it at the next check of the queue; it does not mean the system is monitored around the clock. A real study must state who reviews alerts, how often, and what happens out of hours — and tell participants plainly that the kit is not an emergency alarm.
API (implemented)
| Route | Access | Purpose |
|---|---|---|
POST /api/platform/device/ingest | Device HMAC | Signed batch of readings; validated, de-duplicated by (device, seq), alerts evaluated |
GET /api/platform/catalog | Public | Metrics, units, ranges, domains, rules |
GET /api/platform/participants/:id/profile | Public for synthetic, admin for real | Domains with intervals, series, visits, discordance |
GET /api/platform/participants/:id/alerts | same | Alert list |
GET /api/platform/participants/:id/export.csv | same | Long-format export |
POST /api/platform/alerts/:id/ack | Admin | Acknowledge with name and note (audited) |
POST /api/platform/admin/provision, /admin/participants/:id/withdraw, /admin/seed | Admin | Provision coded participant and devices; withdraw; seed synthetic demo |
GET /api/platform/demo/participants | Public | Synthetic participant list |
Ingest checks, all exercised by tests
- HMAC-SHA256 over the raw body, constant-time compare; unknown device and bad signature return the same 401.
- Replay of the same (device, seq) returns the original result and stores nothing twice.
- Each reading is validated: known metric, allowed for that device kind, finite number, inside physiological range, integer timestamp not in the future or older than 90 days, valid medication state and quality. Rejected readings are counted and reported back, never silently stored.
- Limits: 256 KB per body, 500 readings per batch; withdrawn participants and revoked devices are refused.
Gaps to close before any real participant
- Authentication. The prototype has one shared admin token. A study needs per-user accounts, roles (clinician, researcher, administrator, auditor), multi-factor sign-in, and session management.
- Key handling. Device secrets are stored in the database in readable form for the prototype. Use a secrets vault or envelope encryption, secure elements on devices, and a rotation procedure.
- Abuse controls. Rate limiting and alerting on repeated failures are not implemented.
- Consent and rights. Consent workflow, withdrawal handling beyond stopping ingest, data-subject requests, retention and deletion schedules, and a privacy impact assessment under the applicable Indian data-protection law and ICMR guidance.
- Clinical governance. Ethics committee approval, trial registration, a named alert-review owner, an adverse-event register and an independent safety monitor if any intervention is added.
- Validation. No device indicator should enter a score until it passes pre-specified agreement and test–retest criteria (see the device page). Until then it is stored as context.
- Scoring. The transforms and equal weights are illustrative; Phase I replaces them with factor-analytic and expert-reviewed versions.
- Backups, monitoring, disaster recovery, and an audit-log review procedure.
- Regulatory check. Ask the ethics committee and the relevant regulator whether the assembled kit and software count as an investigational medical device for the intended use.