IHE là gì? Profile tích hợp y tế và quan hệ với HL7/FHIR

Tóm tắt nhanh

• IHE khởi đầu năm 1998 với sự tham gia của RSNA và HIMSS; profile được tổ chức theo các domain như IT Infrastructure, Radiology, Cardiology, PCC, QRPH và PaLM.
• Một profile thường xác định use case, actor, transaction, option, grouping và/hoặc content module; yêu cầu cụ thể nằm trong đúng phiên bản Technical Framework.
• XDS.b quản lý chia sẻ tài liệu theo mô hình Affinity Domain và không bắt buộc một định dạng nội dung duy nhất. MHD cung cấp giao diện FHIR R4 cho một tập use case document-sharing và có thể làm API trước hạ tầng XDS/XCA.
• PIXm và PDQm là hai profile khác nhau: PIXm xử lý cross-reference identifier; PDQm truy vấn hoặc đối sánh demographic. Không nên gộp chúng thành một API hay một yêu cầu mặc định.
• Danh sách IHE Worldwide tại thời điểm rà soát chưa ghi nhận Deployment Committee của Việt Nam. ATNA, MHD hoặc các profile khác là đầu vào thiết kế kỹ thuật; việc tuân thủ pháp luật vẫn cần phân tích độc lập theo vai trò, dữ liệu và hệ thống triển khai.

1. IHE là gì? Lịch sử và cấu trúc tổ chức

IHE được sáng lập năm 1998 tại Hoa Kỳ bởi hai hiệp hội chuyên ngành: RSNA (Radiological Society of North America) và HIMSS (Healthcare Information and Management Systems Society). Mục tiêu ban đầu là giải quyết tình trạng các hệ thống PACS, RIS, HIS không nói chuyện được với nhau dù cùng dùng HL7 và DICOM — vì mỗi hãng triển khai chuẩn theo cách hơi khác. IHE không viết một chuẩn mới mà mô tả cách kết hợp các chuẩn sẵn có để mọi nhà cung cấp làm giống nhau.

Về tổ chức, IHE International là pháp nhân phi lợi nhuận, vận hành theo mô hình member-driven. Các quốc gia thành lập IHE Affiliate hoặc Deployment Committee để phụ trách bản địa hóa và tổ chức testing trong khu vực — IHE Europe, IHE USA, IHE Japan, IHE Korea và IHE Asia-Oceania là những cộng đồng hoạt động sôi nổi. Theo danh sách IHE Deployment Committees được rà soát tháng 06/2026, Việt Nam chưa xuất hiện như một committee chính thức.

Các đầu ra chính gồm Technical Framework/Profile, tài liệu test và kết quả thử nghiệm liên nhà cung cấp tại Connectathon. Kết quả test chỉ là bằng chứng cho actor, profile, option và phiên bản đã thử trong sự kiện; không chứng minh toàn bộ sản phẩm hay một deployment cụ thể tương thích trong mọi bối cảnh.

2. Profile = use case + actor + transaction

Một IHE profile thường mô tả use case, actor và transaction; tùy profile còn có option, required grouping, content module và security consideration. Các tiêu chuẩn nền vẫn quyết định cấu trúc dữ liệu hoặc giao thức tương ứng, còn IHE ràng buộc cách dùng chúng trong phạm vi workflow đã nêu.

Ví dụ cụ thể với profile XDS.b (Cross-Enterprise Document Sharing) — profile chia sẻ document liên viện kinh điển nhất:

