Liên thông dữ liệu y tế: vì sao Việt Nam cần chuẩn hóa?

1. Bài toán liên thông dữ liệu y tế qua 5 tình huống minh họa

Các tình huống dưới đây minh họa những dạng gián đoạn dữ liệu có thể phát sinh khi hệ thống thiếu hợp đồng trao đổi chung; chúng không phải số liệu khảo sát về tần suất trên toàn quốc.

Tình huống 1 — Bà Lan và hành trình ba bệnh viện

Bà Lan đi qua ba cơ sở khám chữa bệnh: tuyến trung ương phát hiện bệnh, tuyến chuyên khoa điều trị, tuyến tỉnh theo dõi. Mỗi nơi cấp một bộ hồ sơ giấy kèm đĩa CD chứa ảnh DICOM. Bác sĩ tuyến sau không có thời gian đọc lại ba mươi trang bệnh án viết tay từ tuyến trước, nên hỏi lại từ đầu. Một số xét nghiệm máu cơ bản bị chỉ định lại vì kết quả cũ đã quá hai tuần và không có cách tra cứu nhanh. Bệnh nhân tốn tiền, tốn thời gian, và tệ hơn, có nguy cơ điều trị trên cơ sở thiếu thông tin.

Tình huống 2 — Cấp cứu lúc nửa đêm

Một bệnh nhân nam được đưa vào khoa cấp cứu của một bệnh viện tuyến cuối trong tình trạng bất tỉnh sau tai nạn giao thông. Bác sĩ trực không có cách nào biết được người này đã từng dị ứng kháng sinh nhóm beta-lactam tại một bệnh viện khác cách đây hai năm hay chưa. Kíp trực phải quyết định dựa trên thông tin hiện có và phác đồ phù hợp. Một dịch vụ tóm tắt sức khỏe được ủy quyền có thể hỗ trợ quyết định lâm sàng nếu dữ liệu kịp thời, đúng người bệnh và có kiểm soát truy cập; kết nối VNeID chỉ là kiến trúc tham chiếu cho tới khi có đặc tả API và quy trình chính thức.

Tình huống 3 — Đối soát BHYT

Cùng một xét nghiệm cholesterol toàn phần có thể được mã hóa bằng các tên gọi khác nhau ở hai bệnh viện khác nhau, vì mỗi nơi có thể duy trì danh mục dịch vụ kỹ thuật nội bộ riêng. Danh mục chuẩn và payload được kiểm tra có thể giảm sai khác khi đối soát. Giao dịch BHYT hiện vẫn dùng chuẩn dữ liệu đầu ra theo văn bản hiện hành; FHIR có thể làm mô hình nội bộ hoặc lớp mapping, không thay thế quy trình giám định pháp lý.

Tình huống 4 — Đại dịch COVID-19 và bài học dữ liệu

Giai đoạn 2021 cho thấy nhu cầu tổng hợp nhanh dữ liệu ca bệnh, tiếp xúc và tiêm chủng từ nhiều nguồn. Một chuẩn chung có thể giảm mapping lặp lại, nhưng triển khai Bulk Data vẫn cần profile, terminology, endpoint, bảo mật, hạ tầng và kiểm thử; không chỉ là thay đổi cấu hình.

Tình huống 5 — Nghiên cứu AI đa trung tâm

Nhóm AI đa trung tâm thường gặp định dạng ECG theo hãng, quy trình chia sẻ và chất lượng dữ liệu khác nhau. FHIR Bulk Data có thể chuẩn hóa một phần lớp trao đổi khi các bên thống nhất profile và quyền sử dụng; dữ liệu tín hiệu gốc, cơ sở pháp lý, khử định danh và ETL vẫn cần xử lý riêng.

2. Năm lý do cần liên thông dữ liệu y tế

Năm tình huống ở trên gợi ra năm nhóm lợi ích tiềm năng. Tác động thực tế cần được đánh giá bằng đường cơ sở và KPI phù hợp với từng chương trình triển khai.

2.1. Chất lượng và an toàn cho người bệnh

Khi bác sĩ tiếp nhận được quyền truy cập phù hợp vào tóm tắt sức khỏe — gồm chẩn đoán hiện hành, thuốc đang dùng, dị ứng đã ghi nhận và kết quả xét nghiệm gần nhất — thông tin đó có thể hỗ trợ quyết định lâm sàng. Hệ thống có thể cảnh báo tương tác thuốc, hỗ trợ kiểm tra liều theo chức năng thận hoặc hiển thị xét nghiệm gần đây; hiệu quả phụ thuộc vào độ đầy đủ, tính kịp thời, chất lượng dữ liệu và cách tích hợp vào quy trình chăm sóc.

2.2. Hiệu quả vận hành bệnh viện

Một cơ sở có thể vận hành đồng thời HIS, LIS, RIS, hệ thống dược, thanh toán và các module chuyên khoa. Một IG dùng chung có thể hỗ trợ kiến trúc hub-and-spoke hoặc các mô hình tích hợp khác và giảm mapping riêng khi các hệ thống cùng tuân thủ một hợp đồng dữ liệu. Kiến trúc, chi phí bảo trì, thời gian tích hợp và rủi ro phụ thuộc nhà cung cấp không tự động thay đổi chỉ vì sử dụng FHIR.

