FHIR Versions: DSTU1 → R5 và vì sao VN Core dùng R4

Tóm tắt nhanh

• Bảy phiên bản FHIR đã ra mắt: DSTU1 (30/09/2014), DSTU2 (24/10/2015), STU3 (19/04/2017), R4 (30/10/2019), R4B (28/05/2022), R5 (26/03/2023), R6 đang ballot 2026.
• R4 = "Mixed Normative + STU" — khoảng 30 Resource và artifact lõi mang nhãn Normative, phần còn lại trong tổng số 146 Resource vẫn ở Trial Use.
• R5 nâng tổng số Resource lên khoảng 157, bổ sung SubscriptionTopic, ImagingSelection, Permission; bản thân R5 là STU, không phải Normative release.
• VN Core dùng R4 để đồng bộ với US Core, JP Core, KR Core, CH Core và phần lớn vendor HIS/LIS đã certify R4.
• Lộ trình migration: R4 sang R4B khi cần SubscriptionTopic; R4 sang R5 khi vendor tooling đủ trưởng thành và xuất hiện use case bắt buộc.

1. Timeline bảy phiên bản FHIR từ 2014 đến 2026

FHIR (Fast Healthcare Interoperability Resources) được HL7 International khởi xướng năm 2011 dưới cái tên RFH (Resources for Health). Bản trial đầu tiên — DSTU1 — phát hành ngày 30/09/2014 với mã phiên bản 0.0.82. Mười hai năm sau, cộng đồng đã đi qua bảy phiên bản chính thức và đang ballot phiên bản thứ tám. Đây là tốc độ phát triển rất nhanh so với HL7 v2 (vốn mất ba mươi năm để đi từ V2.0 năm 1988 đến V2.9 năm 2019), nhưng cũng tạo áp lực buộc các quốc gia phải chọn một version "neo" để xây National IG.

Bảng dưới tổng hợp ngày phát hành chính thức (theo trang lịch sử của HL7) và trạng thái hiện tại tính đến tháng 05/2026.

Lưu ý: hai mốc thường bị nhầm lẫn là DSTU1 (30/09/2014) và DSTU2 (24/10/2015). DSTU1 nhiều khi bị viết là 21/02 — đây là ngày HL7 mở ballot dự thảo, không phải ngày publish. Khi trích dẫn trong tài liệu kỹ thuật hay báo cáo cho lãnh đạo, hãy dùng đúng ngày publish chính thức.

2. Lifecycle: DSTU, STU, R và Normative nghĩa là gì

Để hiểu vì sao R4 quan trọng, cần nắm bốn nhãn vòng đời mà HL7 dùng cho FHIR.

• DSTU (Draft Standard for Trial Use) — nhãn cũ áp dụng cho DSTU1 và DSTU2. Đặc trưng: cho phép breaking change giữa các bản minor.
• STU (Standard for Trial Use) — nhãn mới từ STU3 trở đi. Vẫn cho phép thay đổi nhưng quy trình ballot chặt hơn DSTU.
• R (Release) — viết tắt cho version chính. R4, R5, R6 đều là Release; nhãn STU/Normative áp dụng ở mức Resource hoặc artifact, không phải toàn release.
• Normative — đã đóng đinh, không được thay đổi theo kiểu breaking. HL7 cam kết: một artifact đã Normative thì sẽ giữ nguyên ngữ nghĩa qua các phiên bản tiếp theo.

R4 là phiên bản đầu tiên có Normative content. Trên thực tế, HL7 gắn nhãn Normative cho khoảng ba mươi Resource và artifact cốt lõi — bao gồm Patient, Observation, các Conformance Resource (StructureDefinition, CapabilityStatement, ValueSet), nền tảng RESTful API và lớp Terminology Service. Phần còn lại trong tổng số 146 Resource của R4 vẫn ở trạng thái Trial Use, ví dụ Encounter, AllergyIntolerance, MedicationRequest. Điều này có nghĩa: khi nhà cung cấp tuyên bố "tuân thủ FHIR R4 Normative", họ đang nói về subset đã chốt — không phải toàn bộ spec.

