Wearable health data
Wearable Health Data on FHIR
Wearables generate dense streams of biometric and activity data. The FHIR-native pattern is to land the data as Observation tied to a Device, decide on raw-vs-summary granularity per use case, and apply the same access model to wearable data as to any other clinical input.
What you can build
- Standard FHIR shape for wearable data
Observation with code, value, effective time, performer Device, subject Patient. No bespoke schema for wearable input.
- Raw vs summary granularity is a deployment decision
Daily summaries fit clinical review; minute-level data fits research or alerting. Both can coexist with the right resource and access strategy.
- Consumer-vs-clinical distinction is captured in Device
Device.type and Device.manufacturer record the source. Reviewers can filter by source when interpreting the data.
What you get out of the box
Who this is for
Product teams integrating Apple HealthKit, Google Health Connect, or clinical wearables into a FHIR backend, and clinical informatics leads evaluating the data shape.
Clinical applicability
A cardiology program ingests heart rate and HRV from patient wearables. The patient app uploads daily summaries to FHIR; the clinician sees trends through a dashboard that queries the Observation history.
Granularity decisions
A consumer wearable can produce thousands of data points a day. Persisting all of them as discrete Observations works but is rarely what the clinical view needs. The common pattern is to write daily summary Observations (averages, counts, totals) for clinical use and keep the raw stream in either a separate analytics store or the same backend with reads scoped to research or research-equivalent roles.
Some signals (HRV episodes, fall events) are inherently event-based and land as discrete Observations or as conditional Observations triggered by client-side detection. The Device resource records which source produced the event, which matters for clinical interpretation.
Consumer vs clinical sources
Consumer wearables are useful for trend visibility but are not regulated medical devices. Device.type captures the distinction so a clinician interpreting the data understands what they are looking at.
Clinical wearables (continuous glucose monitors, cardiac event monitors) typically require additional handling: tighter access controls, retention rules driven by the device's regulatory status, and integration with the device manufacturer's own platform. Both fit the same FHIR shape; the difference is in the rules and retention configuration.
Patient ownership and consent
Patients write their own wearable data through their app. The Patient role has create and update permissions on Observations they own, scoped through PatientCompartment.
Clinical visibility of patient-owned data is opt-in. A consent record (Consent resource) tied to the patient determines whether the clinician role can read the wearable data. The consent change flips the access decision; no separate sharing toggle needed.
Related docs
FAQ
How do I integrate Apple HealthKit?
The patient app reads HealthKit values and writes them to Fire Arrow as Observations through the patient identity. HealthKit-specific handling lives in the app; the FHIR backend sees standard Observations.
What about Google Health Connect?
Same pattern. The Android app writes Observations on submit; the FHIR backend is health-platform-agnostic.
How do I prevent the wearable data from drowning the clinical view?
Filter the clinical view to summary Observations or to specific codes. The raw stream is available for research roles and for ad hoc investigation; it does not have to surface in the routine clinical UI.
Can wearable data feed a research dataset?
Yes. Research roles can read the relevant Observations through property filters that strip identifiers. The patient's consent for research use is the access gate.
