Chapter 01: Introduction to Sleep Monitoring

1.1 Why this book exists

Consider a patient who spends a night in a hospital sleep lab and has also worn a consumer wristband for the last six months. The lab produces a polysomnogram: raw biosignals, a hypnogram scored by a technologist, and a report with an apnoea-hypopnoea index. The wristband produces a nightly "sleep score" and a bar chart of light, deep, and REM minutes. Both describe the same person's sleep. Neither system can read the other's output, and nothing in either says how far the two should be trusted relative to each other.

WIA-MED-021 is an open standard for this problem. It covers four kinds of device:

The goal is that data from any conformant device can travel to any conformant clinical dashboard, EHR system, or research platform without being flattened or misread on the way.

This book explains the standard to three audiences. Device engineers need to know what to emit. Platform and EHR integrators need to know what to accept and what to refuse. Clinicians and researchers need to know what the fields mean before they rely on them. The running example throughout is one polysomnography night, session ses_01HXY, which starts at 22:30 UTC and ends at 07:00 the next morning. You will meet its session record, its stage epochs, a single obstructive apnoea, an arousal, and its scoring summary in turn.

1.2 The state of sleep medicine data

Sleep data is fragmented in three separate ways, and the standard addresses each one.

Fragmentation by device family. Sleep labs buy PSG hardware that speaks vendor-specific protocols. Consumer wearables send data to vendor-locked clouds. Home sleep apnoea tests form a third silo. The signals each family captures differ a great deal, and that difference matters clinically.

Device familysession_kindTypical signals
Sleep-lab PSGpolysomnographyEEG, EOG, EMG, airflow, pulse oximetry, chest and abdomen belts
Home apnoea testhome_sleep_apnoea_testTypically airflow and SpO2 only
Wrist or ring trackerconsumer_wearableTypically heart rate and accelerometer, with stages derived from them
Daytime sleepnapDepends on the recording device

Fragmentation of scoring. The American Academy of Sleep Medicine (AASM) publishes well-defined rules for scoring sleep stages and associated events. Vendor implementations still vary in how faithfully they apply those rules. When two systems report different REM durations for the same night, a downstream reader has no way to tell whether the difference reflects physiology, a different algorithm, or a different rule version.

Fragmentation of evidence quality. A PSG measures REM sleep through EEG. A wristband infers REM from movement and heart-rate patterns. Both can produce a number labelled "REM minutes", but they are not equivalent evidence. A clinician who cannot see the difference may give an estimate the weight of a measurement.

1.3 What WIA-MED-021 changes

The standard makes three changes, one for each fragmentation above.

A shared data shape. Phase 1 fixes JSON objects for sessions, sleep stages, respiratory events, arousals, and scoring metadata. Keys are snake_case. Timestamps are RFC 3339 in UTC with a Z suffix, and events tied to specific waveform samples need sub-second precision. Every object carries a version string:

"wia_sleep_monitoring_version": "1.0.0"

A receiver must refuse a major version it does not implement. This is better than guessing at a shape it only partly understands.

Scoring that can be compared. The scoring metadata record names the algorithm (for example AASM-2024-default), the scorer, and an aasm_compliance_level. A consumer reading two nights can therefore see whether they were scored under the same rules.

Explicit evidence grade. Every session record carries a clinical_grade flag. The flag may be true only when the recording device has regulatory clearance for the relevant signals, such as FDA 510(k), EU CE-MDR, or KFDA approval. A conformant implementation refuses clinical_grade: true without a clearance reference. The flag therefore reflects a checkable fact about the device.

The session record for our example night looks like this, abbreviated:

{
  "type": "session",
  "session_id": "ses_01HXY",
  "patient_id": "did:wia:patient:01HXY",
  "session_kind": "polysomnography",
  "started_at": "2026-04-26T22:30:00Z",
  "ended_at":   "2026-04-27T07:00:00Z",
  "clinical_grade": true,
  "edf_url": "https://recordings.example/sessions/ses_01HXY.edf",
  "edf_sha256": "7d8f2c…",
  "scoring_metadata_id": "scm_01HXY"
}

