Lịch sử HL7: từ v2 (1987) đến FHIR (2014–nay)

Lịch sử HL7 trải dài gần 40 năm và 4 thế hệ tiêu chuẩn. Từ thông điệp pipe-delimited v2 ra đời năm 1987, qua mô hình RIM của v3 và CDA năm 2005, tới FHIR API hiện đại năm 2014 — mỗi thế hệ phản ánh một bài toán khác của ngành y tế. Bài này kể lại bốn giai đoạn đó kèm bối cảnh áp dụng tại Việt Nam.

Tóm tắt nhanh

  • 1987–1996: HL7 v2 ra đời để giải quyết bài toán tích hợp HIS–LIS–RIS, dùng pipe-delimited message và MLLP.
  • 1996–2005: v2.x lan rộng toàn cầu; HL7 khởi xướng RIM năm 1997 nhằm thống nhất ngữ nghĩa y tế.
  • 2005–2014: HL7 v3 và CDA Release 2 ra mắt; v3 messaging gặp khó về adoption, CDA thành công nhờ IHE XDS.
  • 2014–nay: FHIR đảo chiều cuộc chơi với REST + JSON + 80% rule; ONC Cures Act 2020 đưa FHIR R4 thành chuẩn bắt buộc cho EHR được chứng nhận tại Mỹ.
  • Việt Nam: từ HL7 v2 lẻ tẻ ở khối tư nhân (~2010), tới repo hl7vn/vn-core-ig năm 2024, và sáng kiến hl7.org.vn năm 2026 do Omi HealthTech khởi xướng.

Nội dung trang

  1. Bối cảnh — Y tế Mỹ thập niên 1980 cần gì?
  2. Giai đoạn 1987–1996: HL7 v2 ra đời và bùng nổ
  3. Giai đoạn 1996–2005: v2.x toàn cầu hóa, RIM khởi xướng
  4. Giai đoạn 2005–2014: tham vọng v3 + CDA và những bài học
  5. Giai đoạn 2014–nay: FHIR và cuộc cách mạng API y tế
  6. Việt Nam trong dòng chảy HL7
  7. Bài học rút ra cho Việt Nam
  8. Tham chiếu và đọc tiếp

1. Bối cảnh — Y tế Mỹ thập niên 1980 cần gì?

Năm 1987, một nhóm khoảng 30 người tụ tập tại Đại học Pennsylvania để bàn về một vấn đề rất cụ thể: làm thế nào để máy tính trong bệnh viện nói chuyện được với nhau. Đây không phải hội thảo hàn lâm. Họ là kỹ sư từ các bệnh viện lớn, nhà cung cấp HIS, phòng xét nghiệm — những người mỗi sáng phải đối mặt với cả tá giao thức độc quyền khác nhau khi tích hợp hệ thống.

Bối cảnh thập niên 1980 ở Mỹ rất đặc trưng. Hệ thống thông tin bệnh viện (Hospital Information System — HIS) bắt đầu phổ cập sau khi Meditech, Cerner và Epic ra đời. Mỗi vendor lại có một định dạng truyền tin riêng. Một bệnh viện cỡ trung muốn kết nối HIS với hệ thống xét nghiệm (LIS) và hệ thống chẩn đoán hình ảnh (RIS) phải xây dựng từng cây cầu integration thủ công. Chi phí tích hợp dễ vượt cả chi phí mua phần mềm.

Yêu cầu thị trường lúc đó rất rõ: phải có một bộ tiêu chuẩn message dùng chung cho ngành. Tên gọi "Health Level Seven" lấy từ tầng 7 trong mô hình OSI — tầng ứng dụng — vì đây là nơi ngữ nghĩa y tế thật sự nằm. Nhóm sáng lập chọn cách tiếp cận pragmatic: không cần lý tưởng, chỉ cần đủ tốt để tất cả vendor cùng triển khai được.

2. Giai đoạn 1987–1996: HL7 v2 ra đời và bùng nổ

