Get medical notification

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' ```