What VN Core contributes to the health data architecture framework

1. Where VN Core sits in the system of architecture frameworks

The Overall National Digital Architecture Framework (Decision 1425/QĐ-TTg), the National Data Architecture Framework (Decision 2439/QĐ-TTg), the Ministry of Health Digital Architecture Framework (Decision 2146/QĐ-BYT) and the health data framework (Decision 2113/QĐ-BYT) describe which layers, components, principles and roadmaps the system needs to have. The national framework itself states its requirements at the level of principles and orientation; specific standards and technical regulations are issued by sector regulatory authorities. In the health sector, the Ministry of Health Digital Architecture Framework assigns the Department of Science, Technology and Training as the focal point for developing and issuing, in 2026, standards and technical regulations on the structure of data messages exchanged by the national health database and specialised health databases.

VN Core works at this level of detail as an open technical contribution for comparison, not as a standard issued by a state agency. VN Core uses the standard mechanisms of FHIR R4 (profile, extension, CodeSystem, ValueSet, NamingSystem, ConceptMap, CapabilityStatement) to describe Vietnamese health data in a way that machines can validate. VN Core does not replace databases, platforms or catalogues managed by state agencies. The extent to which VN Core is referenced or applied needs a decision by the competent authority, through a governance process and a multi-stakeholder Working Group.

Canonical http://fhir.hl7.org.vn/core, FHIR version 4.0.1. The current release comprises 9 packages, namely the umbrella package hl7.fhir.vn.core and the module packages (core, health insurance (BHYT) data submission, clinical terminology, traditional medicine terminology, medical devices, pharmacy, data for citizens, legal).

2. Shared identifiers → NamingSystem

An interoperability architecture needs consistent identification of persons, facilities and practitioners across systems. The principle backed by international evidence is to reuse the state's existing identification standards rather than build a parallel system (see the article on architecture principles for health data interoperability).

VN Core declares 39 NamingSystems. Some examples:

• Personal identification number (12 digits on the identity card, managed by the Ministry of Public Security) is the citizen identifier used for electronic medical record connection under Circular 13/2025/TT-BYT.
• Healthcare facility code (medical examination and treatment facility code) consists of 5 digits. As of the verification on 23/07/2026, there was not yet any document reissuing the code system after the consolidation into 34 provinces and cities; facilities keep their old codes until they are issued new ones.
• Practising certificates already issued continue to be used during the transition to practising licences. The legal status of a certificate is recorded in a separate extension, not inferred from the identifier type.
• VNeID account: in VN Core's design, the VNeID account is not used as the patient's primary identifier; VNeID belongs to the citizen application, authentication or integration layer.

3. Shared catalogues → CodeSystem and ValueSet with a stated basis and validity periods

Shared catalogues can only be shared when every party knows clearly which catalogue a code belongs to, which version, which source document it is based on, and until when it remains valid. VN Core currently has 207 CodeSystems and 232 ValueSets. The naming and versioning policy (ADR-0017, amended by RFC-VNCORE-NAMING-02 from 17/09/2026) provides that:

• Identifiers of new artifacts do not contain document numbers, years of issue, code counts or appendix positions. Identifiers and codes already published are kept unchanged, including some older identifiers that contain a document number. The legal basis sits in the metadata and points to the project's legal document register.
• The business version of a code system is tied to the effective date of the source document, independent of the IG version.
• When a code changes meaning between two validity periods, the code system is split into separate canonicals: the old period is kept unchanged and immutable, so that historical data is still understood correctly. The administrative unit catalogue is a narrowly scoped exception: it uses a single unified canonical, with history by level.

Without separating validity periods, the same code could carry two meanings in two different years without the receiving system being able to tell them apart. This policy was introduced after a review found exactly that error in a catalogue of health check-up subject categories.

Several requirements of the Shared Data Dictionary have corresponding technical mechanisms in FHIR and in VN Core's policy:

This is a correspondence of technical mechanisms, not a claim that VN Core has been included in the Shared Data Dictionary. The process of proposing, reviewing, consulting on, approving and registering vocabularies belongs to the agency managing the Shared Data Dictionary system.

4. Interoperability standards → profile, CapabilityStatement, ActorDefinition

The Ministry of Health Digital Architecture Framework includes HL7 FHIR R4 in the roadmap for building a data interoperability mechanism. VN Core makes this choice concrete with 99 profiles and 78 extensions.

Profiles only answer the question "what structure does the data have". Interoperability also needs to answer "which system does what". VN Core declares 10 CapabilityStatements and ActorDefinitions for roles such as sender, receiver, electronic medical record repository, citizen application, BHYT record sender and BHYT record assessor, and public service portal. A dedicated gate ensures that the server capability declarations are internally consistent regarding read and write interactions and conditions for create.

5. Semantic mapping → ConceptMap

Legacy data and multi-source data need to be mapped to reference terminologies. The WHO–ITU Handbook regards this as laborious but unavoidable. VN Core currently has 25 ConceptMaps, each stating its scope and equivalence level:

