FHIR and VNeID: Vietnam's national digital health record

1. What VNeID and the PHR actually are

VNeID is Vietnam's national electronic-identification application, developed by an agency under the Ministry of Public Security. It provides an access channel for multiple public services, including residence, driver's licences, social insurance, and social health insurance; it should not be described as the only channel where a service may retain other approved portals or procedures.

The personal health record (PHR), known locally as "Sổ sức khỏe điện tử", is a VNeID section that displays health information within the scope published by competent authorities. Health systems supply the data, the Ministry of Health governs the content, and VNeID is a display channel. An application-account relationship does not by itself prove a one-person-to-exactly-one-record cardinality at the clinical-data layer; record reconciliation requires separate MPI and identity-governance rules.

PHR rollout is expanding gradually through official Ministry of Health channels. Nationally, the rollout schedule is tied to Circular 13/2025/TT-BYT, Decision 1551/QĐ-BYT as amended by Decision 2062/QĐ-BYT, and the Ministry of Health's shared digital-platform decisions; this article describes only the publicly documented data and integration layer.

2. Decision 1332/QĐ-BYT and the PHR scope

Decision 1332/QĐ-BYT (Ministry of Health) issued the personal health record for integration into the VNeID app, together with technical documentation describing the data scope and display format. The Decision positions the PHR as a platform whose content the Ministry of Health governs, while VNeID acts as the citizen distribution channel. The PHR structure covers basic demographics, encounter history, prescriptions, diagnostic results, and discharge summaries.

Alongside Decision 1332, the Ministry of Health's downstream decisions on shared digital platforms — for example Decision 4048/QĐ-BYT (2025) on the deployment plan for shared digital platforms — continue to position the PHR as a Ministry of Health platform. The Department of Medical Service Administration and the National Health Information Center are the units directly responsible for operations. This is worth getting right, lest one mistakenly assume that the Ministry of Public Security owns the health data itself.

When designing VN Core FHIR, this article treats Decision 1332 as the authority for the PHR data scope. The reference inside the VNLegalDocumentRefCS CodeSystem uses the code QD-1332-VNeID to lock onto this exact document and avoid collisions with other decisions that share the number 1332.

3. Circular 13/2025 and linkage to personal identification numbers

Circular 13/2025/TT-BYT (Ministry of Health, issued 06/06/2025, effective 21/07/2025) regulates electronic medical records and replaces Circular 46/2018/TT-BYT. 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 under identity law. It neither creates two alternative identifiers nor mandates integration with any specific VNeID API.

VNeID integration is a separate application/integration layer governed by Decisions 1551 and 2062 and the applicable contract; it is not inferred as satisfying Article 1(3) of Circular 13/2025. The technical surface must be split into two directions. Facility-to-Ministry-of-Health synchronization follows the consolidated contract in Decisions 1551 and 2062. Citizen-facing VNeID Health read/display — OAuth scopes, ID-token claims, document-level authorization, refresh and revocation semantics — still depends on a separate contract from the responsible authorities.

4. FHIR-to-VNeID integration pattern — reference architecture

The diagram below describes the reference architecture under Decision 1551 as amended by Decision 2062: facility-to-Ministry-of-Health synchronization has a published technical contract, while citizen-facing VNeID Health read/display remains a separate integration contract.

[Hospital EMR (FHIR-native)]
       │
       │ FHIR Bundle / DocumentReference (reference architecture)
       ↓
[Health integration gateway (orchestrated by the Ministry of Health)]
       │
       │ Upload/sync: Decisions 1551 + 2062 Annex 02/03 · Citizen read: separate contract
       ↓
