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à có thể được khảo sát qua bốn giai đoạn lớn. Từ thông điệp phân tách bằng ký tự của v2, qua mô hình RIM của v3 và CDA, tới FHIR với mô hình tài nguyên và các cơ chế trao đổi dựa trên công nghệ web — mỗi giai đoạn phản ánh một phạm vi thiết kế khác nhau. Bài viết đồng thời nêu rõ phần nào đã có bằng chứng công khai tại Việt Nam và phần nào chưa có số liệu áp dụng toàn quốc.

Tóm tắt nhanh

  • 1987–1996: HL7 v2 hình thành để hỗ trợ trao đổi giữa các hệ thống bệnh viện; thông điệp dùng ký tự phân tách và thường được vận chuyển qua MLLP.
  • 1996–2005: họ v2 tiếp tục mở rộng; HL7 khởi xướng RIM năm 1997 làm mô hình tham chiếu cho họ v3.
  • 2005–2014: HL7 v3 và CDA Release 2 được công bố; v3 messaging và CDA có mô hình triển khai, công cụ và phạm vi sử dụng khác nhau.
  • 2014–nay: FHIR đưa mô hình Resource, JSON/XML và nhiều cơ chế trao đổi vào cùng một đặc tả; quy định ONC năm 2020 áp dụng yêu cầu FHIR R4.0.1 cho tiêu chí chứng nhận API cụ thể tại Mỹ.
  • Việt Nam: chưa có bộ số liệu công khai mô tả đầy đủ việc dùng HL7 v2 trước năm 2024; các mốc có thể kiểm chứng gồm repo hl7vn/vn-core-ig năm 2024 và sáng kiến trial-use tại hl7.org.vn năm 2026.

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 hình thành và được triển khai ban đầu
  3. Giai đoạn 1996–2005: v2.x mở rộng, RIM được khởi xướng
  4. Giai đoạn 2005–2014: v3 messaging và CDA Release 2
  5. Giai đoạn 2014–nay: FHIR và các mô hình trao đổi dựa trên web
  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ì?

HL7 được thành lập năm 1987 trong bối cảnh các bệnh viện cần trao đổi dữ liệu giữa hệ thống thông tin bệnh viện, xét nghiệm và chẩn đoán hình ảnh. Khi chưa có đặc tả dùng chung, mỗi cặp hệ thống thường phải thống nhất định dạng và giao diện tích hợp riêng.

Tại Mỹ trong thập niên 1980, các nhà cung cấp hệ thống thông tin y tế sử dụng nhiều định dạng truyền tin khác nhau. Việc kết nối HIS với hệ thống thông tin xét nghiệm (LIS) hoặc chẩn đoán hình ảnh (RIS) vì vậy phụ thuộc nhiều vào giao diện tùy chỉnh và thỏa thuận song phương.

Tên gọi "Health Level Seven" tham chiếu tầng 7 — tầng ứng dụng — trong mô hình OSI. Phạm vi của HL7 tập trung vào nội dung và quy tắc trao đổi ở tầng ứng dụng, thay vì quy định toàn bộ hạ tầng mạng bên dưới.

2. Giai đoạn 1987–1996: HL7 v2 hình thành và được triển khai ban đầu

HL7 được thành lập năm 1987. HL7 v2.0 được phát hành tháng 9/1988, và tổ chức HL7 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: v2.1 vào tháng 3/1990, v2.2 vào tháng 12/1994 và v2.3 vào tháng 3/1997. Các hệ thống đang vận hành có thể sử dụng nhiều phiên bản v2 khác nhau cho luồng ADT (Admission–Discharge–Transfer), kết quả xét nghiệm hoặc đơn thuốc. HL7 v2 dùng các ký tự như pipe và caret làm dấu phân tách; MLLP trên TCP là một cơ chế vận chuyển được dùng phổ biến, nhưng không phải là giao thức duy nhất mà đặc tả v2 cho phép triển khai. 

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

