FHIR for hospital CIOs: ROI, roadmap, KPIs

Under Circular 13/2025/TT-BYT (Ministry of Health), hospitals must complete their electronic medical record (EMR) systems by 30/09/2025, while other healthcare facilities (commune health stations, clinics) have until 31/12/2026. 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; a VNeID account is not an alternative patient identifier. In parallel, Decree 278/2025/NĐ-CP sets a unified deadline of 31/12/2026 for mandatory health data connection and sharing. This page analyzes four implementation models, a hospital-specific business-case method, a gate-based roadmap, and evidence-based vendor criteria.

TL;DR

  • Regulatory pressure: Circular 13/2025/TT-BYT (hospital deadline 30/09/2025, other facilities 31/12/2026), Decree 278/2025/NĐ-CP (data connection and sharing by 31/12/2026), Decree 102/2025/NĐ-CP (national health data infrastructure).
  • Architecture option: a FHIR layer over an existing EMR may reduce replacement scope when that EMR remains supportable; budget and duration should be approved only after an audit, data pilot, and dependency analysis.
  • ROI: must be measured against the hospital's own baseline. FHIR may reduce repeat integration work and improve traceability, but it does not by itself reduce BHYT denials or create AI readiness without data governance, terminology, security, and workflow change.
  • Five starting KPIs: conformance of in-scope records, identity-data quality, acceptance of BHXH submissions over the official channel, audit retrievability, and partner onboarding lead time.
  • Risks of delay: failure to meet obligations that apply to the organization, growing technical debt, and insufficient evidence of quality, safety, or interoperability at acceptance.

On this page

  1. Context — why 2026 is the inflection point
  2. Five pressures hospital CIOs are facing
  3. Four options and their trade-offs
  4. Baseline-based ROI framework
  5. Gate-based roadmap
  6. Internal team — who you need
  7. Vendor checklist with 30 evidence criteria
  8. Five starting KPIs
  9. Top risks and how to mitigate them
  10. Frequently asked questions
  11. Legal references
  12. Further reading

1. Context — why 2026 is the inflection point

The 2025-2026 period introduced several new requirements concerning EMRs, data connectivity, and personal-data protection. EMRs had previously been governed mainly by Circular 46/2018/TT-BYT. Circular 13/2025/TT-BYT (issued 06/06/2025, effective 21/07/2025) replaces that framework and introduces three groups of changes relevant to hospital CIOs.

First, the rollout schedule is now clearly tiered: all hospitals (every class) must complete their EMR by 30/09/2025; other healthcare facilities (commune health stations, polyclinics, specialty clinics) have until 31/12/2026. Second, EMR information must 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. This does not create a choice between a personal identification number and a VNeID account; any VNeID flow belongs to a separate application/integration layer and specification. Third, the technical bar for security, backup, disaster recovery, and audit trail retrieval is significantly higher than under Circular 46/2018.

Alongside Circular 13/2025, three other instruments form a compounding regulatory load. Decree 278/2025/NĐ-CP (issued and effective 22/10/2025) governs data connection and sharing within its stated scope and timetable. Each institution must determine the applicable actor, system, and milestone rather than apply one requirement to every database. Decree 102/2025/NĐ-CP (effective 01/07/2025) establishes the national health database and defines connectivity responsibilities by scope and subject. Law 91/2025/QH15 on Personal Data Protection and Decree 356/2025/NĐ-CP (both effective 01/01/2026) place health data within sensitive-personal-data rules under the statutory definitions. Impact-assessment records, data-protection personnel, and penalties depend on the processing role, activity, and violation category; 5% of prior-year revenue is not a default fine for every error.

On the financial axis, Decree 188/2025/NĐ-CP (effective 15/08/2025, issued 01/07/2025) implements the BHYT Law in detail, including benefit, payment, and assessment rules. A threshold tied to 45 months of base salary applies only in the cases specified by the decree; it is not a general ceiling for every claim. Decision 697/QĐ-BYT (effective 19/03/2026; new software and templates must be deployed by 01/07/2026) replaces the billing summary template issued with Decision 6556/QĐ-BYT in 2018, introducing a 12-category, 13-column structure supporting multiple BHYT payment sources. These obligations should be managed through a plan with explicit dependencies, owners, and acceptance evidence; they do not imply one universal delivery duration.

2. Five pressures hospital CIOs are facing

Unlike the 2018-2024 period when hospital IT was largely an internal operations story, from 2025 onward CIOs must handle five sources of pressure that should be assessed with evidence and data.

