Chapter 07: Phase 4 — Integration

7.1 Phase 4 in one paragraph

A sleep study rarely lives in one system. The raw recording sits in an EDF or EDF+ file produced by polysomnography (PSG) hardware. The scoring is done in a vendor's software against the AASM Manual. The summary has to reach the hospital's electronic health record, and the patient may also own a ring or watch that produces a very different kind of sleep data. Phase 4 of WIA-MED-021 defines how the standard's envelopes meet each of these worlds without replacing any of them. It covers three classes of neighbour: clinical sleep medicine standards (AASM scoring, EDF/EDF+, HL7 FHIR R5), vendor sleep platforms (Apple HealthKit, Google Fit, Samsung Health, Fitbit Web API, Oura Ring API, Withings), and sister WIA standards for credentials, wearables, biosignal streaming, transport hardening and accessibility. The design rule behind all of it is composition. The standard does not re-publish the AASM rules, transcode the EDF signal payload or copy the raw recording into FHIR. It supplies the data shape and the references that let each existing system keep doing what it already does well.

7.2 AASM scoring integration

The AASM Manual for the Scoring of Sleep and Associated Events is the clinical reference for turning a night of biosignals into stages, respiratory events and arousals. WIA-MED-021 deliberately does not restate those rules. It provides the data shape that AASM-compliant scorers consume and emit, namely the stage_batch, event and arousal envelopes. A scoring_metadata envelope then says who scored the night and how.

The scoring_algorithm field in that envelope is an opaque identifier drawn from a registry published under the standard's sleep-monitoring/scoring-algorithms/ path. The initial registry shows why the identifier matters:

Algorithm IDMeaning
AASM-2024-defaultDefault scoring per the 2024 edition of the AASM Manual
AASM-2018-defaultDefault scoring per the 2018 edition, preserved for cohort comparability
AASM-2024-paediatric2024 edition with the paediatric adjustments
Vendor-A-v3A reference vendor-specific scorer for consumer wearables

Keeping the 2018 identifier alive is a research-practice decision. A longitudinal cohort scored under one edition cannot be silently compared with data scored under another, because the rule changes shift event counts and therefore indices such as AHI. Tagging each scoring run with its algorithm makes that mismatch visible instead of leaving it as a hidden confounder. The paediatric identifier addresses the same hazard. The AASM rules for children differ from those for adults, so a paediatric night must never be evaluated against adult rules without anyone noticing.

The second integration lever is the aasm_compliance_level ladder defined in Phase 1. Its values include full, partial and consumer_estimate, and downstream consumers filter on it to decide whether data is fit for their purpose. A clinical sleep clinic typically requires full. A research consortium may accept partial provided the rule deviations are documented. A consumer wellness app is content with consumer_estimate. The ladder is how a wrist-worn heart-rate-and-movement estimate and a technician-scored PSG can live in the same host without one being mistaken for the other.

Re-scoring is part of normal clinical life. A sleep physician may ask for a different algorithm, and a new edition of the Manual may force a whole archive to be revisited. The integration answer is that a new scoring_metadata envelope carries a supersedes reference to the one it replaces. The earlier scoring stays in the chain and the raw recording is never touched, so no physical data has to be re-transferred.

7.3 EDF / EDF+ bridge

European Data Format (EDF) and its annotation-capable successor EDF+ are the de-facto raw biosignal formats of sleep medicine, and nearly every PSG system can export them. The Phase 4 bridge treats the file as the authoritative recording and wraps it rather than converting it. In order, it:

The hash is more than housekeeping. Re-scoring is only meaningful if everyone is scoring the same signal, and the hash lets a consumer prove it. A host that detects a mismatch increments the wia_sm_edf_integrity_failures_total counter, which gives operators a measurable signal when storage migration or corruption has damaged a recording.

Raw sleep recordings are also sensitive in a way that is easy to overlook. The biosignal patterns inside an EDF+ file can identify the person, even after the header fields are stripped. The standard therefore requires hosts to encrypt EDF at rest with AES-256-GCM and to refuse any cross-host EDF transfer that is not authorised by a consent envelope.

The bridge's operational cost is mostly storage. A single overnight PSG produces roughly 100 to 500 MB of EDF data, and clinics often retain raw EDF for many years under local regulation (the material cites 7 to 25). Cold-storage cost therefore tends to dominate a deployment budget, and integrators who plan only for the database tier are regularly surprised.

