HL7 v2 vs HL7 v3 vs CDA vs FHIR — choose by use case

1. Quick decision: four use cases, four standards

Rather than selecting one standard for the whole hospital, an RFP should identify sender, receiver, data, interactions, SLA, security, and conformance evidence for each use case. Multiple standards can coexist when each interface has a clear contract.

2. 12-axis comparison table

The table below helps with a fast assessment before going deeper. Some axes such as "schema strictness" and "learning curve" are relative, based on implementation-team feedback and observed integration patterns.

3. Deeper look at each standard

HL7 v2

HL7 v2 was born in 1988 and has evolved continuously: v2.1 (March 1990), v2.3 (March 1997), through v2.9.1 (2024). Its pipe-delimited ER7 form is compact and supported by many integration engines. Latency, throughput, and reliability still depend on transport, acknowledgements, infrastructure, and interface configuration.

Use v2 when you need low-latency internal hospital integration, partner systems already have HL7 v2 adapters, or you are running traditional ADT/ORM/ORU/MDM flows. Avoid v2 when you need to expose APIs over the public internet, require zero-trust auth, or your partners refuse to open MLLP ports through their firewalls.

v2 permits many optional fields and local variations. It does have conformance profiles, but two vendors must still agree on version, message profile, vocabulary, and segment rules such as OBX usage. Mapping effort therefore depends on the specification and testing discipline of each interface.

HL7 v3

v3 is built on the RIM (Reference Information Model) and uses tightly specified models, vocabularies, and messages. A new project should select v3 when a specification or partner system requires it; FHIR may fit a new API better, but it does not automatically replace an operating v3/CDA/SPL contract.

CDA R2

CDA is a structured XML clinical-document standard and can be signed within an appropriate exchange architecture. In the US, C-CDA is used for many clinical exchange documents. In Vietnam, selecting CDA for referrals, discharge summaries, or records must follow the system's workflow, electronic-signature, and legal-record requirements.

FHIR supports documents through Composition in a document Bundle, but that does not make every CDA template one-to-one equivalent to FHIR. A system can retain CDA and add FHIR when the exchange contract, IG, and testing support it.

FHIR R4

FHIR R4 (4.0.1) was released publicly in 2019. Important caveat: R4 is not fully normative — HL7 labels it "Mixed Normative + STU", meaning the foundational artifacts (XML/JSON/RDF format, RESTful API, terminology services, and several resources such as Patient and Observation) are Normative, while most clinical resources remain at STU (Standard for Trial Use). R4 is the current VN Core baseline. R5 (5.0.0) is the latest published major release and remains Trial Use; R6 is currently a CI/ballot build. Production selection must follow the target IG and compatibility chain, not a global default.

FHIR uses formats and protocols familiar to web teams, including JSON and REST. OAuth/SMART is an additional security layer, not a default in FHIR core. An endpoint must declare supported resources, interactions, search parameters, and security through its CapabilityStatement and applicable IG. Profiles and extensions still need governance to avoid incompatible variants.

4. Side-by-side code sample: ADT^A01 admission

The same event — patient Nguyễn Thị Lan (MRN0001) admitted to ICU room 301 at 14:30 on 30/04/2026 — represented in three standards so you can feel the difference.

HL7 v2.5 (pipe-delimited)

MSH|^~\&|HIS|HOSP|ADT|HOSP|202604301430||ADT^A01|MSG001|P|2.5
EVN|A01|202604301430
PID|1||MRN0001||NGUYEN^THI LAN||19850315|F|||123 LE LOI^^HCMC^^70000^VN
PV1|1|I|ICU^301^1|||||||||||||||V001

This ER7 example is compact, but a production interface also needs a message profile, vocabulary, acknowledgements, error handling, and interoperability testing between the parties.

CDA R2 (XML, abbreviated)

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <templateId root="2.16.840.1.113883.10.20.22.1.1"/>
  <id root="2.16.840.1.113883.19.5.99999.1" extension="DOC0001"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1"
        displayName="Summarization of Episode Note"/>
  <effectiveTime value="202604301430"/>
  <recordTarget>
    <patientRole>
      <id extension="MRN0001" root="2.16.840.1.113883.19.5"/>
      <patient>
        <name>
          <family>Nguyễn</family>
          <given>Thị Lan</given>
        </name>
        <administrativeGenderCode code="F"
          codeSystem="2.16.840.1.113883.5.1"/>
        <birthTime value="19850315"/>
      </patient>
    </patientRole>
  </recordTarget>
</ClinicalDocument>

CDA provides a document structure; digital signatures, legal archiving, and a transport such as IHE XDS must be configured and verified in the corresponding implementation layer.

FHIR R4 (Bundle transaction)

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "urn:uuid:9b1e5a2c-3f8d-4a1c-8e7b-1c2d3e4f5a6b",
      "resource": {
        "resourceType": "Patient",
        "identifier": [{
          "system": "http://fhir.hl7.org.vn/core/sid/mrn",
          "value": "MRN0001"
        }],
        "name": [{
          "family": "Nguyễn",
          "given": ["Thị", "Lan"]
        }],
        "gender": "female",
        "birthDate": "1985-03-15"
      },
      "request": { "method": "POST", "url": "Patient" }
    },
    {
      "fullUrl": "urn:uuid:7c2f6b3d-4e9a-5b2d-9f8c-2d3e4f5a6b7c",
      "resource": {
        "resourceType": "Encounter",
        "status": "in-progress",
        "class": {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
          "code": "IMP",
          "display": "inpatient encounter"
        },
        "subject": {
          "reference": "urn:uuid:9b1e5a2c-3f8d-4a1c-8e7b-1c2d3e4f5a6b"
        },
        "period": { "start": "2026-04-30T14:30:00+07:00" },
        "location": [{
          "location": { "display": "ICU - Room 301" }
        }]
      },
      "request": { "method": "POST", "url": "Encounter" }
    }
  ]
}

