Why Vietnam's healthcare needs data standardization

1. The interoperability problem in five illustrative scenarios

The scenarios below illustrate forms of data discontinuity that can arise when systems lack a shared exchange contract; they are not survey findings about nationwide frequency.

Scenario 1 — Mrs. Lan's journey across three hospitals

Mrs. Lan passed through three healthcare facilities: a central-tier hospital that detected the disease, a specialized cancer hospital that delivered treatment, and a provincial hospital that handled follow-up. Each facility issued its own paper file along with a CD containing DICOM images. The downstream physicians had no time to re-read thirty pages of handwritten notes from the previous hospital, so they questioned her from scratch. Several routine blood tests were re-ordered because the original results were more than two weeks old and could not be retrieved quickly. The patient lost time and money — and worse, ran the risk of being treated on incomplete information.

Scenario 2 — A midnight emergency

A male patient was rushed unconscious into the emergency department of a tertiary hospital after a traffic accident. The on-call physician had no way to know whether this person had experienced a beta-lactam antibiotic allergy at another hospital two years earlier. The team had to decide based on the available information and an appropriate protocol. An authorized patient-summary service could support clinical decisions when data is timely, patient-matched, and access-controlled; VNeID connectivity remains a reference architecture until official API specifications and operating processes are available.

Scenario 3 — BHYT reconciliation

The same total cholesterol test can be coded under different names at two hospitals because each may maintain its own internal procedure catalog. Standard catalogs and validated payloads can reduce reconciliation differences. BHYT transactions still use the output-data standard prescribed by current legal instruments; FHIR may serve as an internal model or mapping layer, but it does not replace the statutory adjudication process.

Scenario 4 — The COVID-19 pandemic and its data lessons

The 2021 period demonstrated a need to aggregate case, contact, and immunization data quickly from multiple sources. A shared standard can reduce repeated mapping, but Bulk Data deployment still requires profiles, terminology, endpoints, security, infrastructure, and testing; it is not merely a configuration change.

Scenario 5 — Multi-center AI research

Multi-center AI teams commonly encounter vendor-specific ECG formats, different sharing processes, and uneven data quality. FHIR Bulk Data can standardize part of the exchange layer when participants agree on profiles and permitted uses; raw signal data, legal basis, de-identification, and analytical ETL still require separate work.

2. Five reasons Vietnam needs interoperable health data

The five scenarios above suggest five potential benefit categories. Actual effects should be assessed against a baseline and KPIs appropriate to each implementation program.

2.1. Patient quality and safety

When the receiving physician has appropriately authorized access to a patient summary — current diagnoses, active medications, recorded allergies, and recent results — that information can support clinical decisions. Systems may flag drug interactions, support renal-dose checks, or surface recent tests; effectiveness depends on completeness, timeliness, data quality, and integration into the care workflow.

2.2. Hospital operational efficiency

A facility may operate HIS, LIS, RIS, pharmacy, billing, and specialty systems at the same time. A shared IG can support hub-and-spoke or other integration topologies and reduce bespoke mapping when systems conform to the same data contract. Architecture, maintenance cost, integration time, and vendor-dependency risk do not change automatically merely because FHIR is used.

2.3. BHYT reconciliation and settlement

Shared terminology and a validated internal data model can support automated rules and mapping into BHYT submissions. However, output data used for BHYT adjudication and payment must still follow the current statutory standard and process; a FHIR Bundle is not automatically a replacement filing. Effects on payment time, reconciliation cost, or discrepancies must be measured for each program.

2.4. Public health and epidemiological reporting

The Disease Prevention Law (Law 114/2025/QH15, effective July 1, 2026) addresses immunization management, communicable disease surveillance, and reporting of public-health events. Shared data definitions and tested interfaces can improve reporting timeliness and consistency; actual latency also depends on reporting rules, data quality, infrastructure, and operating capacity.

2.5. Innovation: AI, research, and startups

Healthcare AI depends on data quality, representativeness, lawful basis, and governance. FHIR can structure the exchange layer but does not itself perform de-identification, consent management, authorization, or purpose assessment. Multi-center research still requires source-data harmonization, bias controls, and analytical transformation.

3. The legal framework driving standardization

Instruments adopted during 2025–2026 create obligations related to electronic medical records, database connectivity, and personal-data protection. Their scopes differ; those obligations do not by themselves recognize FHIR or VN Core as a national standard.

Beyond these four documents, Decision 1332/QĐ-BYT lays the groundwork for the Electronic Health Record (Sổ SKĐT) inside VNeID as a channel for providing people with health information. The project's tracked legal catalog is maintained in the VNLegalDocumentRefCS CodeSystem within the VN Core IG and published at legal framework.

