Architecture principles for health data interoperability: international practice and comparison with Vietnam's frameworks

1. Interoperability must cover all four layers

The European Interoperability Framework (EIF), adopted by the European Commission in 2017, divides interoperability into four layers: legal, organisational, semantic and technical. Alongside these four layers are integrated public service governance and interoperability governance. The semantic layer ensures that the format and meaning of data are preserved and understood consistently by the parties throughout the exchange.

EIF is a framework for digital public services in general, not specifically for health. Even so, this layering helps avoid a common mistake: treating the choice of a technical standard as having solved the interoperability problem. A system with a standard API still cannot interoperate if:

• there is no legal basis for sharing (legal layer);
• it is unclear who provides, who is responsible and under which process (organisational layer);
• each party uses its own code set and its own definitions (semantic layer).

2. Share foundational components instead of integrating pair by pair

The Digital Health Platform Handbook, published by WHO and ITU in 2020, describes a digital health platform as the foundation layer for applications and systems serving health care. This foundation layer is a standards-based information infrastructure made up of shared, reusable components.

The Handbook lists several core services that most applications need: authentication, registries, terminology services with reference data, and workflow support. External applications connect to and share these components without having to integrate directly with each other. The Handbook presents this list as examples, not as a mandatory catalogue, and stresses that each platform will differ according to each country's context.

The OpenHIE architecture specification follows the same direction. The current specification describes components such as Client Registry, Facility Registry, Health Worker Registry, Interoperability Layer, Shared Health Record, Terminology Service and Product Catalogue. The component list changes between specification versions, so it should not be reduced to a fixed number.

3. Identifiers and master data must have an authoritative source

According to the WHO–ITU Handbook, registries manage the master data of each entity: identifier, name, location and the information needed for identification. Three common registries are for health facilities, health workers and patients; a registry holds only the minimum information sufficient for identification.

The Handbook also notes that each country usually already has cross-sector standards for identifying people, places, administrative units and government agencies. The architectural consequence is that health registries should reuse these identification standards rather than build a parallel system.

The "once-only" principle in EIF points in the same direction: users provide data once, and agencies can retrieve and re-share that data. At the infrastructure layer, the X-Road exchange platform allows organisations to reuse data already held in trusted national registers, while each organisation retains control of its own systems and data. X-Road is a tool for implementing the principle, not the place where the principle is set.

4. Semantics must be governed as a service

The WHO–ITU Handbook treats the terminology service as a foundational component for harmonising how data exchanged between applications is coded. The Handbook also acknowledges that mapping the code sets in use to national reference terminologies is time-consuming and complex, but unavoidable. Operating the platform needs a unit that manages master data and data quality, including the task of providing reference data to applications.

In OpenHIE, the Terminology Service is the central source for terminologies, dictionaries, code sets and ValueSets. The mandatory functions of this component are implemented according to the FHIR Terminology Service specification. This is a requirement for a product to be considered an OpenHIE component, not a legal regulation of any country.

At the specification layer, FHIR R4 defines terminology binding strengths. With required, the value must come from the specified ValueSet. With extensible, the value must come from the ValueSet if it contains a code suitable for the concept to be conveyed. Which strength to choose is a design decision for each IG. For example, the UK Core methodology documentation sets a principle of using extensible for all ValueSets.

5. Exchange specifications should be layered: core data set, Core IG, domain-specific IGs

The FHIR R4 specification acknowledges that practices, requirements and regulations differ between jurisdictions. FHIR therefore must be adapted (profiling), and adaptation layers can be stacked by domain, country, institution or implementer.

Many countries organise their national adaptation layer as a base Core IG:

• United States. US Core describes itself as the foundation for FHIR IGs within the United States. The USCDI data set published by ONC is kept separate from the implementation IG. The HTI-1 rule makes USCDI version 3 the baseline standard of the health IT certification programme from 01/01/2026; this rule applies to software participating in certification, not directly to every health facility.
• Australia. AU Core, published by HL7 Australia, sets minimum expectations and serves as the foundation for use-case IGs. AU Core is built on AU Base and is developed through the Sparked programme.
• Switzerland. CH Core, published by HL7 Switzerland, is tied to the national electronic patient record; an annex to the law on this record prescribes technical and semantic requirements for interoperability.
• Japan. JP Core is developed by a working group of the medical informatics association. The IG for the electronic medical record information sharing service of Japan's Ministry of Health, Labour and Welfare builds on JP Core and refers to JP Core for content it does not describe itself.
• Denmark. DK Core states that it actively harmonises its base profiles with those already published by the Nordic countries.

