FHIR for Vietnam's electronic medical records (Circular 13/2025/TT-BYT)

1. Circular 13/2025 — core requirements for a FHIR-based EMR

Circular 13/2025/TT-BYT (Ministry of Health) was issued on 06/06/2025 and took effect on 21/07/2025, replacing Circular 46/2018 on electronic medical records. It sets the foundation for a new wave of EMR rollouts and is the main reason many hospitals now need FHIR — the international interoperability standard developed by HL7 for exchanging clinical data between disparate systems.

The core requirements are straightforward: the EMR must connect to the personal identifier or the VNeID electronic identification account; it must guarantee secure infrastructure and data recovery; it must comply with Decree 137/2024/NĐ-CP on electronic transactions and digital signatures; it must allow data retrieval when authorities request it; and it must comply with the Law on Medical Examination and Treatment 2023 regarding scope of practice.

Specific deadlines

FHIR mapping for each requirement

2. FHIR architecture for EMR

FHIR does not replace an existing EMR. FHIR is a communication layer that sits on top of the clinical data store, allowing the existing EMR to exchange data with VNeID, the BHXH gateway, laboratory systems, and other hospitals using a common language. This approach lets a hospital avoid rewriting the EMR from scratch while opening the door to long-term integration.

The diagram below shows where the FHIR server sits between the EMR user interface and external systems. Note that VNeID lives in the authentication and identity layer — not in Patient.identifier on a FHIR resource.

┌─────────────────────────────────────────────────┐
│ EMR UI (clinicians and nurses entering data)    │
└─────────────────────────────────────────────────┘
                     │ FHIR REST
                     ↓
┌─────────────────────────────────────────────────┐
│ FHIR Server (HAPI / Microsoft / Google / ...)   │
│  - Patient, Encounter, Composition              │
│  - Condition, Observation, Procedure            │
│  - MedicationRequest, AllergyIntolerance        │
│  - DocumentReference (PDF storage)              │
│  - Provenance, AuditEvent, Consent              │
└─────────────────────────────────────────────────┘
         │                        │
         │ Integration             │ FHIR API
         ↓                        ↓
┌──────────────┐          ┌──────────────┐
│ VNeID        │          │ BHXH gateway │
│ auth /       │          │ (Claim,      │
│ identity     │          │  XML 4210)   │
└──────────────┘          └──────────────┘

A hospital can pick an open-source FHIR server such as HAPI FHIR, or a managed service such as Microsoft Azure API for FHIR or Google Cloud Healthcare API. The choice depends on scale, in-house skills, and the data residency policy required by the Cybersecurity Law.

3. Mapping the EMR structure to FHIR Composition

Composition is the Resource that plays the role of the EMR header. A Composition holds metadata (document type, patient, encounter, date, author, title, attester) along with a list of section entries that point to other clinical Resources. Combined with a Bundle of type document, the Composition produces a self-contained, signed clinical document ready to exchange between systems.

The example below describes an inpatient cardiology record for patient Mrs. Nguyễn Thị Lan at Bach Mai Hospital, attested by Dr. Trần Văn Minh. Every required field of an R4 Composition is present: status, type, subject, date, author, and title. Each section includes text as a Narrative with status and div so the document remains human-readable in any standard FHIR viewer.

{
  "resourceType": "Composition",
  "id": "comp-bm-001",
  "status": "final",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "11503-0",
      "display": "Medical records"
    }]
  },
  "subject": { "reference": "Patient/nguyen-thi-lan" },
  "encounter": { "reference": "Encounter/enc-tim-mach-001" },
  "date": "2026-04-30T17:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-tran-van-minh" }],
  "title": "Inpatient record — Cardiology — Bach Mai Hospital",
  "attester": [{
    "mode": "professional",
    "time": "2026-04-30T17:00:00+07:00",
    "party": { "reference": "Practitioner/bs-tran-van-minh" }
  }],
  "custodian": { "reference": "Organization/bv-bach-mai" },
  "section": [
    {
      "title": "Administrative",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Patient Mrs. Nguyễn Thị Lan, admitted 28/04/2026.</div>"
      },
      "entry": [
        { "reference": "Patient/nguyen-thi-lan" },
        { "reference": "Encounter/enc-tim-mach-001" }
      ]
    },
    {
      "title": "History",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Hypertension for 5 years; penicillin allergy.</div>"
      },
      "entry": [
        { "reference": "Condition/tha-001" },
        { "reference": "AllergyIntolerance/aller-pcn-001" }
      ]
    },
    {
      "title": "Physical examination",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "ClinicalImpression/ci-tm-001" }]
    },
    {
      "title": "Diagnostics",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "DiagnosticReport/ecg-001" }]
    },
    {
      "title": "Diagnosis",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "Condition/dx-i10" }]
    },
    {
      "title": "Treatment",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "MedicationRequest/mr-001" }]
    },
    {
      "title": "Discharge summary",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "Observation/summary-001" }]
    }
  ]
}

