A black-box conformance test suite is published at https://github.com/WIA-Official/wia-wearable-health-conformance and walks through discovery document round-trip, device publish/read/withdraw with clearance refusal path, bulk sync with idempotency key collision, measurement query with type and time-window filters, stream subscribe / reconnect with Last-Event-Id, session create + summary patch within 24-hour window, alert submission with critical-severity paging assertion, calibration due?within= query, rate-limit headers and exhaustion behaviour. Hosts publishing bridge_profile=Full SHOULD additionally pass the suites bridge tests for at least one supported vendor (HealthKit / Google Fit / Samsung / Garmin / Fitbit).
A reference container image is published as wia/wearable-health-host:1.0.0 on the WIA registry. The container ships with the HTTP surface implementing all Phase 2 endpoints, a SQLite-backed record store suitable for vendor-cloud-scale (under 1 M patients), HL7 FHIR R5 bridge for outbound EHR export, IEEE 11073 inbound bridge for at least one device class, and a built-in conformance test runner. Production deployments typically swap SQLite for PostgreSQL with the WIA-supplied schema and add a dedicated object store for raw_payload references.
| Version | Focus |
|---|---|
| 1.0.0 | Initial publication: Phases 1–4 stable, conformance suite v1, reference container |
| 1.1.x | Additive: more device classes (continuous BP cuffs, infant pulse oximeters, pediatric ECG patches), additional measurement types, optional WIA-AIR-SHIELD scoring profile |
| 1.2.x | Additive: federated identity for clinicians via WIA-OMNI-API integration tightening, optional public-registry export profile for de-identified research data |
| 2.0.0 (no earlier than 2028) | Possible breaking change: post-quantum signature suite migration following the parent WIA family roadmap |
Within the 1.x line every Phase 2 endpoint MUST remain reachable and MUST continue to honour the documented status codes and content shapes. Hosts MAY add optional query parameters, response fields, new endpoints, or media types. Hosts MUST NOT remove or repurpose existing ones. Breaking changes ride a major version bump and MUST be preceded by a 12-month deprecation window per IETF RFC 8594 and RFC 9745.
The standard is maintained by the WIA Standards Committee. Change proposals follow the WIA RFC process: anyone may submit a proposal; the Committee reviews quarterly; accepted proposals enter an open comment period before being merged into a minor-version release. Breaking changes require a two-thirds Committee vote.
Wearable health monitoring is at a hinge moment: consumer wearables are accumulating clinical-grade capability faster than the standards that govern their data. WIA-MED-020 exists to close that gap with an open, federation-aware, audit-logged standard that lets clinicians, researchers, and patients share data on terms each can verify. The hope is that vendor lock-in stops being the default; that a patient owning three different wearables can present their physician with one continuous physiological narrative; and that the field collectively benefits from a wire format that no single vendor controls.
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.
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.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.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.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.