Resolve refIds to Signals ids
- Sandbox: available
- Staging: available
- Production: unknown
An object from each patientRefId this tenant holds to its Signals id. A refId the tenant does not hold is left out rather than failing the request.
Through ovok
- Who can call it: Manager 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
patientRefId, 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 arefId; ovok asks Signals which patient a Signals id is.
AuthorizationBearer <JWT>patientRefId*array<string>The caller's refIds to resolve. Repeat the parameter or separate with commas.
An object mapping each found refId to its Signals id: { [refId]: id }.
curl -X GET 'https://api.sandbox.ovok.com/v1/signals/api/patient/ids?patientRefId=string'Create patients POST
Upserts on `refId`: posting a patient that already exists updates it rather than duplicating it, so a replayed provisioning run is safe. Each entry's `config` — flags and triggers — is applied in the same call, and `metadata` is merged. ### Through ovok - **Who can call it:** Manager apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_patients:update`. Project admins have every capability; client applications get no admin bypass. - ovok adds your project's submitter to each new patient and stamps `metadata.project` with your project. Sending `config` also needs `signals_config:update` and `signals_silence:update`. New patients count toward your plan's monitored-patient cap. - 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.
Get one patient GET
The patient with its config, triggers keyed by code. A SUBMITTER or SUBSCRIBER reads only patients it is attached to. ### 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), 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.