Electronic referral via FHIR: ServiceRequest, Task, and Composition

The problem and context of referrals in Vietnam

Transfer between healthcare facilities combines clinical decisions, intake coordination, and administrative requirements. Under the current professional and technical model, an initial-level facility may transfer a patient to a basic- or specialized-level facility with appropriate capability; transfer can also occur between facilities at the same level. Commune, district, provincial, and central labels may remain in legacy records but should not replace the current care-level classification.

Paper-dependent processes can increase the risk of misreading, duplicate data entry, lost documents, and delayed information at the destination. They can also limit automated verification of document origin, issuance time, and intake status. Actual risk varies by facility. Digitization is useful only when paired with reliable identity, access control, data quality, and an appropriate audit trail.

Circular 13/2025/TT-BYT requires electronic medical records to be created, updated, displayed, and signed or electronically confirmed through lawful methods. Hospitals within its scope had a 30/09/2025 deadline; other healthcare facilities providing inpatient, day, or outpatient treatment have a 31/12/2026 deadline. The Circular does not prescribe a FHIR format for transfer documents, does not require both ServiceRequest and Composition to be signed, and does not define a BHXH benefit-determination algorithm.

FHIR R4 provides several resources that can be combined for this use case. This page selects ServiceRequest, Task, and Composition as one architecture pattern, with Provenance where origin or signature data is represented. Implementers must publish profiles, interactions, and security requirements in the relevant IG, CapabilityStatement, and interface contract.

The current paper referral form

Transfer forms and processes must be checked against the healthcare-sector instrument, currently effective template, and receiving-party requirements at implementation time. The table below uses a common field set for illustration: document number, issue date, sending and receiving facilities, patient identity, diagnosis, reason for transfer, prior treatment, confirming person, and attachments. It is not a legally authoritative reproduction of a specific form.

Each field can be analyzed by data type and responsible source. The document number is a business identifier; the issue date is a timestamp; the facility and requester may reference Organization, PractitionerRole, or Practitioner. VN Core uses the personal identification number/CCCD as the core identifier when available and models passports, birth certificates, and force-majeure cases through the profile. Diagnoses may use the applicable release of ICD-10 VN. Electronic signatures, seals, and other confirmation methods are not automatically interchangeable: legal effect depends on the signer, signed payload, certificate or trust framework, time, and verification process.

In this architecture pattern, ServiceRequest represents the request, Composition represents the explanatory document, and Task tracks processing. The separation keeps clinical content distinct from workflow state. A system may still need DocumentReference or Binary for an original artifact under retention and evidence rules. It should not be inferred that every paper form must be replaced by exactly these three resources.

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.

Reference coordination of ServiceRequest, Task, and Composition

ServiceRequest: the clinical order

ServiceRequest describes a request for a healthcare service. In this pattern, the service is continued assessment or care at the destination facility, and ServiceRequest is the Task focus. FHIR R4 does not require ServiceRequest, Composition, or any other resource in this workflow to carry a digital signature. The applicable law, IG, and interface contract must define the artifact to sign, the signed payload, and the verification method.

{
  "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 separates workflow state from clinical content. In this pattern, the destination updates Task when it accepts, rejects, or completes intake; ServiceRequest and Composition change only under the interface's versioning rules. They should not be described as signed legal documents until the signed data, signature validity, and immutability policy have been established.

{
  "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." }
}

The proposed state machine is requested → accepted → in-progress → completed; refusal uses rejected with statusReason, and policy-based cancellation uses cancelled. Parties must agree who may change state, transition conditions, and retry/idempotency behavior. FHIR Subscription may deliver notifications if the server supports and declares it in CapabilityStatement; polling or a message broker are alternatives.

Composition: the structured referral letter

Composition can represent a referral letter explaining the transfer and summarizing relevant clinical context. In FHIR R4, required Composition elements are status, type, date, author, and title. subject is 0..1 in base FHIR but should be profiled for a patient-transfer use case. When section.text is present, it 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 in the Bundle or on the server, while section.text is human-readable narrative. The two should remain consistent under the narrative-generation rules. What a signer attests to depends on the payload actually signed and the signature policy; Composition.attester does not itself determine whether narrative or references are covered by a cryptographic signature.

End-to-end workflow between two facilities

The sequence below is a reference flow, not a mandatory eight-step process. Before use, the facilities must agree endpoints, profiles, authentication and authorization, Task states, error and retry handling, retention, minimum necessary data, and processing responsibility.

Step 1. A practitioner evaluates and records the transfer decision under the applicable process
Step 2. The EMR creates resources required by the use-case IG, for example ServiceRequest + Task + Composition
Step 3. The system signs or confirms the policy-designated artifact; Provenance records origin where applicable
Step 4. Send a Bundle or message through the agreed endpoint if CapabilityStatement and contract allow it
Step 5. Notify through Subscription, polling, or a broker according to declared capability
Step 6. The destination updates Task under the agreed state machine
Step 7. When the patient arrives, Encounter.basedOn references ServiceRequest where appropriate
Step 8. Complete the workflow and discharge documentation under the separate use case

