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

1. Circular 13/2025 — requirements relevant to 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.

On identity, Article 1(3) requires EMR information to be linked to the personal identification number of Vietnamese citizens and of foreign nationals who have been issued an electronic identification account; it does not allow a VNeID account to be selected instead of that number. Article 2 covers infrastructure, security, recovery, and retrievability. Article 3 permits signing or electronic confirmation through a lawful electronic signature, biometrics, or another electronic confirmation method recognized by law. Circular 13 expressly cites Decree 137/2024/NĐ-CP in Article 5(2) for converting paper records created before the Circular took effect into data messages; that citation should not be generalized into a mandatory FHIR signature format.

Specific deadlines

Mapping requirements to one possible FHIR approach

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 when applicable│
└─────────────────────────────────────────────────┘
         │                        │
         │ Integration             │ FHIR API
         ↓                        ↓
┌──────────────┐          ┌──────────────┐
│ VNeID        │          │ BHXH gateway │
│ auth /       │          │ (Claim,      │
│ identity     │          │  XML 4210)   │
└──────────────┘          └──────────────┘

A hospital may choose an open-source FHIR server such as HAPI FHIR or an appropriate managed service. The choice depends on scale, in-house skills, the threat model, processing location, and applicable legal duties; using FHIR alone does not establish a domestic-storage requirement.

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 a fictional central 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 — Central Hospital A",
  "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. Trial-use VNCorePatient sets its CCCD slice to 1..1 as a project conformance rule, with data-absent-reason and allowed alternative-basis handling; other slices include BHYT, BHXH, GKS, HC, and MRN. Circular 13/2025 does not itself set this FHIR cardinality. VNeID is not part of Patient.identifier; authentication is handled outside Patient, and the deployment's audit/provenance matrix selects which events require a trace.

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. Personal identification numbers and the VNeID integration layer

Article 1(3) of Circular 13/2025 requires EMR information to be linked to the personal identification number of Vietnamese citizens and of foreign nationals who have been issued an electronic identification account. “Who have been issued an electronic identification account” qualifies the group of foreign nationals; it does not create a substitute VNeID identifier. In VN Core, CCCD/the personal identification number is the administrative identifier on Patient; any VNeID account or session that must be traced belongs to the application/integration layer under the applicable contract.

VNCorePatient defines six identifier slices: CCCD, BHYT, BHXH, GKS (birth certificate — for children without a CCCD), HC (passport — for foreign nationals), and MRN (a per-facility medical record number that may repeat). The passport 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 = #pattern
* identifier ^slicing.discriminator.path = "type"
* 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[CCCD].type = $vn-identifier-type-cs#CCCD
* identifier[BHYT].system = "http://fhir.hl7.org.vn/core/sid/bhyt" (exactly)
* identifier[BHYT].type = $vn-identifier-type-cs#BHYT
* identifier[BHXH].system = "http://fhir.hl7.org.vn/core/sid/bhxh" (exactly)
* identifier[BHXH].type = $vn-identifier-type-cs#BHXH
* identifier[GKS].system  = "http://fhir.hl7.org.vn/core/sid/gks"  (exactly)
* identifier[GKS].type = $vn-identifier-type-cs#GKS
* identifier[HC].system   = "http://fhir.hl7.org.vn/core/sid/passport" (exactly)
* identifier[HC].type = $vn-identifier-type-cs#HC
* identifier[MRN].type = $vn-identifier-type-cs#MRN
// 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, keep identity and data synchronization separate. Citizen authentication remains a reference model: the VNeID app issues an identity token to the citizen; the hospital validates that token through the approved identity channel and reconciles the identifier in the token against Patient.identifier under the contract. Decision 1551/QĐ-BYT is the baseline specification; Decision 2062/QĐ-BYT dated 7 July 2026 replaced Appendices 01–03 and added Appendices 04–05. Under the current consolidated contract, health-check synchronization uses Appendix 02 (data-sync/push), while health-resource synchronization uses Appendix 03 (resource-sync/push); citizen-facing VNeID Health read/display scopes and endpoints remain a separate integration contract. The deployment must derive an event matrix from legal bases, its threat model, and policy, then use AuditEvent or Provenance only where their semantics and the contract require them.

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. Electronic signing, confirmation, and Provenance

Article 3 of Circular 13/2025 permits signing or electronic confirmation through a lawful electronic signature, biometrics, or another electronic confirmation method recognized by law. Decree 137/2024/NĐ-CP forms part of the electronic-transaction framework and is cited by Circular 13 specifically for converting older paper records into data messages. Neither instrument mandates Provenance or a particular cryptographic signature format. Composition.attester may capture attester metadata, while Provenance.signature may carry a representation such as CMS/PKCS#7 or JOSE/JWS when the contract selects that model.

Provenance describes data origin, agents, transformations, or attestations. AuditEvent describes system security or privacy events. They serve different purposes; whether a particular interaction uses both, one, or neither must be defined in the workflow's control matrix from the legal basis, threat model, and policy.