Profile: XDS.b (Cross-Enterprise Document Sharing)
├── Actor:
│   ├── Document Source       (BV phát sinh tài liệu, ví dụ BV tỉnh)
│   ├── Document Repository   (lưu trữ binary của tài liệu)
│   ├── Document Registry     (chỉ mục metadata, nơi truy vấn)
│   └── Document Consumer     (BV/ứng dụng đọc tài liệu, ví dụ BV xã)
├── Transaction:
│   ├── ITI-41: Provide and Register Document Set-b
│   ├── ITI-42: Register Document Set-b
│   ├── ITI-43: Retrieve Document Set-b
│   └── ITI-18: Registry Stored Query
└── Technology:
    ├── ebXML Registry metadata (ebRIM/ebRS)
    ├── SOAP 1.2 over HTTPS, MTOM/XOP cho binary attachment
    └── Payload: CDA R2, PDF/A, hình ảnh DICOM, văn bản — tuỳ Affinity Domain quy định

Lưu ý: XDS.b dùng ebXML Registry trên SOAP 1.2 với MTOM/XOP để truyền file binary, payload có thể là CDA, PDF, ảnh hoặc bất kỳ định dạng nào do Affinity Domain quy định — CDA chỉ là một trong nhiều lựa chọn payload, không phải yêu cầu cứng. Cách viết "actor + transaction + công nghệ" này lặp lại cho mọi profile khác.

3. Các domain chính của IHE

IHE chia profile thành các domain theo lĩnh vực lâm sàng hoặc kỹ thuật. Bảng dưới liệt kê các domain hoạt động chính cùng profile tiêu biểu (có thể tra cứu đầy đủ tại profiles.ihe.net):

Lưu ý quan trọng về tên gọi: PaLM là tên domain, không phải tên một profile — domain này hợp nhất từ Laboratory và Anatomic Pathology cũ. Các mã LAB-* hiện vẫn còn nhưng là transaction nằm trong profile thuộc PaLM (ví dụ LTW, LAW). Tương tự, DSG (Document Digital Signature) thuộc domain ITI chứ không phải QRPH.

4. 10 profile phổ biến cần biết

4.1 XDS / XDS.b — Cross-Enterprise Document Sharing

XDS.b hỗ trợ đăng ký, phân phối và truy cập tài liệu giữa các tổ chức trong một hoặc nhiều Affinity Domain. Luồng cơ bản thường có Document Source, Repository, Registry và Consumer cùng các transaction như ITI-41, ITI-42, ITI-43 và ITI-18; profile còn định nghĩa actor, transaction và grouping khác. Nội dung tài liệu được xử lý như payload và chính sách Affinity Domain quyết định format, định danh, consent và access control. Chưa có bằng chứng công khai trong corpus dự án để kết luận XDS.b đang được triển khai ở một chương trình cụ thể tại Việt Nam.

4.2 PIX / PDQ — Patient Identity Cross-reference / Demographics Query

PIX hỗ trợ cross-reference nhiều patient identifier domain; PDQ hỗ trợ truy vấn demographic theo transaction được định nghĩa trong profile. Đây là các pattern có thể được đánh giá cho MPI/HIE, nhưng Thông tư 13/2025/TT-BYT không tự động chỉ định PIX, PDQ hay kiến trúc “MPI quốc gia”. Thiết kế tại Việt Nam phải xác định authority của từng identifier, quy tắc match/merge, quyền truy cập và xử lý sai ghép.

4.3 ATNA — Audit Trail and Node Authentication

ATNA định nghĩa các actor và transaction liên quan đến node/application security và audit record repository. Yêu cầu grouping phải đọc trong từng profile; ví dụ XDS.b có required grouping cụ thể với ATNA. Việc triển khai ATNA có thể hỗ trợ một phần kiến trúc audit, nhưng không tự chứng minh tuân thủ Luật 91/2025/QH15 hay Nghị định 356/2025/NĐ-CP; phạm vi sự kiện, retention, truy cập log và trách nhiệm xử lý vẫn phải được xác định riêng.

4.4 BPPC — Basic Patient Privacy Consents

BPPC mô tả cách ghi nhận việc bệnh nhân chấp thuận một chính sách quyền riêng tư trong môi trường document sharing. BPPC và FHIR Consent có mô hình, transaction và phạm vi tuân thủ khác nhau; không được xem chúng là hai phiên bản thay thế trực tiếp. Use case tại Việt Nam cần bắt đầu từ căn cứ xử lý và yêu cầu pháp lý, sau đó mới chọn profile và representation phù hợp.

