Read the config status of many patients
- Sandbox: available
- Staging: available
- Production: unknown
Each patient's configUpdatedAt and trigger codes, so a caller can confirm a push landed without re-reading every trigger; triggerFingerprints adds what each rule says.
Exactly one row per requested id, in the order asked. An id that resolves to nothing answers refId: null with no codes, as v1 did.
A POST because the id list is the request; it writes nothing.
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), every patient the body names 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.
AuthorizationBearer <JWT>application/json- body
ids*array<string>One status row per requested id, in request order.
application/json- response
[index: integer]?curl -X POST 'https://api.sandbox.ovok.com/v1/signals/api/patient/config/bulk-status' \ -H 'Content-Type: application/json' \ -d '{ "ids": [ "string" ]}'[ { "id": "string", "refId": "string", "configUpdatedAt": "2019-08-24T14:15:22Z", "triggerCodes": [ "string" ], "triggerFingerprints": [ { "code": "string", "fingerprint": "string", "updatedAt": "2019-08-24T14:15:22Z" } ] }]Write a different config to each of many patients POST
The per-patient form, each entry with its own triggers, flags, `metadata` and `resolvedAt`. `results[]` has v1's `{id, matched, modified}` per entry; `staleIgnored` and `misses` are additions. ### 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. - A patient stamped with another project is refused. - If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), every patient the body names 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.
List patients GET
Scoped to what the caller may see: a MANAGER gets the tenant, a SUBMITTER or SUBSCRIBER only the patients it is attached to. Newest first. v1's paginate envelope, driven by `page` and `limit` (default 10). A page may start at most 10000 rows in; past that, walk with the keyset `cursor`: pass `nextCursor` back verbatim, and `null` means the last page. ### Through ovok - **Who can call it:** Manager apps and Submitter apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_patients: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), name them with `ids`, each one you can read, at most 100. Signals then pages over just those patients, so pages and totals stay true. 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.