Electronic referral via FHIR: ServiceRequest, Task, and Composition

The problem and context of referrals in Vietnam

Referrals between healthcare facilities are the most common administrative-and-clinical workflow in Vietnam's health system. A patient with hypertension at a commune health station (CHS) may be referred up to a provincial hospital during an acute episode. A suspected myocardial infarction at a provincial hospital is referred up to a central hospital. A pediatric patient who needs specialized cardiac surgery is referred from a general hospital to a children's specialty hospital. Every one of these cases moves through a single sheet of A4 paper: pre-printed, hand-filled, sealed with a red stamp, and handed to the patient to carry.

The paper-based status quo carries a lot of risk. Hard-to-read handwriting leads to incorrect data entry at the destination facility. Patients who lose the form or arrive late disrupt the intake process. The destination facility has no advance notice and cannot prepare a bed, equipment, or staffing. Vietnam Social Security (BHXH) has no fast way to verify whether a referral is in-network, which leads to reimbursement disputes after treatment is already complete. The audit trail is essentially nonexistent, making it difficult to investigate clinical incidents.

Circular 13/2025/TT-BYT on electronic medical records (EMR) lays critical legal groundwork. The circular requires healthcare facilities to create, update, electronically sign, and query medical records using legally valid methods. Hospitals must complete EMR adoption no later than 30/9/2025, and all other facilities no later than 31/12/2026. Circular 13 does not mandate a specific format for an electronic referral form, nor does it specify a BHXH algorithm for automatically validating in-network status. However, the EMR ecosystem the circular creates is the foundation that makes FHIR-based referrals workable.

FHIR R4 provides exactly the three resources needed to model this workflow: ServiceRequest for the clinical order, Task for the cross-facility workflow, and Composition for the structured referral letter. The next sections walk through how to map the current paper form to these three resources.

The current paper referral form

The referral form widely used in Vietnam is a single-page document. Its core fields have remained relatively stable across many editions of guidance from the Ministry of Health and Vietnam Social Security (BHXH). Although individual facilities use minor layout variations, the core fields are nearly identical: referral number, date issued, originating facility, destination facility, patient identification, current diagnosis, reason for referral, history and treatment to date, recommended next steps, physician's signature, and the facility's red seal.

When you decompose each field, every one carries information that maps directly to FHIR. The referral number is a business identifier. The issue date is a timestamp. The originating facility paired with the signing physician maps to an Organization plus Practitioner. The patient is a Patient with identifiers like the national ID card (CCCD), social health insurance card number, or medical record number. Diagnoses use ICD-10 Vietnam per Decision 4469/QĐ-BYT (with COVID-19 codes added per Decision 98/QĐ-BYT). The reason for referral and recommended next steps are free text but should be stored in a structured form so they remain queryable. History and prior treatment reference Conditions, MedicationRequests, and Observations already present in the EMR. Finally, the digital signature replaces the handwritten signature and red seal.

One important nuance: the current paper form does not clearly distinguish between "the referral request itself" and "the document explaining the request". On paper the two collapse into one. In FHIR they are separated cleanly: ServiceRequest is the request (the service order), Composition is the explanatory document, and Task is the status thread that tracks fulfillment of that request. This separation of concerns is what allows two facilities to exchange and synchronize state without dragging an entire PDF back and forth.

Mapping the paper form to FHIR resources

The table below maps each field on the current paper referral form to the corresponding FHIR R4 element. This is a principle-level mapping; the VN Core profile will impose more specific constraints on Must Support, slicing, and terminology.

Three core resources: ServiceRequest, Task, Composition

ServiceRequest: the clinical order

ServiceRequest describes a request for a healthcare service. In the referral workflow, the service is "continuation of care for the patient at the destination facility". This is the only resource that must carry a digital signature, because it is the legally binding order and is the root reference for both Task and Composition.

{
  "resourceType": "ServiceRequest",
  "id": "sr-referral-001",
  "status": "active",
  "intent": "order",
  "priority": "urgent",
  "category": [{ "coding": [{ "system": "http://snomed.info/sct", "code": "306206005", "display": "Referral to service" }] }],
  "code": { "coding": [{ "system": "http://snomed.info/sct", "code": "3457005", "display": "Patient referral" }] },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/enc-tyt-001" },
  "authoredOn": "2026-04-30T10:00:00+07:00",
  "requester": { "reference": "PractitionerRole/bs-tyt-001" },
  "performer": [{ "reference": "Organization/bv-tinh-k" }],
  "performerType": { "coding": [{ "system": "http://snomed.info/sct", "code": "394579002", "display": "Cardiology" }] },
  "reasonReference": [{ "reference": "Condition/dx-stemi-001" }],
  "reasonCode": [{ "text": "Đau ngực kéo dài, ECG có ST chênh lên ở V1-V4, troponin tăng, nghi nhồi máu cơ tim cấp" }],
  "supportingInfo": [
    { "reference": "Observation/ecg-001" },
    { "reference": "Observation/troponin-001" }
  ]
}