Cú pháp phân tách giúp con người có thể kiểm tra trực tiếp nhiều thông điệp v2. Tuy nhiên, khả năng tương tác trong sản xuất còn phụ thuộc vào phiên bản, implementation guide, bảng mã, trường tùy chọn và thỏa thuận cục bộ; đọc được cú pháp không đồng nghĩa hai hệ thống tự động tương thích.

3. Giai đoạn 1996–2005: v2.x mở rộng, RIM được khởi xướng

Trong giai đoạn này, v2.3 (1997), v2.4 (2000) và v2.5 (2003) tiếp tục mở rộng nội dung của họ tiêu chuẩn. Các bản về sau — tới v2.9 năm 2019 — cho thấy v2 vẫn được duy trì song song với các họ tiêu chuẩn mới. Phiên bản và phạm vi triển khai khác nhau theo quốc gia, chương trình và từng giao diện.

HL7 v2 có cấu trúc thông điệp, segment và trường được định nghĩa; vấn đề tương thích thường phát sinh từ mức độ tùy chọn cao và khác biệt giữa các implementation guide cục bộ. Z-segment là cơ chế mở rộng hợp lệ, nhưng cần được đặc tả và quản trị chung giữa các bên. V2 chủ yếu tối ưu cho trao đổi thông điệp theo sự kiện, không phải cho mọi kiểu truy vấn hoặc mô hình dữ liệu lâm sàng.

Năm 1997, HL7 khởi xướng Reference Information Model (RIM) làm mô hình tham chiếu cho họ tiêu chuẩn v3. RIM định nghĩa các lớp gốc như Act, Entity, Role, Participation và ActRelationship, qua đó tạo cơ sở mô hình hóa thống nhất cho các artifact v3.

4. Giai đoạn 2005–2014: v3 messaging và CDA Release 2

Năm 2005, HL7 công bố Normative Edition của HL7 v3 và CDA Release 2 (Clinical Document Architecture). RIM sau đó được công bố trong ISO/HL7 21731. Dù cùng dựa trên RIM, v3 messaging và CDA giải quyết các kiểu trao đổi khác nhau và cần được đánh giá riêng.

HL7 v3 messaging dùng XML và các mô hình dẫn xuất từ RIM, với ràng buộc kiểu dữ liệu, từ vựng và cấu trúc chính thức hơn v2. Mức hình thức này có thể cải thiện tính nhất quán ngữ nghĩa, đồng thời làm tăng yêu cầu về công cụ, artifact conformance và năng lực mô hình hóa của đội triển khai.

Mức độ triển khai v3 messaging khác nhau theo chương trình và lĩnh vực. Không nên suy từ một dự án riêng lẻ rằng toàn bộ họ v3 "thành công" hoặc "thất bại"; đánh giá cần tách biệt v3 messaging, CDA và các artifact khác dẫn xuất từ RIM, đồng thời xem xét conformance thực tế của từng chương trình.

CDA R2 định nghĩa tài liệu lâm sàng XML có header và body, với đặc tính duy trì ngữ cảnh tài liệu. CDA có thể tham gia quy trình lưu trữ hoặc ký số, nhưng bản thân đặc tả không quyết định hiệu lực pháp lý của chữ ký. IHE XDS cung cấp hạ tầng chia sẻ nhiều loại tài liệu và có thể vận chuyển tài liệu CDA; XDS không giới hạn container ở CDA. CDA tiếp tục xuất hiện trong một số chương trình quốc gia và khu vực, với phạm vi khác nhau.

Kinh nghiệm từ giai đoạn này cho thấy mô hình ngữ nghĩa chính thức chỉ là một phần của khả năng tương tác. Công cụ, tài liệu triển khai, quản trị phiên bản, kiểm thử conformance và năng lực vận hành cũng ảnh hưởng trực tiếp đến kết quả.

5. Giai đoạn 2014–nay: FHIR và các mô hình trao đổi dựa trên web

