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

Tóm tắt nhanh

• Các mốc công bố chính gồm DSTU1, DSTU2, STU3, R4, R4B và R5; R6 đang được phát triển trên nhánh ballot/CI.
• R4 gồm cả nội dung Normative và Trial Use; nhãn mức trưởng thành phải được đọc ở từng Resource hoặc artifact, không suy ra cho toàn release.
• R5 bổ sung hoặc làm lại nhiều artifact, trong đó có SubscriptionTopic, ImagingSelection và Permission; R5 được công bố dưới dạng STU, còn nội dung đã Normative từ R4 giữ nguyên nhãn tương ứng.
• VN Core hiện khai báo FHIR 4.0.1 để duy trì một baseline kỹ thuật rõ ràng và có thể đối chiếu với repo VN Core năm 2024; cùng base version không đồng nghĩa tự động tương thích.
• Chỉ migration sau khi kiểm tra package/profile, CapabilityStatement, thuật ngữ, transform, đối tác và kiểm thử hồi quy; R4B không phải bước bắt buộc trước R5.

1. Timeline các mốc FHIR từ 2014 đến nhánh R6 ballot

FHIR (Fast Healthcare Interoperability Resources) được HL7 International khởi xướng năm 2011 dưới tên RFH (Resources for Health). DSTU1 phát hành ngày 30/09/2014 với mã phiên bản 0.0.82. Từ đó HL7 đã công bố các mốc DSTU2, STU3, R4, R4B và R5; R6 hiện vẫn ở nhánh ballot/CI. Mỗi IG phải khai báo rõ phiên bản FHIR nền và quản lý migration như một thay đổi hợp đồng kỹ thuật.

Bảng dưới tổng hợp các mốc phiên bản và trạng thái được đối chiếu ngày 18/07/2026. Nhánh CI có thể thay đổi giữa hai lần rà soát và không được xem là bản công bố ổn định.

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) — ký hiệu dòng phiên bản chính trong tên phát hành như R4 và R5. “R6” hiện là tên nhánh ballot/CI; chỉ trở thành bản công bố khi HL7 hoàn tất quy trình phát hành. Nhãn maturity vẫn phải đọc ở mức artifact.
• Normative — chịu các quy tắc thay đổi liên phiên bản nghiêm ngặt của HL7; không nên diễn giải là toàn bộ release bất biến.

R4 là phiên bản đầu tiên có nội dung Normative. Nhiều artifact khác của R4 vẫn ở Trial Use, ví dụ Encounter và AllergyIntolerance. Vì vậy, tuyên bố tuân thủ phải chỉ rõ phiên bản FHIR, IG/profile áp dụng và CapabilityStatement; cụm "FHIR R4 Normative" không mô tả đầy đủ toàn bộ hợp đồng triển khai.

Toàn bộ ballot R5 được công bố dưới dạng STU. Nội dung đã Normative trong R4 giữ nhãn đó; một số artifact được tổ chức lại trong R5 cũng có thể mang nhãn Normative vì kế thừa nội dung đã Normative. Vì vậy, không nên rút gọn trạng thái của mọi artifact R5 thành một nhãn duy nhất.

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

Bảng dưới chỉ so sánh các thuộc tính có thể kiểm tra từ lịch sử phát hành và phạm vi dự án. Các IG như SMART App Launch hoặc Bulk Data có vòng đời, package và base version riêng; không được suy ra hỗ trợ chỉ từ tên phiên bản FHIR của server.

Bulk Data Access là một Implementation Guide riêng do HL7 duy trì (canonical hl7.org/fhir/uv/bulkdata), không phải bằng chứng mặc định đi kèm với R4 hay R5. Khi nhà cung cấp tuyên bố hỗ trợ Bulk Data hoặc SMART, cần kiểm tra đúng phiên bản IG, base FHIR, endpoint và các capability bắt buộc.

4. Vì sao R4 là phiên bản nền của VN Core trong năm 2026

Câu hỏi "R4 hay R5" phải được trả lời theo hợp đồng liên thông cụ thể. Với VN Core hiện hành, các lý do dưới đây giải thích quyết định dùng R4; chúng không phải khuyến nghị mặc định cho mọi hệ thống tại Việt Nam.

