List patients

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 ```bash 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" }' ```