The FHIR Bundle is longer than the sample v2 message and explicitly represents resources, code systems, and internal references with urn:uuid. A client must still follow the profiles, terminology, interactions, and transaction rules declared by the server.

5. Hybrid v2 + FHIR architecture

At modern hospitals worldwide, and increasingly in Vietnamese hospital integration projects, the dominant pattern is to keep v2-style internal integration where it already works and expose FHIR through a controlled facade for external interactions.

[Lab analyzer]   --HL7 v2 ORU---> [HIS / EMR core]
[Pharmacy]       --HL7 v2 RDE---> [HIS / EMR core]
[RIS / PACS]     --HL7 v2 ORM---> [HIS / EMR core]
                                       |
                                       v
                          [FHIR Facade / API Gateway]
                                       |
        +---------+----------+---------+----------+----------+
        v         v          v         v          v          v
   [Mobile app] [AI/ML]  [VNeID]  [BHXH portal] [Telehealth] [Partners]

A combined architecture can retain tested v2 interfaces and add FHIR one use case at a time. It is an option, not a mandatory pattern; each bridge must be assessed for mapping, losslessness, operations, and conformance:

• HAPI FHIR — Java FHIR libraries and server; v2 mapping requires additional components or transformation rules.
• NextGen Connect (Mirth Connect) — an integration engine that can configure channels between formats.
• Microsoft FHIR Converter — a template-based reference project for HL7 v2/C-CDA-to-FHIR conversion; assess maintenance status and scope before use.
• Commercial FHIR products — adapter and SMART/OAuth capabilities vary by version; verify product documentation and the endpoint CapabilityStatement.

6. Stage-gated v2 and FHIR transition roadmap

There is no common schedule for converting every v2 interface to FHIR. Each stage below closes only when its exit criteria are met; v2 and FHIR may continue in parallel when that is the safer operating model.

Stage gates are not a fixed calendar. Estimate effort from interface count, data quality, customization, safety requirements, and party capabilities; do not assume a rewrite or v2 sunset.

7. Decision matrix for Vietnamese use cases

This table consolidates the questions CIOs actually face during an RFP. The "Verdict" column answers in the Vietnamese 2026 context.

8. Frequently asked questions

Can we drop HL7 v2 entirely?

There is no universal timeline. Device and vendor support for v2 varies by product, while a FHIR channel requires compatible IGs and endpoints. A migration plan should retain tested v2 flows, add FHIR by use case, and retire v2 only as the relevant dependencies are replaced.

Will FHIR fully replace CDA?

CDA and FHIR Composition + document Bundle both support clinical documents, but their templates, semantics, and ecosystems are not automatically equivalent. Migrate only after mapping, signatures, retention, transport, and legal requirements have been verified.

A small hospital can only afford one standard — which one?

There is no universal answer. Select the contract that source systems, devices, and partners actually support; a hospital may keep v2 for device flows and use FHIR for a specific API. A converter does not remove the need for mapping, validation, and interoperability testing.

Does Vietnam have a national Implementation Guide yet?

An Omi HealthTech-initiated trial-use VN Core IG based on FHIR R4 is published at the canonical http://fhir.hl7.org.vn/core/ in parallel with the Ministry of Health IT Department version (http://fhir.ehealth.gov.vn/core/). No legal document yet mandates a specific IG.

Is FHIR R5 stable enough to skip straight to it?

R5 (5.0.0) is the latest published major release and remains Trial Use; R6 is currently a CI/ballot build. VN Core currently requires R4 (4.0.1). A new project must use the version required by its target IG, package dependencies, and endpoint CapabilityStatements; there is no fixed two-to-three-year waiting rule.

9. References

• HL7 International — HL7 v2 Product Brief (timeline for v2.0/v2.1/v2.3 and the current v2.9.1).
• HL7 FHIR R4 CapabilityStatement — declaring a FHIR system's capabilities.
• HL7 FHIR R4 spec — hl7.org/fhir/R4/ (labeled "Mixed Normative + STU").
• HL7 FHIR R4 Bundle — hl7.org/fhir/R4/bundle.html (transaction with fullUrl/urn:uuid).
• HL7 v3 Product Suite — Australian Digital Health Agency overview of v3.
• HL7 CDA R2 — Clinical Document Architecture Product Brief.
• HAPI FHIR — hapifhir.io (open-source Java FHIR server).
• Microsoft FHIR Converter — github.com/microsoft/FHIR-Converter.
• Circular 13/2025/TT-BYT on electronic medical records — Thư viện Pháp luật.
• Decision 3176/QĐ-BYT on the BHYT data exchange standard — Thư viện Pháp luật.
• VN Core FHIR IG (trial-use, initiated by Omi HealthTech) — fhir.hl7.org.vn/core.

10. Further reading