Create patient

Creates a resident (patient), optionally placed on devices, in a room and in a zone, and registers them with Signals.

Auth: Bearer token. The caller must be a practitioner, an admin, a super admin, or hold the "System Owner" access policy. The access policy must grant Patient:create, plus Device:update when deviceId is set (an admin or super admin who holds no access policy skips this check). Scope: The resident is created in the caller's project (from the token). A super-admin caller can pass ?projectId=<uuid> to create it in that project instead. Any other caller who passes projectId gets a 403. Devices, rooms and zones you reference must be in your project, its parent project, or one of its sub-projects.

Behaviour

• name must contain an entry with use: "nickname" and a non-blank first given value. This is the Resident ID.
• The Resident ID must be unique in the project, compared as in POST /v1/slim/patient/check-name-exists.
• admissionDate defaults to now. It cannot be later than the start of the current day.
• The resident is created as active, and an EpisodeOfCare is opened for the admission.
• Placement:
  • deviceId (one id or a list): the resident is assigned to those devices. A device that already has a resident is reassigned to the new one, and the resident who had it loses it, with its room, as on PUT /v1/slim/patient/{id}.
  • locationId with deviceId: those devices are also moved to the room.
  • locationId without deviceId: the resident is assigned to the room's device. The room must have exactly one device.
  • organizationId without locationId or deviceId is refused with 422: a resident's zone is read from their device, so a zone alone would not show.
  • organizationId: the resident is placed in the zone. When deviceId is set, those devices and their rooms move to the zone too.
  • Without organizationId, the resident's zone is their device's: the room's zone, else the device's own. Devices in more than one zone are refused with 422.
• The resident is registered with Signals in the same request. If that fails, everything this request wrote is rolled back and you get a 503 with error: "signals_mint_failed". You can retry.
• The write is atomic and locks the Resident ID and the devices, so two concurrent creates of the same Resident ID leave one resident.
• Change-history entries are added for each assignment, including the zone the resident gets from their device, and for a resident who lost a device to the new one.
• The response is the created resident, in the same shape as GET /v1/slim/patient/{id}.
• If the resident cannot be registered with Signals, the create is rolled back and the request fails with 503. Retry it.

Example

curl -X POST 'https://api.sandbox.ovok.com/v1/slim/patient' \  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' \  -H 'Content-Type: application/json' \  -d '{    "name": [      { "use": "nickname", "given": ["Maxi"] },      { "use": "official", "given": ["Max"], "family": "Mustermann" }    ],    "gender": "male",    "birthDate": "1940-05-01",    "deviceId": "c3499c27-2973-0a7f-807e-fb8676a92dcb",    "locationId": "c3499c27-2973-0a7f-807e-fb8676a92dcb",    "organizationId": "87ea5dfc-8b8e-384d-8489-79496e706390"  }'