Healthcare data standards map: HL7, DICOM, IHE, SNOMED, LOINC, ICD

1. Two classification axes — exchange and semantics

When people first encounter healthcare data standards, they often assume they need to pick a single standard. In reality, the standards map is drawn on two complementary, not competing, axes. The first axis defines how data is packaged and transmitted between two systems. The second defines what the values inside that data actually mean. Understanding these two axes is the prerequisite for reading RFPs correctly, evaluating bids fairly, and avoiding pointless arguments like "FHIR replaces SNOMED CT."

Some standards do not fit neatly onto these two axes. CDA and FHIR Composition belong to the document architecture family — conventions for how multiple data fragments combine into a clinical document. The RIM in HL7 v3 and the openEHR reference model belong to the reference model family — abstract scaffolding for clinical entities, from which detailed archetypes are derived. IHE is not itself a new standard but a set of integration profiles; an IHE requirement is meaningful only when the applicable profile, actor, transaction, option, and version are named.

2. Summary table of 10 core standards

The table below summarizes the public legal corpus and technical sources reviewed through July 2026. It is not a deployment census, conformance certification, or legal advice. Public evidence in Vietnam states only what the corpus establishes; Basis/limitation names an instrument or a scope condition. Procurement and acceptance requirements must still identify the use case, actor, transaction, profile/option, version, terminology release, and contract.

3. Exchange standards — HL7, DICOM, IHE

HL7 v2, v3, CDA, and FHIR

HL7 is a family with several standards lines and versions. HL7 v2 uses pipe-delimited syntax; connectivity is defined only when both parties agree on the version, message/event, segments, optionality, vocabulary, and interface profile. HL7 v3/RIM, CDA, and HL7 FHIR are separate lines with their own conformance contracts. VN Core selects FHIR R4 (4.0.1), which defines 146 resources at different maturity levels, as the technical baseline for its current trial-use package. Other projects must select a version from the target IG, dependencies, CapabilityStatement, and endpoint contract; “HL7” or “FHIR” alone does not prove compatibility. See What is HL7 and What is FHIR.

DICOM

DICOM stands for Digital Imaging and Communications in Medicine. It is governed by the DICOM Standards Committee, with NEMA/MITA as secretariat. It covers information objects and file encoding, DIMSE/DICOMweb network services, and workflows such as Modality Worklist, Modality Performed Procedure Step, and Structured Report. A product supports a specific subset. When integrating a modality, PACS, VNA, or viewer, compare both products' DICOM Conformance Statements: Application Entities, SOP Classes, SCU/SCP roles, transfer syntaxes, network services, options, and error behavior. A DICOM logo, the ability to open a .dcm file, or a “DICOM-compatible” claim does not prove interoperability. The public corpus cannot quantify adoption in Vietnam. Detail page: DICOM in Vietnamese healthcare.

IHE profiles

IHE — Integrating the Healthcare Enterprise — is a collection of integration profiles. Each profile defines actors, transactions, options, and constraints on underlying standards for a specific use case; profiles do not all use the same HL7, DICOM, or security mechanisms. XDS, PIX, and MHD should be selected only when the architecture and contract need their respective use cases. A requirement must name the edition/version, implemented actor, required transactions/options, and test method; “supports IHE” is insufficient. The reviewed public list contains no IHE-Vietnam Affiliate/Deployment Committee and provides no project-adoption figures. Detail page: IHE profiles.

4. Reference model — openEHR

openEHR is not a pure exchange standard; it belongs to the reference model family. Its approach separates a Reference Model from archetypes/templates that describe concepts such as blood pressure, prescriptions, or laboratory results. The architecture is designed for governed clinical modeling; suitability for a longitudinal repository depends on the project's persistence, versioning, governance, and query requirements.

openEHR and FHIR can appear in one architecture, for example an openEHR repository behind a FHIR adapter/API, but that division of responsibilities is not mandatory. Mapping, data lifecycle, and conformance ownership must be specified. The reviewed public corpus is insufficient to establish whether Vietnam has production openEHR deployments; adoption status is therefore unknown, not “none.” Detailed comparison at openEHR vs FHIR.

5. Semantic standards — SNOMED, LOINC, ICD, RxNorm, UCUM

SNOMED CT