The JSON below only illustrates one way to carry a CMS/PKCS#7 signature in Provenance.signature when an integration contract selects that representation. The data value is truncated, so this is not an exchange-ready or verifiable instance. In FHIR R4, targetFormat, sigFormat, and data each have cardinality 0..1; targetFormat is present here to declare the target format, not because the base specification requires it.

{
  "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": "MIIHpwYJ...BASE64_TRUNCATED..."
  }]
}

This truncated example does not establish successful cryptographic verification, certificate trust, or legal validity. If the contract selects JOSE/JWS instead of CMS/PKCS#7, the FHIR representation may use sigFormat = application/jose and carry the JWS in data. Changing the MIME type is not sufficient for interoperability or verification: the parties must also agree the exact signed payload and version, canonicalization, algorithm, key and certificate handling, timestamping, revocation checks, and verification process.

Each facility must select a signing or confirmation method appropriate to the content, signer, EMR policy, and applicable law. If the workflow uses a certificate-based signature, the implementation team must verify the provider, certificate, and trust-service conditions within the correct legal scope. Do not assume that every SmartCA product, USB token, chipped-CCCD flow, or VNeID flow uses the same signature container or exposes a public API without a published specification and interoperability test evidence.

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

The Personal Data Protection Law (Law 91/2025/QH15, effective 01/01/2026) and Decree 356/2025/NĐ-CP classify health data associated with an identifiable person as sensitive personal data. Duties and penalties depend on the processing role, conduct, and context. An EMR architecture should incorporate data protection into its threat model, DPIA where applicable, access controls, and operations; adopting FHIR does not alter those obligations.

A facility must identify its processing role and organizational duties under Law 91/2025, Decree 356/2025, and the instruments applicable to it, including a data-protection contact or impact record where the legal conditions require one. Classify data at field and purpose level; a FHIR Resource name does not automatically determine sensitivity. The control matrix should identify processing bases, AuditEvent events, Provenance data, and the cases in which Consent applies.

8. Access audit logs (AuditEvent)

Auditable-event scope must be derived from legal analysis, the threat model, access roles, and the system's security policy. FHIR defines AuditEvent to represent security and privacy events, but a server does not automatically emit one for every interaction. AuditEvent differs from Provenance: AuditEvent describes a system event; Provenance describes data origin, transformation, or attestation.

{
  "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": "Central Hospital A",
    "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 stage-gated implementation roadmap

This roadmap organizes work by completion evidence rather than fixed months. Duration and cost depend on workflow scope, source-data quality, procurement, safety requirements, and partner readiness; they should be estimated after discovery and a pilot.

The business case should separate build, licensing, terminology, migration, testing, information security, operations, and process-change costs. Do not use a generic cost or schedule range without a bill of materials, current-state data, and comparable-scope quotations.

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 assessment against Circular 13/2025 and the interoperability contract: review linkage of EMR information to the personal identification number for the groups specified in Article 1(3), together with signing and verification, access control, audit, and retention. If the scope includes a VNeID flow, assess it separately against the applicable integration specification instead of inferring it from the Circular. A FHIR façade may be placed over the existing system when its data model supports the required semantic mappings, references, versioning, and search; otherwise, targeted refactoring or migration is needed. It is not possible to conclude in advance that every EMR must—or need not—be rewritten.

Do we have to migrate every historical record into FHIR?

Migration scope depends on retention obligations, retrieval use cases, data quality, and the approved transition plan. DocumentReference can reference a preserved document, but it does not turn a scan into structured data or create legal validity by itself; signature, verification, and long-term preservation must follow the applicable rules.

How does VNeID integrate technically?

The reference model is: the VNeID app issues an identity token; the hospital system validates the token through the approved identity channel; the CCCD inside the token is reconciled against the Patient.identifier CCCD slice. VNeID never becomes a separate identifier on Patient. For data exchange, Decision 1551/QĐ-BYT is the baseline and Decision 2062/QĐ-BYT is the current amendment: Appendix 02 specifies data-sync/push for health checks, and Appendix 03 specifies resource-sync/push for health resources. Citizen-facing VNeID Health read/display endpoints remain a separate integration contract. Hospitals should design the connector as a replaceable adapter, not as a Patient identifier.

What is the difference between Provenance and AuditEvent?

Provenance describes data origin, agents, transformations, or attestations; AuditEvent describes security or privacy events such as access or system operations. They are not interchangeable, but neither are they automatically required together for every Resource. The workflow's control matrix must identify which events use which Resource and the minimum data to record.

Will FHIR replace XML 4210?

No. BHYT output data remains governed by the current XML chain descended from Decision 4210/QĐ-BYT and its related successor/amending instruments. If the source system uses FHIR, the hospital needs a tested mapping and adapter to the exact XML version accepted by Vietnam Social Security. No official instrument has replaced the whole flow with FHIR.

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 describes data origin, agents, transformations, or attestations; it may carry a signature when the contract requires one. Different from AuditEvent.
• AuditEvent: The Resource that describes security or privacy events. Scope comes from the legal, risk, and policy matrix; Law 91/2025 does not itself mandate one AuditEvent for every interaction.
• 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.