Một, mức trưởng thành của một số artifact lõi. R4 là phiên bản đầu tiên có nội dung Normative. Những Resource còn ở Trial Use vẫn phải được đánh giá theo use case và profile; nhãn của base Resource không tự chứng minh một triển khai sẵn sàng production.

Hai, pipeline dự án đã được khai báo cho R4. Package VN Core, SUSHI configuration và quy trình validate hiện nhắm tới FHIR 4.0.1. Đây là một thuộc tính có thể kiểm tra của dự án, không phải tuyên bố rằng mọi công cụ hay sản phẩm R4 đều tương thích.

Ba, tính liên tục của VN Core. Repo hl7vn/vn-core-ig năm 2024 được khởi tạo trên R4. Bản trial-use tại hl7.org.vn giữ cùng base version để có thể so sánh cấu trúc; việc hài hòa vẫn cần quyết định quản trị, package dependency và phân tích diff cụ thể.

Bốn, hợp đồng liên thông phải có bằng chứng. Base version chỉ là một lớp của hợp đồng. Khả năng kết nối phải được chứng minh bằng package/profile, canonical URL, thuật ngữ, CapabilityStatement và kiểm thử tích hợp với payload thực tế.

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) bổ sung nhiều Resource và làm lại một số khu vực của đặc tả. Danh sách dưới nêu các thay đổi kỹ thuật đáng đọc; đây không phải bằng chứng rằng một sản phẩm, đối tác hoặc IG cụ thể đã hỗ trợ R5.

Resource mới đáng chú ý

• SubscriptionTopic — định nghĩa topic và trigger cho mô hình subscription đã được làm lại trong R5.
• ImagingSelection — định danh lựa chọn instance, frame hoặc vùng ảnh trong dữ liệu hình ảnh, kể cả tham chiếu DICOM khi phù hợp.
• Permission — biểu diễn tập quy tắc cho phép hoặc từ chối hành động; việc áp dụng kiểm soát truy cập vẫn phụ thuộc kiến trúc bảo mật của hệ thống.
• 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

• Bổ sung các interface CanonicalResource và MetadataResource cho nhóm artifact định nghĩa.
• Các extension được chuyển sang package hl7.fhir.uv.extensions, cho phép phát hành theo nhịp riêng.
• Bổ sung additional bindings và nhiều làm rõ cho REST/Search; migration vẫn cần đối chiếu diff và transform của từng Resource.

Với VN Core, R5 chỉ nên được đánh giá khi có use case, IG hoặc đối tác nêu yêu cầu cụ thể. Quyết định production cần chỉ rõ target package, tác động dữ liệu, biên chuyển đổi và kết quả kiểm thử; tên release tự nó không đủ làm tiêu chí.

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

Tại lần rà soát ngày 18/07/2026, CI build hiển thị 6.0.0-ballot4 và tự cảnh báo nội dung CI có thể không nhất quán. Lịch sử chính thức của nhánh này nêu các thay đổi trọng tâm sau:

• Chuyển một số định nghĩa sang nhóm Additional Resources.
• Làm lại Dosage để biểu diễn chế độ dùng thuốc phức tạp.
• Làm lại cơ chế chữ ký và áp dụng nhiều thay đổi nhỏ trên toàn đặc tả.
• Đề xuất chuyển phần lớn nội dung sang Normative, trừ các trang được đánh dấu Informative; kết quả cuối cùng vẫn phụ thuộc ballot.

Dự án không gán ETA công bố cho R6 khi HL7 chưa có mốc ổn định được viện dẫn. Không dùng CI build làm dependency production; nếu theo dõi R6, phải pin snapshot thử nghiệm và chấp nhận nội dung có thể thay đổi.

7. Đánh giá migration giữa R4, R4B và R5

Không có lộ trình bắt buộc R4 → R4B → R5. R4B là một release độc lập có thể phù hợp với một số hợp đồng, không phải bước đệm bắt buộc. Mỗi đường chuyển đổi phải được đánh giá từ target IG/package, payload đang lưu trữ và các hệ thống ở hai phía biên tích hợp.

