Health Data Aggregator Across Wearables

A privacy-conscious data project that pulls health and activity data from the wearable sources a user actually owns — a fitness watch, a phone’s health app, a sleep device — and normalizes them into one unified personal data model: activities, sleep, heart-rate trends, and step counts with consistent units and timestamps. The result is a single local-first view with provenance (which device reported what), export/delete controls, and an architecture that treats health data as sensitive by default.

>This is a data aggregation and visualization project, not a medical system. Device measurements vary by source and by how each device estimates them; aggregation does not establish medical truth. This application does not diagnose conditions, does not provide treatment recommendations, and never presents aggregated numbers as clinical facts.

Who Is This For?

• Quantified-self users who wear multiple devices and want one private, unified view of their own data
• Developers of health apps who need to understand wearable-API normalization and privacy architecture
• Data-science students who want a real ETL-style project with messy, real-world device data
• Privacy-minded builders who want to practice consent-first, minimum-data, export/delete design on the most sensitive data category there is

The Problem

Every wearable vendor silos its data in its own app with its own units, update cadence, and export format. Users who own two devices have two dashboards, two sets of numbers that disagree, and no way to see a unified picture — and most “aggregator” apps respond by copying everything to a cloud server the user doesn’t control. The missing project is a local-first aggregation layer: adapters that normalize each vendor’s API into a common model, provenance that remembers where every number came from, and privacy controls (consent, retention, export, delete) built in from the start.

How It Works

1. Connect a Source with Consent

The user links a wearable source through its official API (OAuth where offered). The connection flow explains exactly what data will be read and why, stores the token securely (server-side vault or OS keychain), and never touches data the app doesn’t need.

2. Normalize Into a Common Model

Each source adapter maps vendor records into a shared schema: metric type (steps, sleep stages, heart rate, activity), value, unit, start/end timestamps, timezone handling, and provenance (source, device model, ingestion time). Units are converted to canonical forms (meters vs miles, beats-per-minute), and vendor quirks (sleep logged as minutes vs stages) are documented per adapter.

3. Handle Duplicates, Gaps, and Conflicts

The ingest pipeline deduplicates overlapping records (the same step count synced twice), marks missing intervals explicitly rather than inventing values, and resolves conflicting records with a documented precedence rule (for example, the most recent sync wins, with the older record retained as provenance). Every record keeps its source so “why do my two watches disagree?” is answerable.

4. Provide a Unified View and Export

A simple dashboard shows the normalized picture — daily steps, sleep windows, resting-heart-rate trend — with per-metric source breakdown. Export produces the full normalized dataset (CSV/JSON) with provenance columns; delete removes everything in one action.

5. Sync Is Optional and Consent-Gated

The MVP is local-first: no account, no server. Optional sync (for multi-device use) is opt-in, encrypted in transit and at rest, and documented with its third-party risks. The default posture is that health data stays on the user’s device.

Key Features

• Source adapters — pluggable connectors with per-vendor normalization and documented quirks
• Unified data model — canonical metrics, units, timestamps, timezone handling
• Provenance on every record — source, device, ingestion time, precedence on conflicts
• Duplicate and gap handling — dedupe, explicit missing intervals, documented conflict resolution
• Local-first storage — no server required for the MVP; sync opt-in and consent-gated
• Export and delete — full dataset export with provenance; one-tap wipe

Functional Requirements

User Stories

• As a multi-device user, I want one dashboard showing steps from my watch and phone reconciled by rules I can see, so that I stop comparing two apps by hand.
• As a privacy-conscious user, I want my data local by default, with sync clearly optional, so that my health numbers aren’t shipped to a third party as a side effect.
• As a developer, I want each vendor adapter isolated and documented, so that adding a new wearable doesn’t destabilize the pipeline.
• As a user, I want to know why my watch and phone disagree on sleep, so that provenance answers the question instead of hiding it.

MVP Scope

Additional vendors, trend analytics, optional encrypted sync, and wearable-action automation are natural second-phase additions.

Project Timeline

• Phase 1 — Data model and storage (Week 1): Canonical schema, provenance columns, storage layer.
• Phase 2 — First adapter (Weeks 2–3): OAuth/consent flow, pull, normalize, ingest with tests against recorded fixture responses.
• Phase 3 — Pipeline correctness (Week 4): Dedupe, gap marking, conflict precedence, and unit conversion tests.
• Phase 4 — Second adapter + view (Week 5): Second vendor, unified dashboard with source breakdown.
• Phase 5 — Privacy surface (Week 6): Export, delete, token vault hardening, docs, and a personal pilot with the developer’s own (consented) data.

Testing Strategy