Regulatory pressure comes from three angles: the obligation to deploy EMR on time (Circular 13/2025), the obligation to connect data (Decree 278/2025), and the obligation to protect sensitive personal data (Law 91/2025 plus Decree 356/2025). Violations may trigger administrative penalties under Decree 90/2026/NĐ-CP (issued 30/03/2026, effective 15/05/2026), which specifies penalties for EMR-related conduct within its scope.

Financial pressure stems from tighter BHYT claim adjudication under Decree 188/2025/NĐ-CP and the new payment workflow under Decision 697/QĐ-BYT. Hospitals without well-structured data may face denials, write-downs, or delayed settlement when traceability is weak across HIS, EMR, and accounting systems. Competitive pressure comes from the private sector: providers that invested early in EMR, patient apps, and integration APIs are opening a gap in patient experience and partner connectivity, although actual FHIR conformance must be verified per implementation.

Patient pressure rises sharply as the personal health record (PHR) on VNeID, Vietnam's national digital identification app (Decision 1332/QĐ-BYT), gains traction: patients now expect to look up lab results, prescriptions, and discharge summaries directly in the app — provided their hospital can push structured data into the national system. Innovation pressure comes from clinical AI and telehealth: many diagnostic-support models, early-warning systems, and partner integrations depend on structured data, consistent terminology, and provenance. FHIR can provide a standardized exchange layer, but it does not replace data governance, information-security controls, clinical workflow, contracts, imaging standards, or the requirements of a receiving gateway.

3. Four options and their trade-offs

The following are four common models, not an exhaustive list. Each has a different cost, duration, and risk profile; the right pick depends on size, hospital class, and current IT maturity.

Distinguish EMR/interoperability duties from the choice to use FHIR: the cited instruments do not automatically mandate FHIR. “Do nothing” in Option 1 means having no program to meet applicable duties, not a reasoned decision that a particular use case does not require FHIR.

Option 1 — Do nothing

Assessment: not a long-term compliance strategy. Proceeding without an approved remediation program may create three types of risk:

  • Administrative fines under Decree 90/2026/NĐ-CP (effective 15/05/2026).
  • Inspections by the Ministry of Health and provincial health departments reviewing EMR progress.
  • Limited ability to meet the technical entry criteria of interoperability programs or partner arrangements.

An organization past an applicable date should confirm the reporting process with the competent authority and establish a remediation plan with owners, resources, risks, and progress evidence.

Option 2 — Buy a fully FHIR-native EMR

Replace the existing EMR with a product whose data architecture is FHIR at the core. Total cost of ownership and duration depend on functional scope, legacy-data quality, procurement, device integration, and transition design. This option may suit newly founded hospitals, greenfield campus expansions, or cases where the existing EMR has reached end-of-life. Main risks are vendor lock-in, operational disruption during cutover, and the cost of retraining clinicians and nurses from scratch.

Option 3 — FHIR layer on top of the existing EMR

Model: stand up a FHIR layer (HAPI FHIR, Microsoft FHIR Server, or Firely Server) alongside the existing EMR, connected through HL7 v2 ⇄ FHIR adapters and batch ETL. The existing EMR keeps serving the clinician UI; the FHIR layer can provide standardized representations and adapters for approved use cases. Connectivity with VNeID, BHXH, or the national database still depends on official specifications, agreements, and the protocols supported by each receiver.

  • Cost: establish after audit, proof of concept, and scope-specific quotations.
  • Duration: depends on data quality, interface count, procurement, and acceptance conditions.
  • Potential strength: limits front-end change and supports use-case-based rollout.
  • Fit conditions: the EMR remains supported, data access is available, and synchronization can be made reliable.

Compare this model with in-place upgrades, full replacement, and managed service using the same criteria: total cost of ownership, clinical safety, rollback, data-export rights, workflow fit, and evidence of VN Core conformance.

Option 4 — Outsource entirely

An EMR-as-a-Service offering may reduce the need to operate a platform internally, but pricing must be assessed across the lifecycle, data volume, support level, and exit costs. It may fit facilities without dedicated IT teams. Main risks are clinical-data lock-in and, especially, compliance with Law 91/2025 on cross-border data transfers: health data is sensitive personal data, so the hospital should determine when a cross-border transfer assessment dossier is required under Decree 356/2025/NĐ-CP. Before signing, the hospital should verify data locations and flows, the cross-border transfer mechanism, each party's responsibilities, the data-protection contact, and incident-response capability.

