Get terms and conditions consent
- Sandbox: available
- Staging: available
- Production: unknown
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
termsAndConditionsConsentistrueonly 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
falsefor 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/legalreturns 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'bearerAuthorizationBearer <JWT>Terms and conditions consent status retrieved successfully.
application/json- response
termsAndConditionsConsent*booleancurl -X GET 'https://api.sandbox.ovok.com/v1/slim/user/terms-and-conditions-consent'{ "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 }' ```