Working with Signals as a connected part of Ovok

Signals is Ovok’s connected alert-evaluation service. Your application uses Ovok APIs; it does not need Signals credentials or a direct connection to Signals.

For Patients enrolled in Signals, Ovok forwards eligible vital-sign readings according to the documented Signals forwarding behavior. Ovok stores and exposes clinical data through FHIR and makes returned alert decisions available to your application. Do not infer which measurements are forwarded; check Data Ingestion for the current gates and ingestion-path behavior. Signals evaluates the readings and rules; Ovok does not independently evaluate vital-sign alerts.

How the parts fit together

1. A supported device or connected system sends measurements into Ovok.
2. Ovok stores the clinical data as FHIR resources and forwards eligible vital-sign readings for enrolled Patients according to the documented Signals forwarding behavior.
3. Signals evaluates the data using the configured rules and returns alert decisions.
4. Your application reads alert episodes or individual alerts from Ovok, acknowledges them, and records workflow notes through Ovok.

Use the FHIR APIs for standard Patient and clinical-resource operations. Use /v1/signals routes for Signals alert feeds, per-patient bands, notes, and tenant settings. The FHIR Patient threshold route stores Ovok’s threshold model and can optionally push that model to Signals.

Before you call the routes

Requirement	Details
API host	The examples target https://api.sandbox.ovok.com. Use the API host for the environment your project belongs to.
Authentication	Send a valid project bearer token in Authorization. These are authenticated API routes.
Signals permissions	Configure the custom policy rows described in Signals route policies.
Patient permissions	Patient-specific operations also require the matching Patient interaction in the caller’s AccessPolicy. The Patient must belong to the token’s project.
Client applications	Integrations do not inherit a project admin’s Signals bypass. Give the ClientApplication its own exact Signals capability rows and Patient permissions.

The endpoints validate request shapes strictly. Unknown query parameters and unknown body fields are rejected. An invalid or expired token returns 401; insufficient capability, Patient access, or route role returns 403. A missing or out-of-scope Patient or alert generally returns 404. Signals transport failures are returned as 503 signals_unavailable, except where an endpoint has a more specific behavior.

Episodes and raw alerts

An episode groups a period of alerting for a Patient and a code. Episodes are available while the project’s episodicAlerts setting is on. Acknowledging an episode closes it; a later breach can open another episode.

A raw alert represents one individual Signals alert. Raw alerts remain available whether or not episodicAlerts is enabled. A reading can recover and resolve a raw alert without anyone acknowledging it; the acknowledged filter tracks acknowledgement separately from the alert’s status.

Alert objects include both patientId (the Ovok Patient id) and signalsPatientId (the id used by Signals). Use patientId in Ovok routes and FHIR references.

Signals API directory

Each API operation has its own page with request details, permissions, response behavior, and a cURL example. The Patient $enable-signals operation is also documented in the Ovok primitives reference.

Patient enrollment

Operation	Method	Path
Enable Signals for an existing Patient	POST	/fhir/R4/Patient/:id/$enable-signals

Patient threshold bands

Operation	Method	Path
Read Patient thresholds	GET	/v1/signals/patients/:patientId/thresholds
Set a Patient threshold	PUT	/v1/signals/patients/:patientId/thresholds/:code
Remove a Patient threshold	DELETE	/v1/signals/patients/:patientId/thresholds/:code

Alert episodes

Operation	Method	Path
List alert episodes	GET	/v1/signals/alerts
Read an episode	GET	/v1/signals/alerts/:episodeId
Acknowledge an episode	POST	/v1/signals/alerts/:episodeId/ack

Raw alerts

Operation	Method	Path
List raw alerts	GET	/v1/signals/raw-alerts
Read a raw alert	GET	/v1/signals/raw-alerts/:alertId
Acknowledge a raw alert	POST	/v1/signals/raw-alerts/:alertId/ack

Alert notes

Operation	Method	Path
List episode notes	GET	/v1/signals/alerts/:episodeId/notes
Add an episode note	POST	/v1/signals/alerts/:episodeId/notes
List raw-alert notes	GET	/v1/signals/raw-alerts/:alertId/notes
Add a raw-alert note	POST	/v1/signals/raw-alerts/:alertId/notes
Replace note text	PUT	/v1/signals/notes/:noteId
Edit note text	PATCH	/v1/signals/notes/:noteId
Delete a note	DELETE	/v1/signals/notes/:noteId

Project Signals settings

Operation	Method	Path
Read project settings	GET	/v1/signals/settings
Change project settings	PATCH	/v1/signals/settings

Related

• Signals — intended purpose, MDR status, and the boundary for your application
• Signals route policies — exact custom capability rows and Patient access rules
• FHIR resources — FHIR resource API reference
• FHIR Basics