Hội thảo tháng 3/1987 tại UPenn được xem là điểm khởi đầu chính thức của HL7. Phiên bản đầu tiên — HL7 v1 — chỉ là tài liệu nội bộ, mang tính khái niệm. Bản thực sự đi vào sản xuất là HL7 v2.0 phát hành tháng 9/1988. Tổ chức HL7 chính thức trở thành Tổ chức Phát triển Tiêu chuẩn được ANSI công nhận năm 1994.

Các bản v2 đời đầu nối tiếp nhau khá nhanh: v2.1 ra đời tháng 3/1990, v2.2 vào tháng 12/1994, và v2.3 phát hành tháng 3/1997. Trong số này, v2.3 là bản phổ biến nhất; cho tới hôm nay nhiều bệnh viện vẫn còn chạy đúng phiên bản đó cho luồng ADT (Admission–Discharge–Transfer), kết quả xét nghiệm và đơn thuốc. Đặc trưng kỹ thuật của HL7 v2 đơn giản tới mức gần như thô: dùng các ký tự pipe và caret làm dấu phân tách, đóng gói qua giao thức MLLP trên TCP, và có cú pháp ABNF kiểu lập trình. 

MSH|^~\&|HIS|HOSP|LIS|LAB|202604301430||ORM^O01|MSG001|P|2.3
PID|1||MRN0001||NGUYEN^THI LAN||19850315|F

Chính cái sự "thô" đó lại là chìa khóa thành công. Một kỹ sư trung bình có thể đọc message v2 bằng mắt thường, debug bằng grep, log bằng tee. Thư viện parser viết được trong vài trăm dòng code. Kết quả là tới giữa thập niên 1990, HL7 v2 trở thành tiêu chuẩn de facto cho integration nội bộ bệnh viện ở Bắc Mỹ. Khi Internet bắt đầu phổ cập cuối thập kỷ, những vấn đề mới xuất hiện — nhưng đó là câu chuyện của chương sau.

3. Giai đoạn 1996–2005: v2.x toàn cầu hóa, RIM khởi xướng

Sang thập niên 2000, HL7 v2 bước vào giai đoạn "lan rộng và bám rễ". Các bản v2.4 (2000), v2.5 (2003), v2.6 (2007), v2.7 (2011), v2.8 (2014), v2.9 (2019) tiếp tục bổ sung phân hệ — từ quản lý đơn thuốc, vaccine, tới y tế công cộng — nhưng vẫn giữ triết lý cú pháp gốc. Các quốc gia bên ngoài Mỹ bắt đầu adopt nghiêm túc: Úc, Hà Lan, Đức, sau đó là Nhật Bản, Hàn Quốc.

Tuy nhiên cộng đồng cũng nhận ra giới hạn của v2. Bản chất pipe-delimited khiến message không có schema chặt; mỗi vendor extend theo kiểu riêng tạo ra các "phương ngữ" v2 không tương thích. Các trường tự do (Z-segment) bị lạm dụng. Khi cần ngữ nghĩa cao hơn — ví dụ truy vấn dữ liệu lâm sàng phức tạp — v2 lộ rõ hạn chế.

Đáp lại, năm 1997 HL7 khởi xướng dự án Reference Information Model (RIM): một mô hình thông tin hợp nhất bao trùm toàn bộ ngữ nghĩa y tế. RIM định nghĩa các lớp gốc như Act, Entity, Role, Participation, ActRelationship — từ đó suy ra mọi cấu trúc cụ thể. Với tham vọng này, HL7 đặt nền cho thế hệ tiêu chuẩn tiếp theo: v3.

4. Giai đoạn 2005–2014: tham vọng v3 + CDA và những bài học

Năm 2005 là cột mốc lớn: HL7 phát hành Normative Edition của HL7 v3 kèm CDA Release 2 (Clinical Document Architecture). RIM được chuẩn hóa thành ISO/HL7 21731. Trên giấy tờ, đây là một thắng lợi. Trên thực tế, câu chuyện phức tạp hơn nhiều.

