SlimSlim/Notifications

List alarm notifications

  • Sandbox: available
  • Staging: available
  • Production: unknown
GET
/v1/slim/notifications/alarms

Lists your project's device alarms and attention presses, filtered and paged. These are decided by the sending system; Ovok stores them as CommunicationRequests and forwards them.

Auth: Bearer token. The caller must be a practitioner, an admin, a super admin, or hold the "System Owner" access policy. The access policy must grant CommunicationRequest:read, CommunicationRequest:search and Observation:read (an admin or super admin who holds no access policy skips this check). Scope: The caller's project (from the token). The project query parameter is accepted but ignored.

Behaviour

  • One row per alarm episode. Each row's alarm carries the sender's own alarm id (episodeId), its severity, type and text, so the sender can match an acknowledgement to its own record.
  • type: deviceAlarm, attention, or both comma separated. Both when omitted.
  • severity: RED, YELLOW, ATTENTION, comma separated, as the sender coded the alarm. Every severity when omitted.
  • status defaults to active; an acknowledged alarm is completed.
  • sort: newest (default) or oldest, by event time (occurrenceDateTime, then authoredOn, then id).
  • patient, device, startDate, endDate, page, count, total and truncated work as on GET /v1/slim/notifications/oob: count is 1 to 100 (default 25), dates are inclusive UTC instants, and the list pages through at most the first 1,000 results (server-configurable).
  • Acknowledge a row with PATCH /v1/slim/notifications/{id}/ack.
  • Out-of-bed is on GET /v1/slim/notifications/oob; vital-sign alerts, decided by Signals, are on GET /v1/slim/notifications/medical.

Example

curl -X GET 'https://api.sandbox.ovok.com/v1/slim/notifications/alarms?type=deviceAlarm&severity=RED&sort=newest' \  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk'

Authorization

bearer
headerAuthorizationBearer <JWT>

Query Parameters

patient?string

Patient id or reference (Patient/{id})

device?string

Device id or reference (Device/{id})

project?string

project is ignored for scoping; server uses auth token project only.

status?string
Default"active"
Value in"active""completed""cancelled""draft""on-hold""revoked""unknown""entered-in-error"
startDate?string

Inclusive lower bound, as an ISO 8601 UTC instant. Honoured to the millisecond — the server does not re-bucket it to a calendar day in any timezone. Binds to activity time (_lastUpdated) when status=active, otherwise to event time (authoredOn).

Formatdate-time
endDate?string

Inclusive upper bound, as an ISO 8601 UTC instant. Honoured to the millisecond — the server does not re-bucket it to a calendar day in any timezone. Binds to activity time (_lastUpdated) when status=active, otherwise to event time (authoredOn).

Formatdate-time
page?string
Default"0"
count?string
Default"25"
type?string

Comma-separated: deviceAlarm, attention. Both when absent.

severity?string

Comma-separated: RED, YELLOW, ATTENTION, as the sender coded the alarm. Every severity when absent.

sort?string

Order by event time (occurrenceDateTime, then authoredOn): newest or oldest first.

Default"newest"
Value in"newest""oldest"

Response Body

Alarm notifications retrieved successfully.

application/json
  1. response
total*number
page*number
count*number
resources*array<>
truncated*
Example Request
curl -X GET 'https://api.sandbox.ovok.com/v1/slim/notifications/alarms'
Example Response
{  "total": 0,  "page": 0,  "count": 0,  "resources": [    {      "commId": "string",      "patientId": "string",      "patientName": "string",      "deviceId": "string",      "deviceName": "string",      "deviceStatus": "string",      "locationId": "string",      "locationName": "string",      "color": "string",      "trigger": "above",      "type": "hr",      "status": "draft",      "details": {        "threshold": 0,        "value": 0,        "level": "string"      },      "authoredOn": "2019-08-24T14:15:22Z",      "alertCount": 0,      "occurrenceDateTime": "2019-08-24T14:15:22Z",      "episodeEndedAt": "2019-08-24T14:15:22Z",      "effectiveTimestamp": "2019-08-24T14:15:22Z",      "latestObservationTimestamp": "2019-08-24T14:15:22Z",      "alarm": {        "episodeId": "string",        "severity": "RED",        "type": "string",        "text": "string"      },      "noteCount": 0,      "closeReason": "string"    }  ],  "truncated": {    "reason": "result-cap",    "limit": 0  }}

List out-of-bed notifications GET