CapabilityStatement là bằng chứng cần thiết nhưng không tự chứng minh tương thích. Cần lấy /metadata của đúng endpoint và kiểm tra tối thiểu fhirVersion, format, profile/supportedProfile, interaction, search parameter và operation; sau đó đối chiếu package, canonical URL, phiên bản thuật ngữ và chạy kiểm thử tích hợp. Một kiến trúc mixed-version có thể khả thi khi biên chuyển đổi, quy tắc mất dữ liệu và trách nhiệm vận hành được quy định rõ; cũng không được giả định rằng hai hệ thống cùng fhirVersion sẽ tương thích.

Cần phân biệt ConceptMap dùng cho quan hệ giữa các code/khái niệm với StructureMap và FHIR Mapping Language dùng cho chuyển đổi cấu trúc. HL7 công bố inter-version transforms cho phần lớn Resource, nhưng tài liệu R4 maps tự ghi trạng thái Informative và không authoritative. Mỗi dự án phải review, bổ sung quy tắc cục bộ và kiểm tra round-trip trên dữ liệu đại diện; không được xem transform là cam kết chuyển đổi không mất dữ liệu.

8. Vì sao VN Core chọn R4

Baseline R4 hiện tại của VN Core được mô tả bằng các thuộc tính dự án có thể kiểm tra sau:

1. Liên tục về base version — repo hl7vn/vn-core-ig năm 2024 khai báo R4 (canonical http://fhir.ehealth.gov.vn/core/); bản trial-use tại hl7.org.vn cũng khai báo R4 để hỗ trợ so sánh. Đây không phải tuyên bố backward compatibility.
2. Project configuration — package, SUSHI configuration và pipeline validate hiện nhắm tới FHIR 4.0.1.
3. Dependency có kiểm soát — khi tham chiếu IG khác, dự án phải pin đúng package/version và kiểm tra base FHIR, canonical cùng dependency graph.
4. Migration cần quyết định quản trị — chỉ đổi base version sau proposal, phân tích tác động, thử nghiệm transform, kiểm thử conformance/tích hợp và công bố quyết định.

VN Core theo dõi các release FHIR và IG tham chiếu, nhưng không tự động đổi base version theo một dự án khác. Cho đến khi có quyết định thay thế được công bố, hợp đồng hiện hành vẫn là R4 4.0.1 theo package của dự án.

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

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

Nếu áp dụng VN Core hiện hành, dùng R4 và pin đúng package. Với dự án khác, chọn phiên bản từ IG/đối tác áp dụng và CapabilityStatement; có thể dùng sandbox R5 để đánh giá trước khi đưa ra quyết định production.

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

HL7 giữ các bản công bố cũ trong version directory. Không nên gán nhãn "retired" cho cả release nếu trang chính thức không ghi như vậy. Với dự án mới, chọn release theo IG và hợp đồng đích; chỉ giữ DSTU1, DSTU2 hoặc STU3 khi một giao diện legacy cụ thể yêu cầu và phải quản lý riêng biên chuyển đổ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ố: nhà cung cấp 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?

Dự án có chủ trương theo dõi nhưng chưa có lịch hoặc quyết định migration được phê duyệt. Bất kỳ nhánh R5 tương lai nào cũng cần proposal, phân tích tác động, thử nghiệm và quy trình governance trước khi công bố.

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

R4B (4.3.0) đưa một số thay đổi từ quá trình phát triển R5 vào các khu vực chọn lọc, trong đó có mô hình SubscriptionTopic. R4B có thể là lựa chọn staging cho một hợp đồng cụ thể, nhưng không phải cầu nối bắt buộc và không bảo đảm effort thấp; cần so diff của đúng Resource, profile, package và tooling đang dùng.

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
• Managing multiple FHIR versions — hl7.org/fhir/R5/versions.html
• R4 inter-version maps (Informative) — fhir.hl7.org/fhir/r4maps.html
• R4 CapabilityStatement — hl7.org/fhir/R4/capabilitystatement.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 trial-use (Omi HealthTech) — github.com/HL7-org-vn

Đọc tiếp trong knowledge hub

Snapshot nội dung: 18/07/2026. Trước khi quyết định triển khai hoặc migration, cần kiểm tra lại trạng thái phát hành và tài liệu tương thích trên các nguồn chính thức của HL7.