So sánh HL7 v2, v3, CDA, FHIR — chọn phiên bản nào?

1. Quyết định nhanh: bốn use case, bốn chuẩn

Câu hỏi sai phổ biến trong RFP là "chọn HL7 nào". Câu hỏi đúng là "tích hợp gì với gì". Mỗi use case có một chuẩn phù hợp nhất, và một bệnh viện vận hành tốt thường dùng từ hai đến ba chuẩn cùng lúc.

2. Bảng so sánh 12 trục

Bảng dưới đây giúp đánh giá nhanh trước khi đi sâu. Một số trục như "schema strictness" và "learning curve" mang tính tương đối, dựa trên phản hồi từ vendor và đội tích hợp Việt Nam.

3. Sâu hơn từng dòng

HL7 v2

HL7 v2 ra đời năm 1988 và liên tục tiến hoá: v2.1 (3/1990), v2.3 (3/1997), tới v2.9.1 (2024). Định dạng pipe-delimited dễ parse bằng bất kỳ ngôn ngữ nào, tốc độ truyền MLLP gần như tức thời, và mỗi message chỉ vài kilobyte. Đây là lý do v2 vẫn thống trị giao tiếp HIS-LIS-RIS-PACS sau ba thập kỷ.

Dùng v2 khi tích hợp nội bộ bệnh viện cần độ trễ thấp, các hệ thống đối tác (Cerner, Epic, Meditech, Mirth, FPT.eHospital, Viettel ITN, OmiHIS) đã hỗ trợ sẵn, hoặc luồng ADT/ORM/ORU/MDM truyền thống. Tránh v2 khi cần expose API ra public internet, cần auth zero-trust, hoặc đối tác không đồng ý mở port MLLP qua firewall.

Điểm yếu lớn nhất của v2 là schema lỏng. Cùng segment OBX có thể được hai vendor encode khác nhau, và cộng đồng không có cơ chế Profile chính thức như FHIR. Đây là chi phí ẩn của mọi dự án integration v2 — phần lớn effort là negotiate field-by-field giữa hai bên.

HL7 v3

v3 dựa trên RIM (Reference Information Model), schema chặt và rất chuẩn, nhưng đường cong học cực dốc. Adoption hẹp: NHS Anh, một số hệ thống ở Đức, Hàn Quốc, Úc dùng v3 cho registries quốc gia. Greenfield 2026 nên tránh v3, chọn FHIR thay thế. Chỉ cân nhắc v3 khi đối tác đã đầu tư v3/CDA/SPL legacy nhiều năm và chưa có lộ trình migration.

CDA R2

CDA là document XML có chữ ký, giải quyết bài toán "tài liệu y khoa có cấu trúc". Tại Mỹ, C-CDA là chuẩn de-facto cho Continuity of Care Document. Tại Việt Nam, CDA phù hợp với giấy chuyển tuyến, tóm tắt xuất viện, bệnh án có chữ ký số theo Nghị định 137/2024/NĐ-CP.

FHIR có cơ chế tương đương qua Composition + Bundle kiểu document. Nếu hệ thống đã chọn FHIR, không cần thêm CDA. Nếu đã dùng IHE XDS với CDA, cứ giữ và bổ sung FHIR cho các kênh mới.

FHIR R4

FHIR R4 (4.0.1) public năm 2019. Quan trọng: R4 không phải hoàn toàn normative — HL7 đặt label "Mixed Normative + STU", trong đó các artifact nền tảng (XML/JSON/RDF format, RESTful API, terminology services, một số resource như Patient và Observation) đạt Normative; phần lớn resource lâm sàng vẫn ở STU (Standard for Trial Use). R4 vẫn là phiên bản được khuyến nghị cho production hiện nay; R5 đã ra đời nhưng adoption còn hạn chế.

FHIR mạnh ở chỗ giảm rào cản DEV web: REST + JSON + OAuth là kỹ năng phổ thông. Hệ tooling (HAPI Java, Firely .NET, Bonfhir TypeScript, Medplum, Aidbox) đã trưởng thành. Mặt yếu là FHIR cho phép Profile/Extension rất tự do — nếu không có IG quốc gia (như VN Core, đang phát triển tại fhir.hl7.org.vn/core), mỗi vendor lại tự định nghĩa, lặp lại bài học của v2.

4. Code sample song song: ADT^A01 nhập viện

Cùng một sự kiện — bệnh nhân Nguyễn Thị Lan (MRN0001) nhập viện vào khoa ICU phòng 301 lúc 14:30 ngày 30/4/2026 — được biểu diễn bằng ba chuẩn để bạn cảm nhận khác biệt.

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

Bốn dòng, dưới 300 byte, parser viết được trong 50 dòng Python. Đây là lý do v2 sống dai: chi phí integration thấp, throughput cao.

CDA R2 (XML, rút gọn)

<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 verbose hơn nhiều, nhưng có chữ ký số và cấu trúc document chuẩn. Phù hợp khi cần lưu trữ pháp lý hoặc trao đổi giữa hai bệnh viện qua 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 - Phòng 301" }
        }]
      },
      "request": { "method": "POST", "url": "Encounter" }
    }
  ]
}

FHIR Bundle dài hơn v2 nhưng tự mô tả: mỗi field có URI, code có terminology system, reference dùng urn:uuid để link nội bộ trong transaction. Một REST client bất kỳ tiêu thụ được, không cần thư viện chuyên biệt như HAPI.