With this structure, a receiving system can read the summary from section.text even before it fully supports every linked Resource. When it needs to verify the data, it follows entry down to the structured Resource.

4. The eight mandatory EMR sections mapped to FHIR Resources

The EMR template under Circular 13/2025 and the Ministry of Health's guidance circulars consists of eight main sections. Each section maps to one or more specific FHIR Resources. This section walks through each one with the corresponding Resources and important notes about Vietnamese terminology.

4.1 Administrative

The main Resources are Patient (under the VNCorePatient profile) and Encounter. VNCorePatient requires CCCD as the primary identifier, with optional slices for BHYT, BHXH, GKS (birth certificate, for children who do not yet have a CCCD), HC (passport, for foreign nationals), and an internal hospital MRN. Important note: VNeID is not part of Patient.identifier. The relationship between the EMR and VNeID is captured at the authentication layer, outside the Patient Resource, and traced via AuditEvent and Provenance.

Encounter describes a visit or admission: start and end time, encounter class (outpatient, inpatient, emergency), responsible department, and reason for admission. For BHYT patients, the Encounter carries extensions for the level of care and the BHYT visit type.

4.2 History

The history section uses Condition with clinicalStatus = inactive or resolved for past conditions, AllergyIntolerance for drug and food allergies, and FamilyMemberHistory for family history. Past-condition diagnostic codes use the Vietnamese ICD-10 set under Decision 4469/QĐ-BYT (Ministry of Health, 28/10/2020) and its subsequent additions.

4.3 Physical examination

ClinicalImpression captures the physician's overall assessment after examination. Vital signs (pulse, blood pressure, SpO2, temperature, respiratory rate) are recorded as Observation with standard LOINC codes. Organ-system findings (cardiovascular, respiratory, gastrointestinal, neurological) also use Observation, optionally grouped as a panel.

4.4 Diagnostics

Blood, urine, and biochemistry test results use Observation, bound to LOINC together with the diagnostic-indicator catalog under Decision 1227/QĐ-BYT (Phase 1, 11/04/2025), which covers 2,964 indicators across hematology, biochemistry, microbiology, pathology, and imaging. DiagnosticReport packages the consolidated result of a test or imaging report. ImagingStudy points to the PACS system to retrieve the actual DICOM images.

4.5 Diagnosis

Primary and secondary diagnoses use Condition with code bound to the Vietnamese ICD-10 CodeSystem, clinicalStatus = active, and verificationStatus = confirmed. To distinguish admission diagnosis, discharge diagnosis, complications, and comorbidities, use Condition.category together with VN Core's dedicated ValueSet.

4.6 Treatment

CarePlan describes the overall treatment plan. MedicationRequest is used for prescriptions under Circular 26/2025/TT-BYT for outpatient prescribing and Circular 27/2025/TT-BYT for traditional medicines and herbal remedies under BHYT. Procedure records procedures and surgeries using the 2026 ICD-9-CM edition under Decision 387/QĐ-BYT (05/02/2026), which replaces the 2020 edition.

4.7 Course of treatment

For inpatient records, each treatment day can be modeled as a sub-Encounter within the Encounter tree of the admission. Vital-sign monitoring rounds, treatment response, and nursing notes use repeating Observation entries over time. Communication between the attending physician and nursing staff can be captured via Communication when the system needs an audit trail.

4.8 Discharge summary

The discharge summary is typically packaged as a separate Composition with type bound to LOINC code 18842-5 (Discharge summary). When the discharge record must also be retained as a signed PDF, the system creates a DocumentReference pointing to the digitally signed PDF and links it to the original Composition through relatesTo.

5. Integrating CCCD and VNeID the right way

Circular 13/2025 requires the EMR to connect to the personal identifier or the VNeID account. In VN Core, these two concepts are kept separate, in line with FHIR design principles: CCCD is the administrative identifier on Patient, while VNeID is an authentication account at the integration layer.

VNCorePatient slices identifiers into five categories: CCCD, BHYT, BHXH, GKS (birth certificate — for children without a CCCD), and HC (passport — for foreign nationals). The slice is named HC, not passport. The NamingSystem for VNeID is marked retired and does not appear in Patient.identifier.

