Chapter 03: WIA-MED-020 Standard Overview

3.1 The standard at a glance

WIA-MED-020 is a four-phase open standard for wearable health monitoring. The four phases are independent specifications that compose: Phase 2 depends on Phase 1, Phase 3 depends on Phase 2, Phase 4 depends on the rest. An implementer may choose to implement only Phase 1 + 2 (basic local sync) or all four phases (full federation + bridges).

3.2 Architecture

+------------------+
| Phase 4: Bridges |  HL7 FHIR R5 / IEEE 11073 / HealthKit / Google Fit / WIA family
+--------+---------+
         |
+--------v---------+
| Phase 3: Federation Protocol |  cross-vendor handshake, replay defence, patient consent
+--------+---------+
         |
+--------v---------+
| Phase 2: API Interface |  HTTPS surface for device sync, measurement query, alert dispatch
+--------+---------+
         |
+--------v---------+
| Phase 1: Data Format |  device, measurement, session, alert, calibration envelopes
+------------------+

3.3 Object families

Phase 1 defines five primary object families:

1. Device — identity and capability descriptor (vendor, model, firmware, supported measurement types, clinical-grade flag, calibration chain pointer).
2. Measurement — one observation (heart rate value, step count window, glucose reading, ECG waveform reference).
3. Session — a contiguous activity, sleep, workout, monitoring, fasting, or recovery session that bundles many measurements.
4. Alert — a clinically meaningful event derived from one or more measurements (info, warning, urgent, critical severity ladder).
5. Calibration — a signed calibration record tying a device to a national metrology institute reference (NIST, PTB, KRISS, NMIJ, NIM).

3.4 Roles in the federation

Phase 3 defines five roles that compose the federated ecosystem:

• Vendor cloud — holds raw device data and signs envelopes for downstream consumers.
• Patient-controlled host — holds the patient identity and consent envelopes (often the patient themselves).
• Clinical host — hospital or clinic remote-patient-monitoring platform; receives data under consent.
• Research aggregator — receives de-identified data under explicit research consent.
• Custodian — holds the legally binding consent record (patient, or guardian for minors).

3.5 Conformance levels

3.6 Where the standard fits in the WIA family

WIA-MED-020 sits beside WIA Vital Sign Streaming (continuous high-rate waveform companion) and WIA-OMNI-API (credential storage). The three standards compose for end-to-end clinical workflows: WIA-MED-020 carries discrete measurements and alerts, WIA Vital Sign Streaming carries continuous waveforms by reference, WIA-OMNI-API holds the patient and clinician identity proofs that gate access to both.

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.