4. Evaluating HL7 FHIR against a custom standard

A fair question is whether Vietnam's existing XML 4210 format can be extended to address broader interoperability needs. XML 4210 was designed for data output to social insurance; its current structure does not fully model workflows such as patient summaries, care coordination, e-prescriptions, or real-time epidemiological reporting.

HL7 FHIR R4 (4.0.1) defines 146 Resources across administrative, clinical, workflow, and financial groups; some artifacts are Normative while others remain STU/trial-use. The count does not mean FHIR automatically satisfies every use case: Profiles, Extensions, terminology, and workflow rules are still required. Five factors to assess are:

• International reference material: Several jurisdictions publish public IGs, including US Core, AU Core, JP Core, KR Core, and CH Core. Their scope and governance status differ, but they provide patterns for technical comparison.
• Specification and implementation tools: FHIR is published under CC0; HAPI FHIR and the Firely .NET SDK are open-source implementations. This can lower entry cost but does not remove operational, security, terminology, or conformance-testing costs.
• Web integration patterns: FHIR supports REST and JSON; OAuth 2.0 or SMART on FHIR can be applied when required by the IG and endpoint. VNeID integration still depends on an official API specification, access authorization, and an operating agreement.
• Vendor portability: A shared data contract can reduce bespoke mapping when parties use the same IG, version, terminology, and pass conformance tests. FHIR alone does not eliminate migration or vendor-lock-in risk.
• An active Vietnamese standards effort: Alongside the VN Core R4 draft published by the Ministry of Health IT Department in 2024 at http://fhir.ehealth.gov.vn/core/, Omi HealthTech is publishing a trial-use VN Core artifact set at http://fhir.hl7.org.vn/core/ as an open contribution for technical comparison through a national Working Group and formal governance decision.

Each option should be assessed in context. A custom standard introduces version-governance, terminology, tooling, and testing costs; XML 4210 remains appropriate for BHYT transactions within its current legal scope; HL7 v3 and openEHR address different problems with their own trade-offs. FHIR is a candidate for the exchange layer, but selection must follow the use case, target IG, endpoint capability, migration cost, and end-to-end test evidence.

5. Four common hospital objections, addressed

The four questions below reflect legitimate concerns about scope, cost, timing, and user impact. Each answer must be tested against a facility's current state and applicable legal duties rather than treated as a universal conclusion.

"Our hospital already has an EMR — what more do we need?"

The EMR and interoperability are different layers. An EMR is clinical data stored electronically inside one healthcare facility; interoperability is the ability for that data to move safely to another care setting, the insurer, or the patient. 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; it does not define a VNeID account as an alternative to the personal identification number. FHIR is an exchange layer proposed by the trial-use VN Core for testing that requirement; this is not a claim of national recognition.

"FHIR investment is too expensive — small hospitals can't afford it"

Cost depends on Resource scope, source-data quality, security requirements, terminology, traffic, and the operating model. Open-source software can reduce license fees but still requires infrastructure, staffing, testing, monitoring, and incident support. A hospital should estimate several scope scenarios and run a proof of concept before committing a production budget.

"Let's wait for the Ministry of Health to publish a complete national standard"

The Ministry of Health is the authority that can issue or recognize a national standard; while official direction is pending, the trial-use VN Core IG can be used as reference material. Hospitals can clean up drug, procedure, and diagnosis catalogs against ICD-10 VN; separate demographic from clinical data; and pilot Patient and Encounter exports in a sandbox. If a national standard is later approved, the rework will depend on profile, terminology, API-contract, and data-quality differences, so no fixed alignment time can be promised.

"Doctors don't care about coding standards"

Correct — and they shouldn't have to. A cardiologist does not need to know which SNOMED CT code maps to "essential hypertension"; the cardiologist needs an EMR interface that displays the right Vietnamese term and lets them pick it quickly. Terminology standardization is a layer below the user — the job of the EMR vendor and the data integration team. The doctor's experience stays in Vietnamese, with fast keyboard input and smart suggestions; behind the scenes, the system records the standard code so the rest of the health sector can interoperate with it.

6. A stage-gated roadmap for hospitals

This is a reference sequence, not a schedule commitment. Each hospital must set dates from its applicable legal duties, project scope, data quality, vendor capacity, and the acceptance results of the preceding stage.

A more detailed roadmap for the CIO role, including a KPI checklist and common risks, is available at For hospital CIOs.

7. Continue reading