Profile: VNCorePatient
Parent: Patient
* identifier ^slicing.discriminator.type = #value
* identifier ^slicing.discriminator.path = "system"
* identifier contains
    CCCD 1..1 MS and
    BHYT 0..1 MS and
    BHXH 0..1 MS and
    GKS  0..1 MS and    // Birth certificate — for children without a CCCD
    HC   0..1 MS and    // Passport — for foreign nationals
    MRN  0..* MS

* identifier[CCCD].system = "http://fhir.hl7.org.vn/core/sid/cccd" (exactly)
* identifier[BHYT].system = "http://fhir.hl7.org.vn/core/sid/bhyt" (exactly)
* identifier[BHXH].system = "http://fhir.hl7.org.vn/core/sid/bhxh" (exactly)
* identifier[GKS].system  = "http://fhir.hl7.org.vn/core/sid/gks"  (exactly)
* identifier[HC].system   = "http://fhir.hl7.org.vn/core/sid/passport" (exactly)
// VNeID has no dedicated slice. The VNeID account is modeled at the
// authentication layer, not as a Patient.identifier. VNVNeIDNS is retired in VN Core.

For VNeID, the current reference model — pending the official API specification from Department C06 (Ministry of Public Security) and the Ministry of Health — is as follows: the VNeID app issues an identity token to the citizen; the hospital validates that token through the Public Service Portal API and reconciles the embedded CCCD against the Patient.identifier CCCD slice in FHIR. Every authentication and EMR-access event made through VNeID is logged by AuditEvent (see section 8) and, when attestation for the access session needs to be recorded, by Provenance.

When a hospital needs to record an identity-verification step (for example, the front-desk staff scanning a chipped CCCD and matching it against VNeID), it can profile VerificationResult to describe the verification outcome; this is a valid R4 Resource and fits the use case. Never use a non-existent Resource name like IdentityVerification.

For a deeper look at how VN Core models identifiers and VNeID, see the FHIR and VNeID page.

6. Digital signatures under Decree 137/2024 via Provenance

Decree 137/2024/NĐ-CP on electronic transactions requires electronic records to carry a valid digital signature to have legal force. In FHIR, the digital signature is captured in two places: Composition.attester records the authorized attester of the EMR, and Provenance.signature packages the actual digital signature as a PKCS#7/CMS or JOSE/JWS detached signature.

Provenance in FHIR is the Resource that records the chain of custody and attestation: who created the Resource, what sources were used, and when it was signed. This is distinct from AuditEvent — Provenance attaches to the integrity and trustworthiness of the data, while AuditEvent attaches to access history. A complete EMR needs both.

The Provenance example below uses a PKCS#7 detached signature, which fits well with most SmartCA solutions and USB tokens used in Vietnam. The targetFormat field declares the format of the Resource being signed; sigFormat is application/pkcs7-signature; and data contains base64-encoded CMS bytes.

{
  "resourceType": "Provenance",
  "target": [{ "reference": "Composition/comp-bm-001" }],
  "recorded": "2026-04-30T17:00:00+07:00",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "author",
        "display": "Author"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-minh" }
  }],
  "signature": [{
    "type": [{
      "system": "urn:iso-astm:E1762-95:2013",
      "code": "1.2.840.10065.1.12.1.1",
      "display": "Author's Signature"
    }],
    "when": "2026-04-30T17:00:00+07:00",
    "who": { "reference": "Practitioner/bs-tran-van-minh" },
    "targetFormat": "application/fhir+json",
    "sigFormat": "application/pkcs7-signature",
    "data": "MIIHpwYJKoZIhvcNAQcCoIIHmDCCB5QCAQExDzANBglghkgBZQMEAgEFADCB..."
  }]
}

When a hospital prefers JOSE/JWS over PKCS#7 (common with cloud-native systems), simply switch sigFormat to application/jose with data containing a base64-encoded JWS detached signature. The Provenance structure stays the same.

The signing certificate must be issued by a trust service provider authorized by the Ministry of Information and Communications. In practice, most hospitals use SmartCA from VNPT, FPT-CA, or a USB token plugged into the physician's workstation. Some emerging models pilot signing with the chipped CCCD plus a personal PIN, aligning with the broader VNeID integration direction.

7. Security under Law 91/2025 and Decree 356/2025

The Personal Data Protection Law (Law 91/2025/QH15, effective 01/01/2026) and the implementing Decree 356/2025/NĐ-CP classify health data as sensitive personal data, which requires the highest level of protection. Violations can be fined up to 5% of the prior year's revenue. A FHIR EMR must be designed from day one to meet these requirements.