4. Baseline-based ROI framework

ROI should be calculated over a hospital-approved analysis period and against an auditable baseline. FHIR is enabling infrastructure for data exchange; benefits arise only when a use case operates in practice, has users, and measurably reduces a previously observed cost or risk.

Measure Baseline to collect Post-implementation evaluation
Total cost of one integration Labor, licenses, testing, support, and operational change for recent interfaces Compare like scope and service levels, including post-go-live maintenance
Partner onboarding lead time Median from scope approval to production acceptance Use the same start, end, and acceptance definitions
Potentially avoidable repeat-test rate Clinical definition, denominator, and rate for comparable cohorts Adjust for case mix and test whether access to prior results explains the change
BHYT claims denied, reduced, or delayed Rate and value by reason code in a comparison period Attribute only changes linked to data quality or traceability
Auditability Sample rate with retrievable source, time, and actor evidence Test AuditEvent, Provenance, and platform logs against approved scenarios
Digital-use-case readiness Existing use cases, data, terminology, access controls, and quality measures Accept each use case; do not infer AI readiness from the existence of a FHIR API

The business case should publish its formulas, data sources, assumptions, uncertainty ranges, and benefit owners. Subtract transition, operations, licensing, conformance testing, security, training, and terminology-maintenance costs. Do not attribute all BHYT-revenue or clinical-outcome changes to FHIR without an appropriate evaluation design.

This page does not provide universal cost or savings benchmarks. CIOs should use local operational data, current quotations, and sensitivity analysis to present base, downside, and upside cases.

5. Gate-based roadmap

This roadmap applies to Option 3 (a FHIR layer over the existing EMR). A phase advances only when its evidence meets agreed criteria. Duration and budget must be derived from scope, resources, procurement, external dependencies, and the hospital's clinical-safety requirements.

Gate Activities Evidence to proceed Planning basis
G0 Current-state audit + RFP drafting Data/interface inventory, gap report, use cases, and approved scope System volume, data quality, and procurement process
G1 Architecture, governance, and vendor selection Architecture decision, RACI, risk register, contract, and acceptance criteria RFP results, party responsibilities, and legal requirements
G2 FHIR sandbox stand-up CapabilityStatement, security tests, and synthetic test data running Platform, environment, security, and operations capability
G3 Use-case profiles, terminology, and mappings Versioned artifacts, test cases, examples, and validation report Use-case count and the gap between source data and VN Core
G4 HIS/EMR ⇄ FHIR integration and pilot Bidirectional reconciliation, idempotency, error handling, and user acceptance Interface count, frequency, SLA, and workflow change
G5 Identity, external connectivity, and audit controls API/file contract tests, access-control tests, AuditEvent, and incident plan Each gateway's official specification and external coordination schedule
G6 Production readiness and operations Cutover/rollback plan, SLOs, KPI dashboard, and support handover Clinical criticality, measured load, and support model