5. Kiến trúc kết hợp v2 + FHIR

Tại các bệnh viện hiện đại trên thế giới và một số bệnh viện đầu ngành Việt Nam (Bạch Mai, Chợ Rẫy, Vinmec, FV), kiến trúc phổ biến là giữ v2 cho integration nội bộ và đẩy FHIR ra mọi giao tiếp ra ngoài.

[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 cổng]  [Telehealth] [Đối tác]

Lý do kiến trúc này thắng: nội bộ đã đầu tư v2 nhiều năm, không lý do gì rip-and-replace. Bên ngoài cần OAuth, mobile, JSON — đó chính xác là vùng FHIR mạnh. Bridge giữa hai thế giới có sẵn:

• HAPI FHIR (Java) — server FHIR open source mature nhất, có HL7 v2 to FHIR converter built-in.
• Mirth Connect / NextGen Connect — engine ETL chuyển v2 ⇄ FHIR ⇄ CDA, miễn phí cho bản open source.
• Microsoft FHIR Converter — open source, template-based, hỗ trợ HL7 v2, C-CDA, JSON sang FHIR.
• Smile CDR, Firely Server, Aidbox — bản thương mại tích hợp sẵn adapter v2 và OAuth/SMART.

6. Lộ trình migration v2 sang FHIR

Một bệnh viện đang dùng v2 thuần không cần migrate "ngay và luôn". Lộ trình sáu giai đoạn dưới đây dựa trên kinh nghiệm của các BV Singapore, Úc và một số dự án đầu ngành Việt Nam:

Lưu ý: giai đoạn 6 chưa nên đặt KPI cho 2026-2027. Hệ sinh thái LIS/RIS Việt Nam vẫn dựa nặng v2; ép retire sớm sẽ tạo rủi ro vận hành lớn hơn lợi ích.

7. Decision matrix theo use case Việt Nam

Bảng này gom các câu hỏi CIO thực sự đối diện trong RFP. Cột "Kết luận" trả lời cho ngữ cảnh Việt Nam 2026.

8. Câu hỏi thường gặp

Có thể bỏ HL7 v2 hoàn toàn không?

Trong 5-10 năm tới: không. v2 vẫn rẻ và nhanh cho integration nội bộ; LIS/RIS/PACS vendor toàn cầu đều mặc định v2. Hợp lý hơn là mở rộng FHIR cho mọi kênh mới và để v2 tự rút lui dần khi vendor sunset.

FHIR có thay thế hoàn toàn CDA không?

Về kỹ thuật, FHIR Composition + Bundle document tương đương CDA. Về pháp lý, các hệ thống đã chứng nhận C-CDA (Mỹ) hoặc IHE XDS với CDA (châu Âu, Hàn Quốc) sẽ chuyển dần. Việt Nam chưa khoá CDA bằng văn bản, nên có thể chọn FHIR Composition cho dự án mới.

Bệnh viện nhỏ chỉ đủ ngân sách cho một chuẩn — chọn cái nào?

FHIR. Lý do: roadmap dài hơn, skill DEV web phổ thông, hỗ trợ mobile và VNeID sẵn có. Nếu thiết bị LIS/RIS chỉ nói v2, dùng converter (Mirth, HAPI, Microsoft FHIR Converter) để chuyển sang FHIR ở cửa ngõ.

Việt Nam đã có Implementation Guide quốc gia chưa?

Có draft VN Core IG dựa trên FHIR R4, đang được phát triển bởi cộng đồng (canonical http://fhir.hl7.org.vn/core/) song song với bản của Cục CNTT Bộ Y tế (http://fhir.ehealth.gov.vn/core/). Chưa có văn bản pháp lý bắt buộc IG cụ thể nào.

FHIR R5 đã ổn định chưa, có nên nhảy thẳng R5?

R5 đã release nhưng adoption còn hạn chế, và phần lớn IG quốc gia (US Core, AU Core, JP Core, KR Core, VN Core) vẫn ở R4. Greenfield 2026 nên dùng R4, theo dõi R5 cho 2-3 năm tới.

9. Tham chiếu

• HL7 International — HL7 v2 Product Brief (timeline v2.0/v2.1/v2.3 và v2.9.1 hiện hành).
• HL7 / U.S. National Library of Medicine — Health Data Standards: HL7 v2 adoption (~95% tổ chức y tế Mỹ, 35+ quốc gia).
• HL7 FHIR R4 spec — hl7.org/fhir/R4/ (label "Mixed Normative + STU").
• HL7 FHIR R4 Bundle — hl7.org/fhir/R4/bundle.html (transaction với fullUrl/urn:uuid).
• HL7 v3 Product Suite — Australian Digital Health Agency tổng quan v3.
• HL7 CDA R2 — Clinical Document Architecture Product Brief.
• HAPI FHIR — hapifhir.io (FHIR server Java open source).
• Microsoft FHIR Converter — github.com/microsoft/FHIR-Converter.
• Thông tư 13/2025/TT-BYT về bệnh án điện tử — Thư viện Pháp luật.
• Quyết định 3176/QĐ-BYT về chuẩn dữ liệu KCB BHYT — Thư viện Pháp luật.
• VN Core FHIR IG (community, đang phát triển) — fhir.hl7.org.vn/core.

10. Đọc tiếp