R5 không phải Normative release. HL7 nói rõ: R5 chỉ kế thừa nhãn Normative đã có trong R4 và promote thêm vài artifact, còn nội dung mới của R5 vẫn ở STU. Cách phát biểu chính xác là "R5 = Trial Use, kế thừa các artifact Normative từ R4".

3. So sánh DSTU2, STU3, R4, R4B, R5

Bảng so sánh dưới giúp đánh giá khoảng cách giữa các version trên các trục mà CIO hay hỏi: số lượng Resource, mức độ Normative, hệ sinh thái phụ trợ và mức adoption thực tế.

Một điểm hay bị truyền thông sai: Bulk Data Access không phải tính năng "built-in" của R5. Bulk Data là một Implementation Guide riêng do HL7 maintain (canonical hl7.org/fhir/uv/bulkdata), bản hiện hành vẫn build trên FHIR R4. Khi vendor tuyên bố hỗ trợ Bulk Data, hãy hỏi rõ phiên bản IG và FHIR base.

4. Vì sao R4 vẫn là mặc định trong năm 2026

Câu hỏi "R4 hay R5" thường gặp khi một dự án mới đứng trước quyết định kiến trúc. Năm lý do dưới đây giải thích vì sao R4 vẫn là lựa chọn hợp lý cho hầu hết tổ chức tại Việt Nam trong 2026.

Một, nhãn Normative ở các Resource cốt lõi. Patient, Observation cùng nhóm Conformance/Terminology đã Normative trong R4. Đầu tư build profile lên các Resource này không lo "vứt đi" sau vài năm. Encounter và AllergyIntolerance vẫn ở Trial Use, nhưng cấu trúc đã đủ ổn định để dùng production.

Hai, hệ sinh thái tooling mature. HAPI FHIR JPA Server, Firely SDK, Microsoft Azure FHIR Service, Google Cloud Healthcare API, AWS HealthLake — tất cả đều hỗ trợ R4 ở mức GA. SUSHI, IG Publisher và FSH ecosystem đều coi R4 là baseline. Vendor commercial của Việt Nam (Ominext, FPT IS, VNPT, Viettel) cũng đang triển khai trên HAPI R4.

Ba, National IG quốc tế đều bám R4. US Core 6.x và 7.x, JP Core 1.x, KR Core, CH Core, AU Core, IPS (International Patient Summary), IPA (International Patient Access) đều phát hành trên R4. Chọn R4 đồng nghĩa profile của VN Core có thể derive trực tiếp từ các IG này, dễ harmonize quốc tế.

Bốn, ràng buộc từ vendor lớn. Epic, Cerner (Oracle Health), Allscripts đều certify FHIR R4 theo ONC mandate (USCDI, HTI-1). Các bệnh viện Việt Nam đang vận hành Epic hoặc Cerner sẽ tự nhiên kết nối qua R4. Bộ Y tế Nhật cũng chọn R4 làm baseline cho JP Core.

Năm, độ trưởng thành của VN Core. Repo hl7vn/vn-core-ig do Cục CNTT BYT (2024) khởi tạo trên R4. Phiên bản cộng đồng OmiGroup đang phát triển tại hl7.org.vn tiếp tục dùng R4 để bảo đảm backward-compatibility — đây là quyết định có chủ ý, không phải mặc định lười biếng.

5. R5 có gì mới và nên đọc trước thứ gì

R5 (5.0.0, phát hành 26/03/2023) là phiên bản đầu tiên sau khi HL7 có kinh nghiệm 4 năm vận hành R4 ở quy mô lớn. R5 mang tổng số Resource lên khoảng 157, thêm nhiều Resource mới và refactor một số Resource đã quá cũ.

Resource mới đáng chú ý

