Use case / Product architecture

Build respiratory monitoring around supported measurements.

Store supported oxygen and respiratory-related device measurements as FHIR data, then build the patient and care-team review flow in your product.

Start free Review device ingestion

Measurement scope

Start with the fields each device actually provides.

The catalog is the source for model-level compatibility; categories do not imply that every device measures every field.

SpO₂ and pulse rate

These measurements are documented for supported device entries. Confirm the exact model, firmware and output fields in the catalog.

Check device catalog

Respiratory rate

Some catalog entries document respiratory-rate measurements. Availability is device-specific; do not treat it as a universal capability.

Read about Respiratory rate

Related sources

Sleep radars and wearables may provide additional supported data, but their measurements and semantics differ by source.

For the distinct data model and product boundaries of sleep radars, see the sleep monitoring use case.

Architecture

Keep measurements, record and evaluation paths distinct.

01
Supported SpO₂ or respiratory-related source
Select a specific compatible device and define which of its documented measurements the app uses.
02
Device or connected-system ingestion
Use the Native SDK for supported Bluetooth workflows or the configured IoT ingestion route for connected systems.
03
FHIR Observation
Store supported readings in the patient record for the product's longitudinal view.
04
Patient and care-team workflow
Your product presents the readings, source context, check-ins and review process it has designed.

Care workflow

Your clinical team defines how data is used.

Ovok supplies infrastructure; it does not supply a respiratory protocol.

Patient-side

Build measurement capture, recent history, symptom questionnaires and check-ins around the supported records available to the patient.

Practitioner-side

Build a review view with source details and longitudinal observations. Follow-up communication can use documented product capabilities such as video calls.

Read about Practitioner-side

Clinical interpretation

Thresholds, escalation, diagnosis and the respiratory care pathway are defined and governed by your product and clinical team.

Responsibilities

Separate the platform layer from the clinical product.

Ovok provides

FHIR R4 records for supported measurements
Native SDK Bluetooth and configured device ingestion paths
Patient/practitioner identity and Access Policies
Optional Signals evaluation for eligible vital signs and enrolled patients

Your product team owns

Select models and confirm measurement fields
Define thresholds, interpretation and escalation
Build patient and practitioner experiences
Set intended use and regulatory strategy

Implementation pattern

Adapt the documented measurement-to-FHIR flow.

There is no respiratory-specific guide published today. The Blood Pressure RPM guide demonstrates the device-to-Observation implementation pattern, not a respiratory care workflow.

Blood Pressure RPM guide

Review supported Bluetooth setup, normalized measurement handling and saving an Observation, then validate each respiratory device and measurement independently.

Open the device-to-FHIR guide

Relevant documentation

Check device fields, ingestion and access controls.

Signals

Enrollment determines whether the branch is active.

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 Review the device catalog