SNOMED CT is a polyhierarchical clinical terminology governed by SNOMED International. Access, deployment, and distribution rights depend on the Affiliate License, the territory's Member/non-Member status, the use scope, and national-extension terms; fees can vary, and being able to view content does not grant redistribution rights. Vietnam's Ministry of Health has published three scoped content releases: Body Structure under Decision 2427, Morphologic Abnormality under Decision 2493, and Allergy plus Finding under Decision 2805. Before embedding content in a product, a project must verify both the binding/version and the rights for the exact edition or derivative. Detail page: SNOMED CT in Vietnam.

LOINC

LOINC — Logical Observation Identifiers Names and Codes — is maintained by the Regenstrief Institute for observations, laboratory tests, and some document types. LOINC is distributed at no charge under a license with attribution, integrity, and derivative-work conditions; “no charge” does not mean no terms. FHIR base does not require LOINC for every Observation.code: use it only when the profile binding, use case, or exchange contract selects LOINC, with a code/version matching specimen, property, timing, method, and unit. Decision 1227/QĐ-BYT publishes 2,964 Vietnamese diagnostic-indicator codes; it does not itself establish a national LOINC mapping. Any map needs provenance, equivalence, versioning, and tests. Detail page: LOINC in Vietnam.

ICD-10 and ICD-11

ICD-10 is the tenth revision of the International Classification of Diseases issued by WHO. Vietnam's Ministry of Health published ICD-10 VN under Decision 4469/QĐ-BYT and supplemental COVID-19 codes under Decision 98/QĐ-BYT; mandatory scope must be read from the applicable instrument and workflow. ICD-11 came into effect within the WHO system on 01/01/2022, but national transition is a country decision. The VN Core legal registry reviewed through July 2026 contains no formal ICD-11 roadmap for Vietnam. Use, extraction, translation, or distribution must follow the exact WHO edition's license and any domestic-edition rights. Detail page: ICD-10 VN.

ICD-9-CM Volume 3

ICD-9-CM Volume 3 is a U.S. procedure classification, distinct from WHO ICD-10. Vietnam published a 2026 catalog under Decision 387/QĐ-BYT, superseding the 2020 catalog under Decision 4440/QĐ-BYT. A project should use it for Procedure.code, DRGs, or BHYT data only when the corresponding profile, instrument, or contract requires it; publication of the catalog does not create a general binding for every Procedure.

RxNorm and ATC

RxNorm is maintained by the U.S. National Library of Medicine for clinical drugs in the U.S. context. ATC — Anatomical Therapeutic Chemical — is maintained by the WHO Collaborating Centre for Drug Statistics Methodology for drug classification. The reviewed corpus cannot quantify RxNorm or ATC adoption in Vietnam. When encoding Medication.code, select the exact CodeSystem, version, and granularity required by the profile/use case; an internal product code, a Vietnamese catalog code, and an ATC class are not automatically equivalent and should coexist only when the contract says so.

UCUM

UCUM — Unified Code for Units of Measure — provides a formal grammar for unit codes. When a profile or contract selects UCUM for a FHIR Quantity, Quantity.system uses http://unitsofmeasure.org, Quantity.code carries the UCUM code, and Quantity.unit is the display label. FHIR base does not require UCUM for every Quantity. If the use case needs machine-computable comparison or conversion, the profile must state that expectation and the system must send the appropriate code, not only display text.

6. How the standards fit together

The two axes do not run independently, but not every event needs the entire stack. For a laboratory result, FHIR may provide the exchange layer when the target IG requires it; the code binds only to the terminology selected by the profile/use case; UCUM applies only when computable units are required. Document, IHE, and DICOM artifacts participate only within document, interconnection, or imaging scopes defined by the contract.

[Clinical event]
  └── packaged as a FHIR Resource (exchange)
        ├── code field → terminology bound by the profile/use case
        ├── Quantity → UCUM if the contract requires computable units
        ├── transported over REST + OAuth 2.0 (security)
        ├── if a document → CDA or FHIR Composition + Bundle
        ├── if imaging → DICOM Study + FHIR ImagingStudy reference
        └── if the contract requires document sharing → specified IHE profile + actor/transaction/version

Consider total cholesterol. If the profile/use case binds Observation.code to LOINC and the result is a molar concentration in serum or plasma, the matching code is 14647-2; a value of 5.2 can use UCUM mmol/L. Code 2093-3 represents mass concentration and must not be paired arbitrarily with the same unit. subject references Patient under the exchange contract. Composition/document Bundle, signatures, and MHD apply only when the profile, actor, transaction, option, version, and signature policy are specified and tested.

7. Public evidence and gaps in Vietnam