Task: workflow between two facilities

Task pulls workflow state out of clinical content. When the destination facility accepts, rejects, or completes intake, only the Task changes; the ServiceRequest and Composition remain unchanged as signed legal documents. This separation reflects a core FHIR design principle: one resource, one purpose.

{
  "resourceType": "Task",
  "id": "task-referral-001",
  "status": "requested",
  "intent": "order",
  "priority": "urgent",
  "code": { "coding": [{ "system": "http://hl7.org/fhir/CodeSystem/task-code", "code": "fulfill" }] },
  "focus": { "reference": "ServiceRequest/sr-referral-001" },
  "for": { "reference": "Patient/lan-001" },
  "authoredOn": "2026-04-30T10:00:00+07:00",
  "requester": { "reference": "Organization/tyt-xa-h" },
  "owner": { "reference": "Organization/bv-tinh-k" },
  "businessStatus": { "text": "Awaiting intake by Provincial Hospital K." }
}

Task moves through the sequence requested → accepted → in-progress → completed. When the destination facility refuses, use rejected with a statusReason describing why. When the patient does not arrive within an agreed window, use cancelled. The originating facility tracks the Task via FHIR Subscription and reflects the state back into its own EMR.

Composition: the structured referral letter

Composition plays the role of the referral letter — the document that explains the reason for the referral and summarizes the relevant clinical context. It is the digital successor to "the back side of the paper referral form", but with a much clearer structure. FHIR R4 requires Composition to have status, type, subject, date, author, and title, and every section.text must be Narrative XHTML { status, div }, not a raw string.

{
  "resourceType": "Composition",
  "id": "comp-referral-001",
  "status": "final",
  "type": {
    "coding": [{ "system": "http://loinc.org", "code": "57133-1", "display": "Referral note" }]
  },
  "subject": { "reference": "Patient/lan-001" },
  "encounter": { "reference": "Encounter/enc-tyt-001" },
  "date": "2026-04-30T10:00:00+07:00",
  "author": [{ "reference": "PractitionerRole/bs-tyt-001" }],
  "title": "Giấy chuyển viện - TYT xã H. sang BV tỉnh K.",
  "attester": [{
    "mode": "professional",
    "time": "2026-04-30T10:05:00+07:00",
    "party": { "reference": "PractitionerRole/bs-tyt-001" }
  }],
  "section": [
    {
      "title": "Hành chính",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Bệnh nhân Nguyễn Thị Lan, sinh 1962, thẻ BHYT HC4010112345678, đăng ký KCB ban đầu tại TYT xã H.</div>"
      },
      "entry": [
        { "reference": "Patient/lan-001" },
        { "reference": "Coverage/cov-bhyt-001" }
      ]
    },
    {
      "title": "Lý do chuyển",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Đau ngực sau xương ức 30 phút, lan ra cánh tay trái, ECG có ST chênh lên V1-V4, troponin I tăng. Vượt khả năng chuyên môn của TYT xã.</div>"
      }
    },
    {
      "title": "Chẩn đoán",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">I21.0 - Nhồi máu cơ tim cấp xuyên thành thành trước</div>"
      },
      "entry": [{ "reference": "Condition/dx-stemi-001" }]
    },
    {
      "title": "Tiền sử và điều trị đã thực hiện",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Tăng huyết áp 5 năm, đang dùng amlodipin 5mg/ngày. Tại TYT đã cho aspirin 300mg, clopidogrel 300mg, nitromint xịt dưới lưỡi.</div>"
      },
      "entry": [
        { "reference": "Condition/htn-001" },
        { "reference": "MedicationRequest/aspirin-loading-001" }
      ]
    },
    {
      "title": "Sinh hiệu và cận lâm sàng",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">HA 150/95 mmHg, mạch 92/phút, SpO2 96%. ECG: ST chênh lên V1-V4. Troponin I 2.3 ng/mL.</div>"
      },
      "entry": [
        { "reference": "Observation/bp-001" },
        { "reference": "Observation/ecg-001" },
        { "reference": "Observation/troponin-001" }
      ]
    },
    {
      "title": "Đề xuất tiếp theo",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Đề nghị BV tỉnh K. tiếp nhận khẩn, đánh giá can thiệp mạch vành thì đầu (primary PCI) trong vòng 90 phút.</div>"
      }
    }
  ]
}

