Phase 3 specifies how independent wearable health hosts build trust over time, exchange device data without merging databases, defend against replay, and enforce the patient-consent boundary. The handshake state machine, replay defence bounds, and audience controls are designed so that a vendor cloud, a hospital RPM platform, and a research aggregator can collaborate on a patients data without any single party becoming the central database.
The five roles (vendor cloud, patient-controlled host, clinical host, research aggregator, custodian) are summarised in Chapter 3. Phase 3 specifies how they federate: each issues federation receipts to the others after a handshake, the receipts are persisted by both sides, and every cross-host data flow is gated on a fresh patient consent envelope.
The handshake reuses the WIA-SOCIAL Phase 3 §5 receipt shape so that vendor implementations can share their federation library across multiple WIA family standards. State machine: IDLE → PENDING (origin verifies signature) → ACCEPTED (origin issues receipt) → optional REVOKED.
The patient consent envelope is the gating control on cross-host data flow. It declares the audiences (clinical hosts, research aggregators) authorised to read the patient data, the scopes (clinical_dashboard, ehr_export, research_aggregate) of each authorisation, the validity window, and whether the consent is revocable.
{
"wia_wearable_health_version": "1.0.0",
"type": "patient_consent",
"patient_id": "did:wia:patient:01HXY",
"scopes": ["clinical_dashboard", "ehr_export"],
"audiences": [
{ "audience_id": "did:wia:clinical-host:hospital-A", "scope": "clinical_dashboard" }
],
"valid_from": "2026-04-01T00:00:00Z",
"valid_until": "2027-04-01T00:00:00Z",
"revocable": true,
"signature": { "alg": "Ed25519", "value": "AY3o..." }
}
For paediatric patients the custodian is the legal guardian; the custodian MUST be cleared via a separate identity-proofing flow documented in Phase 4 §WIA-OMNI-API.
Each signed envelope (sync, alert, consent) carries a 96-bit nonce and an RFC 3339 timestamp. Receivers MUST reject envelopes with skew greater than ±300 seconds, reject envelopes whose (signer, nonce) tuple has been seen within the last 600 seconds, and maintain the seen-nonce cache for at least 600 seconds. For critical alerts the cache MUST be persistent across restarts so that a vendor failover does not re-open the window for a duplicated critical alert (which could trigger duplicate clinician pages).
The audience matrix encodes who can see what. Public audience sees only aggregate engagement statistics. Patient sees their own full data. Caregiver sees per-scope summaries. Clinician sees full data for patients under active care. EHR bridge sees per-minute aggregates by default; full waveform requires elevated consent. Research sees de-identified data per HIPAA Safe Harbor §164.514(b)(2). Emergency service sees full data plus identifying metadata under emergency consent that auto-expires after 24 hours.
A patient transferring from one vendor cloud to another publishes a signed patient_move envelope. The new vendor fetches the patients history from the prior vendor over a federated read; the old vendor returns 301 Moved Permanently for the patients data URL for at least 12 months.
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.