This section classifies what the reviewed public legal and technical corpus through July 2026 can establish. It does not count live facilities, products, or interfaces and must not label the whole country as having “adopted” or “not adopted” a standard.

Domestic instruments or catalogs are published

• ICD-10 VN under Decision 4469/QĐ-BYT, with supplemental COVID codes under Decision 98/QĐ-BYT. Required use must be determined for the report, record, or transaction within the applicable instrument's scope.
• ICD-9-CM Volume 3 (2026 edition) under Decision 387/QĐ-BYT, superseding Decision 4440/QĐ-BYT. Procedure, DRG, or BHYT scope follows the specific profile/instrument/contract.
• Decisions 2427, 2493, and 2805/QĐ-BYT publish scoped SNOMED CT VN content; they do not by themselves prove adoption or grant reuse rights beyond applicable terms.
• Decision 1227/QĐ-BYT publishes 2,964 Vietnamese diagnostic-indicator codes; the corpus does not establish a published national LOINC mapping.

Artifacts or choices require project-specific scope

• VN Core FHIR R4 — a trial-use artifact set under development, not legislation; conformance must name the package/version, profile, actor, capability, and workflow test.
• DICOM — each modality/PACS/VNA/viewer pair must match DICOM Conformance Statements, SOP Classes, roles, transfer syntaxes, and options; do not infer compatibility from product labels.
• IHE — apply a profile only when the contract states the actor, transaction, option, version, and test method; XDS/MHD is not the default for every HIE.
• LOINC, UCUM, SNOMED CT, RxNorm, or ATC — use only under the relevant binding/use case, exact version, and artifact license.

The corpus cannot establish deployment level

• HL7 v2, DICOM, and IHE — no public census by facility, interface, version, or vendor appears in the reviewed corpus.
• openEHR — insufficient public evidence to assert that production projects exist or do not exist; status is unknown.
• RxNorm and ATC — insufficient evidence to quantify use or claim a nationwide adoption roadmap.
• ICD-11 — in effect within the WHO system since 2022, but the VN Core legal registry reviewed through July 2026 contains no national roadmap.

8. Reference stack for scoping an EMR project

Circular 13/2025/TT-BYT sets an EMR rollout schedule, but it does not approve one standards stack. The list below is a scoping reference, not a guarantee of legal compliance or interoperability. Each project must build an obligations matrix for its facility type, workflow, data, receiver, contract, and instruments in force, then test every interface/profile/version.

Minimum stack

• Exchange: define the use case, actor, and IG/package/version first; VN Core currently uses FHIR R4 (4.0.1). Retain HL7 v2 only when an actual legacy interface requires it, with its own message profile/version.
• Diseases and diagnoses: use ICD-10 VN for Condition.code when the profile or workflow falls within Decisions 4469/QĐ-BYT and 98/QĐ-BYT.
• Surgeries and procedures: use ICD-9-CM 2026 for Procedure.code only within the scope defined by Decision 387/QĐ-BYT, a profile, or a contract.
• Lab tests and diagnostic indicators: use Decision 1227's Vietnamese catalog for its codes; add LOINC to Observation.code only when the binding/use case requires it and the map is governed, versioned, and tested.
• Clinical terminology: use the selected SNOMED CT VN scope only when the profile requires it and after verifying the edition/version and license; do not generalize the published branches to all SNOMED CT.
• Imaging: use DICOM according to the product pair's Conformance Statements and SOP Class/service scope; use FHIR ImagingStudy when the target IG requires a reference/context representation.
• Units of measure: use UCUM in Quantity.system/code when the profile or contract requires computable units.
• Clinical documents: use FHIR Composition and document Bundle only when the target IG/workflow requires them; not every document is a FHIR document by default.

Extended stack

• VN Core IG profiling: inherit the trial-use profiles at http://fhir.hl7.org.vn/core/ with an exact package and version. Interoperability still requires compatible CapabilityStatements, validation, workflow tests, and terminology agreements.
• SMART on FHIR: use only when the authorization architecture selects the exact profile/version; consent, client registration, token scopes, audit, and security policy still require design.
• FHIR Bulk Data API ($export): use only for a defined analytics use case and actor; assess processing basis, data minimization, authorization, and obligations under Law 91/2025/QH15 and Decree 356/2025/NĐ-CP.
• IHE: select MHD, XDS, or another profile only when the use case requires it, with explicit actors, transactions, options, version, and test plan.

9. Frequently asked questions

Which standards require a license fee?

