Bộ Hướng dẫn Triển khai Core FHIR cho Việt Nam - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Ma trận pháp lý theo hồ sơ

Ma trận pháp lý theo hồ sơ

Trang này gom các căn cứ pháp lý theo nhóm hồ sơ FHIR, giúp đơn vị triển khai trả lời nhanh 4 câu hỏi:

1. Hồ sơ này đang dựa trên văn bản nào còn hiệu lực?
2. Có văn bản lịch sử nào cần giữ để chuyển đổi dữ liệu cũ không?
3. Quyết định thiết kế nào của VN Core được rút ra từ các văn bản đó?
4. Khi triển khai HIS, EMR, BHYT hoặc liên thông, cần lưu ý điều gì?

Trang này không thay thế Cơ sở pháp lý.
Cơ sở pháp lý là trang tổng hợp văn bản; còn trang này là lớp diễn giải theo từng nhóm hồ sơ.

Khi cần tra ngày ban hành, ngày hiệu lực pháp lý hoặc mốc áp dụng triển khai của từng văn bản, ưu tiên dùng Cơ sở pháp lý; trang này tập trung vào hệ quả thiết kế theo từng nhóm hồ sơ.

Trang này dành cho ai?

• Nhóm triển khai muốn biết một profile hay nhóm resource đang chịu ràng buộc pháp lý nào.
• Nhóm BA, product owner và reviewer nghiệp vụ cần chuyển từ văn bản pháp lý sang quyết định thiết kế cụ thể.
• Nhóm QA và audit nội bộ cần truy vết quyết định kỹ thuật theo từng nhóm hồ sơ.

Khi nào nên đọc trang này?

• Khi cần trả lời một profile hay một nhóm resource đang bám căn cứ pháp lý hiện hành nào.
• Khi cần tách phần nào là dữ liệu lịch sử/chuyển đổi và phần nào là thiết kế chuẩn mới.
• Khi đang tranh luận xem một ràng buộc là yêu cầu pháp lý, quy ước triển khai hay chỉ là hỗ trợ tương thích ngược.

Sau khi đọc, bạn nên chốt được gì?

• Nhóm hồ sơ nào đang chịu tác động của văn bản nào còn hiệu lực.
• Quyết định thiết kế nào của VN Core được rút ra từ từng nhóm văn bản.
• Khi nào một yêu cầu nên nằm ở resource lõi, ở package riêng, hay chỉ nên nằm ở narrative/gateway layer.

---

0. Chiến lược và kiến trúc số tác động xuyên suốt

0.1. Ma trận pháp lý

Nhóm dữ liệu / kiến trúc	Văn bản hiện hành	Văn bản lịch sử / chuyển đổi	Quyết định thiết kế trong VN Core
Chiến lược chuyển đổi số ngành y tế	QĐ 3516/QĐ-BYT	—	Ưu tiên lấy dữ liệu làm trung tâm, VNeID, EMR/HSSK, LGSP, tái sử dụng dữ liệu và gia cố bảo mật trước khi mở rộng mạnh thêm tài nguyên
Kiến trúc số / Chính phủ số Bộ Y tế	QĐ 4152/QĐ-BYT	QĐ 1928/QĐ-BYT	Định vị VN Core là lớp chuẩn dữ liệu và liên thông cho HIS, EMR, HSSK, gateway và tích hợp API; không coi VN Core là toàn bộ kiến trúc số của Bộ Y tế
Dữ liệu dùng chung và ranh giới tích hợp	QĐ 3516/QĐ-BYT, QĐ 4152/QĐ-BYT	—	Giữ VN Core Base ở vai trò lõi FHIR-native; các gateway layer, payer submission layer, LGSP/API facade và hướng dẫn tái sử dụng dữ liệu được tách khỏi ngữ nghĩa lõi

0.2. Quyết định thiết kế then chốt

• QĐ 3516 ảnh hưởng trực tiếp đến thứ tự ưu tiên roadmap, không chỉ là văn bản tham khảo.
• QĐ 4152 và QĐ 1928 được dùng để hiểu vị trí của VN Core trong kiến trúc số Bộ Y tế, không dùng để viết thẳng cardinality hoặc binding cho từng profile.
• Các trang như CapabilityStatement, Must Support Guidance, General Guidance, Package Architecture và Stability & Conformance phải phản ánh trục lấy dữ liệu làm trung tâm, EMR/HSSK, LGSP và ưu tiên bảo mật.