4.5 MHD — Mobile access to Health Documents

MHD định nghĩa giao diện FHIR cho việc publish, tìm và truy xuất tài liệu, tập trung vào client có stack đơn giản hoặc bị giới hạn tài nguyên. MHD dùng các profile trên DocumentReference, List, Bundle và Binary; Folder và SubmissionSet được biểu diễn qua các profile của List, không phải Resource FHIR riêng. Tại snapshot 18/07/2026, trang IHE công bố MHD 4.2.5-comment ở trạng thái Publication Ballot trên FHIR R4; triển khai phải pin đúng package/trạng thái. MHD hỗ trợ một tập con use case XDS và có thể làm API trước XDS/XCA, nhưng không thay thế toàn bộ tính năng, security hoặc scalability của một hạ tầng XDS.

4.6 SWF / SWF.b — Scheduled Workflow (Radiology)

SWF/SWF.b mô tả actor và transaction cho luồng chỉ định, lập lịch, thực hiện và lưu trữ chẩn đoán hình ảnh. Một sản phẩm có DICOM Modality Worklist hoặc C-STORE không mặc nhiên hỗ trợ toàn bộ SWF actor/option; cần kiểm tra IHE Integration Statement, DICOM Conformance Statement và cấu hình đã triển khai tại site.

4.7 XCA / XCA-I — Cross-Community Access

XCA định nghĩa actor/transaction để truy vấn và truy xuất tài liệu qua ranh giới community; XCA-I áp dụng bài toán cross-community cho dữ liệu hình ảnh. Đây là một pattern liên kết phân tán, nhưng vị trí lưu dữ liệu, access control và “chủ quyền dữ liệu” vẫn do chính sách và kiến trúc deployment quyết định.

4.8 PIXm / PDQm — FHIR-native Patient Identity

PIXm và PDQm đều dựa trên FHIR R4 nhưng giải quyết hai hợp đồng khác nhau. PIXm 3.1.0 công bố ITI-83 để truy vấn cross-domain identifier và ITI-104 cho patient identity feed; PDQm 3.2.0 công bố ITI-78 cho demographic query và ITI-119 cho patient match. Việc chọn một hoặc cả hai phụ thuộc actor và use case; VN Core Patient chỉ hỗ trợ cấu trúc dữ liệu Việt Nam, không tự tạo khả năng PIXm/PDQm.

4.9 IPS — International Patient Summary

International Patient Summary là một họ tiêu chuẩn và hướng dẫn cho bản tóm tắt sức khỏe tối thiểu, không phụ thuộc một hệ thống quốc gia cụ thể. Khi tham chiếu cần nêu rõ artifact, chẳng hạn ISO 27269 hoặc HL7 FHIR IPS IG và phiên bản tương ứng. IPS có thể được dùng để phân tích gap cho một use case tóm tắt sức khỏe tại Việt Nam, nhưng Quyết định 1332/QĐ-BYT không vì thế mặc nhiên yêu cầu IPS hay bảo đảm tương thích với VNeID.

4.10 PaLM domain — Pathology and Laboratory Medicine

PaLM không phải một profile mà là một domain, hợp nhất từ Laboratory và Anatomic Pathology trước đây. Các profile tiêu biểu trong PaLM: LTW (Laboratory Testing Workflow), LAW (Laboratory Analytical Workflow), LDA (Laboratory Device Automation), LPOCT (Laboratory Point-of-Care Testing), LCSD (Laboratory Code Set Distribution), LBL (Laboratory Barcode Labeling) và XD-LAB (Sharing Laboratory Reports cross-enterprise). Các transaction LAB-* cũ vẫn còn nhưng được gộp vào các profile này.

5. IHE và FHIR — quan hệ và xu hướng dịch chuyển

