FHIR Wearable Integration and Data Modeling

Almost every wearable measurement becomes an Observation. For vital signs, the Observation conforms to the FHIR vital-signs profile and, in US implementations, the corresponding US Core profile. That means category vital-signs, a LOINC code from the expected set, a value with a UCUM unit, a subject reference to the Patient and an effective time.

The effective time is where wearables differ from clinic data. A single cuff reading has an effectiveDateTime. A daily step total or an average resting heart rate covers a period and uses effectivePeriod with start and end. Mixing the two, or using the upload time instead of the measurement time, causes trend displays and downstream analytics to drift.

Each data type needs a specific LOINC code and a UCUM unit expressed in the unit code field, not just as display text. These are the codes we use most often for wearable and home device data. Some data types, such as sleep stages or heart rate variability, have less settled coding and need a documented decision per project.

Blood pressure is a single Observation with the panel code and two components, not two separate Observations. Pulse captured by the same cuff is a separate heart rate Observation, linked if needed. This matches what US Core expects and what EHRs display as a single reading.

Aggregated values — daily averages, minimum and maximum overnight SpO2, weekly step totals — use effectivePeriod, and the method or a note should indicate how the value was derived. For waveform data such as ECG traces, the SampledData data type carries the sample series with origin, period, factor and dimensions. Waveforms are large, so we usually store them in your platform and expose summaries or references rather than pushing full traces to every consumer.

Clinicians and researchers need to know whether a value came from a validated clinical device or a consumer wearable. The Observation's device element references a Device resource carrying manufacturer, model, serial number where appropriate and software version. A Provenance resource can record which system created or transformed the data and when.

For data from personal health devices, the HL7 Personal Health Device implementation guide maps IEEE 11073 device information and measurements to FHIR, including how to represent the gateway that relayed the data. We follow it where it fits the use case, which keeps medical device integration and FHIR output aligned.

Standard FHIR REST interactions cover most needs: create Observations, search by patient, code and date. For near-real-time notification, FHIR Subscriptions let a receiving system be told when matching data arrives, though support for the newer topic-based Subscriptions framework varies by server. For research and population analytics, the Bulk Data Access specification ($export) produces NDJSON files of all matching resources for a group of patients.

We pick the pattern per consumer. An EHR may accept only individual creates, a research warehouse may only want periodic bulk exports, and a partner app may want subscriptions. Our technical expertise page covers the FHIR servers and tooling we work with.

Every resource we generate is validated against the declared profiles before it leaves your platform, using the official FHIR validator or an equivalent in the pipeline. Validation errors are treated as defects, not warnings. Profiles and terminology change over time, so we pin implementation guide versions and record them in the resource meta.profile element.

Upstream source data can come from consumer platforms such as Apple HealthKit or from clinical devices; the FHIR layer gives both a common, validated shape.