Lists your project's out-of-bed notifications, filtered and paged. Out-of-bed is evaluated and recorded by Ovok as CommunicationRequests, and this is its feed. Medical notifications are not here; read `GET /v1/slim/notifications/medical` for those. **Auth:** Bearer token. The caller must be a practitioner, an admin, a super admin, or hold the "System Owner" access policy. The access policy must grant `CommunicationRequest:read`, `CommunicationRequest:search` and `Observation:read` (an admin or super admin who holds no access policy skips this check). **Scope:** The caller's project (from the token). The `project` query parameter is accepted but ignored. ## Behaviour - The notification type is fixed to out-of-bed; there is no `type` parameter. Prefer this route over the deprecated `GET /v1/slim/notifications?type=outOfBed`. - `status=active` lists the new notifications and `status=completed` the reviewed ones. Leave `status` out to list new and reviewed together; each row keeps its own `status`. An episode closed by hand without an acknowledgement is `revoked`, so it is in none of these lists; ask `status=revoked` for it. An episode that has ended but has not been acknowledged stays `active`, with an end-of-episode marker, so one resident can have more than one active row. - One row per out-of-bed episode, not per reading: the resident's open episode is updated in place. - Sort order: newest first by event time (`occurrenceDateTime`, then `authoredOn`, then id). - `patient` takes a Patient id or `Patient/{id}`. `device` takes a Device id, `Device/{id}`, or the device's identifier value. A Device id that does not exist returns an empty page rather than an unfiltered one. `device` matches the device that raised each alert, and each row's device and room are that device's, also after the resident moved to another device or was unassigned. - `startDate` and `endDate` are inclusive ISO 8601 UTC instants, used exactly as sent. They bind to the episode's last firing time (`occurrenceDateTime`), whatever the status. Either may be omitted. A missing `startDate` defaults to one year back for `status=active` and 30 days back otherwise. Without `status`, the new rows keep the one-year default and the reviewed rows the 30-day one, so the list holds exactly the rows of `status=active` and `status=completed` together. - Paging: `page` from 0, `count` from 1 to 100 (default 25). `total` is an exact count for the filter, the same on every page, cached for 15 seconds. It counts matching CommunicationRequests, so it is an upper bound on the rows you can page through. It reads `0` if the count lookup fails; the rows are unaffected. - The list pages through at most the first 1,000 results (server-configurable). `total` is clamped to that cap. When the cap or the per-request scan limit stops a page short, `truncated` says why: `{ reason: 'result-cap', limit }` or `{ reason: 'scan-budget', limit }`. `truncated` is `null` when the page is complete. - Acknowledge a row with `PATCH /v1/slim/notifications/{id}/ack`. ## Example ```bash curl -X GET 'https://api.sandbox.ovok.com/v1/slim/notifications/oob?status=active&page=0&count=25' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' ```

List medical notifications GET

Lists your project's medical notifications (heart rate, respiratory rate and other vital-sign alerts), newest last notification first, one page at a time. Medical episodes are decided by Signals; Ovok reads them from Signals, adds the resident context, and never re-derives a clinical value. **Auth:** Bearer token. The caller must be a practitioner, an admin, a super admin, or hold the "System Owner" access policy. The access policy must grant `Patient:read`, `Device:read` and `Location:read` (an admin or super admin who holds no access policy skips this check). **Scope:** The caller's project (from the token), applied on both sides: Signals filters on the resident's project stamp, and Ovok checks each resolved resident against your project. ## Behaviour - Order: newest last notification first. That is `episode.lastFiringAt`, the newest reading outside the band, or `episode.openedAt` for an episode stored without one (before 2026-09-28). An open episode that fires again moves up, so while you read page 2 it can move to page 1. It is never listed twice, and the next read of page 1 shows it. - One row per episode, not per reading: a run of readings outside the band is one episode, which closes on recovery or acknowledgement. - Each row has three blocks. `episode` is the Signals episode with its aggregates. `carehub` is the resident context Signals does not hold: resident, room and bed, device, zone. `patientName` is the resident's Resident ID, also after a discharge, an unassign or a device move. The room, bed, device and zone are those of the device the episode was raised on, also after the resident moved to another device or was unassigned. They are `null` when that device is not known or is no longer in your project. `acknowledgement` is `null` until someone acknowledges the episode. - Use `episode.id` with `GET /v1/slim/notifications/medical/{episodeId}` to get the full value history. - `episode.firedBand` is the band the episode was judged under: the band Signals recorded when it fired, or else the band rebuilt from Signals' configuration history at the episode's trigger version. It is not the resident's current band, so editing a threshold does not change past rows. `min` and `max` are each nullable (a band can be one-sided). `firedBand` is `null` when the band cannot be established; that never fails the read. - Filters: `status` (`OPEN` or `CLOSED`, both when omitted), `since` (episodes whose last notification, as in the order above, is at or after this ISO 8601 instant), `acknowledged` (`true`, `1` or `yes` for acknowledged only; any other value for unacknowledged only; both when omitted). - `patient` narrows the feed to one resident, by Medplum `Patient.id` (the `carehub.patientId` a row returns). It does not change the project scope. A resident who cannot be resolved, or who is in another project, answers 404 rather than an unfiltered page. - `codes` narrows the feed to these LOINC codes, comma separated, at most 32 (for example `8867-4,9279-1`). Perfusion index is `PI`. Signals applies the filter. Out-of-bed is never in this feed. - Paging: `limit` is 1 to 200 (default 50). Pass the previous page's `nextCursor` as `cursor`. Page until `nextCursor` is `null`, not until a short page arrives: rows whose resident cannot be resolved into your project are dropped after Signals counted them. - A resident with no Signals project stamp matches no project and does not appear. - When the project's Signals tenant has episodic alerts switched off, the page is empty. - Out-of-bed is served by `GET /v1/slim/notifications/oob`. - A 503 with `signals_unavailable` means Signals could not be reached; retry after `retryAfterSec`. ## Example ```bash curl -X GET 'https://api.sandbox.ovok.com/v1/slim/notifications/medical?status=OPEN&codes=8867-4,9279-1&limit=50' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' ```