[VNeID app on the patient's smartphone]

Two data directions may be designed in this reference model: Push or Pull. Push means a healthcare facility sends data under an approved contract; Pull means the destination queries within the authorized request and scope. Each flow must establish roles, purpose, scope, and processing basis. Use FHIR Consent only when consent is the basis or an actual consent decision must be exchanged; do not assume every flow is consent-based.

The hospital-side FHIR layer may use VNCorePatient for healthcare identity, Composition for the record header, DocumentReference for documents, an IPS-shaped Bundle for the summary, and Consent, Provenance, and AuditEvent under the integration policy. The threat model, DPIA, and integration contract must define which events are audited and which artifacts require provenance; a FHIR server does not emit these Resources automatically.

5. FHIR and VNeID inside the PHR: CCCD is the primary citizen identifier

This is a frequent point of confusion in the field. In VN Core, Patient.identifier uses the CCCD as the core identifier, complemented by auxiliary slices for BHYT, BHXH (Vietnam Social Security), birth certificate, passport, and the hospital's internal medical record number (MRN). The NamingSystem for VNeID has been marked retired in this project to prevent modeling a VNeID account as an identifier on par with the CCCD. The reason: VNeID is an authentication and display channel, not the patient's independent clinical identifier.

An excerpt from the actual profile at input/fsh/profiles/VNCorePatient.fsh illustrates the identifier slicing:

Profile: VNCorePatient
Parent: Patient

* identifier ^slicing.discriminator.type = #pattern
* identifier ^slicing.discriminator.path = "type"
* identifier ^slicing.rules = #open
* identifier contains
    CCCD 1..1 MS and
    BHYT 0..1 MS and
    BHXH 0..1 MS and
    GKS  0..1 MS and    // Birth certificate — fallback for children without a CCCD
    HC   0..1 MS and    // Passport — for foreign nationals
    MRN  0..* MS

* identifier[CCCD].type = $vn-identifier-type-cs#CCCD
* identifier[BHYT].type = $vn-identifier-type-cs#BHYT
* identifier[BHXH].type = $vn-identifier-type-cs#BHXH
* identifier[GKS].type  = $vn-identifier-type-cs#GKS
* identifier[HC].type   = $vn-identifier-type-cs#HC
* identifier[MRN].type  = $vn-identifier-type-cs#MRN
* identifier[CCCD].system = $vn-sid-cccd (exactly)
* identifier[HC].system   = $vn-sid-passport (exactly)

// VNeID has NO dedicated slice in VNCorePatient core (VNVNeIDNS is retired).
// References to a VNeID account (when needed) live in the integration layer
// via AuditEvent / Provenance, not in Patient.identifier core.

To record which VNeID account performed an action, use AuditEvent.agent.who.identifier (or agent.altId when only a string identifier is available); if the actor is represented as a Resource, use Provenance.agent.who. AuditEvent.agent.policy carries applicable policy URIs, not account identities. This keeps the clinical identifier (CCCD) separate from the authentication-session identity.

6. FHIR IPS — a Patient Summary reference

The International Patient Summary (IPS) is an Implementation Guide co-developed by HL7 and CEN, grounded in ISO 27269. IPS defines a FHIR document carrying essential summary information for unplanned care, including cross-border settings. It is a useful comparison model for a health summary; selecting IPS for VNeID still depends on the official dataset, contract, terminology, usability testing, and conformance criteria.

An IPS Bundle is a document (type=document) anchored by a root Composition that describes its sections and links to clinical resources. A national adaptation must address local terminology bindings and constraints without simply claiming IPS compatibility. Cross-border exchange must be demonstrated against the exact package/version, terminology, and receiving systems.

7. IPS STU2 structure — Required, Recommended, and Optional

The IPS STU2 reference — specifically the "Structure of the International Patient Summary" — defines three explicit obligation levels for sections inside the Composition.

Required (3 mandatory sections)

1. Problem List — uses Condition with clinical-status active/inactive/resolved and verification-status confirmed.
2. Allergies and Intolerances — uses AllergyIntolerance.
3. Medication Summary — uses MedicationStatement (preferred) or MedicationRequest.

Recommended (4 sections)

4. Immunizations — uses Immunization, aligned with the Expanded Program on Immunization (EPI/TCMR) under the 2025 Disease Prevention Law.
5. Diagnostic Results — uses Observation (laboratory) and DiagnosticReport.
6. Procedures (History of) — uses Procedure.
7. Medical Devices — uses DeviceUseStatement for hearing aids, pacemakers, and other implanted medical devices.

Optional (depending on clinical context)

• History of Past Illness — Condition with clinical-status resolved or inactive.
• Pregnancy Status / History — Observation.
• Functional Status — ClinicalImpression.
• Plan of Care — CarePlan.
• Advance Directives — modeled with Consent using an appropriate category, or DocumentReference for the source document. FHIR R4 has no resource named AdvanceDirective.
• Vital Signs — Observation (vital-signs category).
• Social History — Observation (social-history category).

A skeleton for an IPS Bundle (simplified pseudo-code, not full validation-ready JSON) looks like the following. In a real implementation, the Bundle must carry a timestamp, every entry must have a fullUrl, and the Composition must include the FHIR R4 mandatory fields (status, type, subject, date, author, title).

// Pseudo-code for illustration — NOT directly validatable
Bundle {
  resourceType: "Bundle",
  type: "document",
  timestamp: "2026-04-30T17:00:00+07:00",
  identifier: { system: "http://fhir.hl7.org.vn/core/sid/skdt-bundle", value: "..." },
  entry: [
    { fullUrl: "urn:uuid:composition-1",
      resource: Composition { status, type, subject, date, author, title, section[...] } },
    { fullUrl: "urn:uuid:patient-1",     resource: Patient { ... } },
    { fullUrl: "urn:uuid:allergy-1",     resource: AllergyIntolerance { ... } },
    { fullUrl: "urn:uuid:condition-1",   resource: Condition { ... } },
    { fullUrl: "urn:uuid:medstmt-1",     resource: MedicationStatement { ... } },
    { fullUrl: "urn:uuid:immun-1",       resource: Immunization { ... } }
  ]
}

8. DocumentReference for discharge PDFs

Discharge summaries in Vietnam typically exist as PDFs digitally signed by the attending physician and the department head. When pushed into the PHR, the PDF is referenced through a DocumentReference. The document type uses the matching LOINC code — for example 18842-5 Discharge summary — together with a subject pointing to the Patient and an author pointing to the signing Practitioner.

{
  "resourceType": "DocumentReference",
  "status": "current",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "18842-5",
      "display": "Discharge summary"
    }]
  },
  "subject": { "reference": "Patient/vn-001" },
  "date": "2026-04-30T17:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-001" }],
  "content": [{
    "attachment": {
      "contentType": "application/pdf",
      "url": "https://bv.local/discharge/abc.pdf",
      "hash": "...",
      "size": 245000
    }
  }]
}

