ParkinSync

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 contributes medication and daily-condition events; GutPacer contributes bowel and related care events. The intended boundary is a versioned care-event export into ParkinSync — not a direct database link between products.

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, and putting a person at the boundary where raw observations become records, is a deliberate product decision — not a limitation worked around.

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 OCR step is deliberately not trusted to auto-fill records. Amazon Textract validates the form’s structure, but a human operator verifies the transcription before anything is synced to the ledger — OCR is supporting infrastructure, not the final authority. This “garbage-in” guard is what keeps the dataset clean enough to analyze.

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.