Đừng "di chuyển" HL7 v2 sang FHIR bằng cách viết lại các interface đang chạy tốt. Giữ các luồng v2 ổn định (ADT, ORU, ORM, DFT) trên interface engine, chuyển sang FHIR ở rìa hệ thống nơi người dùng mới cần, chạy song song đường cũ và đường mới với so sánh tự động, và chỉ khai tử một luồng v2 khi bên tiêu thụ cuối cùng đã chuyển đi.
Có hai lý do khiến đây thành quyết định của năm 2026 với nhiều đội. NextGen chuyển Mirth Connect sang giấy phép đóng, trả phí từ phiên bản 4.6, nên "engine miễn phí cộng mã nguồn mở" không còn là mặc định. Và Microsoft đã ngừng Azure API for FHIR từ 30/09/2026, buộc ai dùng nó làm đích chuyển đổi phải đổi nền tảng. Trong khi đó, các bên tiêu thụ mới (AI agent, phân tích, API cho payer theo CMS-0057-F) đều muốn FHIR. Bài này trình bày các mẫu kiến trúc chạy được, các engine đang có trên thị trường, và những phần bạn nên để yên.
Có nên thay HL7 v2 bằng FHIR không?
Thường là không thay toàn bộ. HL7 v2 vẫn là cách đa số hệ thống bệnh viện chuyển sự kiện ADT, chỉ định và kết quả, và các luồng đó ổn định, có giám sát, được mọi analyst tại chỗ hiểu rõ. Chỉ thay v2 ở chỗ bên tiêu thụ cần thứ v2 không cho: truy vấn theo yêu cầu, truy cập RESTful, hay API chuẩn cho bệnh nhân, app và payer.
Một cách nghĩ hữu ích: v2 là đẩy sự kiện; FHIR (phần lớn) là kéo trạng thái. Chúng giải các bài toán khác nhau. FHIR có thêm Subscriptions để đẩy, nhưng trên các EHR production vẫn chưa đồng đều; ví dụ nền tảng FHIR subscription của athenahealth được ghi là alpha giới hạn. Hãy lên kế hoạch cho hai mô hình cùng tồn tại nhiều năm.
| Giữ trên HL7 v2 | Mở ra dưới dạng FHIR | Xây lại trên FHIR |
|---|---|---|
| Luồng ADT tới các hệ thống hạ nguồn đang chạy tốt | View Patient, Encounter, Observation cho app mới và AI agent | Luồng point-to-point tự chế không ai bảo trì nổi |
| Chỉ định/kết quả xét nghiệm và chẩn đoán hình ảnh với đối tác bên ngoài | Dữ liệu cho API payer (CMS-0057-F) và truy cập của bệnh nhân | Thả file theo lô lẽ ra phải là truy vấn |
| Luồng phí dịch vụ (DFT) vào hệ thống billing | Trích xuất phân tích qua Bulk FHIR hoặc view đã làm phẳng | Interface đằng nào cũng bị thay do đổi EHR |
| Interface thiết bị, máy xét nghiệm có chứng nhận của vendor | Read model cho portal và dashboard | Tích hợp mới chưa có lịch sử v2 |
Giấy phép Mirth Connect đã thay đổi thế nào?
Từ phiên bản 4.6, NextGen chuyển Mirth Connect sang một giấy phép duy nhất, đóng và độc quyền, và mã nguồn của các bản phát hành mới không còn công khai. Muốn nâng lên 4.6 trở đi bạn phải mua giấy phép từ NextGen. Bản mã nguồn mở cuối cùng trên GitHub của NextGen là 4.5.2, phát hành tháng 9/2024.
Trang tải Mirth Connect của NextGen liệt kê các gói Enterprise, Gold và Platinum với nút "Speak with Sales", không có giá công khai. Các lựa chọn của bạn:
- Mua giấy phép thương mại. Hợp lý nếu bạn cần vendor hỗ trợ và đường nâng cấp có bảo đảm. Hãy lấy giá và giới hạn của gói bằng văn bản.
- Ở lại 4.5.2. Chỉ tạm thời. Từ giờ bạn gánh mọi lỗ hổng không được vá, rất khó bảo vệ trong vòng đánh giá bảo mật.
- Chuyển sang bản fork cộng đồng. Open Integration Engine tự mô tả là bản fork mã nguồn mở của Mirth Connect nay đã đóng, giấy phép MPL-2.0, phát hành v4.6.0 tháng 7/2026 và v4.7.0 tháng 10/2026. Hãy cân nhắc nhịp phát hành và số người đóng góp so với mức chấp nhận rủi ro của bạn.
- Chuyển sang engine thương mại khác như Rhapsody, InterSystems HealthShare / IRIS for Health, hay iNTERFACEWARE Iguana. Hãy lấy mô hình cấp phép của từng vendor bằng văn bản, và so sánh theo công sức chuyển channel chứ không chỉ theo giá giấy phép.
Chọn gì cũng phải kiểm kê trước: số channel, loại message, transformer JavaScript tự viết, bảng mã, và channel nào mang PHI ra bên ngoài. Bản kiểm kê đó mới là kích thước thật của công việc.
Ánh xạ message HL7 v2 sang resource FHIR thế nào?
Bắt đầu từ implementation guide V2-to-FHIR của HL7, rồi viết ánh xạ tường minh, có kiểm thử cho các biến thể cục bộ của bạn. HL7 Version 2 to FHIR IG (v1.0.0, STU 1, trial use) ánh xạ message, segment, kiểu dữ liệu và từ vựng v2 sang FHIR R4, theo dạng tích lũy bắt đầu từ v2.9.
IG cho bạn ánh xạ chuẩn. Message production thì chẳng bao giờ chuẩn. Những thứ làm hỏng ánh xạ trong thực tế:
- Z-segment chứa dữ liệu cục bộ quan trọng (ví dụ segment bảo hiểm hay đồng ý tự định nghĩa). Hãy ánh xạ chúng sang extension có chủ đích, hoặc bỏ đi khi đã biết rõ.
- Trường bị dùng sai mục đích: site đặt MRN ở PID-2 thay vì PID-3, hay mã dạng text tự do trong trường mã hóa.
- Mã cục bộ cho xét nghiệm, địa điểm và loại lượt khám, cần ConceptMap sang LOINC, SNOMED CT hay value set của riêng bạn.
- Sự kiện định danh: gộp hồ sơ (ADT^A40), chuyển, liên kết/hủy liên kết. Chúng đổi việc resource thuộc về Patient nào và là nơi bắt đầu của phần lớn sự cố chất lượng dữ liệu.
- Sự kiện hay trạng thái: một bản cập nhật A08 có thể chứa toàn bộ bệnh nhân hoặc chỉ phần thay đổi, tùy bên gửi. Logic upsert FHIR của bạn phải biết là loại nào.
Các lựa chọn converter
Converter dựa trên template giúp được 80% đầu. $convert-data của Microsoft dùng template Liquid cho HL7v2, C-CDA, JSON và FHIR STU3 sang R4, với root template HL7v2 cho các loại message như ADT_A01, ORU_R01, ORM_O01, VXU_V04 và SIU_S12. Microsoft cảnh báo template mặc định không dành cho production và không được hỗ trợ, và yêu cầu bạn tự host, đăng ký bản sao riêng để hành vi không đổi giữa các phiên bản. Lời khuyên đó đúng với mọi converter: quản lý phiên bản ánh xạ như quản lý code.
Mẫu chuyển đổi an toàn nhất là gì?
Một lớp facade với chạy song song. Giữ nguyên luồng v2, rẽ nhánh nó vào pipeline chuyển đổi ghi ra FHIR, cho bên tiêu thụ mới đọc FHIR, và so sánh đầu ra tự động tới khi số liệu khớp. Sau đó chuyển từng bên tiêu thụ cũ một.
- Rẽ nhánh, đừng cắt. Nhân bản luồng v2 trong engine (thêm một destination), để đường gốc không đổi.
- Chuyển đổi và lưu. Ánh xạ sang FHIR, validate theo profile của bạn (US Core nếu áp dụng), upsert vào FHIR server với khóa idempotency là message control ID (MSH-10) cộng bên gửi.
- So sánh liên tục. Với mỗi message, so kết quả FHIR với những gì bên tiêu thụ cũ đã lưu. Theo dõi tỷ lệ lệch theo loại message và theo trường.
- Chuyển từng bên tiêu thụ, bắt đầu từ bên chỉ đọc, rủi ro thấp nhất.
- Chỉ khai tử luồng khi không còn ai đọc. Giữ khả năng phát lại message v2 vào đường mới ít nhất trong một chu kỳ nghiệp vụ trọn vẹn.
Cách này chậm hơn một cuối tuần cutover, và rẻ hơn rất nhiều so với một sự cố định danh bệnh nhân.
Những gì không nên viết lại?
Đừng viết lại các interface bên ngoài đang ổn định với phòng xét nghiệm, chẩn đoán hình ảnh, nhà thuốc và đối tác billing trừ khi đối tác yêu cầu. Đừng viết lại interface thiết bị có xác nhận của vendor hay cơ quan quản lý. Và đừng viết lại luồng đổ vào một hệ thống đằng nào cũng bị khai tử trong 18 tháng tới.
Mỗi việc như vậy kéo theo kiểm thử và hợp đồng với một tổ chức khác mà roadmap FHIR của bạn không chi trả. Hãy đặt lớp FHIR phía sau chúng. Logic tương tự áp dụng cho interface EHR có chứng nhận của vendor: ví dụ Epic vẫn cung cấp spec HL7 v2 và X12 qua Vendor Services song song với FHIR, vì cả hai vẫn đang được dùng. Bài tích hợp Epic năm 2026 nói khi nào nên đi đường nào.
Việc ngừng Azure API for FHIR đã thay đổi điều gì?
Microsoft ngừng Azure API for FHIR từ 30/09/2026; triển khai mới đã bị chặn từ 01/04/2025. Các đội phải chuyển sang FHIR service của Azure Health Data Services hoặc một FHIR server khác, và kiểm thử lại mọi pipeline từng ghi vào endpoint cũ.
FAQ chuyển đổi của Microsoft trỏ tới một công cụ migration và liệt kê lợi ích của dịch vụ mới, gồm $import tăng dần và sự kiện FHIR. Bài học cho ai thiết kế pipeline v2 sang FHIR: đặt FHIR server sau một interface bạn kiểm soát, giữ logic chuyển đổi và validate trong code có phiên bản của riêng bạn, để việc đổi nền tảng chỉ là trỏ lại và kiểm thử lại, không phải xây lại.
AI agent thay đổi tích hợp HL7 v2 thế nào?
Agent cần dữ liệu truy vấn được, mới, được mã hóa tốt và có nguồn gốc rõ. Thường điều đó nghĩa là một read model FHIR được nuôi bằng sự kiện v2, không phải để agent tự đọc chuỗi HL7 thô. Agent đọc FHIR qua các tool hẹp; interface engine tiếp tục làm tốt việc của nó.
Ba quy tắc thiết kế: cho agent quyền đọc read model FHIR, không cho chạm vào engine; mọi thao tác ghi mà agent đề xuất phải qua bước người duyệt rồi đi theo đường interface bình thường, để hệ thống hạ nguồn nhận một message bình thường; và giữ provenance (message v2 nào tạo ra resource FHIR nào) để giải thích được mọi câu trả lời. Về xác thực cho read model đó, xem SMART on FHIR backend services; về các lớp kiểm soát, xem AI agent tuân thủ HIPAA.
Kiểm thử pipeline v2 sang FHIR thế nào?
Dùng mẫu message thật (đã khử định danh) theo từng bên gửi và loại message, một bộ regression chạy mỗi khi đổi ánh xạ, validate profile cho mọi đầu ra, và so sánh trên production trong giai đoạn chạy song song. Kiểm thử tường minh các sự kiện định danh và message đến sai thứ tự.
- Golden file: message đầu vào, bundle FHIR mong đợi, lưu cạnh file ánh xạ.
- Trường hợp biên: gộp hồ sơ, hủy (A11, A13), kết quả đã sửa, segment lặp, trường bắt buộc bị trống, tên có ký tự ngoài ASCII.
- Thứ tự: gửi bản cập nhật trước bản tạo mới và kiểm tra pipeline xếp hàng hoặc từ chối đúng.
- Phát lại: chạy lại lưu lượng của một ngày và kiểm tra kho FHIR hội tụ về cùng trạng thái.
- Giám sát: tỷ lệ lệch, kích thước dead-letter queue và độ trễ, đều có cảnh báo.
Về phía bảo mật của pipeline, bài phát triển phần mềm tuân thủ HIPAA bàn về logging, mã hóa và kiểm soát truy cập.
BeevR làm việc này thế nào
Chúng tôi bắt đầu bằng kiểm kê channel, loại message, code tự viết và các bên tiêu thụ, rồi thiết kế facade, ánh xạ và cơ chế so sánh trước khi chạm vào bất kỳ luồng production nào. Chúng tôi xây converter như code có phiên bản và kiểm thử, chạy song song tới khi tỷ lệ lệch chấp nhận được, và để yên các interface v2 đang ổn định. Chúng tôi sẽ nói thẳng khi mua giấy phép engine thương mại rẻ hơn xây lại. BeevR ký BAA với tư cách business associate, model dùng cho lớp AI có thể chạy trong chính tài khoản AWS của bạn theo AWS BAA, và bạn sở hữu source code và IP từ ngày đầu.
Đội senior do founder dẫn dắt ở Hà Nội đang vận hành một EHR multi-tenant ở bốn phòng khám tại Mỹ với khoảng 300 bệnh nhân mỗi ngày, có demo chạy được mỗi thứ Sáu và các giai đoạn phạm vi cố định, giá cố định từ $10K mỗi giai đoạn. Xem dịch vụ tích hợp EHR và phát triển AI agent cho y tế.
Sắp phải gia hạn Mirth hay đổi nền tảng FHIR? Đặt lịch gọi 30 phút, chúng tôi giúp bạn ước lượng khối lượng chuyển đổi và quyết định phần nào giữ lại trên v2.