HL7 v2 vs v3 vs CDA vs FHIR — which version should you choose?

1. Quick decision: four use cases, four standards

A common mistake in RFPs is asking "which HL7 should we pick?". The right question is "what's being integrated with what?". Each use case has a best-fit standard, and a well-run hospital typically uses two or three standards in parallel.

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 feedback from Vietnamese vendors and integration teams.

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). The pipe-delimited format is parseable in any language, MLLP transmission is near-instantaneous, and each message is just a few kilobytes. That is why v2 still dominates HIS-LIS-RIS-PACS communication after three decades.

Use v2 when you need low-latency internal hospital integration, partner systems (Cerner, Epic, Meditech, Mirth, FPT.eHospital, Viettel ITN, OmiHIS) already support it natively, or you're 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.

The biggest weakness of v2 is its loose schema. The same OBX segment can be encoded differently by two vendors, and the community has no formal Profile mechanism comparable to FHIR. This is the hidden cost of every v2 integration project — most of the effort goes into negotiating fields one by one between two parties.

HL7 v3

v3 is built on the RIM (Reference Information Model), with a strict and very standardized schema, but the learning curve is brutally steep. Adoption is narrow: the UK's NHS, several systems in Germany, South Korea, and Australia use v3 for national registries. Greenfield 2026 projects should avoid v3 and choose FHIR instead. Only consider v3 when a partner has invested in v3/CDA/SPL legacy systems for years and has no migration roadmap.

CDA R2

CDA is a signed XML document that solves the "structured medical document" problem. In the US, C-CDA is the de-facto standard for the Continuity of Care Document. In Vietnam, CDA fits referral letters, discharge summaries, and digitally signed medical records under Decree 137/2024/NĐ-CP on electronic transactions.

FHIR offers an equivalent mechanism through document-style Composition + Bundle. If your system has already chosen FHIR, you don't need to add CDA. If you already run IHE XDS with CDA, keep it and add FHIR for new channels.

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 still the recommended version for production today; R5 has been released but adoption remains limited.

FHIR's strength is lowering the barrier for web developers: REST + JSON + OAuth are universal skills. The tooling ecosystem (HAPI Java, Firely .NET, Bonfhir TypeScript, Medplum, Aidbox) has matured. Its weakness is that FHIR allows very free Profile/Extension authoring — without a national IG (such as VN Core, currently in development at fhir.hl7.org.vn/core), each vendor defines its own variant and repeats the v2 lesson.

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

Four lines, under 300 bytes, with a parser writeable in 50 lines of Python. This is why v2 endures: low integration cost and high throughput.

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 is far more verbose, but offers digital signatures and a standardized document structure. It fits when you need legal-grade archival or hospital-to-hospital exchange via IHE XDS.

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 v2 but self-describing: every field has a URI, every code carries a terminology system, and references use urn:uuid to link entries inside the transaction. Any REST client can consume it, no specialized library like HAPI required.

5. Hybrid v2 + FHIR architecture

At modern hospitals worldwide and at leading Vietnamese hospitals (Bach Mai, Cho Ray, Vinmec, FV), the dominant pattern is to keep v2 for internal integration and push FHIR out to every external interaction.

[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]

Why this architecture wins: years of v2 investment internally — there's no reason to rip and replace. External channels demand OAuth, mobile, and JSON, which is exactly where FHIR shines. Bridges between the two worlds already exist:

• HAPI FHIR (Java) — the most mature open-source FHIR server, with a built-in HL7 v2 to FHIR converter.
• Mirth Connect / NextGen Connect — an ETL engine that translates v2 ⇄ FHIR ⇄ CDA, free in its open-source edition.
• Microsoft FHIR Converter — open source, template-based, supports HL7 v2, C-CDA, and JSON to FHIR.
• Smile CDR, Firely Server, Aidbox — commercial offerings with v2 adapters and OAuth/SMART built in.

6. v2-to-FHIR migration roadmap

A hospital running pure v2 doesn't need to migrate "right now". The six-stage roadmap below draws from the experience of hospitals in Singapore, Australia, and several leading Vietnamese projects:

Note: don't put a KPI on stage 6 for 2026-2027. Vietnam's LIS/RIS ecosystem still leans heavily on v2; forcing early retirement creates more operational risk than benefit.

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?

In the next 5-10 years: no. v2 remains cheap and fast for internal integration; LIS/RIS/PACS vendors worldwide ship v2 by default. The smarter move is to expand FHIR for every new channel and let v2 retreat naturally as vendors sunset it.

Will FHIR fully replace CDA?

Technically, FHIR Composition + Bundle documents are equivalent to CDA. Legally, systems already certified for C-CDA (US) or IHE XDS with CDA (Europe, South Korea) will migrate gradually. Vietnam has not locked in CDA by regulation, so new projects can choose FHIR Composition.

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

FHIR. Reasons: a longer roadmap, common web developer skills, native support for mobile and VNeID. If LIS/RIS devices only speak v2, use a converter (Mirth, HAPI, Microsoft FHIR Converter) to translate to FHIR at the edge.

Does Vietnam have a national Implementation Guide yet?

A draft VN Core IG based on FHIR R4 is being developed by the community (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 has been released, but adoption is still limited, and most national IGs (US Core, AU Core, JP Core, KR Core, VN Core) remain on R4. Greenfield 2026 should use R4 and watch R5 for the next 2-3 years.

9. References

• HL7 International — HL7 v2 Product Brief (timeline for v2.0/v2.1/v2.3 and the current v2.9.1).
• HL7 / U.S. National Library of Medicine — Health Data Standards: HL7 v2 adoption (~95% of US healthcare orgs, 35+ countries).
• 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 (community, in development) — fhir.hl7.org.vn/core.

10. Further reading