Hướng dẫn triển khai FHIR cốt lõi Việt Nam — VN Core FHIR Implementation Guide
0.9.0 - Draft for Community Review
Hướng dẫn triển khai FHIR cốt lõi Việt Nam — VN Core FHIR Implementation Guide - Draft for Community Review (v0.9.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Mức nền tối thiểu cho quyền riêng tư, bảo mật và quản trị dữ liệu khi triển khai VN Core gồm 3 lớp: nền tảng pháp lý, kiểm soát kỹ thuật và vận hành theo vai trò triển khai.
Lưu ý pháp lý: Luật Bảo vệ dữ liệu cá nhân (91/2025) và Nghị định 356/2025/NĐ-CP có hiệu lực từ 01/01/2026. VN Core cung cấp hướng dẫn kỹ thuật để hỗ trợ tuân thủ, nhưng không thay thế tư vấn pháp lý hoặc quyết định vận hành của từng đơn vị.
| FHIR element | Dữ liệu | Ghi chú |
|---|---|---|
Patient.name |
Họ và tên | |
Patient.birthDate |
Ngày sinh | |
Patient.identifier[CCCD] |
Số CCCD | Định danh cá nhân lõi |
Patient.telecom |
Số điện thoại, email | |
Patient.address |
Nơi cư trú | |
Patient.identifier[HC] |
Số hộ chiếu | Slice VN Core cho passport |
Dữ liệu về sức khỏe và thông tin đời tư được ghi trong hồ sơ bệnh án thuộc dữ liệu cá nhân nhạy cảm. Đơn vị triển khai phải phân loại từng tập dữ liệu theo nội dung, mục đích xử lý và phạm vi pháp luật áp dụng. Các nhóm resource thường có rủi ro trực tiếp gồm:
| Resource | Ví dụ dữ liệu nhạy cảm | Hệ quả thiết kế |
|---|---|---|
Condition |
Chẩn đoán, bệnh sử | Cần kiểm soát truy cập và kiểm toán ở mức cao |
Observation |
Kết quả xét nghiệm, sinh hiệu | Cần bảo vệ khi truyền, khi lưu và khi chia sẻ |
AllergyIntolerance |
Tiền sử dị ứng | Không mở mặc định ngoài phạm vi đã công bố |
Procedure |
Thủ thuật, phẫu thuật | Cần provenance và kiểm soát hiển thị phù hợp |
Coverage |
Thông tin BHYT | Liên quan cả dữ liệu y tế lẫn dữ liệu hướng đến bên thanh toán |
Encounter |
Lịch sử khám bệnh | Phải có chính sách truy cập và thời hạn lưu giữ rõ |
NĐ 356/2025/NĐ-CP cũng làm tăng yêu cầu với dữ liệu VNeID, hình ảnh CCCD và lịch sử giao dịch khi chúng đi kèm dữ liệu y tế.
| Quyền | Diễn giải trong ngữ cảnh VN Core |
|---|---|
| Quyền được biết | Phải công bố ai xử lý dữ liệu, mục đích và phạm vi truy cập |
| Quyền đồng ý | Khi đồng ý là căn cứ hoặc quyền được thực hiện trong use case, cần cơ chế ghi nhận có thể truy xuất; không suy ra mọi xử lý dữ liệu y tế đều dựa trên consent |
| Quyền truy cập | Chỉ mở đúng tập dữ liệu đã công bố và đúng actor |
| Quyền chỉnh sửa | Có quy trình sửa dữ liệu và hậu kiểm thay đổi |
| Quyền xóa / ngừng xử lý | Không diễn giải máy móc thành FHIR delete; có thể là ngừng chia sẻ, ẩn truy cập hoặc xóa theo policy áp dụng |
| Quyền hạn chế xử lý | Phải phản ánh được ở policy và khi cần thì ở Consent.provision |
| Quyền khiếu nại | Ngoài phạm vi FHIR, nhưng phải có đầu mối và quy trình vận hành |
Từ 0.8.0, quyền truy cập của người đại diện tách làm hai trục rõ ràng:
vn-ext-representation-authority (type/source/verifiedDate/period) trên RelatedPerson xác nhận ai có thẩm quyền đại diện (Luật 91/2025/QH15 Điều 24 khoản 2, Bộ luật Dân sự 2015). Token KHÔNG mang ngữ nghĩa hạn chế dữ liệu.VNCoreConsent.provision: permit theo lớp dữ liệu + provision con type=deny với securityLabel (bind vn-data-sensitivity-class-vs) cho slice actor[representative] — actor này gắn CHÍNH extension token tại chỗ, tạo liên kết token↔consent để Policy Decision Point (PDP) resolve một chiều.Chính sách triển khai do VN Core khuyến nghị, không phải ràng buộc mặc định của FHIR R4: áp dụng deny-by-default tại PDP — không có provision permit phủ actor, purpose và lớp dữ liệu thì từ chối; token hết hạn (period) hoặc quan hệ mâu thuẫn với nguồn định danh có thẩm quyền thì từ chối. Với lớp special-protection (sức khỏe sinh sản, tâm thần hoặc HIV của vị thành niên), nên từ chối truy cập đại diện trừ khi có provision permit tường minh và căn cứ phù hợp. Phạm vi sự kiện truy cập thay cần ghi log phải được xác định trong threat model, legal analysis và policy. Khi trao đổi quyết định Điều 19 bằng FHIR, VNCoreAuditEventLegalBasisDecision bắt buộc mang vn-ext-processing-legal-basis; lần truy cập/tiết lộ thực tế được ghi bằng AuditEvent tiếp theo. Integration contract không trao đổi FHIR vẫn có thể dùng hồ sơ nội bộ tương đương nếu bảo toàn được cùng thông tin và khả năng hậu kiểm.
Chi tiết danh mục pháp lý xem tại Cơ sở pháp lý.
user, patient và system.system/*.* nếu chỉ cần một tập quyền hẹp hơn.VNCoreConsent chỉ biểu diễn lựa chọn hoặc chỉ thị của chủ thể dữ liệu hay người đại diện hợp pháp: đồng ý, từ chối, rút lại hoặc giới hạn phạm vi xử lý/chia sẻ. Không tạo Consent mới để ghi một hoạt động xử lý không dựa trên sự đồng ý theo Luật 91/2025/QH15 Điều 19 khoản 1. Từ VN Core 0.9, extension[processingLegalBasis] bị cấm khi authoring VNCoreConsent; context Consent của extension chỉ được giữ tạm để đọc dữ liệu legacy 0.8 và dự kiến gỡ ở 1.0.
Khi áp dụng Điều 19 khoản 1, VN Core tách các carrier kỹ thuật sau. Đây là mô hình triển khai của IG, không phải một representation FHIR duy nhất do pháp luật ấn định.
| Thông tin/sự kiện | Cách biểu diễn VN Core |
|---|---|
| Quyết định cho phép hoặc từ chối theo căn cứ pháp lý | VNCoreAuditEventLegalBasisDecision, subtype legal-basis-authorization, extension processingLegalBasis, outcome, actor, URI điều luật/chính sách và evidence |
| Truy cập hoặc tiết lộ thực tế | Một VNCoreAuditEvent thứ hai, subtype legal-basis-access, liên kết tới quyết định |
| Tạo, sửa hoặc dẫn xuất dữ liệu | VNCoreProvenance có cùng căn cứ pháp lý khi hoạt động thuộc phạm vi áp dụng; Provenance không thay AuditEvent cho hành vi đọc |
| Độ nhạy và nghĩa vụ xử lý | Resource.meta.security và/hoặc AuditEvent.entity.securityLabel; security label không tự cấp quyền |
| Lựa chọn của chủ thể | VNCoreConsent; không dùng làm carrier cho Điều 19 khoản 1 khi không có hành vi đồng ý, từ chối, rút lại hoặc giới hạn |
Các điểm cần giữ ổn định cho Consent thật:
Consent.status phản ánh trạng thái còn hiệu lực, bị rút lại hoặc hết hiệu lực.Consent.category cho biết directive phục vụ điều trị, chia sẻ hồ sơ, nghiên cứu hay đồng ý qua đại diện.Consent.patient là bắt buộc.Consent.provision.purpose phải đủ để giải thích mục đích xử lý dữ liệu.Nếu đơn vị chưa dùng Consent như resource trao đổi, vẫn phải có cơ chế tương đương để chứng minh trạng thái lựa chọn và phạm vi mà chủ thể đã cho phép hoặc từ chối.
| Điểm | Phạm vi pháp lý (diễn giải) | Mã VN Core | Bằng chứng/kiểm soát gắn với quyết định |
|---|---|---|---|
| a | Bảo vệ cấp bách tính mạng, sức khỏe hoặc quyền/lợi ích hợp pháp; hoặc bảo vệ cần thiết trước hành vi xâm phạm | emergency-vital hoặc legitimate-defense |
Ghi evidence phù hợp với tình huống. Bên kiểm soát dữ liệu cá nhân, bên xử lý dữ liệu cá nhân, bên kiểm soát và xử lý dữ liệu cá nhân, bên thứ ba có trách nhiệm chứng minh trường hợp này. |
| b | Tình trạng khẩn cấp; nguy cơ đe dọa an ninh quốc gia nhưng chưa đến mức ban bố tình trạng khẩn cấp; phòng, chống bạo loạn, khủng bố, tội phạm hoặc vi phạm pháp luật | public-emergency-security |
Ghi căn cứ thẩm quyền, sự kiện và policy có version; không suy ra từ nhãn “cấp cứu” lâm sàng. |
| c | Hoạt động của cơ quan nhà nước hoặc quản lý nhà nước theo pháp luật | state-agency-operation |
Ghi URI điều khoản cụ thể và policy thực thi; không mặc định mọi trao đổi với cơ quan nhà nước đều thuộc điểm c. |
| d | Thực hiện thỏa thuận của chủ thể dữ liệu với bên liên quan theo pháp luật | subject-agreement |
Tham chiếu thỏa thuận áp dụng; nếu có một directive lựa chọn của chủ thể thì biểu diễn directive đó riêng bằng Consent. |
| đ | Trường hợp khác được pháp luật quy định | other-lawful |
Phải chỉ ra văn bản/điều khoản cụ thể; mã tổng quát này không tự chứng minh tính hợp pháp. |
Luật 91/2025/QH15 Điều 19 khoản 2 yêu cầu cơ chế giám sát cho mọi trường hợp xử lý không cần sự đồng ý, gồm quy trình, phân trách nhiệm, biện pháp bảo vệ/đánh giá rủi ro, kiểm tra định kỳ và tiếp nhận phản ánh.
NĐ 356/2025/NĐ-CP Điều 19 quy định lớp trách nhiệm giải trình qua hồ sơ đánh giá tác động khi nghĩa vụ này áp dụng, trong đó có mục đích, luồng dữ liệu, biện pháp bảo vệ, rủi ro và biện pháp giảm thiểu. Không diễn giải NĐ 356/2025/NĐ-CP là đặt cùng một nghĩa vụ chứng minh cho cả năm điểm của Luật 91/2025/QH15 Điều 19 khoản 1.
processingLegalBasis và purpose-of-use là hai trục khác nhau. Chỉ dùng BTG khi người dùng thực sự override chính sách/quyền thông thường; dùng ETREAT cho mục đích điều trị khẩn cấp và ERTREAT cho quyền thường trực của khoa cấp cứu theo policy. Không dùng ba mã này thay mã căn cứ pháp lý.
TLS 1.2+ hoặc tốt hơn.AES-256.VN Core coi VNCoreAuditEvent là mức nền đối với truy cập, chỉnh sửa và chia sẻ dữ liệu nhạy cảm; VNCoreAuditEventLegalBasisDecision là profile chuyên biệt cho quyết định permit/deny theo căn cứ pháp lý.
Tối thiểu phải giữ:
typerecordedagentsourceentitypurposeOfEventMục tiêu không chỉ là log kỹ thuật, mà là chứng minh được ai truy cập gì, khi nào, từ đâu và vì mục đích nào.
VN Core ưu tiên dùng VNCoreProvenance để ghi nhận:
target)agent)reason)signature) khi tài liệu đã được xác nhậnProvenance NÊN được dùng khi cần trao đổi bằng chứng truy vết; một cơ chế truy vết tương đương có thể được dùng nếu được công bố rõ. signature chỉ bắt buộc khi văn bản pháp luật hoặc quy trình nghiệp vụ áp dụng yêu cầu chữ ký hay khả năng không thể chối bỏ.
VN Core công bố các CapabilityStatement mức cơ sở theo vai trò:
VNCoreEMRServerVNBHYTGatewayClientVNBHYTGatewayServerVNCitizenAppClientCác CapabilityStatement mô tả tương tác FHIR, không tự định nghĩa toàn bộ chính sách OAuth/SMART. Bảng sau chỉ là điểm khởi đầu minh họa; mỗi deployment phải công bố authorization server metadata, scope thực tế, audience, launch context và quy tắc truy cập theo use case. Ma trận scope đầy đủ theo use case, nghĩa vụ của bốn vai trò SMART và cách gắn scope với căn cứ pháp lý: xem SMART on FHIR — nghĩa vụ và scope.
| Vai trò | Kiểu token | Scope tham khảo — phải thu hẹp theo use case |
|---|---|---|
| EMR/HIS nội bộ | user |
openid, profile, fhirUser, launch, user/Patient.read, user/Encounter.*, user/Condition.*, user/Observation.*, user/DocumentReference.*, user/Composition.*, user/Consent.* |
| Ứng dụng người dân / VNeID connector | patient |
openid, profile, launch/patient, patient/Patient.read, patient/RelatedPerson.read, patient/Coverage.read, patient/DocumentReference.read, patient/Consent.*, patient/AuditEvent.read |
| Gateway BHYT máy chủ - máy chủ | system |
system/Bundle.create, system/Bundle.read, system/Claim.create, system/Claim.read, system/Patient.read, system/Coverage.read, system/Organization.read |
Break-glass cho phép truy cập vượt ngoài phân quyền thông thường trong bối cảnh cấp cứu hoặc an toàn người bệnh. Hệ thống nên:
BTG chỉ áp dụng khi người dùng thực sự vượt quyền/policy thông thường. Nếu nhân viên khoa cấp cứu đã được cấp quyền thường trực theo policy thì dùng ERTREAT; nếu mục đích là điều trị khẩn cấp nhưng không có override thì dùng ETREAT. Ba mã purpose-of-use này không thay thế processingLegalBasis. Nếu có cơ chế phê duyệt sau truy cập, hãy gắn mã phiếu xử lý/ca bệnh vào AuditEvent.agent.policy hoặc cơ chế tương đương.
VN Core không áp đặt cứng thời hạn lưu trữ cho mọi loại tài nguyên, nhưng ở mức cơ sở hệ thống nên giữ tối thiểu:
| Resource | Trường tối thiểu cần giữ |
|---|---|
AuditEvent |
type, subtype, action, recorded, outcome, purposeOfEvent, agent.who, agent.requestor, source.observer, entity.what |
Consent |
status, category, patient, dateTime, performer, organization, policy.uri, provision.period, provision.purpose, provision.provision.type khi dùng provision con |
Provenance |
target, recorded, reason, agent.who, agent.onBehalfOf, signature.when, signature.who, signature.sigFormat |
Nếu chính sách nội bộ yêu cầu xóa hoặc ẩn dữ liệu lâm sàng theo quyền của chủ thể dữ liệu, siêu dữ liệu kiểm toán vẫn nên được giữ theo cách còn đáp ứng nghĩa vụ chứng minh truy cập và trách nhiệm giải trình.
Provenance và khi nào cần thêm signature| Tình huống | Provenance | Signature |
|---|---|---|
| Bệnh án điện tử đã xác nhận | NÊN có hoặc có cơ chế truy vết tương đương | BẮT BUỘC khi quy định áp dụng hoặc quy trình đã công bố yêu cầu ký số |
| Tóm tắt ra viện / tài liệu giao cho người bệnh | NÊN có hoặc có cơ chế truy vết tương đương | BẮT BUỘC khi loại tài liệu và quy trình áp dụng yêu cầu ký số |
| Kết quả cận lâm sàng final | NÊN có | NÊN có nếu quy trình ký số kết quả đã áp dụng |
| Liên thông hồ sơ BHYT / bằng chứng gửi - thu hồi | NÊN có | NÊN có nếu cần khả năng không thể chối bỏ ở lớp cổng |
| Consent điện tử / consent qua cha mẹ-người giám hộ | NÊN có | NÊN có khi consent được ký số hoặc cần chứng cứ pháp lý mạnh |
Nếu dữ liệu VN Core được dùng cho hệ thống AI y tế hoặc phân tích thứ cấp:
Trang này không tạo profile AI riêng, nhưng coi AI/sử dụng thứ cấp là lý do để siết quản trị dữ liệu từ đầu thay vì bổ sung muộn.
Chi tiết về mức xử lý dữ liệu, các trường mang rủi ro tái nhận dạng trong profile VN Core, nhãn meta.security và nghĩa vụ theo Luật 134/2025/QH15: xem Khử định danh và dữ liệu dùng cho AI.
| Nếu cần | Nên đọc tiếp |
|---|---|
| Registry pháp lý chi tiết | Cơ sở pháp lý |
| Nghĩa vụ theo vai trò | Tuân thủ theo vai trò triển khai |
| Kiểm tra hợp lệ và tập lệnh kiểm thử | Hướng dẫn kiểm tra hợp lệ |
| Vòng đời và mức ổn định bản phát hành | Ổn định và tuân thủ |
VNCoreConsent carries only the data subject's choice. An Article 19(1) authorization is a VNCoreAuditEventLegalBasisDecision; each actual access is a follow-up AuditEvent, with Provenance for create/modify and security labels for sensitivity. Purpose-of-use stays separate from legal basis (BTG only for a real override). The duty to demonstrate applicability attaches to point (a); Article 19(2) monitoring still applies. Technical guidance, not legal advice.