Do not reduce licensing to “free” versus “paid.” SNOMED CT uses Affiliate/national licensing, with fees and obligations depending on territory, use, and distribution; HL7 licenses many standards at no charge for specified uses, but registration, copyright, trademark, incorporation/redistribution, and third-party IP terms still apply; LOINC is distributed at no charge under attribution and derivative-work conditions; DICOM requires no license fee to download or implement, while the standard text, trademarks, excerpts, and embedded third-party terminology retain separate rights; WHO classifications use edition-specific licenses — ICD-11 currently uses CC BY-ND 3.0 IGO, with separate translation/adaptation and API terms. Vietnamese translations or derivatives may carry domestic rights. Verify the current terms for the exact artifact before embedding or redistributing it; this paragraph is not legal advice.

Will ICD-11 replace ICD-10?

ICD-11 came into effect within the WHO system on 01/01/2022, but it does not automatically replace ICD-10 in every national workflow. The VN Core legal registry reviewed through July 2026 contains no formal Vietnamese ICD-11 adoption roadmap. Each report, medical record, statistic, or BHYT transaction must use the classification/version required by the current instrument and contract for that workflow.

openEHR vs FHIR — which one should I pick?

The two standards do not sit on the same axis. FHIR is an exchange standard with 146 resources in R4 and a REST API; openEHR is a reference model plus archetypes for the core EHR. There is no default choice for every project in Vietnam: exchange conforming to current VN Core uses FHIR R4, while openEHR may suit a clinical repository that needs detailed, long-lived modeling. The two can be combined when the API contract and mappings are specified explicitly.

Do I still need FHIR if I have DICOM?

DICOM and FHIR can complement each other, but scope must be explicit. Image objects and technical metadata belong to the DICOM services a product supports; FHIR ImagingStudy can represent metadata/references under the target IG. PACS–FHIR or modality–PACS interoperability must be tested from the DICOM Conformance Statements, endpoint capabilities, and workflow; it cannot be inferred because both products claim DICOM/FHIR support.

Is IHE actually needed in Vietnam?

Facility count alone does not decide this. IHE fits when the use case and contract require a specific integration profile; plain FHIR is not automatically sufficient or insufficient. A project must select the profile, actor, transaction, option, version, security policy, and test plan. XDS, PIX, and MHD are use-case choices, not a default HIE stack.

10. References

Vietnamese legal documents

• Decision 4469/QĐ-BYT (28/10/2020) — ICD-10 VN. Referenced in the legal corpus.
• Decision 98/QĐ-BYT (14/01/2022) — adds COVID-19 codes (U07.1, U07.2) to ICD-10 VN. See QD-98-2022.
• Decision 1227/QĐ-BYT (11/04/2025) — diagnostic test code catalog batch 1 (2,964 indicators). See QD-1227-2025.
• Decision 2427/QĐ-BYT (25/07/2025) — SNOMED CT VN batch 1 (Body Structure). See QD-2427-2025.
• Decision 2493/QĐ-BYT (2025) — SNOMED CT VN batch 2 (Morphologic Abnormality). See QD-2493-2025.
• Decision 2805/QĐ-BYT (04/09/2025) — SNOMED CT VN batch 3 (Allergy + Finding). See QD-2805-2025.
• Decision 387/QĐ-BYT (05/02/2026) — ICD-9-CM Volume 3, 2026 edition. See QD-387-2026.
• Circular 13/2025/TT-BYT (06/06/2025) — electronic medical records, effective 21/07/2025.

International technical documents

• HL7 FHIR R4 (4.0.1) specification — hl7.org/fhir/R4.
• FHIR Quantity datatype — hl7.org/fhir/R4/datatypes.html#Quantity.
• SNOMED International value proposition — snomed.org/value-proposition.
• SNOMED International licensing — snomed.org/get-snomed.
• LOINC getting started — loinc.org/get-started/getting-loinc.
• LOINC copyright and license — loinc.org/license.
• WHO ICD-11 implementation FAQ — who.int (ICD-11 FAQ).
• WHO copyright, classification licensing, and permissions — who.int/about/policies/publishing/copyright.
• DICOM current edition, including PS3.2 Conformance — dicomstandard.org/current.
• DICOM IP/patent policy — dicomstandard.org/patent.
• IHE profile catalog — ihe.net/resources/profiles.
• HL7 IP and licensing policy — hl7.org/legal/ippolicy.cfm.
• openEHR Architecture Overview — specifications.openehr.org.

11. Further reading