Signals route policies

Ovok protects its Signals API with custom AccessPolicy rows. These rows are not FHIR resource types. They express what a caller may do through Ovok's Signals routes, and they are checked in addition to the caller's access to the affected Patient.

Custom capability rows

Add the exact resource type and interaction shown below to the AccessPolicy. A catch-all FHIR rule does not grant these capabilities.

AccessPolicy resourceType	Interaction	Grants
signals_alerts	read	Read alert episodes, raw alerts, and their notes.
signals_alerts	update	Acknowledge alerts and create, edit, or delete alert notes, subject to the note's author and route checks.
signals_config	read	Read project Signals settings and a patient's thresholds.
signals_config	update	Enable Signals for a patient, change patient thresholds, or request project Signals settings changes, subject to additional checks.
signals_silence	update	Perform changes that reduce the likelihood of an alert, including deleting or loosening a threshold or disarming alert behavior.

In policy data these are resource[] rules: resourceType is signals_alerts, signals_config, or signals_silence, and interaction contains read or update. The route guard checks the exact custom row. An AccessPolicy row for * does not grant a Signals capability.

Patient access still applies

For a route tied to a patient, the caller also needs the matching Patient interaction in the same policy:

• Reading a patient's thresholds requires Patient read access.
• Updating or deleting a patient's threshold, or enabling Signals for the patient, requires Patient update access.
• The patient must belong to the current project. Signals routes do not allow a project admin or integration to cross that project boundary.

The alerts and raw-alerts collection endpoints only return results for patients the caller can read. For individual alert and note operations, Ovok checks the relevant patient and applies the route's capability requirement.

Route reference

All paths below use the /v1/signals prefix.

Operation	Method and path	Custom capability	Additional authorization
List patient thresholds	GET /patients/:patientId/thresholds	signals_config:read	Patient read
Set a patient threshold	PUT /patients/:patientId/thresholds/:code	signals_config:update	Patient update; loosening a threshold also requires signals_silence:update and a reason
Delete a patient threshold	DELETE /patients/:patientId/thresholds/:code	signals_silence:update	Patient update and a reason
List alert episodes	GET /alerts	signals_alerts:read	Results are limited to readable patients
Read an alert episode	GET /alerts/:episodeId	signals_alerts:read	Access to the episode's patient
Acknowledge an alert episode	POST /alerts/:episodeId/ack	signals_alerts:update	Access to the episode's patient
List raw alerts	GET /raw-alerts	signals_alerts:read	Results are limited to readable patients
Read a raw alert	GET /raw-alerts/:alertId	signals_alerts:read	Access to the alert's patient
Acknowledge a raw alert	POST /raw-alerts/:alertId/ack	signals_alerts:update	Access to the alert's patient
Read alert notes	GET /alerts/:episodeId/notes, GET /raw-alerts/:alertId/notes	signals_alerts:read	Access to the related alert
Add an alert note	POST /alerts/:episodeId/notes, POST /raw-alerts/:alertId/notes	signals_alerts:update	Access to the related alert
Edit or delete a note	PUT, PATCH, or DELETE /notes/:noteId	signals_alerts:update	Note ownership and project checks also apply
Read project Signals settings	GET /settings	signals_config:read	Project scope
Change project Signals settings	PATCH /settings	signals_config:update	Project admin; some settings require Super Admin. Disarming additionally requires signals_silence:update and a reason.

FHIR threshold endpoints also use the custom policy checks:

Operation	Method and path	Required custom capabilities	Patient interaction
Update a patient threshold	PUT /fhir/R4/Patient/:id/threshold (also the unversioned and R5 aliases)	signals_config:update and signals_silence:update	Patient update
Enable Signals for a patient	POST /fhir/R4/Patient/:id/$enable-signals (also the unversioned and R5 aliases)	signals_config:update	Patient update

Example policy

This example gives a ward team read access to its patients, update access where monitoring workflows require it, and the Signals capabilities used by those workflows. Replace the organization reference and interactions with the scope your application needs.

{
  "resourceType": "AccessPolicy",
  "name": "Ward Signals team",
  "resource": [
    {
      "resourceType": "Patient",
      "criteria": "Patient?organization=Organization/ward-a",
      "interaction": ["read", "search"]
    },
    {
      "resourceType": "Patient",
      "criteria": "Patient?organization=Organization/ward-a",
      "interaction": ["update"]
    },
    {
      "resourceType": "signals_alerts",
      "interaction": ["read", "update"]
    },
    {
      "resourceType": "signals_config",
      "interaction": ["read", "update"]
    },
    {
      "resourceType": "signals_silence",
      "interaction": ["update"]
    }
  ]
}

The example is illustrative: confirm that the criteria matches your Patient data and that every interaction is needed. A Signals capability does not widen the Patient scope. Conversely, Patient access alone does not grant the matching Signals operation.

Grant signals_silence:update only to roles that are allowed to weaken or remove a threshold or disarm alert behavior. It is intentionally separate from ordinary threshold configuration.

Admin and integration behavior

Super Admins and project admins pass the custom capability check for project users. Project scope and Patient project membership checks still apply. ClientApplication callers do not receive the admin bypass, even if marked as an admin; grant an integration the exact capability rows it needs.

Signals settings have stricter route-specific checks beyond the AccessPolicy: changing project settings requires a project admin, and changing selected high-impact fields requires Super Admin. See the Signals overview for its role in the Ovok architecture and regulatory context.

Related

• Working with Signals as a connected part of Ovok
• AccessPolicy model and membership
• Default policies
• Signals
• DEFAULT_PRACTITIONER_ACCESS_POLICY