HL7 v3 messaging dùng XML, dựa trực tiếp trên RIM, có schema chặt và ngữ nghĩa giàu. Nhưng cái giá phải trả là độ phức tạp khổng lồ. Một message v3 đơn giản như đăng ký bệnh nhân có thể dài hàng trăm dòng XML lồng nhau, mỗi thuộc tính phải tuân thủ vocabulary controlled. Việc viết message đúng đòi hỏi đội ngũ phân tích nghiệp vụ chuyên sâu về RIM — nhân lực rất hiếm.

Hệ quả: các chương trình đầu tư lớn vào v3 messaging gặp khó. Chương trình NPfIT của NHS Anh — một trong những dự án CNTT y tế tham vọng nhất lịch sử — đã hủy bỏ phần lớn nội dung v3 vì chi phí và độ phức tạp triển khai. Đức và Hàn Quốc adopt v3 ở quy mô có giới hạn. Chỉ một số mảng cụ thể như báo cáo y tế công cộng giữ lại được v3 messaging.

Trong khi đó, CDA lại đi một đường khác. CDA dùng RIM nhưng đóng gói thành tài liệu lâm sàng (clinical document) — mỗi tài liệu là một file XML có header và body, có thể ký số, lưu trữ độc lập. Khung tích hợp IHE XDS (Cross-Enterprise Document Sharing) chọn CDA làm container chuẩn cho tài liệu chia sẻ giữa các tổ chức. Nhờ đó CDA tồn tại bền bỉ tại châu Âu, Mỹ, Nhật Bản — cho tới hôm nay vẫn là chuẩn chính cho tóm tắt xuất viện và biểu mẫu hành chính y tế ở nhiều nước.

Bài học lớn rút ra từ chu kỳ v3: một mô hình lý tưởng trên giấy không tự động dẫn tới adoption. Nếu chi phí triển khai vượt giá trị thu được trong ngắn hạn, các tổ chức sẽ chọn giải pháp đơn giản hơn — hoặc đợi thế hệ tiêu chuẩn kế tiếp. Bài học đó chính là tiền đề cho FHIR.

5. Giai đoạn 2014–nay: FHIR và cuộc cách mạng API y tế

Năm 2011, Grahame Grieve — một kỹ sư người Úc với kinh nghiệm lâu năm trong cộng đồng HL7 — đăng một bài blog tựa đề "Resources for Health". Ý tưởng đơn giản: thay vì cố nhồi mọi ngữ nghĩa y tế vào RIM, hãy chia thông tin thành các Resource độc lập (Patient, Observation, MedicationRequest…), mỗi Resource có schema riêng, được trao đổi qua REST API và serialize bằng JSON hoặc XML. Bài viết lan nhanh trong cộng đồng. Năm 2012, HL7 chính thức adopt project và đặt tên là FHIR — Fast Healthcare Interoperability Resources.

Cột mốc đầu tiên là FHIR DSTU1, phát hành ngày 30/09/2014. Triết lý "80% rule" được nêu rõ ngay từ đầu: spec sẽ chuẩn hóa 80% trường hợp sử dụng phổ biến, 20% còn lại để cộng đồng giải quyết bằng extension hoặc profile. Triết lý này khác hoàn toàn tham vọng "phủ kín mọi thứ" của v3, và nó đánh trúng nhu cầu thực tế của developer hiện đại — những người đã quen REST + JSON từ thế giới web.

Chu kỳ tiếp theo diễn ra liên tục. DSTU2 phát hành 2015. STU3 phát hành 2017. R4 đạt mốc Normative Edition vào 27/12/2018, sau đó bản kỹ thuật 4.0.1 — vẫn được gọi là R4 — ra đời 2019; đây là lần đầu tiên FHIR có nội dung Normative (cụ thể là Patient và Observation), trong khi phần lớn các Resource khác — bao gồm AllergyIntolerance, Condition, Encounter — vẫn giữ trạng thái Trial Use. Vì cấu trúc lai này, R4 thường được mô tả là "Mixed Normative + STU".