0.3. Hệ quả triển khai

Tình huống	Cách làm khuyến nghị
Thiết kế API liên thông nhiều hệ thống	Dùng VN Core Base làm hợp đồng dữ liệu, còn LGSP/API facade và logic gateway layer đặt ở lớp triển khai
Muốn mô hình hóa ngay dữ liệu thứ cấp, phân tích, AI	Chỉ mở rộng sau khi ranh giới nghiệp vụ / dùng chung / mở và mức bảo mật cơ sở đã ổn định
Xây thí điểm EMR/HSSK hoặc cổng công dân	Ưu tiên hướng dẫn theo từng vai trò, Composition, DocumentReference, Observation, DiagnosticReport, Consent, AuditEvent, Provenance

0.4. Hồ sơ pháp lý tham chiếu nội bộ

• legal-references/strategy-architecture/QD-3516-QD-BYT-2025-ChienLuocChuyenDoiSoBYT.pdf
• legal-references/strategy-architecture/QD-4152-QD-BYT-2024-SuaDoiQD1928-KienTrucCPDT-BYT.pdf
• legal-references/strategy-architecture/QD-1928-QD-BYT-2023-KienTrucCPDT-BYT-v2.1.pdf

---

1. Patient và RelatedPerson

1.1. Ma trận pháp lý

Nhóm dữ liệu	Văn bản hiện hành	Văn bản lịch sử / chuyển đổi	Quyết định thiết kế trong VN Core
Định danh cá nhân	Luật Căn cước 2023, TT 17/2024/TT-BCA	NĐ 137/2015/NĐ-CP	CCCD là định danh cá nhân hiện hành; CMND chỉ còn để liên thông dữ liệu lịch sử
Địa chỉ hành chính	NQ 202/2025/QH15, QĐ 19/2025/QĐ-TTg	NĐ 104/2022/NĐ-CP, danh mục ĐVHC cũ	Mô hình địa chỉ theo 34 tỉnh/thành và cấp xã/phường; Dữ liệu quận/huyện chỉ giữ để tương thích dữ liệu cũ
Dân tộc, tôn giáo, nghề nghiệp	121/TCTK-PPCĐ, CV 6955/BNV-TGCP, QĐ 34/2020/QĐ-TTg	—	Dùng bộ mã cục bộ có căn cứ pháp lý rõ; không dùng text tự do làm chuẩn mặc định
Quyền riêng tư và dữ liệu nhạy cảm	Luật 91/2025/QH15, NĐ 356/2025/NĐ-CP	—	Định danh, địa chỉ, dữ liệu lâm sàng đều phải đi theo hướng bảo vệ dữ liệu cá nhân
Bệnh nhân trẻ em / người đại diện	TT 13/2025/TT-BYT, Luật BHYT, Luật Căn cước 2023	—	Ưu tiên mô hình chuẩn RelatedPerson và Patient.contact; không tạo extension riêng khi FHIR base đã đủ

1.2. Quyết định thiết kế then chốt

• Patient.identifier[CCCD] là trục định danh hiện hành.
• Patient.identifier[CMND] chỉ còn phục vụ dữ liệu lịch sử.
• Địa chỉ dùng state + vn-ext-province + vn-ext-ward; district không còn là lớp chính thức.
• Với trẻ em hoặc ca bất khả kháng chưa có CCCD, dùng data-absent-reason và lý do hợp lệ theo profile.
• Cha, mẹ, người giám hộ, người đại diện không được nhét vào Patient bằng văn bản tự do nếu quy trình cần liên thông máy đọc được.

1.3. Hệ quả triển khai

Tình huống	Cách làm khuyến nghị
HIS còn lưu cả CCCD và CMND	Giữ riêng từng loại định danh bằng system và lát cắt tương ứng
Hệ thống cũ chỉ lưu huyện/quận	Vẫn chuyển được sang FHIR, nhưng cần điền thêm tỉnh/xã hiện hành khi có thể
Hồ sơ trẻ em chưa có CCCD	Dùng GKS, BHXH, BHYT, RelatedPerson, và quy tắc thiếu dữ liệu có giải trình