2.3. Đối soát và thanh toán BHYT

Thuật ngữ thống nhất và mô hình dữ liệu nội bộ được kiểm tra có thể hỗ trợ quy tắc tự động và mapping sang hồ sơ gửi BHYT. Tuy nhiên, dữ liệu đầu ra phục vụ giám định, thanh toán BHYT vẫn phải theo chuẩn và quy trình pháp lý hiện hành; FHIR Bundle không mặc nhiên là hồ sơ thay thế. Tác động đến thời gian thanh toán, chi phí đối soát hoặc sai lệch cần được đo trong từng chương trình.

2.4. Y tế công cộng và báo cáo dịch tễ

Luật Phòng bệnh số 114/2025/QH15 (hiệu lực từ 01/07/2026) đặt yêu cầu về quản lý tiêm chủng, giám sát bệnh truyền nhiễm và báo cáo tình huống y tế công cộng. Định nghĩa dữ liệu chung và interface đã kiểm thử có thể cải thiện tính kịp thời và nhất quán của báo cáo; độ trễ thực tế còn phụ thuộc quy tắc báo cáo, chất lượng dữ liệu, hạ tầng và năng lực vận hành.

2.5. Đổi mới sáng tạo: AI, nghiên cứu, khởi nghiệp

AI y tế phụ thuộc vào chất lượng, tính đại diện, cơ sở pháp lý và quản trị dữ liệu. FHIR có thể cấu trúc lớp trao đổi nhưng không tự thực hiện khử định danh, quản lý đồng ý, phân quyền hoặc đánh giá mục đích sử dụng. Nghiên cứu đa trung tâm vẫn cần hài hòa dữ liệu nguồn, kiểm soát thiên lệch và chuyển đổi phục vụ phân tích.

3. Khung pháp lý đang thúc đẩy chuẩn hóa

Các văn bản giai đoạn 2025–2026 tạo nghĩa vụ liên quan đến bệnh án điện tử, kết nối cơ sở dữ liệu và bảo vệ dữ liệu cá nhân. Phạm vi áp dụng của từng văn bản khác nhau; các nghĩa vụ này không mặc nhiên công nhận FHIR hoặc VN Core là chuẩn quốc gia.

Ngoài bốn văn bản trên, Quyết định 1332/QĐ-BYT đặt nền cho Sổ Sức khỏe điện tử trên VNeID như một kênh cung cấp thông tin sức khỏe cho người dân. Danh mục pháp lý mà dự án theo dõi được duy trì trong CodeSystem VNLegalDocumentRefCS của VN Core IG và xuất bản tại trang khung pháp lý.

4. Đánh giá HL7 FHIR so với xây mới

Một câu hỏi hợp lý: nếu Việt Nam đã có XML 4210 cho dữ liệu BHXH, có thể mở rộng định dạng đó cho các nhu cầu liên thông rộng hơn không? XML 4210 được thiết kế cho dữ liệu đầu ra phục vụ BHXH; cấu trúc hiện hành không mô hình hóa đầy đủ các luồng như tóm tắt sức khỏe, điều phối chăm sóc, đơn thuốc điện tử hay báo cáo dịch tễ thời gian thực.

HL7 FHIR R4 (4.0.1) định nghĩa 146 Resource thuộc các nhóm hành chính, lâm sàng, workflow và tài chính; một nhóm artifact đã đạt Normative, phần còn lại vẫn ở mức STU/trial-use. Con số 146 không đồng nghĩa FHIR tự động đáp ứng mọi use case: vẫn cần Profile, Extension, terminology và quy tắc workflow. Năm khía cạnh cần đánh giá gồm:

• Nguồn tham chiếu quốc tế: Nhiều quốc gia và khu vực công bố IG công khai, gồm US Core, AU Core, JP Core, KR Core và CH Core. Phạm vi và trạng thái governance của từng IG khác nhau, nhưng chúng cung cấp mẫu để đối chiếu kỹ thuật.
• Đặc tả và công cụ triển khai: FHIR được công bố theo CC0; HAPI FHIR và Firely .NET SDK là các triển khai mã nguồn mở. Điều này giảm chi phí khởi đầu nhưng không loại bỏ chi phí vận hành, bảo mật, terminology và kiểm thử conformance.
• Mẫu tích hợp web: FHIR hỗ trợ REST và JSON; OAuth 2.0 hoặc SMART on FHIR có thể được áp dụng khi IG và endpoint yêu cầu. Tích hợp VNeID còn phụ thuộc đặc tả API chính thức, quyền truy cập và thỏa thuận vận hành.
• Khả năng chuyển đổi nhà cung cấp: Một hợp đồng dữ liệu chung có thể giảm mapping riêng nếu các bên dùng cùng IG, phiên bản, terminology và vượt qua conformance test. FHIR tự thân không loại bỏ rủi ro migration hoặc vendor lock-in.
• Nỗ lực chuẩn hóa tại Việt Nam đã khởi động: Bên cạnh bản VN Core R4 do Cục Công nghệ thông tin Bộ Y tế công bố năm 2024 tại canonical http://fhir.ehealth.gov.vn/core/, Omi HealthTech đang công bố bộ artifact VN Core trial-use tại http://fhir.hl7.org.vn/core/ như một đóng góp mở để đối chiếu kỹ thuật qua Working Group quốc gia và quyết định governance chính thức.