IHE công bố nhiều profile dựa trên FHIR R4, trong đó có MHD, PIXm, PDQm, mXDE và QEDm. Chúng cung cấp hợp đồng actor/transaction riêng và thường kế thừa một phần khái niệm từ profile trước đó; không nên mô tả như một lộ trình thay thế bắt buộc hoặc suy ra rằng mọi deployment IHE đang chuyển sang FHIR.

Một deployment có thể dùng MHD như API trước XDS/XCA, dùng độc lập trong một push solution, hoặc chọn profile khác theo requirement. Việc đặt nhiều profile cạnh nhau đòi hỏi mapping metadata, identity, security và error behavior cụ thể; không có profile gateway nào tự bảo đảm dữ liệu lưu thông đúng nghĩa giữa hai kiến trúc.

Bảng so sánh nhanh XDS.b và MHD:

6. Connectathon — testing thực chiến

Connectathon là hoạt động kiểm thử liên nhà cung cấp do các khu vực IHE tổ chức theo lịch công bố từng năm. Hệ thống được thử theo profile, actor và option đã đăng ký; kết quả cần tra trong cơ sở dữ liệu Connectathon Results. IHE Product Registry chủ yếu là nơi nhà cung cấp công bố IHE Integration Statement, nên không được đồng nhất hai loại bằng chứng.

Một điểm thường bị hiểu sai: pass Connectathon không đồng nghĩa với "được chứng nhận compliant". IHE nói rõ Connectathon cung cấp bằng chứng baseline về khả năng tương thích, không phải chứng nhận độc lập về tuân thủ sản phẩm. Trách nhiệm cuối cùng thuộc về nhà cung cấp thông qua văn bản IHE Integration Statement tự công bố. Việc không có pass cũng không tự động đồng nghĩa "không compliant" — nó chỉ có nghĩa là không có bằng chứng test công khai.

Một đội triển khai tại Việt Nam có thể đánh giá Connectathon phù hợp nếu đã xác định actor, profile, option, test partner và tiêu chí pass. Kết quả sự kiện vẫn cần được bổ sung bằng kiểm thử tại site với policy, terminology, volume và security của deployment thực tế.

7. Bối cảnh Việt Nam và khuyến nghị

Snapshot 18/07/2026: trang IHE Worldwide liệt kê 17 quốc gia có national deployment committee và không liệt kê Việt Nam. Corpus pháp lý VN Core cũng chưa ghi nhận văn bản Việt Nam bắt buộc một IHE profile cụ thể. Vì vậy, XDS.b, MHD, PIXm, PDQm, ATNA hoặc SWF chỉ nên được đưa vào hồ sơ kiến trúc/mua sắm khi actor và transaction của chúng khớp use case; bằng chứng cần gồm đúng Technical Framework version, Integration Statement, Connectathon result nếu có, conformance statement liên quan và kiểm thử tại site.

Cách chọn profile theo use case:

• Đánh giá MHD khi cần API FHIR R4 cho publish/query/retrieve tài liệu; đánh giá XDS.b khi cần đầy đủ actor, transaction và policy model của XDS.
• Đánh giá PIXm cho cross-reference identifier và PDQm cho query/match demographic; không coi CCCD là khóa duy nhất nếu use case còn người chưa có số định danh hoặc dữ liệu legacy.
• Đánh giá ATNA theo required grouping và threat model; lập ma trận riêng giữa event IHE, FHIR AuditEvent, log hạ tầng và nghĩa vụ pháp lý.
• Đánh giá SWF/SWF.b ở mức actor/option và đối chiếu với DICOM Conformance Statement của từng sản phẩm.
• Dùng IPS làm một nguồn so sánh cho patient-summary khi phù hợp; không suy ra API hoặc dataset VNeID từ IPS nếu hợp đồng chính thức không quy định.
• Chỉ tham gia Connectathon khi phạm vi test và mục tiêu bằng chứng đã rõ; kết quả không phải credential pháp lý hay chứng nhận toàn sản phẩm.

