Chapter 02: Current Wearable Health Landscape

2.1 The vendor-locked landscape today

The wearable health device market is dominated by a handful of vertically integrated platforms. Apple HealthKit, Google Fit, Samsung Health, Garmin Connect, and Fitbit Web API together cover the majority of consumer wearables. Each maintains its own data model, OAuth scopes, rate limits, and per-region availability rules.

For a patient using devices from two or three of these vendors, the practical consequences are:

• Three separate apps, three separate dashboards, three separate consent flows.
• No way to view a continuous timeline of heart rate from the morning Apple Watch run, the lunchtime Fitbit walking metric, and the evening Withings blood-pressure reading.
• If the patient changes wearables, the historical data either does not move or moves only via a vendor-specific export tool that loses fidelity.

2.2 Why earlier standardisation attempts stalled

This is not the first attempt to unify wearable health data. IEEE 11073 (the personal health device family) is the most mature prior effort. Continua Design Guidelines and the HL7 Personal Health Monitoring Working Group both pursued the same goal in earlier decades.

The recurring failure modes were:

• Specification weight. The earlier efforts produced encyclopaedic standards that vendor implementers could not afford to fully implement. The result was partial implementations that did not fully interoperate.
• Lack of streaming. The earlier efforts targeted episodic measurement (a single weigh-in, a single cuff inflation) rather than the continuous streaming of modern wearables.
• No federation primitive. They assumed a single-vendor universe — a manager and an agent on the same local network — rather than addressing the cross-cloud reality of today.
• Consent as an afterthought. Patient consent for cross-organisation data sharing was treated as an extension rather than a baked-in primitive.

2.3 What WIA-MED-020 does differently

WIA-MED-020 is positioned as a thin layer on top of existing transport protocols rather than a wholesale replacement. Vendor adapters keep their existing on-device firmware and gain WIA conformance through bridge software running on the vendor cloud or the patient phone. Specifically:

• Streaming-native. Phase 1 envelopes accommodate continuous high-rate streams (ECG, full PPG, accelerometer waveform) via the raw_payload_url reference + WIA Vital Sign Streaming composition.
• Federation-aware. Phase 3 specifies how multiple hosts hand off data ownership as a patient changes vendors or moves between care providers.
• Consent-typed access controls. The patient consent envelope (Phase 3 §4) is the single gate controlling cross-host data flow; per-audience scopes (clinician, EHR bridge, research, emergency) make the boundaries explicit.
• Open governance. The standard is published under MIT licence; conformance test suites are open-source; no vendor pays for the right to claim conformance.

2.4 What the standard is not

WIA-MED-020 is not a vendor product, not a hosted service, not a regulatory body, and not a database schema. It is a wire format and a protocol, with a reference container and conformance test suite as the practical artifacts. Vendors retain ownership of their device firmware, their cloud infrastructure, and their commercial relationships with users. The standard creates portability without dictating implementation.

2.5 The clinical-grade gap

One specific failure of today vendor stacks is that consumer wearables and clinical-grade devices share UX surfaces but not data semantics. A patient looking at their Apple Watch sees both fitness tracker resting heart rate and FDA-cleared ECG together with no visual distinction of regulatory grade. A clinician trying to interpret the data downstream cannot tell which signal is appropriate for clinical decisions.

The standard addresses this with the clinical_grade boolean (Phase 1 §3.2) and the device-level calibration chain (Phase 1 §3.3 and §7). Together these create an explicit, signed evidence trail tying every measurement to its regulatory provenance.

Chapter Cross-References

This chapter participates in the WIA-MED-020 8-chapter survey. Each chapter is intended to be readable standalone, but together they map the full surface of the standard. The Phase numbering used throughout (Phase 1 / 2 / 3 / 4) refers to the four-document specification — Chapter 4 covers Phase 1, Chapter 5 covers Phase 2, Chapter 6 covers Phase 3, Chapter 7 covers Phase 4.

Where to look next

• Conformance test suite — https://github.com/WIA-Official/wia-wearable-health-conformance is the single source of truth. When this book and the test suite disagree, the test suite wins.
• Reference container — wia/wearable-health-host:1.0.0 implements every Phase 2 endpoint with mock data; integrators exercise their bridge against it before going to production.
• Companion CLI — cli/wearable-health.sh ships sample envelope generators (validate, device, measurement, alert, consent, info subcommands) so an implementer can produce conformant payloads without hand-rolling JSON.
• Companion standards — WIA-OMNI-API for credentials, WIA-AIR-SHIELD for transport hardening, WIA-INTENT for clinician intent lowering, WIA-ACCESSIBILITY for accommodations, WIA Vital Sign Streaming for high-rate continuous waveforms.

Patient-First Design

Every choice in this standard is filtered through the question: "does this make wearable data more useful for the patient and their care team, or just easier for vendors to ship?" When the two conflict, the patient and care team win. That is why the standard mandates explicit patient consent for cross-host data flow, refuses to accept clinical-grade claims without regulatory clearance, and requires implementations to surface calibration provenance so that clinicians can verify the source quality of every measurement they make decisions on.