Case Study · Healthcare Research
Stanford Wearable Health AI
AI health intelligence platform for Stanford University’s Center for Genomics and Personalized Medicine — wearable sync, vitals aggregation, and encrypted de-identified data for clinical research. Live since 2020.
The Problem
Stanford’s SCGPM research teams needed a single mobile platform to enroll participants across multiple clinical studies — from COVID wearable validation to TRAC pain and wellness programs. Each study required continuous vitals from diverse devices, but data arrived in incompatible formats: Apple HealthKit exports, Fitbit OAuth APIs, Bluetooth LE streams from Oura and Polar, and manual glucose entry.
Early versions forced participants to keep the app open for 20+ minutes during initial sync, causing drop-off and poor App Store reviews. IRB requirements demanded de-identified, encrypted transfer with no PHI linked to research datasets. The platform also needed modular survey engines — different studies, different schedules, one app.
The Dataset
MyPHD normalizes high-resolution wearable streams into a unified research schema:
- Cardiovascular: Heart rate, resting HR, HRV intervals (including higher-resolution RR intervals), blood pressure, ECG waveforms from Apple Watch and compatible devices
- Activity: Step counts, distance, active energy — from HealthKit and Fitbit with deduplication across sources
- Sleep: Total sleep, REM, deep sleep stages, sleep onset/offset — merged from HealthKit, Fitbit, and Oura
- Metabolic: Blood glucose values (manual entry + CGM where available), SpO2 readings
- Contextual: Location (background, study-configurable), survey responses, medication and risk-factor questionnaires per IRB protocol
Model & Approach
- Unified ingestion layer: Adapter pattern per data source — HealthKit observers, Fitbit OAuth refresh pipeline, CoreBluetooth GATT parsers — all writing to a normalized local store with source attribution and conflict resolution.
- Multi-level encryption: AES-256 for data at rest in encrypted Core Data stores, Keychain-backed participant keys, TLS 1.3 for upload. De-identification strips direct identifiers before server transfer per study IRB specs.
- Background sync engine: Chunked historical backfill with resumable checkpoints, delta sync for incremental updates, and BGTaskScheduler for off-foreground uploads. API timeout handling with exponential backoff.
- Modular study framework: Study-specific enrollment keys, survey schedules (daily check-ins, discharge surveys, TRAC pain modules), and dashboard views configured server-side without app resubmission for each new protocol.
- Personal health dashboard: Participants see their own vitals locally — heart rate trends, sleep breakdown, step counts — building trust and adherence while research data flows separately.
Architecture
Native Swift/SwiftUI iOS app → ingestion adapters (HealthKit, Fitbit Web API, CoreBluetooth) → normalization & deduplication engine → encrypted local store (Core Data + Keychain) → background upload queue → Stanford research API gateway → study-specific analysis pipelines.
Push notifications drive survey reminders and sync status. Server-side study configuration controls which data types, surveys, and schedules apply per enrolled participant. iPad and visionOS compatibility extends the same codebase with adaptive layouts.
Deployment
Launched on the App Store in 2020 for Stanford’s wearable validation studies. Phased rollout across study cohorts with enrollment key authentication. Continuous iteration through 100+ App Store releases (currently v10.4.0) — adding TRAC study modules, REM/deep sleep granularity, HRV interval resolution, Fitbit step algorithm updates, iOS 26 compatibility, and iPad survey fixes.
App Store privacy nutrition labels configured for health data not linked to identity. Participant support channel integrated for study enrollment issues.
Results
Business Impact
Eliminated manual data collection across Stanford’s multi-study wearable research program — researchers previously spent hours reconciling CSV exports from Fitbit, Apple Health, and Bluetooth devices. Automated ingestion cut per-participant onboarding from days to minutes. Survey completion rose from 58% to 84% with push-driven reminders and streamlined daily check-in flows. The platform has supported 6+ years of continuous production use across evolving study protocols without requiring participants to switch apps.
Why It Was Hard
Every wearable speaks a different protocol. HealthKit delivers observer queries with batch limits; Fitbit rate-limits OAuth token refresh; Bluetooth LE devices disconnect mid-stream. Normalizing sleep stages across Apple Watch (sleep analysis categories), Fitbit (sleep levels API), and Oura (readiness scores) required a canonical sleep model with source-priority rules.
Research compliance added constraints beyond typical consumer apps: de-identification had to happen on-device before upload, enrollment keys tied participants to studies without exposing identity in transit, and App Store review required precise privacy label declarations for background location and health data access.
What We Learned
Participants abandon apps that hijack their phone. Moving sync to true background execution — with visible progress only when requested — was the single biggest retention improvement. Resumable chunked uploads turned a 20-minute foreground blocker into a 4-minute background process.
Showing participants their own dashboard data builds study adherence. When people can see their heart rate and sleep trends locally, they trust the app enough to complete daily surveys and keep wearables charged. Transparency and research integrity aren’t opposing goals.
FAQ
What wearable devices does MyPHD support?
Apple HealthKit (Apple Watch and compatible apps), Fitbit via OAuth, Bluetooth LE devices including Oura ring and Polar Beat, plus manual entry for glucose and clinical vitals. The platform normalizes 12+ data source types into a unified research schema.
How is participant privacy protected?
AES-256 encryption at rest, TLS 1.3 in transit, and on-device de-identification before upload. App Store privacy labels reflect health data collected but not linked to user identity for research analysis.
Can the app sync in the background?
Yes. Background App Refresh and BGTaskScheduler handle incremental sync. Initial historical backfill was optimized from 20+ minutes to under 4 minutes through chunked uploads, delta sync, and API timeout handling.
Have aSimilarChallenge?
Tell us about your wearable health, research, or clinical study app project.