Signals API - Settings

Get a patient's own rule settings

  • Sandbox: available
  • Staging: available
  • Production: unknown
GET
/v1/signals/api/patient/{id}/settings

{} when none were written.

Signals stores settings as given and reads it only through the triggers it holds (triggers, the home's and the resident's own): what each other key means is theirs, so the object is checked for shape and size only. The default pack reads bands — per code { low?, high? }, { mode: 'baseline', pct, low?, high? } (outside either band fires; a patient's own baseline band with no sides of its own is judged alone) or "NO_THRESHOLD" — and outOfBed: { limitSeconds, enabled?, returnSeconds?, window?: { start: 'HH:MM', end: 'HH:MM', timeZone } }. A patient's own key wins over the org's; extra keys are ignored. See tech/RULES-ENGINE.md.

Through ovok

  • Who can call it: Manager apps, and users whose access policy grants the capabilities.
  • Capabilities, all required: signals_config:read. Project admins have every capability; client applications get no admin bypass.
  • If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), the patient must be one you can read. A patient is named by its Signals id, or by its Medplum Patient id where Signals takes a refId; ovok asks Signals which patient a Signals id is.

Authorization

headerAuthorizationBearer <JWT>

Path Parameters

id*string

The Signals patient id.

Response Body

The settings.

application/json
  1. response
patientId*string
settings*

Opaque to Signals beyond triggers; the triggers give the other keys their meaning.

Example Request
curl -X GET 'https://api.sandbox.ovok.com/v1/signals/api/patient/string/settings'
Example Response
{  "patientId": "string",  "settings": {}}

Detach a patient from a subscriber DELETE

The subscriber no longer reads the patient's records or receives its alerts. ### Through ovok - **Who can call it:** Manager apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_associations:update`. Project admins have every capability; client applications get no admin bypass. - If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), the patient must be one you can update. A patient is named by its Signals id, or by its Medplum Patient id where Signals takes a `refId`; ovok asks Signals which patient a Signals id is.

Replace a patient's own rule settings PUT

Replaced whole. The triggers read them beside the org's, as `settings.individual`. Audited as `UPDATE_PATIENT_SETTINGS`. For each patient the write reaches, judged by its own settings over the org's: a band changed ends the episode judged under the old one `THRESHOLD_CHANGED`; a code switched off (its band `"NO_THRESHOLD"`, or out of bed `enabled: false`) has its active alert resolved and its open episode closed `THRESHOLD_CHANGED` at the save, the other codes' left alone; an acknowledged out-of-bed absence, whose episode the ack closed, has its still-active alert resolved; a band deleted closes nothing. A body whose `settings` has no `triggers` key keeps the stored `triggers` (the home defaults seeded by Signals, or triggers pushed through the config routes); a body that sends `triggers`, `{}` included, replaces them. The body may carry `resolvedAt` (ISO 8601), when the caller resolved this write: it lands only over a stored write resolved earlier, or stored without one, and is otherwise refused 409 `STALE_SETTINGS` with nothing written or audited. A write without `resolvedAt` always lands and keeps the stored stamp. Signals stores `settings` as given and reads it only through the triggers it holds (`triggers`, the home's and the resident's own): what each other key means is theirs, so the object is checked for shape and size only. The default pack reads `bands` — per code `{ low?, high? }`, `{ mode: 'baseline', pct, low?, high? }` (outside either band fires; a patient's own baseline band with no sides of its own is judged alone) or `"NO_THRESHOLD"` — and `outOfBed`: `{ limitSeconds, enabled?, returnSeconds?, window?: { start: 'HH:MM', end: 'HH:MM', timeZone } }`. A patient's own key wins over the org's; extra keys are ignored. See tech/RULES-ENGINE.md. ### Through ovok - **Who can call it:** Manager apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_config:update`, `signals_silence:update`. Project admins have every capability; client applications get no admin bypass. - `resolvedAt` may be at most 5 minutes ahead of now. - If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), the patient must be one you can update. A patient is named by its Signals id, or by its Medplum Patient id where Signals takes a `refId`; ovok asks Signals which patient a Signals id is.