Implementation

Three concrete paths to put VN Core into practice.

Hospitals, vendors and public-sector teams start from different places. This page mirrors the Vietnamese implementation playbook: legal deadlines, suggested phases, common mistakes and links into the technical IG.

Playbook · Hospitals / care providers

Meet EMR and BHYT interoperability requirements without replacing everything at once.

VN Core helps providers standardize demographics, encounters, diagnoses, lab/imaging, medication, EMR documents, and BHYT payment data on FHIR R4. It runs alongside the current output-data XML standard under QĐ 3176/QĐ-BYT (often referred to by the legacy name “XML 4210”) rather than replacing it by default.

Relevant legal deadline: TT 13/2025/TT-BYT and QĐ 697/QĐ-BYT set separate legal milestones. Work backward from the applicable date, but estimate each technical gate from scope and test evidence rather than a fixed calendar.

Main steps

  1. Gate 1 · Inventory

    Survey and map source systems

    Inventory HIS, EMR, LIS, and PACS; identify data owners, interfaces, vocabularies, SLAs, and a quality baseline. Map local fields to Patient, Encounter, Condition, Observation, Coverage, and Claim.

    Output: Exit when system owners approve the inventory, mapping, gap/risk register, and baseline

  2. Gate 2 · Contract

    Pilot identity and encounters

    Select a bounded pilot workflow and agree on package version, profiles, terminology, interactions, and security contract. Apply the VN Core CCCD constraint; include BHXH and current or legacy BHYT identifiers only in the correct context.

    Output: Exit when the CapabilityStatement, test plan, sample data, and rollback criteria are agreed

  3. Gate 3 · Clinical pilot

    Add lab, imaging and medication

    Add DiagnosticReport, Observation, and MedicationDispense within the pilot scope. Preserve provenance, relationship, and version for mappings to QĐ 1227/QĐ-BYT and clinical terminology.

    Output: Exit when validation, interoperability tests, reconciliation, and clinical review meet approved criteria

  4. Gate 4 · BHYT adapter

    Add BHYT payment exchange

    Create Coverage, Claim, and ExplanationOfBenefit data; implement an adapter for the 16 BHYT logical models (Check-in + XML1–XML15) and three validate/submit/reverse operations. Element-level ^mapping is technical input; the package does not yet publish an end-to-end verified ConceptMap for the complete XML ↔ Claim/EOB flow.

    Output: Exit when every in-scope table/operation is tested, reconciliation passes, and current submission is not disrupted

  5. Gate 5 · Operate and scale

    Conformance and rollout

    Operate with monitoring, reconciliation, incident response, and audit. Expand only after SLA and security acceptance pass; use Consent, AuditEvent, and Provenance only where their semantics and deployment policy apply.

Common mistakes

  • Do not use VNeID as the core patient identifier. CCCD is the core personal identifier; VNeID is an application/account layer.
  • Do not switch off XML 4210 prematurely. There is no official replacement yet, so run FHIR in parallel.
  • Do not use the old 63-province administrative model for new data. NQ 202/2025/QH15 changed the official model to 34 provinces and two tiers.
  • Do not equate data-protection obligations with one FHIR resource. Assess DPIA, consent, access control, audit, and retention for the actor, processing purpose, and applicable law.

Reference resources

Playbook · HIS / EMR / LIS / middleware vendors

Publish a scoped FHIR interface with clear conformance evidence.

A vendor may retain its internal schema behind a VN Core adapter or change the product data model when justified. Decide from use-case scope, reuse potential, semantic loss, operations, and the organization’s own total-cost assessment.

Relevant legal deadline: Allow enough time for procurement, mapping, validation, and operational acceptance before the customer go-live; there is no universal buffer for every product.

Main steps

  1. Gate 1 · Reproducible setup

    Set up the development environment

    Run a FHIR server, install SUSHI and the FHIR validator, then load the VN Core package.

    Output: Exit when the build/package version is locked and the environment is reproducible in CI

  2. Gate 2 · Interface contract

    Implement the compatibility layer

    Map native HIS data into the resources required by the selected use case. Declare supported interactions, profiles, search parameters, and security in a CapabilityStatement; do not imply support for all FHIR REST interactions.

    Output: Exit when the interface contract, mappings, and test fixtures are reviewed and versioned

  3. Gate 3 · Conformance evidence

    Automate conformance checks

    Run the official FHIR validator in CI. Treat errors as release blockers and document accepted warnings.

    Output: Exit when CI is green for the declared scope, warnings are justified, and negative/security tests pass

  4. Gate 4 · Operational pilot

    Pilot with real deployments

    Run with customers that have agreed on scope. Measure SLAs, reconciliation, and rollback; write an implementation report before scaling and feed confirmed gaps back into the community process.

Common mistakes

  • Do not hardcode province/ward lists into product code. Use the VN Core terminology package so legal updates can be absorbed.
  • Do not validate only against local schemas. Use the FHIR validator with the VN Core package.
  • Do not drop Vietnamese extensions such as ethnicity, BHYT card details and insurance visit type. US Core is not a replacement for VN Core.
  • Do not create a parallel vendor-only profile set unless there is a clear extension path back into VN Core.

Reference resources

Playbook · Regulators / MoH / VSS / provincial health departments

Use the trial-use draft as a practical reference model before formal standardization.

VN Core is not an official national standard yet. It can still help public-sector teams evaluate field definitions, registry boundaries, BHYT mapping and EMR interoperability before issuing formal guidance.

Relevant legal deadline: Stabilizing VN Core, preparing an Affiliate filing, and aligning policy depend on pilot evidence, governance procedures, and approval by the relevant authorities; there is no default completion date.

Main steps

  1. Phase 1

    Review and comment

    Technical and policy teams review the IG, confirm operational fit and send concrete feedback through the project channels.

  2. Phase 2

    Coordinate pilots

    Select providers and partners representative of the workflow under review; define the dataset, success criteria, responsibilities, and Claim/EOB trial scope in advance.

  3. Phase 3

    Formalize stable pieces

    Move proven slices into official technical guidance while keeping backward compatibility with XML 4210/QĐ 3176/QĐ-BYT where required.

  4. Phase 4

    Support the HL7 Vietnam path

    Prepare governance and an Affiliate filing when eligibility criteria are met; transfer stewardship only after formal approval and a documented continuity plan.

Common mistakes

  • Do not publish a hard standard before pilots show that the model works in real hospitals.
  • Do not bind the ecosystem to a single vendor. VN Core is CC-BY-4.0 and designed for broad implementation.
  • Do not ignore international interoperability. VN Core stays on HL7 FHIR R4 and remains comparable with JP Core, KR Core, US Core and other national IGs.

Reference resources

Next step

Need an implementation path for your organization?

Omi HealthTech can share practical FHIR implementation experience from Vietnam, Japan and Korea, then help you choose a pilot scope that is small enough to finish and real enough to validate.

Book a 30-minute consultation Contact maintainers