OVOK DOCS
Get startedOvokSignalsSDKsGuidesAPI referenceDeveloper resources
Signals API - Patients

Detach a patient from a submitter

  • Sandbox: available
  • Staging: available
  • Production: unknown
DELETE
/v1/signals/api/submitter/{id}/patients/{patientId}

The submitter may no longer post readings for the patient.

Through ovok

  • Who can call it: Manager apps, and users whose access policy grants the capabilities.
  • Capabilities, all required: signals_associations:update. Project admins have every capability; client applications get no admin bypass.
  • Your project's own submitter stays attached to its patients.
  • 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 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>

Path Parameters

id*string

The client's clientId: the value a patient's submitters/subscribers hold.

patientId*string

The Signals patient id.

Response Body

The pair that was detached.

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

Attach patients to a submitter POST

Grants the client permission to post readings for those patients. Unknown patient ids are skipped, so a caller can re-post a superset of ids without a 404. ### Through ovok - **Who can call it:** Manager apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_associations:update`. 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 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 subscriber's patients GET

The ids of the patients in this tenant the subscriber reads and receives alerts 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.