Mỗi phương án cần được đánh giá theo bối cảnh. Xây một chuẩn riêng làm phát sinh chi phí quản trị phiên bản, terminology, tooling và kiểm thử; XML 4210 tiếp tục phù hợp với giao dịch BHYT trong phạm vi pháp lý hiện hành; HL7 v3 và openEHR giải quyết các bài toán khác với trade-off riêng. FHIR là một ứng viên cho lớp trao đổi, nhưng quyết định phải dựa trên use case, IG đích, năng lực endpoint, chi phí chuyển đổi và bằng chứng thử nghiệm đầu-cuối.

5. Phản biện 4 lý lẽ thường gặp ở bệnh viện

Bốn câu hỏi dưới đây phản ánh các cân nhắc hợp lý về phạm vi, chi phí, thời điểm và tác động tới người dùng. Câu trả lời cần được kiểm chứng theo hiện trạng từng cơ sở và nghĩa vụ pháp lý áp dụng, thay vì dùng một kết luận chung cho mọi bệnh viện.

"Bệnh viện chúng tôi đã có EMR rồi, cần gì thêm?"

EMR (bệnh án điện tử) và liên thông là hai lớp khác nhau. EMR là dữ liệu lâm sàng được lưu điện tử trong nội bộ một cơ sở khám chữa bệnh; liên thông là khả năng dữ liệu đó di chuyển an toàn ra ngoài đến tuyến khác, cơ quan bảo hiểm hoặc người bệnh. Điều 1 khoản 3 TT 13/2025/TT-BYT yêu cầu kết nối thông tin bệnh án với số định danh cá nhân của công dân Việt Nam và của người nước ngoài đã được cấp tài khoản định danh điện tử; điều khoản này không quy định tài khoản VNeID như một lựa chọn thay cho số định danh. FHIR là một lớp trao đổi mà VN Core trial-use đề xuất để kiểm thử yêu cầu kết nối; đây chưa phải tuyên bố công nhận quốc gia.

"Đầu tư FHIR rất đắt, bệnh viện nhỏ không kham nổi"

Chi phí phụ thuộc vào phạm vi Resource, chất lượng dữ liệu nguồn, yêu cầu an toàn thông tin, terminology, lưu lượng và mô hình vận hành. Phần mềm mã nguồn mở có thể giảm phí bản quyền nhưng vẫn cần hạ tầng, nhân sự, kiểm thử, giám sát và hỗ trợ sự cố. Bệnh viện nên lập dự toán theo nhiều kịch bản và thực hiện proof of concept trước khi cam kết ngân sách production.

"Cứ chờ Bộ Y tế ra chuẩn quốc gia hoàn chỉnh rồi làm"

Bộ Y tế là cơ quan có thẩm quyền ban hành hoặc công nhận chuẩn quốc gia; trong khi chờ định hướng chính thức, VN Core IG bản trial-use có thể dùng làm tài liệu tham khảo. Bệnh viện có thể làm sạch danh mục thuốc, dịch vụ kỹ thuật và chẩn đoán theo ICD-10 VN; tách dữ liệu nhân khẩu khỏi dữ liệu lâm sàng; và thử xuất Patient, Encounter trong sandbox. Nếu một chuẩn quốc gia được phê duyệt, khối lượng căn chỉnh sẽ phụ thuộc vào chênh lệch profile, terminology, API contract và chất lượng dữ liệu, nên không thể cam kết một thời gian cố định.

"Bác sĩ không quan tâm đến mã chuẩn"

Đúng — và họ không cần phải quan tâm. Một bác sĩ tim mạch không cần biết SNOMED CT mã nào ứng với "tăng huyết áp nguyên phát"; bác sĩ chỉ cần một giao diện EMR hiển thị đúng từ tiếng Việt và cho phép chọn nhanh. Chuẩn thuật ngữ là việc của tầng dưới — nhà cung cấp EMR và đội tích hợp dữ liệu. Trải nghiệm bác sĩ vẫn là tiếng Việt, gõ phím nhanh, gợi ý thông minh; nhưng phía sau, hệ thống đã ghi mã chuẩn để liên thông được với phần còn lại của ngành y tế.

6. Lộ trình theo cổng kiểm soát cho bệnh viện

Đây là trình tự tham chiếu, không phải cam kết tiến độ. Mỗi bệnh viện phải đặt lịch theo nghĩa vụ pháp lý áp dụng, phạm vi dự án, chất lượng dữ liệu, năng lực nhà cung cấp và kết quả nghiệm thu của giai đoạn trước.

Lộ trình chi tiết hơn cho vai trò CIO, kèm checklist KPI và rủi ro thường gặp, có tại trang Cho CIO bệnh viện.

7. Đọc tiếp