Create a share invite
- Sandbox: available
- Staging: available
- Production: unknown
The signed-in patient creates a one-time invite to share Observations with the given codes with another patient. Set includeMedications to true to also share patient-scoped MedicationStatements and MedicationAdministrations. Hand the inviteId and code to the other patient, who accepts with POST /v1/patient-sharing/invites/redeem.
Auth: bearer token of a Patient. Scope: the caller's project (from the token).
Behaviour
- Patient sharing must be on for the project (
PUT /v1/patient-sharing/settings). codes: 1 to 100 Observation codes, each 1 to 64 letters, digits,.or-. Duplicates are removed.includeMedications: optional, defaults tofalse. When true, the recipient can read the sharer's MedicationStatements and MedicationAdministrations until the share ends.endsAtmust benull: a share lasts until it is ended. A date is refused for now.- The invite is stored as a draft
Consent. Only a SHA-256 hash ofcodeis stored, socodeis returned once, in this response. - The invite expires 15 minutes after it is created (
expiresAt). - A patient can hold at most 10 unexpired invites at once.
- A 429 means the patient already holds 10 unexpired invites.
Example
curl -X POST 'https://api.sandbox.ovok.com/v1/patient-sharing/invites' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' \ -H 'Content-Type: application/json' \ -d '{ "codes": ["8480-6", "8462-4"], "endsAt": null, "includeMedications": true }'bearerAuthorizationBearer <JWT>application/json- body
codes*array<>1 <= items <= 100endsAt*stringdate-timeincludeMedications?booleanfalseThe invite ID, its one-time code (returned only here) and its expiry.
application/json- response
inviteId*stringcode*stringexpiresAt*stringcurl -X POST 'https://api.sandbox.ovok.com/v1/patient-sharing/invites' \ -H 'Content-Type: application/json' \ -d '{ "codes": [ "string" ], "endsAt": "2019-08-24T14:15:22Z"}'{ "inviteId": "string", "code": "string", "expiresAt": "string"}Update patient sharing settings PUT
Turns patient-to-patient sharing, and the patient and practitioner invites (`/v1/invites`), on or off for the caller's project. **Auth:** bearer token of a project admin. **Scope:** the caller's project (from the token). ## Behaviour - `enabled` is required. Turning it on creates the read-only sharing template AccessPolicy, or brings an existing one up to date, in the same atomic write as the setting. The template lets a recipient read and search the sharer's Observations with the shared codes, and read the sharer's Patient resource with contact details, identifiers and most other fields hidden. - Turning `enabled` off stops new invites and redemptions. Existing shares stay until they are ended. - `enabled` also lets a signed-in patient share Observation codes with a related person by email (`POST /v1/invites/record-share` with `"recipient": "related-person"`). A new address gets a related-person account when it accepts, with a built-in base policy that reads only its own RelatedPerson; it is created the first time it is needed. Map `RELATED_PERSON_INVITED` and `RELATED_PERSON_RECORD_SHARED`, or the `PATIENT_INVITE` and `PATIENT_ASSIGNMENT_REQUEST` templates they fall back to: an invite whose email cannot be sent is undone. - `practitionerSharingEnabled` does the same for the patient and practitioner invites, with the practitioner share's template. Leave it out or send `null` to keep its current value. - Both are off by default. The response is the settings after the write, as `GET /v1/patient-sharing/settings` returns them. - With `practitionerSharingEnabled` on, a signed-in patient can create a practitioner account (with the project's default practitioner access policy) for a new address, and a practitioner can create a patient account, each holding the share. Make sure that policy gives a new practitioner nothing a patient should not hand out. Map the `PATIENT_INVITE`, `PATIENT_ASSIGNMENT_REQUEST`, `PRACTITIONER_INVITED_BY_PATIENT` and `PRACTITIONER_PATIENT_SHARED` email templates first: an invite whose email cannot be sent is undone. - Do not turn on `practitionerSharingEnabled` in projects whose practitioners use the carehub dashboard: its route guard checks resource types only, so a practitioner who only holds shared patients could see project-wide data there. - `practitionerAlertDigest` turns the clinician alert digest on or off: `{ "enabled": true, "everyHours": 6 }`, where `everyHours` is 1, 6, 12 or 24. Leave `everyHours` out to keep the saved hours (6 until set). Leave the whole field out, or send `null`, to keep the digest as it is. - Switching it on needs Signals annotations (`SIGNALS_ANNOTATE_OBSERVATIONS`), `enabled` and `practitionerSharingEnabled` all on; otherwise the write is refused with 409 `SETTING_NOT_AVAILABLE`. A write that only keeps it on is not checked, so sharing can still be turned off. While any of the three is off, no digest goes out. - Every `everyHours`, each practitioner on an active practitioner share gets one email listing their patients with new Signals alerts: the patient's name, how many new alerts, and a link to the patient's alerts in the dashboard. It carries no reading or value, and nothing goes out when there are no new alerts. - It counts alerts from the moment it was switched on, never the backlog before. Switching it off, or one of its prerequisites going off, forgets where it was, so switching it on again starts afresh. - Each digest covers alerts up to an hour before it goes out: alerts reach FHIR through a flush that can lag, and an alert that arrives more than an hour late is not counted. - Map the `PRACTITIONER_ALERT_DIGEST` email template first. - A 409 without a code means the project's settings changed during the write. Read the settings again and retry. ## Example ```bash curl -X PUT 'https://api.sandbox.ovok.com/v1/patient-sharing/settings' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' \ -H 'Content-Type: application/json' \ -d '{ "enabled": true, "practitionerSharingEnabled": null, "practitionerAlertDigest": { "enabled": true, "everyHours": 6 } }' ```
Accept a share invite POST
The signed-in patient accepts another patient's share invite, and from then on can read what it shares. **Auth:** bearer token of a Patient. **Scope:** the caller's project (from the token). ## Behaviour - Patient sharing must be on for the project. - The invite is single use, expires 15 minutes after it was created, and cannot be accepted by the patient who made it. - On success the invite's `Consent` becomes `active` and names the caller as recipient, and a grant is added to the caller's membership, in one atomic write. The caller's cached sessions are refreshed, so the new access applies on the next request. - The grant lets the caller read and search the sharer's Observations with the shared codes, and read the sharer's Patient resource with contact details, identifiers and most other fields hidden. - A share also grants a multi-value reading's group Observation when it covers every value the group repeats (systolic and diastolic for blood pressure, the waveform for an ECG, any part of an SpO2 or urine-strip reading), so the whole reading can be read and nothing more. The share's `codes` stay as the sharer chose them. - A 409 that says your account changed meanwhile can be retried as is. - A 503 means sharing is on but its template AccessPolicy is missing. ## Example ```bash curl -X POST 'https://api.sandbox.ovok.com/v1/patient-sharing/invites/redeem' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' \ -H 'Content-Type: application/json' \ -d '{ "inviteId": "c3499c27-2973-0a7f-807e-fb8676a92dcb", "code": "<code from the invite>" }' ```