section.entry holds references to resources that already exist in the Bundle or on the FHIR server, while section.text is the human-readable narrative. The two must stay consistent; the signer is attesting to the narrative, not the references.

End-to-end workflow between two facilities

The end-to-end electronic referral workflow has eight steps, running from the moment the originating physician decides to refer until the destination facility completes intake and reports back.

Step 1. Physician at CHS H. examines and decides to refer the patient
Step 2. EMR creates a Bundle: ServiceRequest + Task + Composition + Provenance
Step 3. Physician signs Composition and ServiceRequest electronically (Circular 13/2025)
Step 4. Bundle POSTed to the provincial FHIR Server or interoperability bus
Step 5. FHIR Subscription pushes the notification to Provincial Hospital K. - Task.status = requested
Step 6. Hospital K. physician accepts the Task -> Task.status = accepted
Step 7. Patient arrives at the hospital - new Encounter references the ServiceRequest -> Task.status = in-progress
Step 8. After treatment, the hospital creates a discharge Composition and sets Task.status = completed

Every step is recorded in AuditEvent and Provenance to maintain an audit trail under the Personal Data Protection Law (Law 91/2025/QH15) and Decree 356/2025/NĐ-CP. When an incident needs to be investigated, the entire chain of events can be reconstructed without relying on any participant's memory.

In emergency situations the order may be reversed: the receiving hospital treats first, then the system creates a retroactive ServiceRequest with an occurrenceDateTime tied to the actual emergency time and a note documenting why it was created after the fact.

In-network and out-of-network BHYT referrals

Law 51/2024/QH15, which amends Vietnam's Health Insurance Law, replaced the old tier framework (commune – district – province – central) with a three-tier model based on professional and technical capability: initial care, basic care, and specialized care. Decree 188/2025/NĐ-CP provides detailed reimbursement rules for this model. The old shorthand of "60% inpatient at the provincial level, 40% at the central level" no longer reflects the current rules.

Under Article 22 of the amended Health Insurance Law, patients receive full reimbursement at their full benefit level for examinations and treatment at the initial-care tier, in some cases at the basic-care tier, and in transition cases tied to the former district-level rules. When a patient self-presents for inpatient treatment at the specialized-care tier without a properly authorized referral, reimbursement drops to 40% of the full benefit level, except for certain specifically listed populations. Emergencies are always considered in-network regardless of which facility the patient reaches.

In FHIR, the in-network or out-of-network context is represented on the Encounter for the visit at the destination facility. The VN Core IG uses the vn-ext-insurance-visit-type extension to describe the BHYT visit type (initial, referral, emergency, network-wide), and vn-ext-referral-mode records the HTCHUYEN referral-source code per Decision 3176/QĐ-BYT (1 = self-presented, 2 = referred from a lower tier, 3 = from a higher tier, 4 = same-tier transfer, 5 = emergency). Link the originating ServiceRequest via Encounter.basedOn or Encounter.appointment — NOT through this extension. The final determination of in-network status should be made by the BHXH system based on the referenced ServiceRequest, the professional tier of both facilities, and the patient's BHYT beneficiary group.

{
  "resourceType": "Encounter",
  "id": "enc-bv-tinh-001",
  "status": "in-progress",
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-insurance-visit-type",
      "valueCoding": {
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-insurance-visit-type-cs",
        "code": "referral",
        "display": "Khám chữa bệnh do chuyển tuyến"
      }
    },
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-referral-mode",
      "valueCodeableConcept": {
        "coding": [{
          "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-referral-mode-cs",
          "code": "2",
          "display": "Referred from a lower tier"
        }]
      }
    }
  ],
  "subject": { "reference": "Patient/lan-001" },
  "serviceProvider": { "reference": "Organization/bv-tinh-k" }
}

The exact extension names in the VN Core IG may shift between versions; the authoritative source is always the FSH files in input/fsh/extensions/ in the repository.

Sample transaction Bundle