Two details are worth noting early. The patient is identified by a did:wia:patient:… identifier, which keeps directly identifying data off the wire. The record also holds only a pointer to the raw recording, which section 1.6 explains. A session kind the receiver does not know is treated as unrecognised and is not rejected, which lets the vocabulary grow without breaking older readers.

1.4 The 4-Phase architecture

The standard is built in four layers. Each can be implemented and tested on its own, and each depends only on the layers before it.

PhaseScope
1 — Data FormatSession, sleep stage, respiratory event, arousal, scoring metadata
2 — API InterfaceHTTP surface for session ingest, query, stream, scoring re-computation
3 — Federation ProtocolCross-device handshake, replay defence, patient consent
4 — IntegrationHL7 FHIR R5, AASM scoring, EDF / EDF+ raw recordings, WIA family

Phase 2 is the part most integrators touch first. A host (a vendor cloud, a sleep-lab platform, or a hospital remote-monitoring system) advertises itself at /.well-known/wia-sleep-monitoring. The discovery document lists the endpoints for session, stage, event, arousal, and scoring. It also lists the supported session kinds and scoring algorithms, so a client can find out before uploading whether a host will accept, say, a consumer_wearable session scored with a particular vendor algorithm. Transport is HTTPS with TLS 1.3 or later.

Sessions have a lifecycle that matches how sleep studies are handled in practice:

DRAFT → IN_PROGRESS → SCORING → SCORED → ARCHIVED
                              ↓
                          → CORRECTED (new scoring_metadata appended)

The recording starts as a draft and is in progress while the patient sleeps. A technologist scores it. A physician reviews it and it is archived. If the review changes the scoring, the session moves to CORRECTED and a new scoring metadata record is appended. The earlier one stays in the record. Transitions are signed PATCH operations, and the signer needs the right scope: technician_scoring, physician_review, or archive_manager. Deleting a session leaves a tombstone, and the audit trail is kept for 25 years.

Phase 3 covers what happens when data crosses organisational boundaries: the handshake between devices, defence against replayed messages, and patient consent. Phase 4 connects the standard to the rest of the clinical world, namely HL7 FHIR R5, AASM scoring, EDF / EDF+ recordings, and the sibling WIA standards.

A first experiment needs only the reference container and two requests:

docker run -p 8080:8080 wia/sleep-monitoring-host:1.0.0

curl -X POST "http://localhost:8080/sm/session" \
     -H "Content-Type: application/json" \
     -d @session.json

curl "http://localhost:8080/sm/session/{session_id}/scoring"

1.5 AASM is the clinical reference

The standard does not define its own sleep science. It adopts the AASM Manual for the Scoring of Sleep and Associated Events, in its current edition, as the authority, and it turns the manual's vocabulary into reserved tokens.

FieldReserved tokens
stagewake, n1, n2, n3, rem, unscored
event_kindobstructive_apnoea, central_apnoea, mixed_apnoea, hypopnoea, rera, oxygen_desaturation
arousal kindspontaneous, respiratory, limb_movement, external
aasm_compliance_levelfull, partial, consumer_estimate

Future minor versions add tokens but never remove them, so a reader written today will not break on an old record.

Stages and epochs. A night is divided into epochs, typically 30 seconds each, and each epoch receives one stage. An eight-hour night therefore yields 960 epochs. Phase 2 expects them to be submitted in bulk in one envelope, with an Idempotency-Key, so a retry cannot duplicate the night. Consumer wearables may use 5-minute epochs at lower confidence. The epoch_duration_seconds field records the real granularity, so a coarse estimate cannot pass as a fine one. The unscored token exists for epochs an algorithm could not classify. It lets a gap stay visible and avoids filling it with a guess.

Respiratory events. An event record such as re_01HXY-12 is an obstructive apnoea starting at 23:45:12.300Z. It lasts 14 seconds, is accompanied by a 3.5 percent oxygen desaturation, and is followed by an arousal. Each event kind has its own AASM criteria. The standard stores the per-event detail so that the apnoea-hypopnoea index (AHI) can be audited:

AHI = (apnoeas + hypopnoeas) / sleep_hours
RDI = (apnoeas + hypopnoeas + reras) / sleep_hours

