Phase 4 specifies how WIA-MED-020 integrates with three classes of existing system: vendor health platforms (Apple HealthKit, Google Fit, Samsung Health, Garmin, Fitbit), clinical interoperability standards (HL7 FHIR R5, IEEE 11073, IHE PCD-01), and the WIA family standards (WIA-OMNI-API, WIA-AIR-SHIELD, WIA-INTENT, WIA-ACCESSIBILITY, WIA Vital Sign Streaming). The aim is that one WIA-MED-020 host is the canonical record while every vendor / EHR / research system reads from or writes to it through bridges, never holding canonical state for the patients wearable data.
Each WIA measurement envelope maps deterministically to an HL7 FHIR R5 Observation resource. The default LOINC mapping covers heart rate (8867-4), step count (55423-8), SpO2 (59408-5), glucose (2339-0), systolic and diastolic blood pressure (8480-6 / 8462-4), body temperature (8310-5), and body weight (29463-7). For ECG raw waveforms the bridge uses HL7 FHIR MediaStream with a derivedFrom link to a binary representation conforming to the WIA Vital Sign Streaming standard.
IEEE 11073-104xx defines per-device profiles for personal health device communication. The bridge subscribes to the devices IEEE 11073 measurement channel, translates each measurement into the WIA envelope, and preserves the IEEE 11073 device specialisation code in the WIA device.metadata field. The mapping covers thermometers (-10408), weighing scales (-10415), glucose meters (-10417), blood pressure monitors (-10421), and cardiovascular fitness devices (-10441).
The HealthKit bridge runs as part of an iOS companion app. It reads HealthKit data via HKObjectTypeIdentifier queries with the users explicit consent under iOSs per-type permission model, translates each sample into the WIA envelope, and writes WIA-host-derived measurements back to HealthKit under the apps own source identifier. Apple Health UI shows "WIA Wearable Health" as the data source.
The Google Fit bridge runs as part of an Android companion app. It subscribes to DataType streams via the Fit REST API with the users OAuth consent, translates samples into the WIA envelope, and writes back via the bulk insert endpoint under the apps data source. The bridge shares its OAuth token storage with WIA-OMNI-API for centralised credential rotation.
WIA-MED-020 composes with WIA-OMNI-API for credentials (patient identity, vendor account credentials, provider licence records, paediatric custodian relationships), WIA-AIR-SHIELD for transport hardening (peer reputation scoring), WIA-INTENT for clinician intent lowering (a "show me last week of glucose" intent lowers to a measurement query under the licence verification + consent verification + accessibility rendering pipeline), WIA-ACCESSIBILITY for patient and clinician accommodations, and WIA Vital Sign Streaming for high-rate continuous waveforms.
HIPAA Security Rule controls (administrative / physical / technical safeguards including audit controls and encryption at rest) apply to every WIA-MED-020 host carrying PHI. The patient consent envelope is the GDPR Article 7 consent record; the patients right to revocation (GDPR Article 7(3)) is implemented via the revocable: true field. For clinical-grade devices, the FDA 510(k) clearance number is the binding tie to regulatory approval; the bridge MAY pre-validate the number against the FDAs public databases before accepting the device record.
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.