Năm 2020, ONC Cures Act Final Rule tại Mỹ đưa ra yêu cầu quan trọng: các certified health IT module theo §170.315(g)(10) phải cung cấp công nghệ FHIR API tiêu chuẩn dựa trên FHIR R4.0.1, thời hạn tuân thủ 31/12/2022. Quy định không phủ kín "mọi EHR" mà nhắm vào các module được chứng nhận — nhưng do gần như mọi EHR lớn ở Mỹ đều cần chứng nhận để tham gia chương trình bảo hiểm liên bang, hiệu ứng dây chuyền là cực lớn. Apple Health, Epic, Cerner, Allscripts đều adopt FHIR R4 trong vài năm sau đó.

Năm 2022, HL7 phát hành FHIR R4B (4.3.0) — bản Trial Use với thay đổi giới hạn so với R4, không phải bản Normative mới. Năm 2023, FHIR R5 (5.0.0) chính thức ra mắt với nhiều cải tiến cho dược phẩm, di truyền học và thiết bị y tế. Tuy nhiên, R4 vẫn là lựa chọn mặc định cho hầu hết quốc gia xây dựng IG quốc gia: US Core, JP Core, KR Core, CH Core, AU Core đều đứng trên R4.

Tới giữa thập niên 2020, FHIR đã trở thành chuẩn de facto cho interoperability y tế toàn cầu. Apple, Google, Microsoft đều cung cấp dịch vụ FHIR-native trên cloud. WHO, Gavi, Ngân hàng Thế giới dùng FHIR cho các sáng kiến y tế toàn cầu. Khi làn sóng AI agent y tế bắt đầu năm 2024–2025, FHIR tự nhiên trở thành lớp dữ liệu nền — vì nó đã có sẵn ở mọi hệ thống đáng kể.

6. Việt Nam trong dòng chảy HL7

Việt Nam đến với HL7 muộn hơn các nước phát triển khoảng hai thập kỷ, nhưng đường đi cũng có nét riêng. Khoảng năm 2010, một số bệnh viện tư đầu tư hệ thống mới — Vinmec là ví dụ điển hình — bắt đầu yêu cầu HIS, LIS và RIS giao tiếp qua HL7 v2 thay vì các giao thức tự chế. Đó là lần đầu tiên HL7 v2 xuất hiện trong sản xuất tại Việt Nam, dù phạm vi còn hẹp ở khối tư nhân và bệnh viện quốc tế.

Trong cùng giai đoạn, mảng dữ liệu BHYT đi theo hướng riêng. QĐ 4210/QĐ-BYT chuẩn hóa định dạng dữ liệu đầu ra phục vụ giám định BHYT — nhưng dùng XML thuần, không phải HL7 v2 hay CDA. Sau đó được thay thế bằng QĐ 130/2023 và QĐ 4750/2023, rồi QĐ 3176/QĐ-BYT (29/10/2024). Hệ sinh thái BHYT do đó phát triển song song chứ không hợp lưu vào HL7.

Bước ngoặt diễn ra năm 2024. Cục CNTT Bộ Y tế (tên đơn vị tại thời điểm publish) công bố repo hl7vn/vn-core-ig — bản phác thảo đầu tiên cho Vietnam Core IG dựa trên FHIR R4, canonical http://fhir.ehealth.gov.vn/core/. Cùng thời điểm, cộng đồng fhir.chiaseyhoc.vn mirror nội dung và bắt đầu đối thoại quanh cấu trúc profile cho Việt Nam.

Năm 2025 mang đến cú hích pháp lý. Thông tư 13/2025/TT-BYT (ban hành 06/06/2025, hiệu lực 21/07/2025) quy định bệnh viện phải hoàn thành bệnh án điện tử chậm nhất 30/9/2025 và toàn bộ cơ sở khám chữa bệnh chậm nhất 31/12/2026. Cùng năm, Luật 91/2025/QH15 về Bảo vệ dữ liệu cá nhân (hiệu lực 01/01/2026) và Nghị định 356/2025/NĐ-CP hướng dẫn chi tiết — phân loại dữ liệu y tế là dữ liệu nhạy cảm — siết toàn diện yêu cầu bảo mật. Khi EMR bắt buộc gặp Bảo vệ dữ liệu nhạy cảm, FHIR trở thành lựa chọn tự nhiên để vừa interoperable vừa kiểm soát được consent.