Two areas require particularly strong controls: profile/terminology design and source-data integration. For the first, the project team should apply the VN Core Implementation Guide (canonical http://fhir.hl7.org.vn/core/) and the NamingSystems for Vietnamese identifiers (CCCD, BHYT, BHXH, healthcare facility codes). In the second, the team should define the authoritative source, reconciliation rules, duplicate handling, and behavior when either system is unavailable.

6. Internal team — who you need

The project needs a multidisciplinary team with decision authority over architecture, data, clinical meaning, information security, and operations. FTEs, sourcing, and budget should follow from the backlog, support model, available capability, and use-case criticality.

Role Primary responsibility Capability evidence Sourcing model
FHIR Architect Architecture, profiling, versioning, and interoperability decisions Built/validated artifacts and Implementation Guide review experience Internal, advisory, or blended
Backend Developer (Java/Node) APIs, persistence, validation, observability, and automation Code review, automated tests, and operational documentation Prioritize sustainable capability
Integration Engineer (HL7 v2/Mirth) Mapping, interface engine, reconciliation, and error handling Versioned mappings, test fixtures, and runbooks Internal or partner with handover
Clinical Informatician Semantic, workflow, and clinical-safety validation Approval of use cases, ValueSets, and clinical acceptance criteria Clinician with allocated project time
Data Protection Officer (DPO) Data-protection duties, DPIA, and incident-response advice Documented role, authority, and contact arrangements According to the organization's legal model
QA / Security Engineer Conformance, performance, security, and recovery testing Reproducible test reports and remediation tracking Independence proportionate to risk

Data-protection responsibilities and personnel should be determined from processing scope, scale, the organization's legal role, and the instruments in force; do not assume a fixed FTE. A clinical informatician need not author FSH, but must have authority to validate semantics, workflow exceptions, and clinical-safety risk before a profile or mapping is released.

7. Vendor checklist: 30 evidence criteria

The checklist splits into three groups: technical, legal compliance, and commercial. The hospital should define mandatory gates, weights, and thresholds for its use cases in the RFP. Vendors should answer each criterion with verifiable evidence, not only a self-assigned score.

Technical (10 criteria)

  1. Native FHIR R4 (4.0.1) support with a complete and valid CapabilityStatement.
  2. Declares the supported VN Core version and provides conformance evidence, clearly recognizing trial-use status.
  3. HL7 v2 ⇄ FHIR adapter for the existing HIS/LIS.
  4. Support for DICOM ImagingStudy references against the PACS.
  5. Clearly stated FHIR platform: HAPI FHIR, Microsoft FHIR Server, Firely Server, or equivalent.
  6. Support for FHIR Bulk Data Access ($export) for analytics.
  7. Support for SMART on FHIR for embedded and third-party apps.
  8. Support for FHIR Subscription R4 (or Subscription Backport IG if a topic-based architecture is needed).
  9. AuditEvent and Provenance per HL7 standard.
  10. Meets hospital-approved throughput and latency SLOs under a representative, reproducible workload.

Legal compliance (10 criteria)

  1. Mapping document covering Law 91/2025 and Decree 356/2025 for every data-processing activity.
  2. Discloses data locations, flows, and recipients, with a compliance basis for storage and cross-border transfers.
  3. Provides data-protection roles and incident contacts appropriate to the committed operating model.
  4. DPIA template provided (Form 10 of Decree 356/2025).
  5. Encryption at rest and in transit under an approved cryptographic baseline, including key management and protocol lifecycle.
  6. Valid ISO 27001 certification or equivalent.
  7. Reference architecture aligned with HIPAA/GDPR for international scalability.
  8. AuditEvent retention policy with legal and business rationale and integrity controls.
  9. Backup and disaster recovery plan with RTO/RPO derived from business and clinical impact analysis.
  10. SLA/SLO, support response, and remedies proportionate to service criticality.

Commercial (10 criteria)

  1. Reference customers or other deployment evidence with comparable scope and scale.
  2. Transparent pricing model: license, maintenance, and professional services itemized separately.
  3. Source-code escrow clause to protect against vendor bankruptcy and lock-in.
  4. Vietnamese-language training and support, with bilingual Vietnamese-English technical documentation.
  5. Support team based in Vietnam (not solely remote from abroad).
  6. Product roadmap sufficient to assess support lifecycle, version upgrades, and platform dependencies.
  7. Track record at FHIR Connectathons or equivalent interoperability testing events.
  8. Clear pricing distinction between open-source components and proprietary commercial components.
  9. Risk-based vulnerability and patch process with contractual remediation times.
  10. A migration plan for hospitals that decide to switch vendors in the future.

The evaluation should separate disqualifying gates from weighted criteria and preserve evidence for the procurement decision. A total score cannot compensate for a missing mandatory safety, legal, or data-export requirement. Note that base FHIR R4 has no SubscriptionTopic resource — that capability lives in FHIR R4B/R5 or in the HL7 Subscription Backport IG, so item 8 accepts either implementation path.

8. Five starting KPIs

KPIs should be set at project kickoff and reported monthly to the hospital leadership board. The five metrics below are a starting set; definitions, denominators, exceptions, and targets must be approved from the hospital's baseline.

KPI Baseline Target-setting method Why it matters
% of in-scope records with a conformant FHIR Composition Measure for a defined use case and reporting period Approved rollout and quality threshold Document exchange when the use case requires it
% of patient records with a verified identifier Measure with a defined denominator and valid exceptions Improve according to verification capability and data quality Safer identity matching and record linkage
Acceptance rate for BHXH submissions over the official channel Separate technical and business-rule failures Based on the receiver's published SLA and specification Submission-process quality
% of audit samples meeting retention and retrieval policy Scenario-based tests across the retention period No critical failure; threshold per risk acceptance Audit and incident-response evidence
Partner onboarding lead time Median for integrations of comparable scope Controlled improvement without omitting tests Integration lifecycle efficiency

This page has no authoritative source establishing a FHIR Bundle receiving contract at BHXH. Measure the currently published XML output channel. FHIR may support the internal data layer or mapping; add a Bundle KPI only when a corresponding endpoint, profile, and acceptance process exist.

9. Top risks and how to mitigate them

Risk Likelihood evidence Impact basis Mitigation
Vendor misses delivery deadline Assess from project evidence Based on service criticality Milestone-based contract penalties, source-code escrow
Clinicians reject the new interface Assess from user research Based on safety and operational risk Keep existing EMR UI, train in small cohorts, run change management
Official receiving format differs from the internal FHIR model Verify against current specifications Based on transaction dependency Versioned mappings, contract tests, and an adapter for the published format
Law 91/2025 breach via cross-border data flow Assess from the data-flow map Based on legal and data assessment Map data flows, assess transfer duties, complete the applicable DPIA, and add data-protection clauses
Project budget overrun Based on forecast and scope volatility Based on the approved budget threshold Risk-register-based contingency, evidence-based payments, and gate reviews

Cross-border data transfer should be assessed from the actual architecture, including backups, telemetry, remote support, and subprocessors. Legal and data-protection teams should confirm the applicable duties, filings, and contract terms; the primary server location alone does not establish compliance.

10. Frequently asked questions

What is an appropriate starting scope for a small hospital?

HAPI FHIR is open-source licensed, but total cost also includes infrastructure, security, backup, monitoring, integration, validation, and operations staff. Start with one bounded, valuable use case, select only its required Resources, test with non-identifiable data, and estimate delivery from the pilot evidence.

Will a FHIR rollout disrupt clinician workflows?

A FHIR layer over an existing EMR may limit front-end change, but it can still affect workflow through data-entry rules, identity reconciliation, latency, error alerts, or downtime. Every option needs a clinical-safety assessment, user testing, and a rollback plan.

Should we wait for the Ministry of Health to publish a national FHIR standard?

There is no universal yes-or-no answer. Hospitals need not defer standard-independent work such as inventory, identifier and catalog cleanup, use-case definition, security controls, and data-export testing. The trial-use VN Core can support sandbox evaluation and technical feedback, but it is not a national mandate and may change. Production decisions should follow the current legal instruments, receiver specifications, and authoritative governance at contracting time.

We missed 30/09/2025 — what should we do?

Confirm the applicable duties and reporting process with the competent authority, legal counsel, and accountable leadership. Establish a remediation plan with risks, resources, and progress evidence, while prioritizing missing safety and retrieval controls. This page does not predict enforcement in an individual case.

11. Legal references

  • Circular 13/2025/TT-BYT (issued 06/06/2025, effective 21/07/2025) — electronic medical record deployment. See in legal-corpus.md.
  • Decree 278/2025/NĐ-CP (issued and effective 22/10/2025) — mandatory data connection and sharing, unified deadline 31/12/2026. See details.
  • Decree 102/2025/NĐ-CP (effective 01/07/2025) — national health database. See details.
  • Law 91/2025/QH15 (effective 01/01/2026) — Personal Data Protection Law. See details.
  • Decree 356/2025/NĐ-CP (effective 01/01/2026) — implementing the Personal Data Protection Law. See details.
  • Decree 188/2025/NĐ-CP (effective 15/08/2025) — implementing the BHYT Law, with a payment ceiling of 45 months of base salary.
  • Decision 697/QĐ-BYT (effective 19/03/2026; new software and templates must be deployed by 01/07/2026) — billing summary template, replacing Decision 6556/QĐ-BYT (2018).
  • Decree 90/2026/NĐ-CP (issued 30/03/2026, effective 15/05/2026) — administrative penalties in the health sector.
  • FHIR R4 (4.0.1) — international HL7 standard, canonical http://hl7.org/fhir/. hl7.org/fhir/R4.
  • VN Core Implementation Guide — canonical http://fhir.hl7.org.vn/core/, a trial-use artifact set initiated by Omi HealthTech.

FHIR does not guarantee a universal ROI, cost, or delivery duration. Each hospital should build its business case from an auditable baseline, current quotations, and sensitivity analysis.

12. Further reading

→ FHIR in electronic medical records — technical deep dive → HL7 v2 vs v3 vs FHIR — a primer for newcomers → Why Vietnamese healthcare needs standardization → Getting started with VN Core implementation → Vietnam's digital health legal framework