Three common points can be drawn from the examples above:

1. The core data set (which data needs to be exchanged) is separate from the implementation specification (which structure is used for the exchange).
2. The Core IG holds the stable shared part. Domain-specific IGs build on it and add constraints for each workflow.
3. The "minimum" level is how US Core and AU Core describe themselves, not a general HL7 rule.

At the international level, HL7's International Patient Summary (IPS) is an essential, specialty-agnostic summary designed for unscheduled and cross-border care. ISO 27269:2025 defines the IPS data set at an abstract level. Making a national Core IG compatible with IPS is a design choice specific to that IG.

The European Health Data Space (EHDS), under Regulation (EU) 2025/327, uses a common exchange format for priority data categories. The first group (patient summaries, e-prescriptions, e-dispensations) applies from 26/03/2029; the remaining groups (images, laboratory results, discharge reports) from 26/03/2031. The European Commission's Q&A states clearly that health facilities must be able to export and import this format, but are not bound as to the format they use internally.

6. Build on open standards, stay technology-neutral, keep components replaceable

The model set of design principles in the WHO–ITU Handbook includes two directly relevant principles. First, use internationally accepted standards for data, processes and technology. Second, use open source where appropriate to avoid vendor lock-in. The Handbook also warns that the risk of contractual lock-in can cause large costs in the long term.

OpenHIE prioritises consensus-based international interoperability specifications and is designed so that each component is replaceable. EIF sets principles of reusability, technological neutrality and data portability to avoid lock-in. The Principles for Digital Development (2024 version) bring these ideas together under the principle "Share, reuse, and improve": use open standards, build for interoperability, avoid duplication and fragmentation.

7. Interoperability testing and lifecycle governance before scaling up

The WHO–ITU Handbook identifies two key outputs when building a platform. One is a national standards framework, defining the set of standards the national system will use. The other is a governance framework, assigning roles for oversight, support, testing and maintenance of the platform.

According to HL7, FHIR Connectathons help demonstrate that a specification is complete and help IGs mature. The IHE Connectathon is a supervised peer-to-peer testing environment. Both are interoperability testing, not product certification programmes.

8. Comparison with Vietnam's digital architecture frameworks

The table below places each principle beside the corresponding content in the current frameworks. The right-hand column only records where the documents make room for the principle; it is not an assessment of the level of compliance. Note: EIF's four layers (legal, organisational, semantic, technical) and the national framework's four layers (infrastructure, data and core platforms, applications, interaction channels) are two different axes of division and do not correspond one-to-one.

The current frameworks do not provide for a public, multi-party interoperability testing mechanism of the Connectathon kind; Decision 2439/QĐ-TTg only refers to the data creation units of ministries, agencies and localities coordinating data testing and quality assessment with the National Data Center. This is a gap that international programmes often fill with test environments and public testing events before scaling up adoption.

9. Reading international sources correctly

Some conclusions are often drawn but have no basis in the official sources:

• HL7 International does not prescribe that every country must have a Core IG. The FHIR specification only acknowledges that country-level adaptation layers exist.
• WHO does not require countries to use HL7 FHIR. WHO uses FHIR for the machine-readable layer of SMART Guidelines, that is, WHO's own guideline content.
• EHDS does not force health facilities to change their internal format. The European Commission's Q&A on EHDS does not mention FHIR by name.
• "Profile" in the WHO–ITU Handbook is not synonymous with a FHIR profile. The Handbook uses the word in the sense of a process for applying standards to a workflow.
• Taking part in a Connectathon is not the same as being certified.

10. Frequently asked questions

Is choosing HL7 FHIR enough for interoperability?

No. FHIR is a standard at the technical layer and part of the semantic layer. Interoperability also needs a legal basis, organisational role allocation, shared identifiers, governed code sets and testing between parties.

How "minimal" should a national Core IG be?

There is no general rule. US Core and AU Core describe themselves as the minimum level on which domain-specific IGs build. A common approach is to keep the stable shared part in the core and push workflow-specific constraints down to domain-specific IGs.

Is a national terminology server needed?

The WHO–ITU Handbook and OpenHIE both treat the terminology service as a foundational component. The form of deployment, the operating unit and the scope of service are decisions for the competent authority.

11. Further reading