Uzbekistan Digital Health Platform
0.10.0 - draft Uzbekistan flag

This page is part of the Uzbekistan Digital Health Platform (v0.10.0: Releases Draft) based on FHIR (HL7® FHIR® Standard) v5.0.0. This is the current published version. For a full list of available versions, see the Directory of published versions

e-Referral lifecycle

This workflow shows how a referral is created and fulfilled. Referrals are where developers most often get lost, because two resources are involved and their relationship is not obvious from the profile tables. The one-line rule:

ServiceRequest is the referral itself - what is to be done. Task is the work of fulfilling it - who did it, when, and how far along it is.

Profile status: both resources are now profiled - UZ Core ServiceRequest for the referral and UZ Core Task Referral Approval for the approval stages. Both are still marked experimental, so review them before building against them. Procedure, Observation, Encounter and Condition used at fulfilment are profiled.

Actors: the referring clinician; approval commissions (for state-funded referrals); the performing facility.

e-Referral lifecycleReferringclinicianReferringclinicianDHPDHPApprovalcommissionsApprovalcommissionsPerformingfacilityPerformingfacility1POST ServiceRequest(intent = order, PaymentType)alt[PaymentType = State-funded]2create approval Task chain(first Task status = requested)loop[approve-family-doctor ... approve-hospitalization]3advance Task(accepted -> in-progress -> completed)final approval Task completed[other financing]4referral proceeds directly(no Task created)5recordProcedure/Observation(basedOn -> ServiceRequest)6final Task completed7ServiceRequest -> completed


1. Create the referral

The clinician creates a ServiceRequest (intent = order) carrying the referral classification: the service requested in code, urgency in priority (routine | urgent | stat), the target service via HealthcareService, the clinical justification in reason, and the financing type in the PaymentType extension (Free | Paid | Insurance | State-funded).

POST [base]/ServiceRequest
{ "resourceType": "ServiceRequest", "status": "active", "intent": "order",
  "priority": "routine",
  "code": { "coding": [{ "system": "http://snomed.info/sct", "code": "..." }] },
  "subject": { "reference": "Patient/[id]" },
  "requester": { "reference": "PractitionerRole/[id]" },
  "reason": [{ "reference": { "reference": "Condition/[id]" } }] }

2. The approval chain (state-funded only)

This is the central decision rule:

If the ServiceRequest's PaymentType is State-funded, the platform creates a chain of approval Tasks; otherwise no Task is created and the referral proceeds directly.

Each approval stage is a Task referencing the ServiceRequest (Task.focus/basedOn) with a Task.code from the approval category set:

approve-family-doctor → approve-specialist → approve-regional-commission → approve-national-commission → approve-insurance-fund → approve-hospitalization

A Task carries two status axes: the FHIR Task.status (the lifecycle: requested, accepted, in-progress, completed, rejected, on-hold, failed, …) and a Task.businessStatus (the domain state shown to users: in-review, confirmed, overdue, …).

Tasks have no user-facing UI. Managers act on process events; they never close a Task directly. This prevents a stage being marked done without the underlying work.

3. Synchronisation rules

The ServiceRequest and its Tasks stay consistent by these rules:

Event Effect
ServiceRequest becomes active (state-funded) first approval Task created with status=requested
ServiceRequest set revoked all open Tasks set revoked
ServiceRequest set entered-in-error all Tasks set entered-in-error
Final approval Task completed ServiceRequest set completed
A commission Task failed/rejected ServiceRequest set revoked
Returned for revision Task → on-hold / in-review; ServiceRequest → on-hold, then back to active with a new approval Task
SLA breach only Task.businessStatus = overdue - the ServiceRequest status does not change
Referral ServiceRequest status, driven by Task eventson-holdentered-in-erroractivecompletedrevokedAn SLA breach sets only Task.businessStatus = overdue;the ServiceRequest status does not change.created (status = active)returned for revisionresubmitted with a new approval Taskfinal approval / fulfilment Task completedcancelled, or a commission Task failed / rejectedcancelledcorrection


The user-facing label is derived from the Task state - e.g. businessStatus=overdue → "Overdue", status=requested → "Awaiting acceptance", status=rejected → "Rejected".

4. Fulfilment

When the service is delivered, the performing facility records the result against the referral: a Procedure and/or Observation (and an Encounter for the visit), each linking back to the ServiceRequest via basedOn. Imaging results use ImagingStudy/DocumentReference; a narrative conclusion uses DiagnosticReport. On completion the final Task is completed and the ServiceRequest is completed.

GET [base]/Task?based-on=ServiceRequest/[id]&_sort=-modified
GET [base]/ServiceRequest?patient=Patient/[id]&status=active
GET [base]/Procedure?based-on=ServiceRequest/[id]

A cancelled referral cannot be fulfilled, a Procedure cannot start without an active ServiceRequest, and a completed Procedure cannot be modified.