Use case / Product architecture

Build sleep-monitoring experiences around supported data.

Bring sleep-radar, wearable and health-platform records into a FHIR-backed product while keeping each source's meaning and limits visible.

Start free Explore the Healthspan guide

Sources

Sleep data is not one interchangeable measurement.

Available fields vary by device, platform, permission and source record. Confirm the data you can actually receive before shaping the experience.

Supported devices

The catalog includes sleep-radar devices, supported wearables and some SpO₂ sources; each device exposes its documented measurements.

Review supported devices

HealthKit and Health Connect

A patient can grant access to selected records when present. Sync may return no data, and background delivery depends on the platform and app configuration.

Read about HealthKit and Health Connect

Different record types

A sleep session, an oxygen measurement and a wearable metric have distinct source semantics; don't collapse them into one score by default.

Architecture

Preserve the source while building the product view.

01
Radar, wearable or health-platform source
Collect only the measurements and session records supported by that source and permitted by the patient.
02
Supported SDK or import path
Use the Native SDK for supported device workflows and the documented HealthKit or Health Connect path for selected platform data.
03
FHIR-backed records
Represent supported metrics in their documented Observation form and preserve the source coding and provenance needed by the product.
04
Sleep experience
Your app can organize the records into history, trends, reflections and practitioner review without changing what the original source measured.

Data semantics

A sleep interval is not necessarily time asleep.

The Healthspan guide makes an important modeling distinction that applies to sleep-related product work.

Keep the interval literal

A recorded sleep session describes an elapsed interval and may include awake time. Do not relabel its duration as time asleep.

Keep source stages honest

Preserve stages when a source provides them. Do not invent missing stages or assume all devices classify sleep in the same way.

Retain provenance

Health-platform records should remain attributable to their source. Sleep sessions and steps are not automatically LOINC-coded clinical observations.

Read about Retain provenance

Separate reflection from measurement

A patient questionnaire can capture a reflection; it is a distinct record from device-derived sleep data.

Read about Separate reflection from measurement

Product workflow

Build the interpretation layer deliberately.

Patient experience

Your team can build sleep history, device status, reflections and educational content around the records available to that patient.

Practitioner review

Use FHIR-backed history in the practitioner experience your team builds; define which source fields and context belong on screen.

No diagnostic claim

Ovok does not provide sleep-apnea detection, sleep diagnosis or treatment recommendations as part of this platform pattern.

Signals boundary

Sleep metrics are not all Signals inputs.

Implementation example

Start with the health-platform and reflection pattern.

The Whole-Person Healthspan guide documents sleep sessions and selected health data alongside reflections and goals; it is a wellness example, not a sleep diagnosis workflow.

Whole-Person Healthspan & Coaching

Review its HealthKit and Health Connect connection, sleep-session handling, QuestionnaireResponse reflections and longitudinal app view.

Open the Healthspan guide

Relevant documentation

Validate sources and fields before designing trends.

Evaluate the product pattern

Build against the infrastructure your team will use.

Start in the Developer sandbox with test data, then validate supported-device and workflow requirements against the current docs.

Start free Explore the Healthspan guide