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

Laboratory order to result

This workflow shows how a laboratory test is ordered and how the result comes back. It is the canonical FHIR diagnostic chain, with the reference wiring made explicit - a profile table tells you Observation.specimen exists, but this page tells you it must point at the specimen produced from this order.

Actors: an ordering clinician; the laboratory (LIS); the platform (DHP).

The sequence of interactions:

Ordering a test and returning the resultOrderingclinicianOrderingclinicianDHPFHIR serverDHPFHIR serverLaboratory(LIS)Laboratory(LIS)1POST ServiceRequest (intent = order)2order availablecollect specimen,run each analyte3POST Bundle (transaction):Specimen+Observations + DiagnosticReport(all reference ServiceRequest)4GET DiagnosticReport?based-on=ServiceRequest/[id]&_include=DiagnosticReport:result5Bundle - report + observations


The chain and its references:

Laboratory result - reference wiringServiceRequestSpecimenObservationDiagnosticReportBlue boxes are profiled in UZ Core and link totheir profile page; the rest are not yet profiled.requestbasedOnspecimenbasedOnresult


Profile status: Specimen and Observation are profiled in UZ Core. The ServiceRequest and DiagnosticReport profiles are in development - until they publish, use the base FHIR R5 resources with meta.profile omitted or set to the base resource, and follow the wiring below.

1. Order the test

The clinician creates a ServiceRequest with intent = order, the test or panel in code, the patient in subject, the requester, and a reasonCode/reasonReference (the Condition being investigated). The orderable tests are published as HealthcareService entries; priority is routine, urgent or asap.

POST [base]/ServiceRequest
{ "resourceType": "ServiceRequest", "status": "active", "intent": "order",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "58410-2" }] },
  "subject": { "reference": "Patient/[id]" },
  "requester": { "reference": "PractitionerRole/[id]" },
  "priority": "routine" }

A repeat of an earlier test sets ServiceRequest.basedOn to the original order.

2. Collect the specimen

The lab records a Specimen with its type, collection date/time and identifier, the patient in subject, and crucially Specimen.request pointing back at the ServiceRequest.

POST [base]/Specimen
{ "resourceType": "Specimen",
  "meta": { "profile": ["https://dhp.uz/fhir/core/StructureDefinition/uz-core-specimen"] },
  "subject": { "reference": "Patient/[id]" },
  "request": [{ "reference": "ServiceRequest/[id]" }],
  "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0487", "code": "BLD", "display": "Whole blood" }] } }

3. Return the results

Each analyte is an Observation with a LOINC code, a value[x], an interpretation (normal / high / low / critical) and a referenceRange. Each Observation sets basedOn to the ServiceRequest and specimen to the Specimen. The set is summarised by a DiagnosticReport whose basedOn is the ServiceRequest and whose result lists the Observations.

GET [base]/DiagnosticReport?based-on=ServiceRequest/[id]&_include=DiagnosticReport:result
GET [base]/Observation?patient=Patient/[id]&category=laboratory&_sort=-date

The whole set is best returned as one transaction Bundle so the order, specimen, observations and report arrive atomically. A finalized, signed report is assembled as a document Bundle (Composition header referencing the results, signed via Provenance) - the Composition references the resources rather than duplicating them. See General guidance → Bundles.

Status and concurrency

The ServiceRequest.status follows the order lifecycle (draft → active → completed, or revoked); entered-in-error/unknown are reserved for corrections. A cancellation moves an active order to revoked (with a note), and a completed order cannot be modified. Concurrent edits use optimistic concurrency - send the ETag from your last read as If-Match; a stale version is rejected with 412 Precondition Failed. Re-read and retry - see Concurrency.