In a design that uses IPS, DocumentReference may sit alongside Observations and Conditions. Whether VNeID displays a structured summary, a PDF link, or a signature depends on the official dataset, contract, and user interface; this JSON is only one FHIR design example.

9. Consent for the VNeID PHR

Health data is sensitive personal data under Law 91/2025/QH15 and Decree 356/2025/NĐ-CP. Each sharing flow must identify the processing actors, recipient, purpose, scope, and applicable processing basis. When a consent decision must be exchanged between systems, FHIR Consent can model it; the Resource does not itself establish a lawful basis.

{
  "resourceType": "Consent",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://loinc.org",
      "code": "59284-0",
      "display": "Patient Consent"
    }]
  }],
  "patient": { "reference": "Patient/vn-001" },
  "dateTime": "2026-04-30T16:00:00+07:00",
  "policy": [{ "uri": "https://vneid.gov.vn/policy" }],
  "policyRule": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "OPTIN"
  },
  "provision": {
    "provision": [{
      "type": "permit",
      "period": { "start": "2026-04-30", "end": "2027-04-30" },
      "purpose": [{
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-consent-purpose-cs",
        "code": "EHRSHARE",
        "display": "Health record sharing"
      }],
      "actor": [{
        "role": { "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
          "code": "IRCP",
          "display": "information recipient"
        }] },
        "reference": { "reference": "Organization/vneid-health-gateway" }
      }]
    }]
  }
}

When consent is the processing basis, the decision must be captured and enforced before data is shared. Withdrawal must use the deployment's actual workflow and channel, and the FHIR Consent record is updated under the applicable versioning policy. Create AuditEvent or Provenance only when the event matrix and resource semantics require it. Access, rectification, and erasure requests still need separate workflows.

10. Authentication and authorization — sync specs published, citizen read pending