Here RDI is the respiratory disturbance index, which also counts respiratory-effort-related arousals (RERAs). The standard does not ask consumers to recompute these. The producer publishes AHI and RDI in the scoring metadata, and consumers must trust those published values. The reason is that some wearables derive AHI from inputs that are not AASM-equivalent. A consumer recomputing from events would give a wrong figure a clinical look. The events remain available for audit and for re-scoring through the host's scoring endpoint. The published summary is what a report should cite.

Arousals. The AASM does not score arousals shorter than 3 seconds. The standard follows suit: implementations must not emit sub-3-second arousals, and a conformant receiver refuses them. An arousal linked to a respiratory event uses the respiratory kind and points to that event through associated_event_id.

Compliance level. The aasm_compliance_level in the scoring metadata is the most direct answer to the question from section 1.2. Its three values mean:

The summary for ses_01HXY reports 480 total sleep minutes, 102 of them REM, an AHI of 4.5, an RDI of 6.0, and a minimum SpO2 of 88 percent. It is scored at full compliance by a named technologist.

1.6 EDF / EDF+ stays sovereign

The European Data Format (EDF) and its extension EDF+ are the long-established file formats for raw biosignal recordings in sleep labs and research. Since the sleep field already uses them, WIA-MED-021 does not attempt to replace them. A PSG file holds all the channels at full sample rate, typically hundreds of megabytes per night. That is the wrong payload for a JSON envelope.

The session record therefore references the recording by edf_url and by edf_sha256, an integrity hash. For clinical-grade sessions both are required. The file stays in its own object store, and anyone who retrieves it can check that it is the recording the session describes:

curl -sO https://recordings.example/sessions/ses_01HXY.edf
sha256sum ses_01HXY.edf    # compare with edf_sha256 in the session record

This division of labour has three consequences:

Sub-second event timestamps are what tie the two layers together. They let an event such as the 23:45:12.300Z apnoea be located in the waveform.

Cross-Chapter Anchors

The ideas introduced here map onto the Phases as follows.

Concept in this chapterWhere it is specified
Session, stage, event, arousal, and scoring records; reserved tokensPhase 1
Discovery, lifecycle states, bulk submission, idempotencyPhase 2
Cross-organisation handshake, replay defence, consentPhase 3
FHIR R5 mapping, EDF+ bridge, HealthKit / Google Fit exchangePhase 4

Implementations are graded by how many surfaces they cover. The Minimal level needs Phase 1 envelopes plus session ingest and query. Core adds federation and the FHIR R5 export bridge. Full adds AASM-compliant scoring, the EDF+ bridge, and two-way HealthKit / Google Fit exchange. Records are signed with Ed25519. A reference command-line tool offers the subcommands validate, session, event, score, consent, and info, which are convenient for trying the examples in this book.

Where to Look Next

Readers who plan to build a device or an uploader should go to the Phase 1 material first. Every other layer assumes the record shapes, and the validation rules there decide what a receiver rejects.

Integrators of hospital systems should study the lifecycle and scope rules of Phase 2, then the FHIR R5 bridge in Phase 4. Researchers who need raw signals should concentrate on the EDF reference and the integrity hash. Readers working with wearable data should keep the sister standard WIA-MED-020 close, because the clinical-grade clearance reference defined there is what makes clinical_grade: true verifiable.

Patient and Clinician Considerations

Sleep data is intimate. It records when a person is at home, when they are awake in the night, and indirectly how well they are. The standard's pseudonymous patient identifiers keep names and direct identifiers out of the envelope, and Phase 3 places patient consent on the path between organisations. Anyone building on the standard should still treat the data as personal health information.

Clinicians reading a record should check three fields before relying on a number:

A consumer_estimate may still be useful for trends, for example whether a patient's nights are getting shorter. The standard states plainly that it is not suitable for clinical decisions. In that case the better course is to order a study with a clinical-grade device.

In summary, this chapter set out the problem as fragmented devices, scoring, and evidence grades. It showed how Phase 1 answers each with a shared record format, AASM vocabulary carried in explicit fields, and EDF recordings referenced by hash. The next step is to open the Phase 1 envelope and read the session, stage, event, arousal, and scoring records field by field, using ses_01HXY as the example throughout.