• Paraclinical indicators to LOINC: maps the 2,964 indicators of the shared code catalogue of paraclinical indicators, Batch 1 (Decision 1227/QĐ-BYT), to LOINC. Here the equivalence classification (equivalent, or a broader LOINC code) is a classification based on inference rules, not yet a conclusion of expert appraisal.
• Vietnam ICD-10 to WHO ICD-10: an identity bridge for codes that have a corresponding WHO code; Vietnam's own extensions have no mapping target. The matching relies on the statements in the appendix of the issuing document, not on direct comparison against WHO's database.
• Vietnam ICD-10 to SNOMED CT: an initial set of 143 common diagnoses, used when projecting the health summary to the International Patient Summary; the artifact is in experimental status.
• Traditional medicine disease names and clinical types to ICD-10: covers all codes of the disease-name code set, all at the "related" level, with no claim of synonymy; the artifact is still in experimental status. The traditional medicine diagnosis branch is not yet mapped because the source appendix has no ICD-10 column.

6. Data for citizens and insurance data

Two-layer health summary. VN Core separates the domestic profile for the health record summary (Vietnamese codes) from the International Patient Summary profile (derived from the international IPS). The $summary operation is the projection point from domestic data to the IPS summary.

Logical models describe the source data first. For non-FHIR data formats such as the output data standard for health insurance (BHYT) assessment (Decision 3176/QĐ-BYT), VN Core uses logical models that describe the source structure accurately; target FHIR types appear only in the mapping section. This approach avoids data loss from type coercion. These logical models are not API specifications for the BHYT Data Reception Portal or for VNeID.

7. Personal data protection → Consent, Provenance, AuditEvent

Health data is sensitive personal data. VN Core has profiles for Consent, Provenance (data origin) and AuditEvent (access log), together with code systems for the method, purpose and category of consent, and a separate logical model for records of consent to personal data processing. These artifacts support recording the basis and traceability; they do not in themselves create a legal basis for data processing.

8. Specification quality governance

• Machine-readable legal document register. Each cited document has an issue date, effective date, status (in force, amended, future-effective, in transition, superseded, expired) and replacement relationships. The register states its own limits: it is the project's working register, not a complete national catalogue of legislation, and not legal advice.
• Automated gates before every commit: IG build, legal citations, in-force status of cited bases, code system naming policy, ConceptMap integrity and many other checks.
• A check coverage ledger records the status of each check for each artifact.

9. Ministry of Health Shared Data Dictionary (Decision 2113/QĐ-BYT)

Appendix 1 of Decision 2113/QĐ-BYT describes the field structure of 18 Ministry of Health shared data catalogues but does not publish the codes or values of those catalogues. VN Core release 0.10.0 represents this verifiable structural part:

• 18 logical models, one per catalogue, preserving the order, field names and descriptions of the appendix; 86 fields in total. The appendix uses three data types (Chuỗi, Ký tự, Logic); VN Core represents the 68 Chuỗi or Ký tự fields as string and the 18 Logic fields as boolean. The document does not state which fields are mandatory, so VN Core makes every field optional (0..1). This is a modelling decision of the project, not a requirement of the document.
• The data group table in Appendix 2 (20 data groups and 9 codes under the Data Reference Model, DRM, printed in the document) is kept as a source lookup table. The DRM codes have not been turned into a CodeSystem because the document does not establish them as a code system.
• The 25 metadata components of the Shared Data Dictionary (Section VII) are cross-walked to the closest carrying element in FHIR and in the project's governance process.

VN Core separates structural representation from semantic coverage. Every field has a place in a logical model. However, only 14 of the 86 fields have a current, verifiable business target in VN Core; 44 fields have a close or partially covering target, which is not treated as equivalent; the remaining 28 fields are currently kept as structure only, with no business target yet. For example, the patient visit type catalogue is linked to VN Core's existing patient visit type code system: three source columns (case, rule, benefit level) are added as properties of the 27 existing codes, without changing any code or display name.

The logical models here describe catalogue structure; they are not complete code lists. VN Core does not create values for catalogues that the document has not published. When the Ministry of Health publishes catalogue values, an exchange specification or an amendment to Decision 2113/QĐ-BYT, these artifacts will need to be re-checked.

10. What VN Core does not yet do

• It does not operate a public terminology service. The project's terminology server serves only internal IG building and validation.
• It is not an API specification for the Social Security portal, VNeID or public service portals.
• Many mappings are at an initial or partial level; the plan for a later release includes an item for full bidirectional coverage of the BHYT output data tables.
• It has no code values for the 18 catalogues of the Ministry of Health Shared Data Dictionary, because the document has not published them; 28 of the 86 fields are currently kept as structure only, with no business target yet.
• It has not yet been approved by a state agency or by HL7 International.

11. Frequently asked questions

Is VN Core a national standard?

No. VN Core is a public draft for community review. Recognition or adoption falls within the competence of state agencies.

Does using VN Core mean you already comply with the digital architecture framework?

No. Compliance with the architecture framework is assessed and monitored according to the method and indicator set whose guidance the Ministry of Science and Technology leads; the authority competent to decide on the investment is responsible for compliance. VN Core only provides a data exchange specification that can be used as one technical component.

Must health facilities store internal data in FHIR?

No. The current framework documents name HL7 FHIR R4 for the interoperability mechanism and refer to ensuring compatibility with international standards; no document in this group requires health facilities to store internal data in FHIR.

12. Further reading