• SubscriptionTopic — chuẩn hoá cơ chế pub/sub, cho phép vendor định nghĩa "chủ đề" mà client subscribe, thay vì subscribe theo query string như cách R4 làm.
• ImagingSelection — cho phép tham chiếu một frame, region hoặc series cụ thể trong DICOM mà không cần tải lại object — quan trọng với teleradiology.
• Permission — Resource mô tả fine-grained access control rule, hữu ích khi triển khai Consent + ABAC.
• RegulatedAuthorization — phục vụ trao đổi dữ liệu đăng ký lưu hành thuốc, drug regulatory affairs.

Thay đổi cấu trúc

• Reference chặt hơn về resolved type — buộc client validate kỹ hơn.
• Coding được mã hóa gọn gàng hơn trong JSON; có thêm format compact cho transmission tiết kiệm băng thông.
• Một số Resource (MedicationStatement, RelatedPerson, AllergyIntolerance) tiếp tục tồn tại trong R5 nhưng có chỉnh nhỏ ở field — cần đọc release note R5 trước khi map dữ liệu cũ.

Adoption R5 hiện ở khoảng 10% và tăng dần. Vendor tooling (HAPI, Firely) đã hỗ trợ R5 ở mức GA, nhưng các National IG lớn (US Core, JP Core) chưa migrate. Câu trả lời thực dụng cho năm 2026: build production trên R4, theo dõi R5 ở môi trường staging, và lập kế hoạch migrate khi xuất hiện use case bắt buộc.

6. R6 đang ballot — chờ điều gì

Tính đến tháng 05/2026, HL7 đã đẩy CI build sang FHIR R6 6.0.0-ballot4 — đây là first full ballot của R6, tổng hợp các thay đổi đã tích luỹ từ sau R5. Nội dung đáng chú ý đang được cộng đồng thảo luận:

• Resource metadata cho AI/ML pipelines — đề xuất Resource mới mô tả model card, training data và provenance.
• FHIR Workflow lên Normative — Task, ServiceRequest, MessageDefinition cùng nhóm pattern execution có thể được đóng nhãn Normative.
• Bundle paging và pagination tốt hơn cho Bulk Data và Search.
• SubscriptionTopic được mở rộng với security profile và backpressure handling.

ETA chính thức: ballot 4 trong 2026, normative publication có thể trong giai đoạn 2027 — 2028. Trong thời gian này, R6 chưa nên dùng cho production. Các quyết định kiến trúc nên dựa trên R4 (production), R5 (staging) và theo dõi R6 ballot ở mức nghiên cứu.

7. Migration roadmap R4 → R4B → R5

Migration giữa các phiên bản FHIR không phải "đổi config, restart server". Thực tế đòi hỏi kiểm tra ConceptMap, profile, code, vendor compatibility và data migration. Bảng dưới phác thảo lộ trình ba bước.

Trước khi bấm nút migrate, hãy kiểm CapabilityStatement.fhirVersion của tất cả vendor đang kết nối. Nếu một thành phần trong chuỗi vẫn ở R4, migration tổng thể sang R5 là không khả thi — cần một adapter hoặc lùi kế hoạch. HL7 cung cấp ConceptMap chính thức giữa các phiên bản; với R4 ↔ R4B, mapping rất gần nguyên trạng. Với R4 ↔ R5, có những resource cần mapping thủ công.

8. Vì sao VN Core chọn R4

Quyết định chọn R4 cho VN Core không phải vì "ngại đổi mới". Đây là kết quả cân nhắc giữa năm yếu tố mà HungPM (Phan Mạnh Hùng, CIO/CTO OmiGroup) cùng cộng đồng kỹ thuật đã đánh giá:

