Hướng dẫn triển khai FHIR cốt lõi Việt Nam — VN Core FHIR Implementation Guide
0.10.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.10.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 khoẻ 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 xoá / 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 xoá 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 |
Hệ thống y tế thuộc diện tới đâu — ba tầng, không phải một câu. Mục 1 của TCVN 14423:2025 giới hạn phạm vi vào "hệ thống thông tin của cơ quan nhà nước và hệ thống thông tin quan trọng về an ninh quốc gia", và lực ràng buộc thực tế đi qua NĐ 331/2026/NĐ-CP. Đọc theo chuỗi Điều 2 → Điều 13 → Điều 30 khoản 1 của nghị định ấy thì phân tầng như sau:
Sẽ cập nhật sang TCVN 14423:2026 ở chu kỳ phát hành sau, nhưng lý do không đơn giản là bản mới thay bản cũ: hiện hai văn bản đang viện dẫn hai bản khác nhau. TT 47/2026/TT-BCA gọi đích danh TCVN 14423:2025 An ninh mạng - Yêu cầu đối với hệ thống thông tin quan trọng; còn NĐ 331/2026/NĐ-CP Điều 30 khoản 1 viện dẫn theo tên "Tiêu chuẩn quốc gia về An ninh mạng - Hệ thống thông tin - Yêu cầu cơ bản" — đó là tên của bản 2026, công bố theo QĐ 3243/QĐ-BKHCN ngày 24/07/2026, bản đã thay thế cả TCVN 14423:2025 lẫn TCVN 11930:2017. IG nạp bản 2025 trước vì đó là bản được viện dẫn đích danh và có toàn văn đối chiếu được; bản 2026 sẽ nạp khi có toàn văn.
Một máy chủ FHIR đang vận hành không mặc nhiên là kho lưu trữ pháp lý. VN Core mô tả cách biểu diễn và trao đổi dữ liệu; nghĩa vụ lưu trữ nằm ở tầng khác và do một nhóm văn bản riêng chi phối.
| Văn bản | Nội dung ràng buộc | Nơi thi hành |
|---|---|---|
| TT 33/2025/TT-BYT (thay TT 53/2017/TT-BYT) | Thời hạn lưu trữ theo loại hồ sơ: bệnh án nội trú và ngoại trú 10 năm; bệnh án tử vong 30 năm; bệnh án tâm thần, tai nạn lao động, tai nạn giao thông 20 năm; bệnh án ghép mô, tạng và phẫu thuật thẩm mỹ 20 năm; Sổ sức khoẻ điện tử 10 năm sau khi người dân qua đời | Chính sách lưu trữ của kho dữ liệu |
| Luật 33/2024/QH15 — Luật Lưu trữ | Giá trị pháp lý, tính toàn vẹn và xác thực lâu dài của tài liệu lưu trữ số; chuyển đổi định dạng qua thời gian | Provenance, chữ ký, hash, phiên bản terminology |
| NĐ 113/2025/NĐ-CP | Cấu trúc cơ sở dữ liệu tài liệu lưu trữ, mã hồ sơ, hệ thống quản lý và lưu trữ dự phòng | Kho lưu trữ và bản sao dự phòng |
| TT 12/2022/TT-BTTTT | Hồ sơ đề xuất cấp độ, yêu cầu kỹ thuật, đánh giá và báo cáo an toàn thông tin — hướng dẫn kỹ thuật của chuỗi NĐ 85/2016/NĐ-CP | Đọc cùng NĐ 331/2026/NĐ-CP, vốn đặt phạm vi và cấp độ theo trục an ninh mạng |
Cách đọc thời hạn cho đúng. Thời hạn gắn với hồ sơ, không phải với từng resource rời rạc.
Đặt TTL lên mỗi Observation rồi xoá nó khi hết 10 năm — trong khi bệnh án chứa nó vẫn còn hạn —
là hiểu sai văn bản: hồ sơ bệnh án là đơn vị lưu trữ, các resource là thành phần của nó. TT
33/2025/TT-BYT Điều 2 khoản 3 cũng nói rõ hồ sơ đã xác định thời hạn trước ngày Thông tư có
hiệu lực thì không áp dụng Thông tư này để xác định lại.
Hệ quả với lưu trữ lâu dài. Yêu cầu "xác thực lâu dài" của Luật Lưu trữ chạm đúng chỗ VN Core
có thể giúp: Provenance và chữ ký phải còn kiểm được sau nhiều năm, nghĩa là phải giữ được cả
phiên bản bộ mã mà dữ liệu tham chiếu. Một hồ sơ năm 2026 trỏ một Coding mà bộ mã đã đổi
display từ lâu vẫn phải giải nghĩa được — đó là lý do bộ mã đơn vị hành chính giữ previousDisplay,
changedOn, changedBy, và vì sao gói của các giai đoạn hiệu lực cũ được giữ trên trang tải về.
Không văn bản nào trong nhóm này chuyển thành cardinality hay invariant của profile.
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 khoẻ 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.
Luật 91/2025/QH15 Điều 9 khoản 2 không mô tả một thủ tục hành chính: nó đặt điều kiện hiệu lực. Sự đồng ý chỉ có hiệu lực khi chủ thể biết rõ loại dữ liệu và mục đích xử lý, bên kiểm soát, và quyền cùng nghĩa vụ của mình. Khi tranh chấp, nghĩa vụ chứng minh thuộc về bên kiểm soát (NĐ 356/2025/NĐ-CP Điều 6 khoản 2) — nên nếu hệ thống không lưu nội dung đã thông báo thì bản ghi Consent không chứng minh được gì cả.
Từ 0.10.0, VN Core mã hoá nghĩa vụ này thành contract kiểm được bằng máy. Bản ghi VNCoreConsent có bất kỳ rule permit nào — tức là có sự đồng ý được cấp — phải mang VNCoreExtConsentDisclosure:
| Căn cứ | Phải chứng minh | Phần tử |
|---|---|---|
| Điều 9 khoản 2 điểm a | Loại dữ liệu cá nhân được xử lý | dataCategory (bind vn-personal-data-category-vs) |
| Điều 9 khoản 2 điểm a | Mục đích xử lý | provision.provision.purpose — bắt buộc với mọi rule permit |
| Điều 9 khoản 2 điểm b | Bên kiểm soát và vai trò pháp lý của bên đó | controller + controllerRole |
| Điều 9 khoản 2 điểm c | Quyền và nghĩa vụ của chủ thể | rightsNotice — bản đã trình, xác định được phiên bản |
| NĐ 356/2025/NĐ-CP Điều 6 khoản 4 | Đã báo rằng dữ liệu là DLCN nhạy cảm | sensitiveDataNotice |
| NĐ 356/2025/NĐ-CP Điều 6 khoản 1 | Phương thức thể hiện đồng ý, kiểm chứng được | extension[consentMethod] |
| NĐ 356/2025/NĐ-CP Điều 6 khoản 2 | Bằng chứng đã lưu, tìm lại được | source[x] hoặc evidenceLocator |
Bản ghi thuần từ chối (chỉ có rule deny) và bản ghi rejected không mang nghĩa vụ này: chúng không phải sự đồng ý. Ranh giới đặt theo sự có mặt của rule permit, đúng ranh giới mà văn bản vạch — chứ không theo status.
Ba giới hạn cần nói thẳng. Thứ nhất, contract chứng minh hệ thống đã khai đã thông báo những gì; nó không chứng minh nội dung ấy thực sự đến được với chủ thể — việc đó thuộc quy trình và bản gốc, không mã hoá được trong cấu trúc dữ liệu. Thứ hai, sensitiveDataNotice = false là một tuyên bố hợp lệ về mặt cấu trúc, nhưng khi dataCategory chạm danh mục nhạy cảm thì invariant chặn — không có trạng thái im lặng. Thứ ba, rightsNotice trỏ tới nội dung đã trình cho chủ thể, khác với Consent.policy.uri trỏ tới văn bản pháp luật làm căn cứ; dùng lẫn hai thứ này là mất đúng bằng chứng mà Điều 9 khoản 2 điểm c yêu cầu.
| Đ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 khoẻ 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 doạ 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 thoả 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 thoả 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 hoạ; 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 xoá 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.