AuditEvent and Provenance serve different purposes: AuditEvent records access or operational events, while Provenance describes data origin and agents involved in creation or change. The IG must define which events to record, who may read them, retention, clock synchronization, and data minimization. Creating these resources does not by itself establish compliance with Law 91/2025/QH15 or Decree 356/2025/NĐ-CP.

In an emergency, document actual care on Encounter and the relevant clinical resources at the real time. If a transfer request is created later, authoredOn must reflect the true creation time; Provenance, when used by the contract, records that true time as well. Do not backdate an order that did not exist. Use occurrence[x] only for the time of a requested service under a confirmed process, with the reason and emergency linkage recorded where needed.

In-network and out-of-network BHYT referrals

Law 51/2024/QH15 uses the categories initial care tier, basic care tier, and specialized care tier. Decree 188/2025/NĐ-CP, effective 15/08/2025, details multiple provisions of the Health Insurance Law. Old administrative-tier labels and shorthand percentages based on “provincial” or “central” facilities are insufficient to determine a current benefit, although those labels may still appear in transitional data.

Article 22 of the amended Health Insurance Law contains multiple branches based on professional-care tier, treatment type, beneficiary population, emergency circumstances, benefit scope, transfer conditions, and transitional rules. It is therefore unsafe to state one percentage as the general rule for every self-presented case at the specialized-care tier, or to mark a visit automatically “in-network” from an emergency flag alone. The benefit and supporting evidence must be determined under the instruments in force and the facts of the individual encounter.

The trial-use VN Core places vn-ext-insurance-visit-type on Encounter for compatibility with the legacy MA_LYDO_VVIEN list in Decision 4210/QĐ-BYT (1 = in-network, 2 = emergency, 3 = out-of-network, 4 = network-wide); code 5 for initial care is a project extension awaiting a source. Current exchanges use MA_DOI_TUONG_KCB and its 27-code list from Decision 3276/QĐ-BYT. vn-ext-referral-mode preserves HTCHUYEN under the existing integration convention (1 = self-presented, 2 = referred from a lower tier, 3 = from a higher tier, 4 = same tier, 5 = emergency). “Lower,” “higher,” and “same” here are displays from the source code set; they do not replace the current three-tier care model. Use Encounter.basedOn to link the ServiceRequest; Encounter.appointment references Appointment only. The payer or authorized adjudication service determines the result from the complete data and current rules, not from these two extensions alone.

{
  "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": "1",
        "display": "Đúng 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"
        }]
      }
    }
  ],
  "basedOn": [{ "reference": "ServiceRequest/sr-referral-001" }],
  "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

A transaction Bundle may be used when the destination server supports the transaction interaction and declares it in its CapabilityStatement. When accepted, the server processes the entries with FHIR transaction atomicity. If the endpoint does not support transactions, the parties must use a message, document, or other workflow API and define compensation and idempotency explicitly.

{
  "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.signature can carry a FHIR representation of a signature and related metadata; its presence does not by itself give the signature legal effect. Verification must identify the exact signed payload, canonicalization, algorithm, certificate and trust chain, timestamp, revocation status, and signer-identification policy. A payer or authority should use this data only within its powers and a published verification process.

Frequently asked questions

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

No. Circular 13/2025/TT-BYT does not prescribe SmartCA or a USB token. It allows lawful electronic signatures, biometrics, or other electronic confirmation methods under electronic-transaction law. A particular product is usable only when it satisfies the applicable legal requirements, trust framework, security policy, and document scope; naming a method does not make it valid for every referral.

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

Under the proposed state machine, Task moves to rejected with a statusReason. The originating facility receives the result through the agreed mechanism—Subscription when supported, polling, or messaging—and may create a new request. The previous request is retained or transitioned under the record policy and versioning rules; it should not be deleted merely to hide business history.

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

The receiving facility records and provides emergency care under the applicable process. Do not create or backdate a ServiceRequest as if an order existed earlier. If the post-emergency process genuinely creates a transfer request, create the Resource at the real time, link the emergency Encounter, and record the context; Provenance, when used, reflects the true creation time. BHYT entitlement is determined by the authorized system from the applicable legal conditions and supporting evidence—not from priority=asap or any single FHIR code.

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

Base FHIR makes Patient.identifier optional, but trial-use VNCorePatient requires at least one identifier and a 1..1 CCCD slice as a project conformance rule. If no CCCD value is available, the slice remains present with data-absent-reason and the profile requires an allowed basis: the force-majeure-reason extension, a passport, or a birth certificate. An MRN may add a local identifier but does not by itself replace that condition. This is a trial-use VN Core constraint; Article 1(3) of Circular 13/2025 only requires EMR information to be linked to the personal identification number of the specified groups. It neither sets this FHIR cardinality nor permits a VNeID account to replace that number.

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