Năm 2011, Grahame Grieve công bố đề xuất "Resources for Health"; HL7 tiếp tục phát triển hướng tiếp cận này thành FHIR — Fast Healthcare Interoperability Resources. FHIR tổ chức dữ liệu thành các Resource như Patient, Observation và MedicationRequest, có biểu diễn JSON/XML và hỗ trợ nhiều mô hình trao đổi, gồm RESTful API, tài liệu và thông điệp. Vì vậy, FHIR không đồng nghĩa mọi triển khai đều phải dùng REST.

Cột mốc công bố đầu tiên là FHIR DSTU1 ngày 30/09/2014. Kiến trúc FHIR mô tả "80/20 rule" như một nguyên tắc thiết kế: ưu tiên các yêu cầu chung, sau đó dùng profile và extension cho ngữ cảnh cụ thể. Đây là heuristic về khả năng tái sử dụng, không phải số liệu chứng minh FHIR đã bao phủ đúng 80% mọi trường hợp sử dụng; extension cũng không thay thế yêu cầu quản trị và kiểm thử conformance.

DSTU2 được công bố năm 2015, STU3 năm 2017 và Release 4 vào 27/12/2018; bản technical correction 4.0.1 được công bố năm 2019. R4 là lần đầu FHIR có nội dung Normative, trong khi các artifact khác vẫn ở Trial Use. Trạng thái tiêu chuẩn được xác định theo từng artifact, và trong một số trường hợp theo nội dung bên trong artifact; vì vậy R4 được mô tả là bản pha trộn Normative và STU, không phải toàn bộ đặc tả đều Normative.

Năm 2020, ONC Cures Act Final Rule tại Mỹ đặt yêu cầu cho tiêu chí chứng nhận §170.315(g)(10): công nghệ API được chứng nhận phải hỗ trợ truy cập tiêu chuẩn dựa trên FHIR R4.0.1 cùng các implementation guide liên quan, với mốc tuân thủ 31/12/2022. Phạm vi này là các module công nghệ y tế thuộc chương trình chứng nhận, không phải mọi EHR hoặc mọi API y tế tại Mỹ.

Năm 2022, HL7 phát hành FHIR R4B (4.3.0) — bản Trial Use tập trung thay đổi ở một số khu vực cụ thể, không phải bản Normative mới. Năm 2023, FHIR R5 (5.0.0) được công bố dưới quy trình Trial Use. R6 hiện là bản ballot/CI, chưa phải release ổn định. Các release hiện hành của US Core, JP Core, KR Core, CH Core và AU Core được dự án rà soát vẫn dựa trên R4; điều này không làm R4 trở thành lựa chọn mặc định cho mọi National IG.

Tới giữa thập niên 2020, FHIR đã được nhiều nền tảng y tế và dịch vụ cloud lớn hỗ trợ cho các kịch bản liên thông. Mức độ áp dụng, phiên bản và phạm vi conformance vẫn khác nhau theo quốc gia, chương trình và nhà cung cấp; vì vậy không thể suy ra rằng mọi hệ thống y tế đều đã có dữ liệu FHIR sẵn dùng.

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

Chưa có bộ dữ liệu công khai cấp quốc gia xác định thời điểm triển khai HL7 v2 đầu tiên, số cơ sở hoặc phiên bản đang vận hành tại Việt Nam. Bằng chứng từ từng dự án riêng lẻ không đủ để ước lượng mức áp dụng toàn quốc; vì vậy bài viết không dùng một năm ước đoán làm mốc quốc gia.

Dữ liệu đầu ra phục vụ giám định, thanh toán BHYT phát triển theo chuỗi đặc tả XML riêng. QĐ 4210/QĐ-BYT là một mốc trong chuỗi này; các quyết định 130, 4750 và 3176/QĐ-BYT (29/10/2024) tiếp tục sửa đổi hoặc thay thế yêu cầu liên quan. Đây không phải HL7 v2, CDA hay FHIR; việc ánh xạ sang FHIR cần một lớp mapping có phiên bản và kiểm thử riêng.

