Signals API - Patients

Create patients

  • Sandbox: available
  • Staging: available
  • Production: unknown
POST
/v1/signals/api/patient

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.

Authorization

headerAuthorizationBearer <JWT>

Request Body

application/json
  1. body
patients*array<>

Response Body

The patients as stored, in request order.

application/json
  1. response
[index: integer]?
Example Request
curl -X POST 'https://api.sandbox.ovok.com/v1/signals/api/patient' \  -H 'Content-Type: application/json' \  -d '{  "patients": [    {      "refId": "string"    }  ]}'
Example Response
[  {    "id": "string",    "tenantId": "string",    "refId": "string",    "name": "string",    "submitters": [      "string"    ],    "subscribers": [      "string"    ],    "alertIfEmpty": true,    "alertIfNote": true,    "alertInactiveDays": 0,    "alertsPaused": true,    "metadata": {},    "configUpdatedAt": "2019-08-24T14:15:22Z",    "lastSeenAt": "2019-08-24T14:15:22Z",    "createdAt": "2019-08-24T14:15:22Z",    "updatedAt": "2019-08-24T14:15:22Z",    "email": "string",    "bsn": "string",    "umoId": "string",    "dateOfBirth": "string",    "tags": {},    "manager": "string",    "_id": "string",    "tenant": "string",    "config": {      "alertIfEmpty": true,      "alertIfNote": true,      "alertInactiveDays": 0,      "updatedAt": "2019-08-24T14:15:22Z",      "triggers": {        "property1": {          "code": "string",          "system": "string",          "display": "string",          "valueKey": "string",          "constants": {},          "logic": {},          "metadata": {},          "version": 0,          "updatedAt": "2019-08-24T14:15:22Z"        },        "property2": {          "code": "string",          "system": "string",          "display": "string",          "valueKey": "string",          "constants": {},          "logic": {},          "metadata": {},          "version": 0,          "updatedAt": "2019-08-24T14:15:22Z"        }      }    }  }]

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.

Resolve refIds to Signals ids GET

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 a `refId`; ovok asks Signals which patient a Signals id is.