• Normalization tests — fixture payloads from each vendor map to the exact canonical records (units, timestamps, timezones).
• Dedupe/gap tests — overlapping syncs collapse to one record; missing intervals are flagged, never fabricated.
• Conflict tests — the documented precedence rule produces the expected winner and preserves the loser’s provenance.
• Token tests — tokens are never logged, never in plaintext storage, and never included in export payloads.
• Privacy tests — delete removes every user record including cached API responses; export contains no tokens.
• Adapter-isolation tests — a failing vendor adapter degrades that source only; other sources remain available.

Security and Privacy Considerations

• Health data is sensitive data. The MVP is local-first: minimum necessary data, no server, no analytics, no third-party SDKs silently touching health records.
• Consent is explicit. Each source connection states what will be read and why; the user can revoke a source at any time, which also deletes that source’s records if requested.
• Tokens are secrets. OAuth tokens live in the OS keychain (or an encrypted server vault for hosted sync); credentials never appear in logs, exports, or configuration files.
• Encryption. Local storage is encrypted where the platform allows; any optional sync is encrypted in transit and at rest.
• Third-party risks are documented. Vendor APIs have their own privacy policies and failure modes; the app’s docs explain what is shared with whom when a source is connected.
• No clinical claims. The app does not diagnose, treat, or recommend; aggregated values are explicitly not medical facts, and measurement variance across devices is documented.
• Retention and deletion. Retention is minimized by design; export and one-tap delete are first-class features.

Success Metrics

• A personal pilot: the developer links two real sources and views a reconciled unified week of their own data.
• Normalization accuracy: fixture-based adapter tests pass with exact canonical output for every seeded vendor payload.
• Provenance completeness: every record in the export carries source/device/ingestion columns; none are missing.
• Privacy audit: token values and raw health records appear in zero log outputs; delete removes 100% of user records in tests.

Common Challenges

• Vendor API rot — wearable APIs change and rate-limit; adapters are isolated so a broken vendor degrades only itself, and fixtures keep tests stable.
• Units and timezones — the classic normalization trap; canonical units plus explicit timezone handling are the core of the data model, not an afterthought.
• Device disagreement — two devices estimating the same metric differ; provenance and conflict rules turn this into a feature (“here’s why they differ”) instead of a data-quality hole.
• Scope creep toward a health platform — clinical features, coaching, and analytics are enormous; the MVP is a correct aggregation layer with honest boundaries.
• Permission fatigue — health APIs demand broad scopes; the consent flow requests minimum scopes and explains each one.

Learning Objectives

• Design a normalized, provenance-aware data model for messy multi-source data.
• Build vendor adapters with unit conversion, timezone handling, and documented quirks.
• Implement dedupe, gap-marking, and conflict-resolution pipelines with tests.
• Practice privacy-by-design: minimum data, explicit consent, secure token handling, export/delete.
• Learn to write honest health-data content: no clinical claims, no fabricated measurements, no guaranteed outcomes.

Why This Idea Is Different

This is the site’s first quantified-self and device-data project, and it deliberately sits apart from the clinical health cluster: the Medical Dataset Explorer for AI Researchers and the Medical Image Annotation Tool for Researchers serve research workflows on de-identified clinical data, while this project aggregates a user’s own wearable data for personal visibility — an entirely different audience, data source, and consent model. Architecturally it mirrors the local-first privacy shape of the Offline-First Note-Taking App (data on device, sync optional and consent-gated) and the transparency values of the Cookie Consent Enforcement Extension: it is a privacy-first integration layer, not another health app that uploads everything to a server.

What Similar Tools Exist

| Tool type | Approach | Limitation |
|———–|———-|————|
| Vendor apps | Single-source dashboards | Siloed; units differ; no unified view |
| Commercial aggregators | Cloud sync of many sources | Data leaves the device; opaque retention |
| Fitness platforms | Social + analytics | Focus on social/competitive features |
| Manual spreadsheet export | CSV joins by hand | Error-prone; no provenance; not repeatable |

This project’s differentiators: local-first default, provenance on every record, documented conflict rules instead of silent overwrites, and privacy controls (consent, export, delete) as core features.

Technology Stack

• JavaScript/TypeScript — app and adapters
• Vendor APIs (OAuth) — wearable/health data sources
• SQLite (or IndexedDB) — local canonical storage
• OS keychain / encrypted vault — token storage
• Simple dashboard UI — unified view with source breakdown
• pytest or Vitest — normalization and pipeline tests

Future Enhancements

• Additional vendor adapters behind the documented interface
• Optional end-to-end-encrypted sync (consent-gated, documented third-party risks)
• Trend analytics with explicit “not medical” labeling
• Data-quality report per source (gap rates, sync freshness)
• Wearable-action automation (opt-in, user-configured)

Related Ideas

• Real-Time IoT Dashboard Builder — the device-data visualization cousin; this project adds health-data sensitivity and provenance
• Offline-First Note-Taking App — the same local-first, optional-sync architecture applied to notes
• Cookie Consent Enforcement Extension — the site’s privacy-transparency standard, applied here to health data

Browse more Product Ideas · Intermediate Ideas