7.4 HL7 FHIR R5 bridge

Hospitals consume results through their electronic health record, so Phase 4 maps each WIA session onto HL7 FHIR R5 resources. The session becomes a Procedure representing the sleep study. The scoring summary metrics (AHI, RDI, total sleep time, stage minutes) become one or more Observation resources. The default LOINC mappings are:

WIA scoring summary fieldLOINCDisplay
total_sleep_minutes93832-4Sleep duration
ahi90562-0Apnea hypopnea index
min_spo2_pct59408-5Oxygen saturation in arterial blood by pulse oximetry
n3_minutes93810-0Slow wave sleep duration
rem_minutes93808-4REM sleep duration

An exported AHI observation therefore follows the usual FHIR shape, with the LOINC code from the table and the value taken from the scoring summary. The sketch below is illustrative only, with elisions marked:

{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [ { "system": "http://loinc.org",
                          "code": "90562-0",
                          "display": "Apnea hypopnea index" } ] },
  "subject": { "reference": "Patient/..." },
  "valueQuantity": { "value": "<from WIA ahi>" }
}

As in the EDF bridge, the bridge moves summaries, not signals. The FHIR side holds a reference to the EDF URL rather than the recording itself, so the health record stays small while the full waveform remains retrievable from the sleep host under the patient's consent. A clinician reading the chart sees AHI and sleep architecture. A reader who needs the underlying epochs follows the reference.

7.5 Vendor platform bridges

Consumer platforms collect a great deal of sleep data, but none of it has PSG provenance. The vendor bridges exist to bring it into the same host without overstating its quality.

The Apple HealthKit bridge runs inside an iOS companion app. It reads HKCategoryTypeIdentifierSleepAnalysis data with the user's explicit per-type consent and turns each sleep period into a WIA session envelope. Every such session is marked session_kind: consumer_wearable and aasm_compliance_level: consumer_estimate, so a downstream filter can never confuse it with a technician-scored night. The bridge also writes a scoring summary back to HealthKit, so the Apple Health interface shows "WIA Sleep Monitoring" as the data source.

Google Fit, Samsung Health, Fitbit, Oura and Withings are handled through vendor-specific profiles kept under spec/profiles/<vendor>.md. Each profile documents the OAuth scopes, the field-by-field mapping, the polling cadence and the credential management for that vendor. Because those bridges hold OAuth tokens for the user's vendor accounts, operators must keep the refresh tokens in HSM-backed storage.

The clinic side has its own bridge problem, which is leaving a vendor-locked PSG stack. The recommended migration is gradual and measured:

  1. Deploy a WIA-MED-021 host alongside the existing vendor system.
  2. Import historical sessions through the vendor's export API, typically EDF plus a vendor-specific scoring XML. The importer maps the vendor's scoring vocabulary onto AASM tokens.
  3. Switch new sessions to direct WIA ingest at the recording workstation.
  4. Run a 30-day shadow period in which both stacks receive every new session, comparing AHI, total sleep time and REM minutes each night. After three consecutive zero-divergence days, retire the vendor stack.

The shadow period works because the comparison uses clinically meaningful summaries rather than file-level equality. A vocabulary-mapping error in step 2 shows up as nightly divergence in exactly the numbers a sleep physician would notice.

7.6 WIA family integration

Five sister standards supply the surrounding infrastructure.

The worked example from the specification shows these pieces cooperating on a single clinical night. The cast is a patient, a PSG device carrying a US FDA 510(k) clearance reference, a hospital sleep-clinic host, a sleep physician and a scoring technician, each identified by a WIA identifier:

Patient   : did:wia:patient:01HXY
PSG vendor: Vendor-A PSG-001 hardware (FDA 510(k) K123456)
Sleep lab : did:wia:sleep-host:hospital-sleep-clinic-A
Sleep MD  : did:wia:clinician:sleep-md-09
Tech      : did:wia:scorer:tech-09
  1. The patient grants consent (clinical_dashboard scope, one-year validity) to the clinic.
  2. The recording workstation captures an eight-hour overnight PSG and uploads the EDF+ file with a session record marked clinical_grade=true.
  3. The technician scores manually with AASM-2024-default in the vendor's software. The vendor exports stage_batch, event and arousal envelopes, and the technician publishes a scoring_metadata referencing that algorithm.
  4. The sleep physician reviews the result. If a different algorithm is requested, the technician publishes a new scoring_metadata with a supersedes reference.
  5. The EHR bridge writes Procedure and Observation resources to Epic.
  6. The patient portal, under the patient's accessibility profile, shows a simplified summary of AHI, REM percentage and sleep efficiency.
  7. After 30 days of clinical follow-up the session is archived but stays queryable for a 25-year retention period, in line with HIPAA and clinical norms.

