Uzbekistan Digital Health Platform
0.5.0 - 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.5.0 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

Workflows

The profile pages tell you the shape of each resource. These workflow pages tell you the story - for a real clinical task, which resources to create, in what order, how they reference each other, and what API calls to make. If you are not sure which resource to use for something, start here.

Each workflow describes the actors, the sequence of FHIR interactions, and the key rules, with example calls and payload fragments.

Available scenarios

Workflow What it covers Resources
Immunization National schedule → recommendation → recording a dose PlanDefinition, ImmunizationRecommendation, Immunization, AdverseEvent
Laboratory order to result Ordering a test and returning the result ServiceRequest, Specimen, Observation, DiagnosticReport
e-Referral lifecycle Creating and fulfilling a referral, including the state-insurance approval chain ServiceRequest, Task, Procedure
Patient journey (Episode of Care) Grouping a case's visits, diagnoses and results under one episode over time EpisodeOfCare, Encounter, Condition, Observation
e-Prescription and dispensing Prescribing a medicine, dispensing it, and reporting to SHIF MedicationRequest, MedicationDispense, Condition

Clinical document creation and signing (assembling a Composition-based document and signing it for legal force) is specified in the DHP Integrations IG under Documents, not here.

More scenarios (population screening) will be added as the corresponding profiles are finalized.

The interaction model

A few rules apply to every workflow:

  • Authenticate first. All requests carry an OAuth2 bearer token (Authorization: Bearer <token>) obtained from the platform SSO. System-to-system clients use the client-credentials flow; user-facing apps use the authorization-code flow via oneID.
  • Declare the profile. Every resource you submit carries meta.profile so the server validates it against the right UZ Core profile. See General guidance → metadata.
  • Group related resources in a Bundle. When several resources belong together, you may submit them as a Bundle (transaction or batch) or, for a finalized document, a document Bundle. See General guidance → Bundles.
  • Honour consent. Read requests are subject to the patient's Consent; a denied request returns 403. Every access is logged to AuditEvent.
  • Logical delete only. Records are retired by changing status, not by DELETE. See General guidance → deleting.

How resources relate

Most clinical data hangs off the patient through a small number of reference patterns. The diagram below maps that core backbone - it is not an exhaustive list of every profile (see Artifacts for the full set):

The core clinical record backbonePatientEpisodeOfCareEncounterConditionObservationProcedureMedicationRequestCompositionSpecimenServiceRequestThese are the core record resources, not everyUZ Core profile. Each arrow points from theresource that holds the reference to its target;the label is the FHIR reference element.Blue boxes are profiled and link to their page;grey boxes are referenced but not yet profiled.patient10..*episodeOfCare0..10..*encounter10..*encounter10..*encounter10..*encounter10..*encounter10..1specimen0..*0..1request0..*0..1


  • A Patient has many Encounters (visits); related Encounters may be grouped into an EpisodeOfCare (an ongoing case).
  • Within an Encounter, clinicians record Conditions (diagnoses), Observations (results, vitals), Procedures, and MedicationRequests.
  • Workflow resources (ServiceRequest, Task) drive ordering and fulfilment; result resources (Observation, DiagnosticReport) reference back to the order.
  • Finalized, legally-significant content is assembled into a Composition-based document and signed via Provenance.

A note on choosing between a document and workflow resources: store ongoing clinical facts as discrete resources (Condition, Observation, Procedure); assemble a Composition-based document only when you need a finalized, legally-significant artifact (a discharge summary, a signed certificate, a signed report).