1.4. Hồ sơ pháp lý tham chiếu nội bộ

• legal-references/demographics/Luat-26-QH15-2023-CanCuoc.pdf
• legal-references/demographics/TT-17-TT-BCA-2024-LuatCanCuoc.pdf
• legal-references/administrative/NQ-202-QH15-2025-SapXepDVHC.pdf
• legal-references/administrative/QD-19-QD-TTg-2025-DanhMucDVHC.pdf
• legal-references/demographics/121-TCTK-PPCD-DanhMucDanToc.docx

---

2. Practitioner, Organization và Location

2.1. Ma trận pháp lý

Nhóm dữ liệu	Văn bản hiện hành	Văn bản lịch sử / chuyển đổi	Quyết định thiết kế trong VN Core
Định danh hành nghề	Luật KCB 2023, NĐ 96/2023	Luật KCB 2009, hồ sơ CCHN cũ	GPHN là định danh hành nghề hiện hành; CCHN chỉ giữ cho dữ liệu lịch sử
Trình độ, chức danh nghề nghiệp	TT 41/2025/TT-BYT, TT 02/2025/TT-BYT, TT 11/2024/TT-BYT	—	qualification giữ vai trò trình độ/chức danh; không dùng chung một trường text cho mọi khái niệm
Hạng pháp lý của cơ sở y tế	TT 06/2024/TT-BYT	—	Tách organizationRank cho cơ sở KCB và healthUnitRank cho đơn vị y tế không phải cơ sở KCB
Cấp KCB hiện hành	Luật KCB 2023, NĐ 96/2023	—	facilityCareLevel phản ánh mô hình 3 cấp hiện hành
Tuyến chuyên môn kỹ thuật lịch sử	TT 43/2013/TT-BYT	TT 23/2024/TT-BYT xác nhận hết hiệu lực	Tạo lớp legacyTechnicalLine riêng, không trộn với cấp KCB hiện hành
Địa điểm cung cấp dịch vụ	Luật KCB 2023, TT 13/2025/TT-BYT	—	Location tách khỏi Organization; không gán hạng pháp lý cho mọi Location

2.2. Quyết định thiết kế then chốt

• Người hành nghề dùng GPHN là định danh hiện hành.
• CCHN không bị xóa khỏi mô hình, nhưng bị hạ xuống vai trò liên thông dữ liệu lịch sử.
• organizationRank, healthUnitRank, organizationRankStatus, facilityCareLevel, organizationLevel, legacyTechnicalLine là các khái niệm độc lập.
• Location dùng để mô hình hóa khoa, phòng, buồng, điểm lấy mẫu, quầy tiếp nhận, phòng khám.

2.3. Hệ quả triển khai

Tình huống	Cách làm khuyến nghị
Hệ thống cũ chỉ có số CCHN	Vẫn đưa vào FHIR, nhưng phải gắn đúng lát cắt CCHN; không gắn nhầm là GPHN
TTYT hoặc đơn vị dự phòng có hạng IV	Dùng healthUnitRank; không dùng organizationRank của cơ sở KCB
Dữ liệu cũ còn lưu tuyến 1-4	Giữ ở legacyTechnicalLine; không dùng thay cho cấp KCB hiện hành
Muốn mô tả phòng khám/điểm lấy mẫu	Dùng Location, không tạo nhiều Organization con chỉ để biểu diễn vị trí

2.4. Hồ sơ pháp lý tham chiếu nội bộ

• legal-references/kcb/Luat-15-QH15-2023-KCB-CongBao.pdf
• legal-references/kcb/ND-96-ND-CP-2023-ChiTietLuatKCB.pdf
• legal-references/kcb/TT-06-TT-BYT-2024-XepHangDonViSuNghiepYTe.pdf
• legal-references/kcb/TT-43-TT-BYT-2013-CongBao-51-52.pdf
• legal-references/practitioner/TT-41-TT-BYT-2025-ChucDanhBacSi-YSi.pdf
• legal-references/practitioner/TT-02-TT-BYT-2025-ChucDanhDieuDuong-HoSinh-KTV.pdf

---

3. Composition, DocumentReference và DiagnosticReport

3.1. Ma trận pháp lý

