ParkinSync
From caregiver paper logs to analysis-ready evidence
Motor symptoms in Parkinson’s Disease are often reported to shift with environmental factors like temperature and barometric pressure — but everyday care tools rarely capture that context next to the caregiver’s own observations. ParkinSync is a serverless data pipeline that collects both streams, synchronizes them by date, and produces a tidy, analysis-ready dataset.
It is honest about its scope: this is exploratory data work on limited, anonymized data — not a diagnostic tool. The whole project is open source, including the test suite and deploy scripts.
Research direction: preserve meaning before adding automation
ParkinSync is also the research layer for a broader VEAI care-data experiment. Medication Promise records medication and daily-condition events; GutPacer records bowel and related care events. Future ingestion is intended to use versioned care-event exports. ParkinSync does not currently ingest these products’ production exports or directly connect their databases.
The current FHIR work is synthetic and offline. It tests how far patient-, caregiver-, and environment-generated observations can be represented while retaining timestamps, missingness, actor role, consent scope, and source-event provenance. It does not claim a live FHIR or EHR integration, clinical validation, or a complete national-profile implementation.
The research question is not simply “can ParkinSync use FHIR?” It is whether a home-care data model can remain understandable and reusable when observations from different people and products are exchanged. That boundary-first work supports future interoperability research without turning the current prototype into a diagnostic or prediction service.
Design constraint: don’t make the caregiver change
The caregiver keeps writing on the structured paper form they already use — no new app to adopt. Paper logs are scanned to S3 and transcribed; the pipeline enriches them with weather and indoor-temperature telemetry and normalizes everything into a fixed 25-column schema. Keeping the human paper workflow intact is a deliberate product decision. The current OCR handler appends rows automatically; an operator needs to review those rows after import before using them for analysis.
Architecture
Caregiver paper log ──[scan / upload]──▶ AWS S3 (ingestion staging)
│
├─ S3 event ▶ Lambda: ParkinSync_OCR_Handler (Python 3.12)
│ ├─ Amazon Textract (form key-value extraction)
│ ├─ Visual Crossing API (historical weather by log date)
│ └─ Google Sheets API v4 (append verified row to ledger)
│
└─ EventBridge cron (every 3h) ▶ Lambda: ParkinSync_IndoorTemp_Logger
└─ SwitchBot Open API (indoor temp/humidity)
└─ Google Sheets API v4 (staging tab; sheet formulas
compute daily avg/min/max — no extra serverless cost)
Master ledger (Google Sheets, 25-column schema)
└─ Amazon SageMaker (Pandas/NumPy/SciPy: Pearson r, lag analysis)
Secrets: AWS Secrets Manager · IaC: deploy.sh (bash)Two decoupled Lambda functions: one event-driven (a scan lands in S3), one schedule-driven (indoor telemetry every 3 hours). They never call each other — they meet only at the shared Google Sheets ledger, which keeps each side independently testable and deployable.
Human-in-the-Loop OCR
The current OCR handler uses Amazon Textract to extract table cells and automatically appends normalized rows to Google Sheets. It then asks an operator to review the imported rows. Human review is an operational responsibility after import; the code does not enforce approval before writing to the ledger. A successful import does not establish that the transcription is correct or ready for analysis.
Tech stack
| Layer | Choice |
|---|---|
| Compute | AWS Lambda (Python 3.12), 2 decoupled functions |
| Scheduling | Amazon EventBridge (3-hour cron) |
| OCR / audit | Amazon Textract |
| Secrets | AWS Secrets Manager |
| Aggregation | Google Sheets API v4 |
| IoT polling | SwitchBot Open API |
| Weather enrichment | Visual Crossing Weather API |
| Analytics | Amazon SageMaker · Pandas / NumPy / SciPy |
| Deploy | deploy.sh (bash, aws lambda update-function-code) |
Also a product-management portfolio
ParkinSync doubles as a working PM artifact — a research-driven data product built solo and AI-assisted, delivered with evidence-first, boundary-aware discipline:
- Evidence-based delivery — the deliverable is a reviewable, analysis-ready dataset, and the project is explicit about what it does not claim.
- Stakeholder management — preserves the caregiver’s paper workflow while producing structured data for whoever reviews it later.
- Agile in practice — a live GitHub Project — ParkinSync Delivery and issues track experiments, decisions, and tasks.
Tested
Python unittest covers the weather integration (happy path + graceful degradation on network failure), the condition-to-emoji mapping, and the handler’s HTTP 404 path when Textract finds no table. A set of dependency-free analytics scripts audit the 25-column schema, build model-ready features (timing, lag, rolling, thermal), and generate weekly caregiver review notes.
The repository is public — github.com/larai-w/ParkinSync.
Open-source collaboration
This product is developed publicly. Review the code, report issues, and propose improvements on GitHub.
Small, focused PRs with a short verification plan are easier to review.
