SlimSlim/User

Get terms and conditions consent

  • Sandbox: available
  • Staging: available
  • Production: unknown
GET
/v1/slim/user/terms-and-conditions-consent

Returns whether the signed-in practitioner has accepted the current terms and conditions. Use it to decide whether to show the terms prompt.

Auth: Bearer token for a practitioner session (the profile must be a Practitioner). The caller's access policy must grant Consent:read and Consent:search (a project admin who holds no access policy skips this check). Scope: The caller's practitioner profile in the caller's project (from the token).

Behaviour

  • termsAndConditionsConsent is true only when an acceptance is on file and either matches the currently published terms version or no version has been published yet.
  • Publishing new terms turns it false for everyone until they accept again.
  • The published version is the one of the root project of your project tree: a child project follows its parent's terms. Without one, the platform-wide version applies.
  • GET /v1/me/consent/legal returns the same acceptance with its dates and terms link.

Example

curl -X GET 'https://api.sandbox.ovok.com/v1/slim/user/terms-and-conditions-consent' \  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk'

Authorization

bearer
headerAuthorizationBearer <JWT>

Response Body

Terms and conditions consent status retrieved successfully.

application/json
  1. response
termsAndConditionsConsent*boolean
Example Request
curl -X GET 'https://api.sandbox.ovok.com/v1/slim/user/terms-and-conditions-consent'
Example Response
{  "termsAndConditionsConsent": true}

Get realtime trends graphs GET

Returns the resident's readings from Signals, one data point per reading, in the same shape as `GET /v1/slim/trends/graphs`. Use it for the live part of a chart, or to look at any day of the last 14. **Auth:** bearer token. The caller must be a practitioner, an admin or a System Owner, and needs `Organization:read`, `Device:read`, `Patient:read` and `DocumentReference:read`. **Scope:** the resident must be in the caller's project or one of its sub-projects (not its parent). A resident outside that scope answers `404`, the same as one that does not exist. ## Behaviour - The chart covers exactly `[startTime, endTime]`. Unlike `/graphs`, it does not snap to monitoring days. - Every reading in the window comes back as Signals recorded it, oldest first: one data point per reading, at the reading's own time, with its own value. Nothing is bucketed or averaged, and no empty points are added between readings, so a silent device shows as a stretch with no points. A reading with no numeric value comes back with `data: null`. - The response grows with the device's cadence: a day of readings every 30 seconds is about 2,900 points per graph type. - The readings are the resident's, whatever device they wear now: a resident whose device was unassigned or moved to someone else, or who was discharged, still gets every reading Signals holds for them in the window. A resident who takes over a device gets only the readings sent after they took it. - Readings are charted under one key: the resident's most recently assigned device, keyed as on `/graphs`. A resident with no device now is charted under the device they wore last, so the key does not change when the device is taken away, and a resident who never wore one under `Patient/<id>`. Signals readings carry no device, so a resident whose device changed inside the window shows one key here where `/graphs` shows one per device. - Threshold and baseline values are the same as `/graphs`. `stats` are computed over every reading in the window. - Every graph type in the table below can be charted. Only `heartRate` and `respiratoryRate` carry threshold and baseline values. Each point carries the limit in force at its own time, as on `/graphs`, so the lines step where a limit changed inside the window. - `startTime` must not be after `endTime`, the window may span at most 24 hours, and `startTime` must not be more than 14 days ago. A request that breaks one of these fails validation. - Readings are charted by when they were observed, or by when Signals stored them when no observed time exists. Late-arriving readings are included. - A graph type with no readings in the window is `{}`. - If Signals cannot be reached, does not answer within 12 seconds, or holds more readings than one request can page through, the route returns `503` with `error: "signals_unavailable"` and a `retryAfterSec` value, rather than a partial or empty chart. - Results are cached for up to 15 seconds. Both request times are rounded down to that interval, and the readings returned are those of the rounded window, so a repeated poll can show a window up to 15 seconds old. A result over 128 KB (most full days) is not cached. - A chart reads this once per page load. Each caller may make 20 requests a minute; past that the route returns `429` with `Retry-After`. When too many realtime reads are already running on the server, it returns `503` with `error: "signals_unavailable"` and `retryAfterSec` at once, before reading anything. ## Graph types Each type charts every Signals reading recorded under one of its codes. The names are the dashboard telemetry's, so pulse rate by pulse oximetry is `pulseRate` and never part of `heartRate`. | `graphType` | Codes | | ------------------------ | ---------------------------------------------------------------- | | `heartRate` | `8867-4`, `43149-4` | | `respiratoryRate` | `9279-1` | | `oxygenSaturation` | `59408-5`, `2708-6` | | `pulseRate` | `8889-8` (heart rate by pulse oximetry) | | `perfusionIndex` | `61006-3`, `PI` (Kinderspitex's own vital code, not LOINC) | | `bodyTemperature` | `8310-5` | | `systolicBloodPressure` | `8480-6` | | `diastolicBloodPressure` | `8462-4` | | `heartRateVariability` | `80404-7` | ## Example cURL request ```bash curl -X GET \ 'https://api.sandbox.ovok.com/v1/slim/trends/realtime?patientId=c3499c27-2973-0a7f-807e-fb8676a92dcb&startTime=2026-01-01T12:00:00Z&endTime=2026-01-02T12:00:00Z&graphType=heartRate,respiratoryRate' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' ```

Update terms and conditions consent POST

Accepts or withdraws the terms and conditions for the signed-in practitioner. Other consents are not changed. **Auth:** Bearer token for a practitioner session (the profile must be a `Practitioner`). The caller's access policy must grant `Consent:read`, `Consent:search`, `Consent:create` and `Consent:update` (a project admin who holds no access policy skips this check). **Scope:** The caller's practitioner profile in the caller's project (from the token). ## Behaviour - `true` records acceptance of the currently published terms version. `false` withdraws it. - The acceptance is also kept as a legal `Consent` in your project: accepting creates or re-activates it with a link to the terms page of your project's practitioner app; withdrawing revokes it with reason `withdrawn`. - Repeating the same value writes nothing. The call is idempotent. - The consent answers of `/v1/me/consent/*` are refreshed right away. - Returns the resulting `termsAndConditionsConsent`. ## Example ```bash curl -X POST 'https://api.sandbox.ovok.com/v1/slim/user/terms-and-conditions-consent' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' \ -H 'Content-Type: application/json' \ -d '{ "termsAndConditionsConsent": true }' ```