Add Patient

---

Use the Patient details section in the Appointment request screen to select or add a patient profile.

The selected patient defines the identity details shared with the doctor during the appointment flow.

This screen includes

• An Add a new patient modal header with a close (X) control.
• A Patient details section with required fields:
  • First name.
  • Last name.
  • Date of birth with a date picker icon.
• A gender selector
• Action buttons:
  • Close, which dismisses the modal without saving changes.
  • Add new patient, which remains disabled until all required fields contain valid values

---

Workflow

1. Open Appointment request.
2. Select Patient name under Patient details.
   
3. Select an existing patient or select Add new patient.
   
4. Enter the required patient details or edit the existing patient.
   
5. Select Add new patient to confirm.
6. Continue the appointment request flow.

---

Latinized Patient Name

The patient form accepts non-Latin characters in First name and Last name.

When either field contains non-Latin characters, the runtime displays the corresponding Latin-script field:

• First name in Latin letters
• Last name in Latin letters

Field visibility is controlled by PATCH /patients/create/validate.

---

Validations

Scenario	App behavior
A required field is empty	The app highlights the field and blocks submission.
Date of birth contains an invalid value	The app shows a validation state and blocks submission.
No patient selection exists	The app blocks progress to the next step.

Actions

Action	Result
Select an existing patient	The app updates the patient context and closes the selector.
Select Add new patient	The app opens the patient creation modal.
Select Close	The app dismisses the modal without changes.
Select Add new patient in the modal	The app creates the profile and assigns it to the appointment.

---

Endpoint Resources

This section lists the endpoints that render patient pages and commit patient selection and identity data.

Shared query parameters

Use this table for endpoints that accept query parameters.

Parameter	Required	Type	Description
patient-details-id	Yes*	Integer (int32)	Patient details ID in the current flow context.
first-name	Yes*	String	Patient first name.
last-name	Yes*	String	Patient last name.
date-of-birth	Yes*	String (date)	Patient date of birth.
gender	Yes*	Enum	Patient sex value. Allowed: male, female, both, other.
personal-id	No	String	Patient personal number.
first-name-latin	No	String	First name in Latin characters.
last-name-latin	No	String	Last name in Latin characters.

Required status depends on endpoint. Each endpoint section lists required parameters.

Patients

PUT 

/patients

Returns the patient list page model.

The response contains a complete page definition used to render the patient selection surface. The structure follows the internal Put Response Format and includes layout components, actions, and navigation metadata required by the client runtime.

New Patient

PUT 

/patients/create

Returns the new patient creation page model.

The response defines all required input fields, validation rules, conditional Latin name logic, and action bindings. The structure follows the internal Put Response Format.

Existing Patient

PUT 

/patients/update

Returns the patient update page model for the specified patient-details-id.

The response pre-populates editable fields and provides validation and action bindings. The structure follows the internal Put Response Format.

Validate Name

PATCH 

/patients/create/validate

Evaluates first-name and last-name values.

The response returns incremental UI updates that control:

Visibility of Latin name fields

Field-level validation states

The structure follows the internal Patch Response Format and applies updates to the currently mounted page without reloading it.

Create Patient

POST 

/patients/create

Persists a new patient record.

The operation validates required identity attributes and optional Latin name fields, then commits the entity. No response body returns. See Committing Data.

Save Selected Patient

POST 

/patients/select

Sets the specified patient as active in the current flow context.

The operation commits the selection state. No response body returns. See Committing Data.

Update Patient

POST 

/patients/update

Persists additional or corrected patient attributes for the specified patient-details-id.

The operation updates identity metadata and commits the changes. No response body returns. See Committing Data.