Decree 356/2025 also requires hospitals to designate a Data Protection Officer (DPO) and maintain an inventory of sensitive personal data. In a FHIR project, that inventory typically lists every clinical Resource (Condition, Observation, MedicationRequest, AllergyIntolerance, and so on) and the Patient.identifier slices (CCCD, BHYT, BHXH).

8. Access audit logs (AuditEvent)

Law 91/2025 mandates that every access event on sensitive personal data be logged. In FHIR, every read, update, or delete on an EMR Resource emits an AuditEvent. This Resource is fundamentally different from Provenance: AuditEvent records system and security events, while Provenance records chain of custody and signature.

{
  "resourceType": "AuditEvent",
  "type": {
    "system": "http://terminology.hl7.org/CodeSystem/audit-event-type",
    "code": "rest",
    "display": "RESTful Operation"
  },
  "subtype": [{
    "system": "http://hl7.org/fhir/restful-interaction",
    "code": "read"
  }],
  "action": "R",
  "recorded": "2026-04-30T17:30:00+07:00",
  "outcome": "0",
  "agent": [{
    "who": { "reference": "Practitioner/bs-tran-van-minh" },
    "requestor": true,
    "network": { "address": "10.20.30.40", "type": "2" }
  }],
  "source": {
    "site": "Bach Mai Hospital",
    "observer": { "reference": "Device/emr-frontend-bm" }
  },
  "entity": [{
    "what": { "reference": "Composition/comp-bm-001" },
    "type": { "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type", "code": "2" }
  }]
}

9. A 12–18 month implementation roadmap for a FHIR EMR

The roadmap below is a reference for a provincial- or central-level general hospital that already runs a basic EMR and wants to add a FHIR layer to meet Circular 13/2025 along with the VNeID and BHXH interoperability requirements. Smaller hospitals can compress steps 4–5.

A typical 12–18 month rollout costs around VND 500 million to VND 2 billion depending on hospital size, covering FHIR server infrastructure, in-house or partner development effort, and integration fees with VNeID and BHXH. This investment should be planned alongside the information-security and DPO budget required by Law 91/2025.

10. Frequently asked questions about FHIR EMR

Our hospital already has an EMR. What more do we need to do with FHIR?

Start with a gap audit against Circular 13/2025: check whether the EMR already connects to CCCD, whether digital signing follows Decree 137/2024 properly, and whether access logging is complete. Then build a FHIR API layer on top of the existing EMR database. There is no need to rewrite the EMR from scratch.

Do we have to migrate every historical record into FHIR?

Not strictly. The most pragmatic approach is to focus on new data and active treatment records first, then migrate historical data as needed (for follow-up visits, BHXH requests, and so on). Closed paper records can be digitized into a DocumentReference with a digitally signed PDF appended.

How does VNeID integrate technically?

The reference model is: the VNeID app issues an identity token; the hospital system validates the token via the Public Service Portal API; the CCCD inside the token is reconciled against the Patient.identifier CCCD slice. VNeID never becomes a separate identifier on Patient. The official API spec from the Ministry of Health and Department C06 is still being finalized — hospitals should design an architecture that lets the connector be swapped when the spec ships.

What is the difference between Provenance and AuditEvent?

Provenance records the chain of custody and signature: who created this Resource, what sources were used, when it was signed. AuditEvent records access events: who has read this Resource, when, and from where. A complete EMR needs both. Provenance answers "Can I trust this Resource?", while AuditEvent answers "Who has looked at this Resource?".

Will FHIR replace XML 4210?

Not yet. BHXH still receives BHYT visit data in the XML 4210 format (under Decision 4210/QĐ-BYT, amended through the chain of Decision 130, Decision 4750, and Decision 3176). Hospitals need an adapter that converts FHIR to XML 4210 to submit to BHXH. The long-term direction is FHIR-native, but no formal document yet replaces 4210.

11. Legal references and further reading

Citation map

More in the knowledge hub

Glossary

• EMR / EHR: Electronic medical record / electronic health record.
• Composition: The FHIR Resource that plays the role of an EMR document header.
• Provenance: The Resource that records chain of custody and digital signature (who created it, who modified it, what sources were used). Different from AuditEvent.
• AuditEvent: The Resource that records access events (read, write, delete). Required by Law 91/2025.
• VerificationResult: A valid R4 FHIR Resource for modeling identity verification or credential verification outcomes. Do not confuse it with IdentityVerification — that name does not exist in R4.
• VNeID: Vietnam's national digital identification app. In VN Core, VNeID lives in the authentication layer, not in Patient.identifier.
• IPS: International Patient Summary — the FHIR standard for cross-border patient health summaries.