1. Backward compatibility với hl7vn/vn-core-ig — Cục CNTT BYT đã publish phiên bản đầu trên R4 (canonical http://fhir.ehealth.gov.vn/core/). Bản phát triển tại hl7.org.vn giữ R4 để có thể merge hoặc redirect sau này.
2. Đồng bộ với National IG quốc tế — US Core, JP Core, KR Core, CH Core, AU Core, IPS, IPA đều R4. Profile VNCorePatient có thể derive từ các base profile này.
3. Tooling SUSHI và IG Publisher — toàn bộ pipeline build, validate, publish đang chạy ổn định trên R4. Đầu tư GitHub Actions cho R4 sinh kết quả ngay.
4. Vendor Việt Nam đã quen R4 — Ominext, FPT IS, VNPT, Viettel đều có sản phẩm HIS/LIS hoặc middleware đang triển khai trên HAPI FHIR R4. Chọn R5 đồng nghĩa toàn bộ vendor phải upgrade — chi phí xã hội rất lớn.
5. R5 chưa thấy adoption rộng tại châu Á — JP Core, KR Core đều chưa migrate. Đi trước thị trường khu vực không mang lại lợi ích cụ thể.

VN Core sẽ theo dõi tiến độ R5 ở các National IG lớn. Khi US Core hoặc JP Core công bố lộ trình migrate sang R5, VN Core sẽ cân nhắc một version 2.x trên R5. Trước thời điểm đó, R4 vẫn là baseline.

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

Bắt đầu dự án mới năm 2026, chọn R4 hay R5?

Chọn R4 cho production. Khởi động một sandbox R5 song song để theo dõi. Chỉ migrate khi xuất hiện use case bắt buộc dùng SubscriptionTopic, ImagingSelection hoặc Permission ở mức ngữ nghĩa native.

FHIR có deprecate phiên bản cũ không?

HL7 không "deprecate" theo nghĩa xoá spec, nhưng các phiên bản trước R4 (DSTU1, DSTU2, STU3) đã được đánh dấu lỗi thời (retired). Spec vẫn online cho mục đích lịch sử nhưng không nên dùng cho dự án mới.

FHIR server hiện đang R4, có bắt buộc upgrade lên R5 không?

Không bắt buộc. Quyết định phụ thuộc vào ba yếu tố: vendor downstream có yêu cầu R5 không, có use case mới chỉ R5 đáp ứng được không, và đội vận hành có đủ năng lực thực hiện regression test toàn bộ profile sau migration không.

VN Core có roadmap lên R5 không?

Có ý định, không có thời điểm cụ thể. OmiGroup và cộng đồng đã thống nhất: VN Core 1.x bám R4 ít nhất đến khi US Core hoặc JP Core công bố migration sang R5. Khi tín hiệu này xuất hiện, sẽ mở ballot cộng đồng cho VN Core 2.x.

R4B khác R4 ở điểm nào quan trọng nhất?

R4B (4.3.0) là bản backport các thay đổi đã có trong R5 về một số Resource cụ thể — quan trọng nhất là SubscriptionTopic. R4B được thiết kế làm cầu nối: hệ thống đã ở R4 có thể nâng lên R4B với effort thấp để có SubscriptionTopic, mà chưa cần migrate full sang R5.

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

Nguồn chính thức

• FHIR Version History — hl7.org/fhir/directory.html
• R4 release history — hl7.org/fhir/R4/history.html
• R4 Resource list — hl7.org/fhir/R4/resourcelist.html
• R5 release history — hl7.org/fhir/R5/history.html
• FHIR (current) Resource list — hl7.org/fhir/resourcelist.html
• Bulk Data Access IG — hl7.org/fhir/uv/bulkdata
• FHIR CI build (R6 ballot) — build.fhir.org

National IG tham chiếu

• US Core — hl7.org/fhir/us/core
• JP Core — jpfhir.jp/fhir/core
• VN Core IG (Cục CNTT BYT) — github.com/hl7vn/vn-core-ig
• VN Core (cộng đồng OmiGroup) — github.com/HL7-org-vn

Đọc tiếp trong knowledge hub