Nhóm dữ liệu	Văn bản hiện hành	Văn bản lịch sử / chuyển đổi	Quyết định thiết kế trong VN Core
Bệnh án điện tử và hồ sơ điện tử	TT 13/2025/TT-BYT, NĐ 137/2024/NĐ-CP	TT 46/2018/TT-BYT, QĐ 4069/2001/QĐ-BYT	Composition là tài liệu cấu trúc; DocumentReference là bản ghi tài liệu/đính kèm; hồ sơ giấy cũ chỉ dùng để ánh xạ chuyển đổi
Chữ ký số, chuyển đổi giấy ↔ điện tử	NĐ 137/2024/NĐ-CP	—	Provenance và chính sách chữ ký đi kèm lớp tài liệu
Kết quả cận lâm sàng	QĐ 1227/QĐ-BYT, các bộ thuật ngữ SNOMED CT VN	TT 54/2015/TT-BYT không dùng làm căn cứ cho HL7	DiagnosticReport là lớp báo cáo kết quả; Observation giữ từng chỉ số
Dữ liệu nhạy cảm và chia sẻ tài liệu	Luật 91/2025/QH15, NĐ 356/2025/NĐ-CP	—	Consent, AuditEvent, Provenance là lớp đi kèm, không tách khỏi luồng tài liệu
Tích hợp với Sổ sức khỏe điện tử	QĐ 1332/QĐ-BYT	—	DocumentReference là điểm tự nhiên để công bố/trao đổi tài liệu cho kênh công dân

3.2. Quyết định thiết kế then chốt

• Không dùng DocumentReference để thay thế toàn bộ ý nghĩa của Composition.
• Composition dành cho tài liệu có cấu trúc, tác giả, tiêu đề, phần mục và ngữ nghĩa hồ sơ.
• DiagnosticReport không thay cho DocumentReference; nếu có file PDF kết quả thì đi song song với DocumentReference.
• Chữ ký, nguồn gốc tạo lập, chính sách chia sẻ nằm ở lớp Provenance và Consent.

3.3. Hệ quả triển khai

Tình huống	Cách làm khuyến nghị
Bệnh viện chỉ có file PDF giấy ra viện	Dùng DocumentReference; nếu về sau có cấu trúc đầy đủ thì bổ sung Composition
LIS trả về nhiều chỉ số xét nghiệm và một phiếu tổng hợp	Mỗi chỉ số là Observation; phiếu tổng hợp là DiagnosticReport; file đính kèm nếu có thì là DocumentReference
HIS đang bám mẫu bệnh án giấy cũ	Dùng các mẫu cũ làm nguồn ánh xạ chuyển đổi, không lấy đó làm ngữ nghĩa chuẩn mới

3.4. Hồ sơ pháp lý tham chiếu nội bộ

• legal-references/emr/TT-13-TT-BYT-2025-BenhAnDienTu.pdf
• legal-references/emr/ND-137-ND-CP-2024-GiaoDichDienTu.pdf
• legal-references/emr/QD-4069-QD-BYT-2001-MauHoSoBenhAn.doc
• legal-references/clinical-terminology/QD-1227-QD-BYT-2025-DanhMucChiSoCLS.pdf
• legal-references/other/QD-1332-QD-BYT-SoSKDT-VNeID.pdf

---

4. Coverage, Claim, ExplanationOfBenefit và liên thông hồ sơ BHYT

4.1. Ma trận pháp lý

Nhóm dữ liệu	Văn bản hiện hành	Văn bản lịch sử / chuyển đổi	Quyết định thiết kế trong VN Core
Quyền lợi và định danh BHYT	Luật BHYT 2008, Luật 51/2024/QH15, NĐ 188/2025/NĐ-CP, NĐ 74/2025/NĐ-CP	—	Coverage hỗ trợ 3 format thẻ BHYT và mô hình người thụ hưởng / người đại diện
Giao dịch điện tử BHXH	NĐ 164/2025/NĐ-CP	—	Lớp liên thông hồ sơ thanh toán BHYT (BHYT Submission) giữ logic gateway layer, tra cứu, gửi hồ sơ và thu hồi
Chuẩn dữ liệu KCB phục vụ BHXH	QĐ 130/QĐ-BYT, QĐ 4750/QĐ-BYT, QĐ 3176/QĐ-BYT	QĐ 4210/QĐ-BYT	Mô hình resource lõi đi theo FHIR; XML/gateway layer được tách riêng bằng logical model và operation
Bảng kê và thanh toán	QĐ 697/QĐ-BYT, TT 12/2026/TT-BTC	QĐ 6556/QĐ-BYT	Claim, ExplanationOfBenefit, bundle submission và round-trip mapper bám bộ quy định hiện hành; riêng mốc chuyển đổi triển khai biểu mẫu mới được theo dõi tách biệt với hiệu lực pháp lý của QĐ 697
Mã đối tượng và mã dùng chung	QĐ 3276/QĐ-BYT, QĐ 2010/QĐ-BYT	các danh mục cũ rời rạc	Thuật ngữ payer nằm ở lớp riêng, gắn rõ provenance pháp lý