Năm 2026, sáng kiến hl7.org.vn do Omi HealthTech (OmiGroup) khởi xướng nhằm tái khởi động Vietnam Core IG ở mức chất lượng cao, công khai dưới giấy phép CC-BY-4.0, và hướng tới mục tiêu trở thành HL7 Affiliate Vietnam chính thức. Canonical mới là http://fhir.hl7.org.vn/core/; project được phát triển bởi cộng đồng, mở contribution cho mọi vendor, bệnh viện và nhà nghiên cứu. Đây là điểm nối tiếp tự nhiên với dòng chảy HL7 toàn cầu mà Việt Nam đã chậm hai mươi năm.

7. Bài học rút ra cho Việt Nam

Bốn mươi năm lịch sử HL7 cho Việt Nam một số bài học rất cụ thể khi xây dựng VN Core IG.

Một là, không lặp lại sai lầm v3. Đừng chờ một mô hình hoàn hảo trước khi launch. Hãy adopt triết lý 80% rule của FHIR: chuẩn hóa cái phổ biến, để extension giải quyết phần dài đuôi. VN Core nên ra mắt dưới dạng draft hữu dụng được, rồi iterate qua phản hồi cộng đồng — chứ không nằm trong ngăn kéo chờ "đủ chín".

Hai là, cộng đồng quan trọng hơn mệnh lệnh hành chính. HL7 quốc tế thành công vì giữ được tính trung lập với vendor và tổ chức. Repo hl7vn/vn-core-ig được khởi tạo bởi nỗ lực ban đầu của cơ quan quản lý — bước tiếp theo là chuyển sang mô hình community-driven, có HL7 Affiliate đại diện chính thức, có working group mở cho mọi tổ chức quan tâm.

Ba là, R4 là sweet spot cho Việt Nam hôm nay. R5 mới hơn nhưng hệ sinh thái tooling, tutorial, IG quốc gia khác đều quanh R4. Chọn R4 nghĩa là đứng được trên vai người khổng lồ — JP Core, US Core, AU Core đều R4; thư viện SUSHI, IG Publisher, validator đều ổn định trên R4.

Bốn là, đầu tư terminology song song với profile. FHIR rỗng nếu không có ICD-10 VN, SNOMED CT VN, LOINC VN, danh mục dịch vụ kỹ thuật, danh mục đơn vị hành chính 34 tỉnh sau Nghị quyết 202/2025. Profile và terminology phải đi cùng nhau ngay từ phiên bản 0.1.0.

Năm là, kết nối FHIR với khung pháp lý. TT 13/2025 (bệnh án điện tử), Luật 91/2025 (bảo vệ dữ liệu cá nhân), NĐ 356/2025 (hướng dẫn DPIA và DPO), QĐ 1332/QĐ-BYT (Sổ sức khỏe điện tử trên VNeID) — đây là driver tạo nhu cầu, FHIR chỉ là công cụ. IG nào không trích dẫn rõ căn cứ pháp lý sẽ rất khó được áp dụng ở khu vực công.

Ghi chú lịch sử. Một số nguồn tiếng Việt từng ghi nhầm ngày phát hành FHIR DSTU1 là 21/02/2014, hoặc cho rằng R4 là Normative hoàn toàn. Bài này cập nhật theo trang lịch sử chính thức của HL7 và spec R4 hiện hành: DSTU1 phát hành 30/09/2014; R4 là Mixed Normative + STU.

8. Tham chiếu và đọc tiếp

Nguồn tham chiếu chính

Văn bản pháp lý Việt Nam liên quan

Đọc tiếp trong knowledge hub

→ HL7 là gì? Tổng quan tổ chức và bộ tiêu chuẩn → FHIR là gì? Resource, REST API và 80% rule → So sánh HL7 v2 vs v3 vs FHIR — chọn chuẩn nào cho dự án mới → Các phiên bản FHIR: DSTU1, DSTU2, STU3, R4, R4B, R5 → Timeline FHIR tại Việt Nam — các cột mốc chi tiết