Năm 2024, Cục CNTT Bộ Y tế (tên đơn vị tại thời điểm công bố) phát hành repo hl7vn/vn-core-ig, một bản Vietnam Core IG dựa trên FHIR R4 với canonical http://fhir.ehealth.gov.vn/core/. Bản mirror tại fhir.chiaseyhoc.vn giúp nội dung build có thể truy cập công khai; phạm vi duy trì và áp dụng của mirror cần được đánh giá riêng, không thể suy ra chỉ từ việc website tồn tại.

Thông tư 13/2025/TT-BYT (ban hành 06/06/2025, hiệu lực 21/07/2025) quy định lộ trình triển khai hồ sơ bệnh án điện tử. Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP đặt ra nghĩa vụ bảo vệ dữ liệu cá nhân, trong đó dữ liệu sức khỏe thuộc nhóm nhạy cảm. Các văn bản này tạo yêu cầu về số hóa, liên thông và kiểm soát dữ liệu nhưng không quy định bắt buộc phải dùng FHIR; lựa chọn FHIR phải dựa trên use case, conformance và kiến trúc an toàn cụ thể.

Năm 2026, Omi HealthTech khởi xướng dự án VN Core trial-use tại hl7.org.vn, công bố nội dung theo CC-BY-4.0 và dùng canonical http://fhir.hl7.org.vn/core/. Dự án vận hành theo mô hình mở hướng tới Working Group đa bên và đang xây dựng cơ chế review, tiếp nhận đề xuất kỹ thuật; đây không phải tiêu chuẩn quốc gia đã được phê duyệt hoặc HL7 Affiliate đã được HL7 International công nhận.

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à, phát hành artifact theo vòng lặp có kiểm thử. Nguyên tắc 80/20 của FHIR là heuristic thiết kế để ưu tiên yêu cầu chung, không phải mục tiêu độ phủ định lượng. Mỗi profile hoặc extension của VN Core cần use case, phạm vi, ví dụ và tiêu chí conformance rõ ràng trước khi mở rộng.

Hai là, quản trị đa bên và truy vết quyết định. Clinical SME, cơ sở y tế, nhà cung cấp, đơn vị chi trả và cơ quan quản lý cần có kênh review minh bạch. Tư cách HL7 Affiliate chỉ được nêu khi hoàn tất quy trình công nhận chính thức; trước thời điểm đó, dự án phải mô tả đúng trạng thái trial-use và mô hình Working Group đang hình thành.

Ba là, giữ baseline R4 đã công bố cho VN Core. Lựa chọn này bám theo package dependency, validator và các IG tham chiếu mà dự án đã kiểm tra. R5 là major release mới nhất đã publish nhưng vẫn thuộc Trial Use, còn R6 mới ở giai đoạn CI/ballot; việc nâng phiên bản cần một đánh giá tương thích riêng thay vì suy từ mức độ phổ biến toàn cầu.

Bốn là, quản trị terminology song song với profile. Khả năng tương tác phụ thuộc vào binding, phiên bản và nguồn phát hành của bộ mã. Việc dùng ICD-10 VN, SNOMED CT, LOINC, danh mục dịch vụ kỹ thuật hoặc đơn vị hành chính phải nêu rõ thẩm quyền, giấy phép, phiên bản và phạm vi; không mặc định một bản dịch hoặc CodeSystem cục bộ là bản phát hành chính thức.

Năm là, duy trì truy vết pháp lý mà không diễn giải quá phạm vi. IG cần chỉ ra văn bản liên quan, data element chịu tác động và mức ràng buộc kỹ thuật do dự án lựa chọn. Việc một văn bản yêu cầu EMR, bảo vệ dữ liệu hoặc liên thông không tự động có nghĩa văn bản đó bắt buộc FHIR.

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