7.7 Compliance mappings

Because WIA-MED-021 carries protected health information, hosts must implement the controls of the HIPAA Security Rule. The patient consent envelope defined in Phase 3 doubles as the consent record under GDPR Article 7 where that regulation applies. For clinical-grade PSG hardware, the device record carries its regulatory-clearance reference (FDA, CE or KFDA) as defined in WIA-MED-020 §3.2, so a clinic can show which cleared device produced which recording.

AASM accreditation is where the integration pays off most directly for a sleep clinic. The standard's audit log can serve as evidence of conformant scoring practice, and the scorer_id field ties each session's scoring to a specific technician's WIA-OMNI-API identity. This satisfies the requirement for traceable scoring provenance. The credential side is operational as well: technician credentials must live in WIA-OMNI-API with periodic re-credentialing, typically every five years under AASM accreditation.

A host should also expose operational metrics, and none of their labels may contain patient identifiers:

MetricWhat it tells an operator
wia_sm_sessions_received_total{kind}Session ingest by kind
wia_sm_scoring_runs_total{algorithm}Scoring runs per algorithm
wia_sm_arousal_too_short_refused_totalArousals refused for violating the AASM minimum
wia_sm_consent_violations_totalCross-host reads refused for lack of consent
wia_sm_edf_integrity_failures_totalEDF SHA-256 mismatches

Cross-Chapter Anchors

Where to Look Next

Implementers will find the vendor-specific bridge detail in the per-vendor profiles under spec/profiles/. Everything else in this chapter comes down to a single declaration. A host states how much of Phase 4 it implements in the bridge_profile field of its discovery document. Minimal covers Phase 1 envelopes plus Phase 2 ingest and query. Core adds AASM-2024-default scoring, the EDF+ bridge and WIA-OMNI-API credentials. Full adds FHIR R5 export, at least one vendor bridge, WIA-MED-020 composition and Vital Sign Streaming for raw EEG and EMG. A black-box test suite and a reference container image with mock data let integrators exercise a bridge before production, and a Full host should additionally pass the suite's extension tests for one third-party scoring algorithm and one vendor platform. Within the 1.x line, existing endpoints and envelopes stay reachable. Unknown enum tokens must be treated as unrecognised rather than causing an envelope to fail, which keeps a bridge written today working when new algorithm identifiers appear.

Patient and Clinician Considerations

For patients, the most important property of this integration is that provenance travels with the numbers. A figure that came from a ring and a figure that came from an attended PSG look similar in a portal, but they are not equivalent, and the compliance level is what lets a portal say so. Consent is equally concrete. Raw EDF+ will not leave a host without an authorising consent envelope, and the HealthKit bridge reads only the data types the user has approved. Interfaces adapt to the patient's accessibility profile, so a simplified summary of AHI, REM percentage and sleep efficiency is readable regardless of vision or motor ability.

For clinicians, the integration removes a quiet source of error. Every scored night names its algorithm, edition and scorer. Paediatric nights cannot slip into adult comparisons unlabelled. A re-score leaves the earlier result visible rather than overwriting it. An EDF whose hash no longer matches is flagged rather than trusted.

To summarise the chapter, Phase 4 connects the standard to AASM scoring through an algorithm registry and a compliance ladder. It connects to raw recordings through a hash-verified, non-transcoding EDF+ bridge, and to the hospital record through LOINC-coded FHIR R5 Procedure and Observation resources. It connects to consumer platforms through consent-gated bridges that always label their output as estimates. It ties clinical accountability to WIA-OMNI-API identities. What these bridges cannot settle is how the whole arrangement behaves over time: how data ages, how scoring standards change, how hosts evolve without stranding years of recordings. The next chapter turns from connecting systems to keeping them trustworthy and maintainable across versions.