OVOK DOCS
Get startedOvokSignalsSDKsGuidesAPI referenceDeveloper resources
Signals API - Patients

Delete a patient

  • Sandbox: available
  • Staging: available
  • Production: unknown
DELETE
/v1/signals/api/patient/{id}

Deletes the patient with its triggers, alerts, episodes and readings. This can't be undone through the API.

Through ovok

  • Who can call it: Manager apps, and users whose access policy grants the capabilities.
  • Capabilities, all required: signals_patients:delete. 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 delete. 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>

Path Parameters

id*string

The Signals patient id.

Response Body

Deleted: the id of the patient that is gone.

application/json
  1. response
_id*string
id*string
Example Request
curl -X DELETE 'https://api.sandbox.ovok.com/v1/signals/api/patient/string'
Example Response
{  "_id": "string",  "id": "string"}

Update a patient POST

Only the fields present are changed; `metadata` is merged, not replaced. Answered with the v1 document. ### 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. - When you send `submitters` or `metadata`, ovok keeps your project's submitter and stamp in them. Sending `alertsPaused`, `alertIfEmpty`, `alertIfNote` or `alertInactiveDays` also needs `signals_config:update` and `signals_silence:update`. - 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, and one a `refId` in the body names, must be ones 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 a submitter's patients GET

The ids of the patients in this tenant the submitter may post readings for. ### Through ovok - **Who can call it:** Manager apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_associations:read`. Project admins have every capability; client applications get no admin bypass. - It can reach any patient of your project without naming one, so it is for callers that reach every patient: project admins, manager or submitter apps, and anyone whose Patient access has no criteria.