Uzbekistan Digital Health Platform
0.11.1 - ci-build Uzbekistan flag

Uzbekistan Digital Health Platform, published by Ministry of Health of the Republic of Uzbekistan. This guide is not an authorized publication; it is the continuous build for version 0.11.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/uzinfocom-org/digital-health-ig/ and changes regularly. See the Directory of published versions

OperationDefinition: Attach a patient to a healthcare organization and/or a practitioner

Official URL: https://dhp.uz/fhir/core/OperationDefinition/patient-attach Version: 0.11.1
Draft as of 2026-10-19 Computable Name: PatientAttach

Attaches a patient to a healthcare organization (Patient.managingOrganization) and/or to a practitioner (Patient.generalPractitioner) in a single call, and records the date of attachment to the organization in the https://dhp.uz/fhir/core/StructureDefinition/managing-organization-attachment extension. The organization and the practitioner are checked for existence in the master data registry; each can be named either by a literal reference or by a business identifier, which the server resolves to a literal reference before writing. The operation is invoked with POST and a Parameters body at instance level (Patient/[id]/$attach), where the patient is named in the URL, or at type level (Patient/$attach), where the patient is named by the patientIdentifier parameter. The response is the updated Patient resource, not Parameters.

Language: en

URL: [base]/Patient/$attach

URL: [base]/Patient/[id]/$attach

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INpatientIdentifiertype0..1Identifier

PINFL (NI) of the patient to attach. Mandatory at type level, rejected with code invalid at instance level, where the patient is taken from the URL. Identifier.value is always treated as a PINFL and is checked for correctness; Identifier.system is ignored. Passed as valueIdentifier.

INpatientBirthDatetype0..1date

Date of birth of the patient, used as an additional matching criterion when the patient is looked up in the state registries. It does not filter the local patient, which is matched by PINFL only. Accepted at type level only. Passed as valueDate.

INorganization0..1Reference | Identifier

The healthcare organization the patient is attached to; written to Patient.managingOrganization. Passed either as valueReference with a relative literal reference Organization/[id], or as valueIdentifier with a business identifier that must match exactly one Organization (Identifier.system is ignored). Absolute URLs, logical references and references to other resource types are rejected with code value; supplying both valueReference and valueIdentifier is rejected with code structure. An organization that does not exist results in HTTP 422 with code not-found.

INpractitioner0..1Reference | Identifier

The practitioner the patient is attached to; replaces Patient.generalPractitioner as a whole. Passed either as valueReference with a relative literal reference Practitioner/[id], or as valueIdentifier with a business identifier that must match exactly one Practitioner (Identifier.system is ignored). PractitionerRole is not accepted. The same reference and identifier rules as for organization apply.

INattachmentDate0..1date

Date of attachment to the organization in full YYYY-MM-DD format; partial dates are rejected. Defaults to the current server date. Accepted only together with organization; must not be later than the current server date and not earlier than the attachment date already stored on the patient. Passed as valueDate.

OUTreturn1..1Patient

The updated Patient resource. If the call changed nothing, the current version is returned and no new version is created.

At least one of organization and practitioner must be supplied, otherwise an OperationOutcome with code required is returned. Changing one side of the attachment detaches the other: when the organization changes and no practitioner is supplied, Patient.generalPractitioner is cleared; when the practitioner changes and no organization is supplied, Patient.managingOrganization is cleared and the attachment date is set to the current server date. When the supplied organization equals the current one, neither the reference nor the attachment date is changed. Repeated identical calls do not create a new version of the Patient. At type level the patient is resolved by PINFL in the same way as Patient/$populate and is created if it does not exist yet, so a single type-level call replaces the $populate + $attach pair. If the Patient was modified concurrently between read and write, the operation fails with HTTP 412 and does not overwrite the other change; the client should retry. The operation does not enforce the rule that a patient may change organization no more than once a year, does not check that the practitioner works in the given organization, and does not look at Patient.active or Patient.deceased. Detachment is done with Patient/$detach.