When the originating facility submits the referral, the entire ServiceRequest, Task, Composition, and supporting resources are packaged into a Bundle of type transaction. The destination FHIR server processes the bundle atomically; if any entry fails, the whole transaction is rolled back to avoid leaving the system in a half-applied state.

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "urn:uuid:sr-referral-001",
      "resource": { "resourceType": "ServiceRequest", "id": "sr-referral-001" },
      "request": { "method": "POST", "url": "ServiceRequest" }
    },
    {
      "fullUrl": "urn:uuid:task-referral-001",
      "resource": { "resourceType": "Task", "id": "task-referral-001" },
      "request": { "method": "POST", "url": "Task" }
    },
    {
      "fullUrl": "urn:uuid:comp-referral-001",
      "resource": { "resourceType": "Composition", "id": "comp-referral-001" },
      "request": { "method": "POST", "url": "Composition" }
    },
    {
      "fullUrl": "urn:uuid:prov-001",
      "resource": {
        "resourceType": "Provenance",
        "target": [{ "reference": "Composition/comp-referral-001" }],
        "recorded": "2026-04-30T10:05:00+07:00",
        "agent": [{ "who": { "reference": "PractitionerRole/bs-tyt-001" } }],
        "signature": [{
          "type": [{ "system": "urn:iso-astm:E1762-95:2013", "code": "1.2.840.10065.1.12.1.1" }],
          "when": "2026-04-30T10:05:00+07:00",
          "who": { "reference": "PractitionerRole/bs-tyt-001" },
          "data": "..."
        }]
      },
      "request": { "method": "POST", "url": "Provenance" }
    }
  ]
}

Provenance carries the digital signature in HL7 format and serves as the legal evidence of the signing event. When BHXH or an inspection authority needs to verify, they retrieve Provenance.signature.data and validate it against the physician's certificate.

Frequently asked questions

Is SmartCA or a USB token required to sign every referral?

No. Circular 13/2025/TT-BYT requires documents to be authenticated using a legally valid electronic method. SmartCA, USB tokens, biometrics, and other forms of electronic authentication are all acceptable, provided they comply with the law on electronic transactions (Decree 137/2024/NĐ-CP). The specific choice depends on each facility's security policy.

The destination facility refuses intake — what happens to the workflow?

The Task moves to rejected with a statusReason explaining why (no beds, specialty mismatch, capability beyond the facility's scope). The originating facility receives the notification via Subscription and may create a new ServiceRequest pointing to a different destination. The original ServiceRequest is not deleted; it remains in the audit trail.

An emergency leaves no time to issue a referral first — how is that handled?

The receiving facility provides emergency care first. Once the patient is stable, the system creates a retroactive ServiceRequest with an occurrenceDateTime tied to the actual emergency time, priority set to asap, and a note stating "created after the emergency". Provenance records the actual creation time. Emergency care is always considered in-network, so it does not affect BHYT reimbursement.

The patient has no national ID card (CCCD) — how do we create a valid Patient?

The base FHIR Patient has an optional identifier. VNCorePatient, however, requires at least one identifier; the profile supports slices for passport, birth certificate, and internal medical record number, plus a data-absent-reason for unavoidable exceptions. Newborns who do not yet have a CCCD typically use the birth certificate; foreign nationals use a passport. Temporary documents such as a temporary residence registration are not part of the standard VNCorePatient slices at this time.

References

• HL7 FHIR R4 ServiceRequest: hl7.org/fhir/R4/servicerequest.html
• HL7 FHIR R4 Task: hl7.org/fhir/R4/task.html
• HL7 FHIR R4 Composition: hl7.org/fhir/R4/composition.html
• HL7 FHIR R4 Provenance and signature: hl7.org/fhir/R4/provenance.html
• Law 51/2024/QH15 amending the Health Insurance Law: congbao.chinhphu.vn
• Decree 188/2025/NĐ-CP guiding the Health Insurance Law: legal-corpus#ND-188-2025
• Circular 13/2025/TT-BYT on electronic medical records: legal-corpus#TT-13-2025
• Decree 137/2024/NĐ-CP on electronic transactions: legal-corpus#ND-137-2024
• Law 91/2025/QH15 and Decree 356/2025/NĐ-CP on personal data protection: legal-corpus#Luat-91-2025
• LOINC code 57133-1 "Referral note": loinc.org/57133-1
• VN Core IG canonical: fhir.hl7.org.vn/core

Further reading