VN Core có thể được so sánh với các package IHE R4 ở từng use case, nhưng “cùng dùng FHIR R4” không tạo tương thích trực tiếp. Mọi tuyên bố alignment phải chỉ ra dependency/package, canonical, profile mapping, terminology, CapabilityStatement và test case đại diện.

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

IHE có miễn phí không?

Có. Toàn bộ Technical Framework và profile được công bố miễn phí tại profiles.ihe.net. Phí thành viên IHE chỉ áp dụng cho tổ chức muốn tham gia bỏ phiếu kỹ thuật và đăng ký Connectathon.

Phải IHE compliant để mua được phần mềm y tế?

Yêu cầu mua sắm thay đổi theo cơ quan và thị trường. Tại Việt Nam, corpus dự án chưa ghi nhận văn bản pháp lý bắt buộc IHE conformance. Nếu RFP dùng thuật ngữ “IHE compliant”, cần yêu cầu bên mời thầu nêu profile, actor, option, version, Integration Statement và tiêu chí test thay vì dùng một nhãn chung.

IHE thay thế HL7 hay DICOM không?

Không. IHE ràng buộc cách dùng các tiêu chuẩn nền trong một profile. XDS.b dùng ebXML/Web Services cho metadata và coi document content là payload theo chính sách Affinity Domain; một content profile có thể quy định CDA, PDF hoặc định dạng khác. SWF/SWF.b sử dụng các transaction HL7/DICOM được nêu trong đúng phiên bản Technical Framework.

Connectathon có tổ chức ở Việt Nam không?

Theo đợt rà soát 06/2026, chưa có Connectathon nào được ghi nhận công khai tại Việt Nam. Các đội triển khai tại Việt Nam có thể tham gia AP Connectathon hoặc các sự kiện IHE khu vực khi đã có phạm vi kiểm thử rõ.

Khác biệt giữa IHE Profile và FHIR Implementation Guide?

Cả hai đều là tài liệu hướng dẫn áp dụng chuẩn cho use case cụ thể. FHIR IG bám sát hệ sinh thái FHIR (resource, profile, ValueSet) và do HL7 quản lý. IHE Profile rộng hơn — có thể dùng HL7 v2, v3, CDA, FHIR, DICOM, SOAP — và do IHE quản lý. Trong thực tế, các profile mới của IHE (MHD, PIXm) thường được công bố dưới dạng FHIR IG để tận dụng công cụ FHIR.

9. Tài liệu tham khảo và đọc tiếp

Tài liệu tham khảo

• IHE International — trang chủ và lịch sử: ihe.net/about_ihe
• IHE Profile Catalog (toàn bộ profile theo domain): profiles.ihe.net
• IHE ITI Technical Framework Volume 2 — XDS.b transaction ITI-41: profiles.ihe.net/ITI/TF/Volume2/ITI-41
• IHE MHD Implementation Guide (FHIR R4): profiles.ihe.net/ITI/MHD
• IHE PaLM domain: profiles.ihe.net/PaLM
• IHE PCC domain: profiles.ihe.net/PCC
• IHE QRPH domain: profiles.ihe.net/QRPH
• IHE General Introduction — Connectathon disclaimer (Appendix F): profiles.ihe.net/GeneralIntro/ch-F
• HL7 International Patient Summary (FHIR IG): hl7.org/fhir/uv/ips
• Luật 91/2025/QH15 — Bảo vệ dữ liệu cá nhân (hiệu lực 01/01/2026)
• Nghị định 356/2025/NĐ-CP — Hướng dẫn Luật BVDLCN (hiệu lực 01/01/2026)
• Thông tư 13/2025/TT-BYT — Bệnh án điện tử (hiệu lực 21/07/2025)
• Quyết định 1332/QĐ-BYT — Sổ sức khoẻ điện tử trên VNeID

Đọc tiếp trên hl7.org.vn