4.2. Quyết định thiết kế then chốt

• Không làm méo Coverage, Claim, ExplanationOfBenefit chỉ để bắt chước XML cũ.
• QĐ 4210 chỉ còn vai trò dữ liệu lịch sử và chuyển đổi.
• Lớp liên thông hồ sơ thanh toán BHYT (BHYT Submission) là lớp độc lập với VN Core Base.
• MA_LK, bảng XML, validate/submit/reverse là ngữ nghĩa của lớp liên thông hồ sơ BHYT, không áp trực tiếp lên mọi resource lõi.

4.3. Hệ quả triển khai

Tình huống	Cách làm khuyến nghị
Hệ thống đang dùng XML cũ	Giữ lớp chuyển đổi riêng; không hardcode XML field vào resource lâm sàng
Trẻ em hoặc người phụ thuộc	Phải phân biệt beneficiary, subscriber, relationship; không dùng một mẫu coverage cho mọi tình huống
Gửi dữ liệu lên cổng BHXH	Kiểm tra cả lớp profile FHIR, lớp quy tắc Tier 2 và round-trip/export layer trước khi gửi hồ sơ

4.4. Hồ sơ pháp lý tham chiếu nội bộ

• legal-references/insurance/Luat-51-QH15-2024-SuaDoiLuatBHYT.pdf
• legal-references/insurance/ND-188-ND-CP-2025-HuongDanLuatBHYT.pdf
• legal-references/insurance/ND-164-ND-CP-2025-GiaoDichDienTuBHXH.pdf
• legal-references/insurance/QD-130-QD-BYT-2023-ChuanDuLieuKCB.pdf
• legal-references/insurance/QD-3176-QD-BYT-2024-ChuanDuLieuKCB.pdf
• legal-references/insurance/QD-4210-QD-BYT-2017-ChuanDuLieuBHXH.pdf
• legal-references/insurance/QD-697-QD-BYT-2026-MauBangKeChiPhiKCB.pdf
• legal-references/insurance/TT-12-TT-BTC-2026-GiamDinhBHYT.pdf

---

5. Cách dùng ma trận này trong triển khai

• Dùng khi quyết định một ràng buộc là bắt buộc pháp lý, quy ước triển khai, hay hỗ trợ dữ liệu lịch sử.
• Dùng khi cần giải thích với đơn vị triển khai vì sao VN Core tách VN Core Base khỏi lớp liên thông hồ sơ BHYT (BHYT Submission).
• Dùng khi rà soát một thay đổi mới xem có làm lệch ngữ nghĩa hiện hành hay không.

Nếu một thay đổi mới:

1. Không có căn cứ pháp lý hiện hành rõ;
2. Chỉ phục vụ một hệ thống nguồn cụ thể;
3. Hoặc làm lẫn lộn dữ liệu hiện hành với dữ liệu lịch sử,

thì thay đổi đó không nên đi thẳng vào lõi quốc gia.

---

English Summary

This page reorganizes Vietnamese legal references by FHIR domain instead of by document. It now also includes a cross-cutting strategy and architecture section covering Decision 3516/QD-BYT and Decision 4152/QD-BYT, because these decisions affect roadmap order, package boundaries, and implementation guidance rather than only individual resource constraints. The matrix then shows which laws and regulations directly govern Patient and RelatedPerson, Practitioner/Organization/Location, clinical documents and reports, and the health-insurance submission layer. For each domain, it distinguishes current law from legacy conversion references and documents the design decisions that VN Core adopts as a result.