The published upload contracts specify OAuth2 Bearer authentication for the relevant synchronization endpoints. That fact does not establish a public citizen-facing OpenID Connect flow, token issuer, scope vocabulary, or authorization model for reading health records; those details remain part of a separate official integration contract.

It is important to distinguish two data directions. Upload/synchronization (healthcare facility → Ministry of Health) follows Decision 1551/QĐ-BYT and the current amendments in Decision 2062/QĐ-BYT: Annex 02 uses data-sync/push for check-up data; Annex 03 uses resource-sync/push, OAuth2 Bearer, RSA-SHA256-signed payloads and routing metadata. Citizen-facing read/display through VNeID Health remains a separate integration contract. This article does not invent scope names such as health-record.read.

11. Frequently asked questions

Does VNeID have a public FHIR specification yet?

Facility-to-Ministry-of-Health synchronization must follow Decision 1551/QĐ-BYT read together with Decision 2062/QĐ-BYT and its current Annexes 02/03. The citizen-facing VNeID Health read/display contract remains separate. VN Core models the current synchronization envelopes and keeps the citizen-app adapter outside Patient.identifier.

What if a patient does not use VNeID?

The 12-digit CCCD remains the core identifier in VNCorePatient. A patient who does not use VNeID still has a complete FHIR record inside the hospital system. VNeID is only an additional display channel — it does not replace the source-of-truth medical record at the hospital.

Is there a sandbox to test the VNeID API?

The reviewed public corpus does not provide a general-purpose VNeID sandbox or API specification for developers. Participation conditions, documentation, test environments, and accounts must be confirmed with the competent authority or program; this page does not infer a registration process.

Where is the PHR stored?

According to public documents (including Decision 1332/QĐ-BYT and Decision 4048/QĐ-BYT), the PHR is a platform managed by the Ministry of Health and surfaced through VNeID. The official physical storage location should be confirmed via concrete architecture documentation — it is not appropriate to draw conclusions without an authoritative source.

Is FHIR mandatory for the PHR?

Current legal documents do not mandate FHIR or IPS for the PHR. IPS may be evaluated as a cross-border patient-summary pattern; choosing IPS, another local profile, or a format published by the competent authority depends on the actual dataset, endpoint, workflow, and conformance criteria.

12. Legal and technical references

Vietnamese legal documents

• Decision 1332/QĐ-BYT — the personal health record on VNeID. Code in VN Core: QD-1332-VNeID.
• Decision 1551/QĐ-BYT (31/05/2026) — programme basis for periodic health-check interoperability. Code: QD-1551-2026.
• Decision 2062/QĐ-BYT (07/07/2026) — replaces Annexes 01–03, adds Annexes 04–05, and governs the current check-up technical contract. Code: QD-2062-2026.
• Decision 4048/QĐ-BYT (2025) — deployment plan for the Ministry of Health's shared digital platforms.
• Circular 13/2025/TT-BYT (issued 06/06/2025, effective 21/07/2025) — 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 prescribe a VNeID API.
• Law 91/2025/QH15 — Personal Data Protection Law, effective 01/01/2026. Code in VN Core: L-91-2025.
• Decree 356/2025/NĐ-CP — implementation guidance for Law 91/2025, effective 01/01/2026.
• Decree 102/2025/NĐ-CP — management of digital health data, effective 01/07/2025.
• Full reference at the VN Core legal corpus.

International technical specifications

• FHIR R4 (4.0.1) — the version used by VN Core.
• International Patient Summary STU2 — FHIR Bundle pattern for summary records.
• Structure of the International Patient Summary — Required, Recommended, Optional sections.
• LOINC — document-type codes for DocumentReference.
• FHIR Security — guidance on AuditEvent and Provenance.

Sources from the VN Core project

• input/fsh/profiles/VNCorePatient.fsh — defines the CCCD/BHYT/BHXH/GKS/HC/MRN identifier slices.
• input/fsh/naming-systems/VNVNeIDNS.fsh — the retired VNeID NamingSystem, with a note on why it is not used as a core identifier.
• input/fsh/terminology/VNLegalDocumentRefCS.fsh — the CodeSystem of legal documents referenced across the IG.

Further reading