FHIR và Luật 91/2025/QH15 về Bảo vệ dữ liệu cá nhân

1. Khung pháp lý 2026

Khung pháp lý về bảo vệ dữ liệu cá nhân tại Việt Nam đã thay đổi căn bản trong nửa cuối năm 2025. Trước đây, Nghị định 13/2023/NĐ-CP là văn bản chính. Từ 01/01/2026, NĐ 13/2023/NĐ-CP hết hiệu lực và bị thay thế hoàn toàn bởi Nghị định 356/2025/NĐ-CP, đặt dưới Luật 91/2025/QH15. Mọi tham chiếu pháp lý trong tài liệu nội bộ, hợp đồng xử lý dữ liệu (DPA) và chính sách quyền riêng tư đều cần cập nhật.

Năm văn bản trọng yếu mà bệnh viện và nhà cung cấp EMR cần ghi nhận:

2. Phân loại dữ liệu cá nhân — y tế là dữ liệu nhạy cảm

Luật 91/2025/QH15 phân biệt hai nhóm: dữ liệu cá nhân cơ bản và dữ liệu cá nhân nhạy cảm. Phụ lục NĐ 356/2025/NĐ-CP liệt kê chi tiết từng nhóm.

Dữ liệu cá nhân cơ bản

• Họ tên đầy đủ, ngày sinh, giới tính, nơi sinh, nơi cư trú.
• Số điện thoại, địa chỉ thư điện tử.
• Số định danh cá nhân (CCCD), số hộ chiếu, giấy phép lái xe.
• Tình trạng hôn nhân, học vấn, nghề nghiệp.
• Hình ảnh cá nhân (không phải hình ảnh CCCD).

Dữ liệu cá nhân nhạy cảm — yêu cầu cao nhất

• Dữ liệu y tế: bệnh án, đơn thuốc, kết quả xét nghiệm, chẩn đoán hình ảnh, dị ứng, tình trạng tâm thần, di truyền.
• Dữ liệu sinh trắc học: vân tay, mống mắt, gương mặt, giọng nói.
• Lịch sử giao dịch tài chính, thông tin tín dụng.
• Nguồn gốc dân tộc, tôn giáo, quan điểm chính trị.
• Thông tin tài khoản VNeID, hình ảnh CCCD/căn cước.
• Đời sống tình dục, xu hướng tình dục.

Hệ quả với hệ thống FHIR: các tài nguyên lâm sàng có gắn với một người bệnh xác định danh tính (Patient, Encounter, Condition, Observation, MedicationRequest, DiagnosticReport, AllergyIntolerance, Procedure...) đều thuộc nhóm dữ liệu cá nhân nhạy cảm. Ngược lại, các tài nguyên cơ sở hạ tầng (CodeSystem, ValueSet, StructureDefinition) hoặc dữ liệu đã ẩn danh, tổng hợp đúng kỹ thuật không tự động bị xếp vào nhóm nhạy cảm; tổ chức phải đánh giá riêng và lập tài liệu chứng minh.

Luật 91/2025/QH15 ghi nhận nguyên tắc: dữ liệu đã ẩn danh đến mức không còn khả năng nhận dạng chủ thể thì không còn là dữ liệu cá nhân. Trước khi dùng dataset cho nghiên cứu, đào tạo AI hoặc báo cáo dịch tễ, bệnh viện vẫn phải chứng minh phương pháp và rủi ro tái nhận dạng, kiểm tra nghĩa vụ chuyên ngành/hợp đồng khác và phản ánh kết quả trong hồ sơ đánh giá tác động khi hoạt động xử lý thuộc phạm vi; không mặc định mọi dataset gắn nhãn “ẩn danh” đều được tự do chia sẻ.

3. Các nhóm quyền của chủ thể dữ liệu — ánh xạ kỹ thuật

Điều 4 Luật 91/2025/QH15 quy định các nhóm quyền của chủ thể dữ liệu tại sáu điểm a, b, c, d, đ, e; một điểm có thể gồm nhiều hành vi như xem/chỉnh sửa hoặc cung cấp/xóa/hạn chế/phản đối. Bảng dưới đây là ánh xạ triển khai tham khảo, không phải ánh xạ pháp lý một-một và không biến một FHIR interaction thành việc hoàn thành quyền theo luật.

4. Consent — biểu diễn quyết định đồng ý

Tài nguyên Consent trong FHIR R4 có thể biểu diễn một directive có cấu trúc: chủ thể, phạm vi, tổ chức, chính sách, thời hạn và các provision cho phép/từ chối. Tài nguyên này là bằng chứng hoặc đầu vào cho policy engine khi thiết kế như vậy; nó không tự chứng minh sự đồng ý đáp ứng Điều 9 Luật 91/2025/QH15 và không tự thực thi kiểm soát truy cập.

SMART on FHIR/OAuth scopes mô tả quyền mà access token được phép yêu cầu đối với API. Token, scope, thao tác đăng nhập hoặc nút “Allow” của OAuth không đồng nhất với sự đồng ý pháp lý vốn phải tự nguyện, dựa trên thông tin rõ ràng và riêng theo từng mục đích. Điểm quyết định truy cập phải kết hợp căn cứ xử lý, mục đích, policy áp dụng, directive Consent nếu có, danh tính và quyền của client.

Ví dụ dưới đây giả định sự đồng ý là căn cứ hoặc điều kiện áp dụng cho luồng cụ thể; không hàm ý mọi hoạt động điều trị đều chỉ có thể dựa trên sự đồng ý. Bệnh nhân Nguyễn Thị Lan (CCCD 12 số) đồng ý cho một bệnh viện trung ương khai thác hồ sơ y tế phục vụ điều trị, đồng thời cho phép chia sẻ tóm tắt sang Sổ sức khỏe điện tử trên VNeID trong 5 năm. Hai mục đích này nên được ghi thành hai tài nguyên Consent riêng, để khi rút đồng ý chia sẻ VNeID không ảnh hưởng tới điều trị.

Lưu ý về luồng VNeID: QĐ 1551/QĐ-BYT (31/5/2026) thiết lập chương trình đồng bộ; QĐ 2062/QĐ-BYT (07/7/2026) thay Phụ lục 01–03 và bổ sung Phụ lục 04–05, nên hai văn bản phải được đọc hợp nhất. Riêng luồng đọc/hiển thị cho công dân, thu hồi quyền và phân quyền phía ứng dụng VNeID Health vẫn là hợp đồng tích hợp riêng. Các flow Consent trong bài vì vậy là mô hình tham chiếu ngoài envelope đồng bộ đã ban hành.

{
  "resourceType": "Consent",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-consent-category-cs",
      "code": "treatment"
    }]
  }],
  "patient": { "reference": "Patient/nguyen-thi-lan-001" },
  "dateTime": "2026-04-30T10:00:00+07:00",
  "performer": [{ "reference": "Patient/nguyen-thi-lan-001" }],
  "organization": [{ "reference": "Organization/bv-bach-mai" }],
  "policy": [{ "uri": "https://bachmai.gov.vn/policy/quyen-rieng-tu-v2" }],
  "provision": {
    "period": { "start": "2026-04-30", "end": "2031-04-30" },
    "provision": [{
      "type": "permit",
      "purpose": [{
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-consent-purpose-cs",
        "code": "TREAT"
      }]
    }]
  }
}

Khi chủ thể gửi yêu cầu rút đồng ý, hệ thống có thể cập nhật directive tương ứng thành Consent.status=inactive. Sự kiện thay đổi phải có bằng chứng kiểm toán phù hợp với event model của deployment; dùng FHIR AuditEvent hoặc Provenance chỉ khi kiến trúc quy định đúng mục đích của từng Resource. Lịch sử đồng ý theo lịch lưu giữ đã được xác định trong hồ sơ pháp lý và quản trị hồ sơ của tổ chức; trang này không ấn định một thời hạn chung.

5. AuditEvent — thiết kế phạm vi audit

Khả năng giải trình cần dựa trên hồ sơ truy cập đủ để tái dựng sự kiện trong phạm vi được xác định bởi phân tích pháp lý, threat model và chính sách kiểm soát truy cập. AuditEvent là Resource FHIR để biểu diễn sự kiện bảo mật và quyền riêng tư; sử dụng Resource này không thay thế hệ thống nhật ký bất biến, giám sát và phản ứng sự cố.

Tổ chức phải định nghĩa ma trận sự kiện cần audit, chẳng hạn đăng nhập, truy cập hồ sơ, thay đổi, xuất dữ liệu, thay đổi quyền và thao tác quản trị. Việc ghi log cần có cơ chế giao nhận tin cậy, correlation identifier, kiểm soát toàn vẹn và kiểm thử khi thành phần audit lỗi; đặt log trong cùng transaction dữ liệu không mặc nhiên bảo đảm không mất vết. Giá trị chứng cứ còn phụ thuộc tính toàn vẹn, chuỗi quản lý và quy trình vận hành.

{
  "resourceType": "AuditEvent",
  "type": {
    "system": "http://dicom.nema.org/resources/ontology/DCM",
    "code": "110100",
    "display": "Application Activity"
  },
  "subtype": [{
    "system": "http://hl7.org/fhir/restful-interaction",
    "code": "read"
  }],
  "action": "R",
  "recorded": "2026-04-30T17:30:00+07:00",
  "outcome": "0",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
        "code": "AUT"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-an" },
    "requestor": true,
    "network": { "address": "10.0.1.42", "type": "2" }
  }],
  "source": {
    "observer": { "reference": "Device/emr-bachmai" },
    "type": [{
      "system": "http://terminology.hl7.org/CodeSystem/security-source-type",
      "code": "4"
    }]
  },
  "entity": [{
    "what": { "reference": "Patient/nguyen-thi-lan-001" },
    "type": {
      "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type",
      "code": "1"
    }
  }]
}

Khuyến nghị thực tế: tách kho lưu trữ AuditEvent ra khỏi máy chủ FHIR chính, đẩy sang hệ SIEM của bệnh viện (Splunk, ELK, Wazuh) để dễ phân tích bất thường, dễ truy hồi khi điều tra sự cố và bảo đảm tính bất biến của log.

6. Provenance — chuỗi nguồn gốc và chữ ký số

Trong khi AuditEvent trả lời câu hỏi "ai đã truy cập", thì Provenance trả lời câu hỏi "dữ liệu này đến từ đâu, ai tạo ra, ai sửa, được ký bởi ai". Hai tài nguyên bổ sung lẫn nhau và không thay thế cho nhau.

Khi workflow yêu cầu chứng thực điện tử, FHIR Provenance.signature có thể mang dữ liệu chữ ký dạng base64Binary, chẳng hạn PKCS#7/CMS hoặc định dạng khác đã thỏa thuận. Việc đặt chữ ký trong Resource không tự xác lập giá trị pháp lý: hệ thống còn phải xác minh chứng thư, thời điểm ký, nội dung được ký và chính sách chữ ký áp dụng. Ví dụ dưới đây minh họa một lựa chọn kỹ thuật cho Composition ra viện.

{
  "resourceType": "Provenance",
  "target": [{ "reference": "Composition/ra-vien-comp-001" }],
  "occurredDateTime": "2026-04-30T17:00:00+07:00",
  "recorded": "2026-04-30T17:00:01+07:00",
  "activity": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
      "code": "CREATE"
    }]
  },
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "author"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-an" },
    "onBehalfOf": { "reference": "Organization/bv-bach-mai" }
  }],
  "signature": [{
    "type": [{
      "system": "urn:iso-astm:E1762-95:2013",
      "code": "1.2.840.10065.1.12.1.1",
      "display": "Author's Signature"
    }],
    "when": "2026-04-30T17:00:00+07:00",
    "who": { "reference": "Practitioner/bs-tran-van-an" },
    "sigFormat": "application/pkcs7-signature",
    "data": "MIIE+wYJKoZIhvcNAQcCoIIE7DCCBOgCAQExDzANBglghkgBZQ..."
  }]
}

Lưu ý kỹ thuật: trường data trong signature phải là chuỗi base64 hợp lệ (không phải placeholder dạng <base64>). Dùng nhà cung cấp dịch vụ tin cậy/chứng thực chữ ký số được cấp phép theo pháp luật Việt Nam, hoặc CA chuyên dùng của Chính phủ khi hệ thống thuộc phạm vi nhà nước.

7. meta.security — nhãn phân loại bảo mật

Mọi tài nguyên FHIR có trường meta.security để gắn nhãn mức độ nhạy cảm. Đây là cơ chế khai báo, để máy chủ FHIR và các hệ thống tiêu thụ áp dụng chính sách kiểm soát truy cập tương ứng.

"meta": {
  "security": [
    {
      "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
      "code": "R",
      "display": "Restricted"
    },
    {
      "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-bvdlcn-cs",
      "code": "sensitive-medical",
      "display": "DLCN nhạy cảm — y tế"
    }
  ]
}

Khuyến nghị cho VN Core: định nghĩa CodeSystem riêng vn-bvdlcn-cs (đề xuất, chưa nằm trong corpus chính thức) để mã hóa các phân loại theo NĐ 356/2025/NĐ-CP — ví dụ sensitive-medical, sensitive-genetic, sensitive-mental-health. Khi máy chủ FHIR thấy nhãn này, có thể tự động yêu cầu xác thực mạnh hơn (MFA), giới hạn IP, ghi AuditEvent chi tiết hơn.

8. Mã hóa dữ liệu trên đường truyền và khi lưu trữ

NĐ 356/2025/NĐ-CP yêu cầu biện pháp kỹ thuật phù hợp với hoạt động xử lý và rủi ro. Dự án có thể dùng các kiểm soát dưới đây làm baseline an toàn, sau đó điều chỉnh theo threat model, phân loại dữ liệu và kiến trúc triển khai; đây không phải danh sách cấu hình mà văn bản pháp luật ấn định đồng loạt:

• Mã hóa trên đường truyền (in transit): baseline dự án nên dùng HTTPS với phiên bản TLS còn được chính sách an ninh của tổ chức hỗ trợ (thường tối thiểu TLS 1.2), ưu tiên TLS 1.3, HSTS cho bề mặt web phù hợp và không cho phép hạ cấp sang HTTP. Với kết nối nội bộ, chọn mTLS, service mesh có mã hóa hoặc kiểm soát tương đương khi đánh giá rủi ro và ranh giới tin cậy yêu cầu; pháp luật không mặc định bắt buộc đúng một công nghệ cho mọi microservice.
• Mã hóa khi lưu trữ (at rest): chọn mã hóa ổ đĩa, cơ sở dữ liệu hoặc cấp ứng dụng theo threat model và độ nhạy trường dữ liệu. HSM/KMS, vị trí quản lý khóa và yêu cầu lưu trữ trong nước phải được quyết định từ phân loại hệ thống, hợp đồng và các nghĩa vụ pháp lý áp dụng, không suy ra tự động cho mọi triển khai.

Riêng dữ liệu cá nhân trên điện toán đám mây, khoản 4 Điều 12 NĐ 356/2025/NĐ-CP yêu cầu mã hóa ở trạng thái nghỉ và khi truyền, kèm phân quyền truy cập nghiêm ngặt. Đây là yêu cầu theo bối cảnh cloud, không phải căn cứ để ấn định cùng một cipher suite hay sản phẩm quản lý khóa cho mọi hệ thống.

NĐ 137/2024/NĐ-CP không ấn định PKCS#7/CMS, JOSE, chế độ detached hay hồ sơ LTV cho bệnh án điện tử và đơn thuốc điện tử. PKCS#7/CMS trong ví dụ Provenance ở trên chỉ là một lựa chọn kỹ thuật. Định dạng chữ ký, nội dung chính xác được ký, chứng thư, dấu thời gian và bằng chứng cần lưu phải được chốt theo pháp luật về giao dịch/chữ ký điện tử, quy định chuyên ngành, trust framework và hợp đồng tích hợp áp dụng.

9. Hồ sơ đánh giá tác động xử lý dữ liệu cá nhân (Mẫu 10)

Điều 21 Luật 91/2025/QH15 phân trách nhiệm theo vai trò: bên kiểm soát và bên kiểm soát–xử lý lập, lưu và gửi hồ sơ trong 60 ngày từ ngày đầu tiên xử lý; bên xử lý lập và lưu theo thỏa thuận với bên kiểm soát. Điều 19 khoản 1 và khoản 4 NĐ 356/2025/NĐ-CP quy định thêm việc các vai trò được liệt kê lập/lưu từ khi bắt đầu xử lý và nộp bản chính theo thủ tục trong 60 ngày. Cơ quan nhà nước có thẩm quyền được miễn theo khoản 6 Điều 21 Luật. Mẫu số 10 là báo cáo nằm trong hồ sơ, không phải toàn bộ hồ sơ và không mặc định lập mới cho từng API.

EMR mới, AI hỗ trợ chẩn đoán hoặc tích hợp VNeID phải được đối chiếu với hồ sơ hiện có: cập nhật hồ sơ khi phát sinh mục đích, bên xử lý hoặc thay đổi thuộc Điều 20 NĐ 356/2025/NĐ-CP; chỉ tách hồ sơ khi phạm vi hoạt động xử lý và cơ cấu chịu trách nhiệm thực sự tách biệt. Các trường thông tin cốt lõi:

• Thông tin, chi tiết liên lạc của các bên xử lý và bộ phận/nhân sự hoặc nhà cung cấp dịch vụ bảo vệ dữ liệu (nếu có).
• Mục đích, loại dữ liệu, hoạt động xử lý và sơ đồ luồng dữ liệu.
• Cách xin sự đồng ý khi áp dụng; chính sách lưu trữ, xóa và hủy dữ liệu.
• Biện pháp an toàn, sơ đồ thiết kế hệ thống và tiêu chuẩn bảo vệ dữ liệu áp dụng.
• Kết quả đánh giá tuân thủ; mức độ ảnh hưởng, rủi ro, hậu quả có thể xảy ra và biện pháp giảm thiểu/loại bỏ.
• Bản sao hợp đồng/thỏa thuận xử lý cùng chính sách, quy trình, biểu mẫu và tài liệu liên quan của hồ sơ.

Hồ sơ phải luôn sẵn sàng để kiểm tra. Theo Điều 20 NĐ 356/2025/NĐ-CP, khi phát sinh mục đích mới hoặc thay đổi các bên xử lý liên quan, hồ sơ được cập nhật định kỳ 06 tháng kể từ lần nộp đầu; các thay đổi tổ chức, nhà cung cấp dịch vụ bảo vệ dữ liệu hoặc ngành/nghề/dịch vụ đã đăng ký phải cập nhật ngay trong 10 ngày. Tổ chức có thể đặt thêm nhịp review nội bộ dựa trên rủi ro, nhưng không thay thế các mốc pháp lý này.

10. Bộ phận/nhân sự bảo vệ dữ liệu cá nhân (DPO)

“DPO” là cách gọi quen thuộc, còn thuật ngữ pháp lý của Việt Nam là bộ phận, nhân sự bảo vệ dữ liệu cá nhân hoặc tổ chức/cá nhân cung cấp dịch vụ bảo vệ dữ liệu cá nhân. Điều 33 khoản 2 Luật 91/2025/QH15 yêu cầu cơ quan, tổ chức chỉ định bộ phận/nhân sự đủ điều kiện hoặc thuê nhà cung cấp dịch vụ; nghĩa vụ này không được giới hạn trong Luật theo hạng bệnh viện hay số lượng người bệnh.

Điều 13 NĐ 356/2025/NĐ-CP yêu cầu việc chỉ định nội bộ phải bằng văn bản và quy định điều kiện năng lực. Điều 14 giao các nhiệm vụ chính:

• Xây dựng hoặc tham mưu chính sách, quy trình, quy định và biểu mẫu tuân thủ.
• Tổ chức hoặc tham gia thực hiện quyền của chủ thể dữ liệu và đánh giá định kỳ tình trạng tuân thủ.
• Lập hồ sơ đánh giá tác động xử lý/chuyển xuyên biên giới, tiếp nhận và báo cáo vi phạm theo phạm vi nhiệm vụ.
• Đào tạo, bồi dưỡng và triển khai biện pháp kỹ thuật, tiêu chuẩn/quy chuẩn, kế hoạch ứng cứu sự cố.

Điều 15–16 cho phép thuê cá nhân/tổ chức đủ điều kiện và khoản 4 Điều 16 cho phép kết hợp chỉ định nội bộ với thuê dịch vụ. Các yêu cầu “báo cáo trực tiếp cấp cao nhất”, “độc lập tuyệt đối” hoặc mô hình xung đột lợi ích của GDPR không được tự động gán thành quy định Việt Nam nếu không có căn cứ riêng.

11. Thông báo vi phạm có điều kiện trong 72 giờ (Mẫu 08)

Khi phát hiện vi phạm có thể gây tổn hại đến quốc phòng, an ninh quốc gia, trật tự, an toàn xã hội hoặc xâm phạm tính mạng, sức khỏe, danh dự, nhân phẩm, tài sản của chủ thể, bên kiểm soát, bên kiểm soát–xử lý hoặc bên thứ ba phải thông báo cho cơ quan chuyên trách chậm nhất 72 giờ. Bên xử lý khi phát hiện phải thông báo kịp thời cho bên kiểm soát hoặc bên kiểm soát–xử lý. Điều 23 Luật 91/2025/QH15 quy định ngưỡng và vai trò; Điều 28 NĐ 356/2025/NĐ-CP quy định nội dung và Mẫu số 08.

Quy trình ứng phó có thể sử dụng dữ liệu FHIR khi deployment đã ghi nhận đủ:

1. Phát hiện sớm qua giám sát AuditEvent bất thường: truy cập ngoài giờ, từ IP lạ, số lượng record cao đột biến.
2. Khoanh vùng bằng inventory, nhật ký ứng dụng/cơ sở dữ liệu/SIEM và hồ sơ sự cố; dùng AuditEvent.entity chỉ khi event model đã ghi reference đủ và được đối soát với các nguồn khác.
3. Đánh giá mức độ tổn hại có thuộc trường hợp bắt buộc thông báo theo Điều 23 Luật 91/2025/QH15 hay không.
4. Lập báo cáo theo Mẫu 08, gửi tới cơ quan chuyên trách bảo vệ dữ liệu cá nhân (đầu mối thuộc Bộ Công an theo NĐ 356/2025/NĐ-CP).
5. Đánh giá nghĩa vụ thông báo chủ thể riêng. Điều 29 NĐ 356/2025/NĐ-CP yêu cầu thông báo trong 72 giờ đối với vi phạm dữ liệu vị trí hoặc sinh trắc học; dùng kênh liên hệ đã được xác minh theo quy trình sự cố, không mặc định Patient.telecom là nguồn bắt buộc hoặc duy nhất.

12. Chuyển dữ liệu xuyên biên giới (Mẫu 09)

Khoản 1 Điều 20 Luật 91/2025/QH15 xác định ba nhóm chuyển xuyên biên giới: chuyển dữ liệu lưu tại Việt Nam sang hệ thống lưu trữ ở nước ngoài; chuyển từ Việt Nam cho tổ chức/cá nhân ở nước ngoài; hoặc dùng nền tảng ngoài Việt Nam để xử lý dữ liệu thu thập tại Việt Nam. Nếu thuộc phạm vi và không có ngoại lệ, hồ sơ có Báo cáo Mẫu số 09 phải được gửi trong 60 ngày từ ngày chuyển đầu tiên. Đánh giá được lập một lần cho thời gian hoạt động và cập nhật theo Luật 91/2025/QH15 Điều 22 cùng NĐ 356/2025/NĐ-CP Điều 20 — không mặc định một hồ sơ độc lập cho mỗi request hay endpoint.

Khoản 6 Điều 20 Luật loại trừ nghĩa vụ đánh giá tác động đối với chuyển dữ liệu của cơ quan nhà nước có thẩm quyền; lưu dữ liệu nhân viên của chính tổ chức trên cloud; và trường hợp chủ thể tự chuyển dữ liệu của mình. Khoản 3 Điều 17 NĐ 356/2025/NĐ-CP bổ sung các trường hợp như báo chí/truyền thông theo luật, dữ liệu đã công khai hợp pháp, tình huống khẩn cấp cần bảo vệ tính mạng/sức khỏe/tài sản hoặc thực hiện nghĩa vụ luật định, quản lý nhân sự xuyên biên giới, và một số thủ tục hợp đồng/vận chuyển/thanh toán được liệt kê. Mỗi ngoại lệ phải được ghi nhận đúng điều khoản; ngoại lệ cloud cho dữ liệu nhân viên không mở rộng sang hồ sơ bệnh nhân. Dữ liệu đã ẩn danh thực sự có thể nằm ngoài khái niệm dữ liệu cá nhân, nhưng mã hóa hoặc pseudonymization đơn thuần không tạo ngoại lệ.

Các tình huống thực tế cần được rà soát để xác định có kích hoạt Mẫu 09 hay không:

• EMR triển khai trên AWS Singapore, GCP Tokyo, Azure Hong Kong.
• Dùng dịch vụ SaaS quốc tế (analytics, email, lưu trữ tài liệu) có truy cập dữ liệu y tế.
• Hợp tác nghiên cứu chia sẻ dataset cho viện nghiên cứu nước ngoài.
• Chăm sóc xuyên biên giới (telemedicine với bác sĩ ở nước ngoài).

Kiến trúc đặt dữ liệu tại Việt Nam có thể giảm một số luồng chuyển, nhưng region trong nước không tự loại bỏ chuyển xuyên biên giới nếu quản trị từ xa, telemetry, backup, hỗ trợ kỹ thuật hoặc sub-processor vẫn ở nước ngoài. Đội triển khai phải xác minh tài liệu region/data residency, hợp đồng và sơ đồ luồng thực tế của nhà cung cấp; chỉ dữ liệu đã ẩn danh thực sự mới có thể nằm ngoài phạm vi dữ liệu cá nhân. Nghĩa vụ lưu trữ trong nước theo pháp luật an ninh mạng phải được xác định theo đối tượng và phân loại của hệ thống cụ thể.

13. Checklist 30 điểm rà soát triển khai

Danh mục này là baseline dự án để Giám đốc CNTT, DPO và đội phát triển EMR rà soát thiết kế. Không phải cả 30 điểm đều là nghĩa vụ pháp luật áp dụng đồng loạt; mỗi kiểm soát cần được xác nhận theo căn cứ xử lý, vai trò, rủi ro và phạm vi hệ thống, rồi lưu bằng chứng quyết định hoặc cấu hình tương ứng.

Định danh và kiểm soát truy cập (1–6)

1. RBAC theo vai trò chuẩn (bác sĩ, điều dưỡng, kỹ thuật viên, dược sĩ, kế toán BHYT) cấu hình trên máy chủ FHIR.
2. SMART on FHIR scopes triển khai cho ứng dụng client.
3. Áp dụng MFA theo rủi ro, ưu tiên tài khoản đặc quyền, truy cập từ xa và thao tác có tác động cao; ghi nhận ngoại lệ và kiểm soát bù trừ.
4. Quản lý vòng đời tài khoản: tạo, gia hạn, vô hiệu khi nhân viên thôi việc.
5. Quản lý vòng đời khóa bằng KMS/HSM hoặc kiểm soát tương đương theo rủi ro; xác định vị trí khóa từ phân loại hệ thống và nghĩa vụ áp dụng.
6. Phân chia môi trường: production / staging / development tách biệt; dữ liệu thật không vào staging.

Quản lý đồng ý (7–11)

7. Khi đồng ý là căn cứ hoặc điều kiện áp dụng, cung cấp giao diện ghi nhận đáp ứng yêu cầu về thông tin, biểu đạt và bằng chứng; chữ ký số/VNeID chỉ dùng nếu kênh đó được phép và đã tích hợp.
8. Nếu biểu diễn bằng FHIR Consent, lưu dấu thời gian, phạm vi, chủ thể, chính sách và lịch sử phiên bản cần thiết; chữ ký phụ thuộc loại giao dịch và chính sách áp dụng.
9. Cung cấp cơ chế rút lại qua kênh thực sự vận hành và có thể xác minh; không giả định VNeID có API cho use case này.
10. Đánh giá căn cứ xử lý và chính sách ủy quyền trước giao dịch chia sẻ; kiểm tra Consent khi đồng ý là căn cứ hoặc điều kiện áp dụng.
11. Ghi sự kiện kiểm toán cho thay đổi trạng thái đồng ý; dùng FHIR AuditEvent khi event model của deployment quy định.

Vòng đời dữ liệu (12–16)

12. Chính sách lưu trữ: bệnh án điện tử theo quy định lưu hồ sơ áp dụng; thời hạn AuditEvent được xác định từ phân tích pháp lý, threat model và chính sách quản trị hồ sơ, không giả định một thời hạn chung.
13. Quy trình lưu trữ lâu dài (archival) cho hồ sơ ngoại trú/nội trú đã đóng.
14. Quy trình xóa dữ liệu khi hết thời hạn lưu trữ pháp lý.
15. Đánh giá nguy cơ tái định danh và áp dụng kỹ thuật ẩn danh/giả danh phù hợp trước khi chia sẻ dataset nghiên cứu; giả danh không đồng nghĩa dữ liệu đã ẩn danh.
16. Quy trình ứng phó sự cố vi phạm dữ liệu, bao gồm bài tập diễn tập định kỳ.

Hồ sơ đánh giá tác động và nhân sự bảo vệ dữ liệu (17–21)

17. Hồ sơ đánh giá tác động xử lý có Mẫu 10 cho hoạt động thuộc phạm vi; phản ánh tích hợp BHYT, VNeID, AI bằng cập nhật hoặc hồ sơ riêng theo ranh giới hoạt động xử lý.
18. Theo dõi mốc cập nhật 06 tháng khi có mục đích/bên mới và cập nhật trong 10 ngày đối với các thay đổi được Điều 20 NĐ 356/2025/NĐ-CP liệt kê.
19. Chỉ định bằng văn bản bộ phận/nhân sự bảo vệ dữ liệu đủ điều kiện hoặc ký hợp đồng với nhà cung cấp dịch vụ đủ điều kiện; lưu bằng chứng năng lực và thực hiện nghĩa vụ công khai thông tin khi quy định yêu cầu.
20. Đào tạo bảo vệ dữ liệu cá nhân định kỳ cho nhân sự có vai trò xử lý hoặc truy cập EMR, với nội dung theo rủi ro và trách nhiệm.
21. Chính sách phân quyền và hợp đồng lao động có điều khoản bảo mật rõ ràng.

Chuyển dữ liệu xuyên biên giới (22–25)

22. Bản đồ luồng dữ liệu (data flow map): liệt kê đầy đủ điểm dữ liệu rời lãnh thổ Việt Nam.
23. Hồ sơ Mẫu 09 cho hoạt động chuyển thuộc phạm vi, gửi trong 60 ngày từ lần chuyển đầu và cập nhật khi có thay đổi; ghi rõ luồng ngoài phạm vi hoặc ngoại lệ và điều khoản áp dụng.
24. DPA hoặc điều khoản xử lý dữ liệu phù hợp khi nhà cung cấp thực sự xử lý dữ liệu cá nhân và quan hệ giữa các bên yêu cầu; không mặc định mọi hợp đồng nhà cung cấp cần cùng một mẫu DPA.
25. Cơ chế giám sát truy cập từ ngoài lãnh thổ; cảnh báo khi phát hiện bất thường.

Quản lý nhà cung cấp (26–30)

26. Quy trình đánh giá an ninh nhà cung cấp HIS, EMR, LIS, RIS trước khi ký hợp đồng.
27. Điều khoản kiểm toán (audit right) trong hợp đồng cho phép bệnh viện rà soát hệ thống nhà cung cấp.
28. Quản lý sub-processor theo hợp đồng và vai trò xử lý; xác định nghĩa vụ thông báo/công khai và cơ chế phản đối nếu quy định hoặc thỏa thuận yêu cầu.
29. Yêu cầu bằng chứng bảo đảm an ninh tương xứng rủi ro; chứng nhận ISO/IEC 27001 còn hiệu lực là một lựa chọn, không phải nghĩa vụ công khai chứng chỉ cho mọi nhà cung cấp.
30. Kế hoạch chuyển đổi nhà cung cấp (exit plan) bảo đảm dữ liệu được trả lại và xóa sạch.

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

Luật 91/2025/QH15 và GDPR khác nhau ở điểm nào?

Hai khung pháp lý có các chủ đề tương đồng như căn cứ xử lý, quyền chủ thể dữ liệu, quản trị nhân sự bảo vệ dữ liệu, đánh giá tác động và thông báo vi phạm. Điều kiện kích hoạt, ngoại lệ, thời hạn và cách tính chế tài không đồng nhất; phải đối chiếu từng điều khoản thay vì chuyển nguyên mô hình GDPR sang Việt Nam.

Bệnh viện vừa và nhỏ có cần DPO không?

Có nghĩa vụ bố trí năng lực bảo vệ dữ liệu: Điều 33 khoản 2 Luật 91/2025/QH15 yêu cầu cơ quan, tổ chức chỉ định bộ phận/nhân sự đủ điều kiện hoặc thuê tổ chức, cá nhân cung cấp dịch vụ. Bệnh viện nhỏ không được miễn chỉ vì quy mô; có thể chọn mô hình nội bộ, thuê ngoài hoặc kết hợp theo Điều 15–16 NĐ 356/2025/NĐ-CP nếu đáp ứng điều kiện và thủ tục áp dụng.

Có thể dùng cloud quốc tế cho EMR không?

Có thể, nhưng cloud ở nước ngoài xử lý dữ liệu người bệnh thu thập tại Việt Nam thường thuộc một trong các trường hợp tại khoản 1 Điều 20 Luật 91/2025/QH15. Đơn vị phải lập bản đồ luồng, kiểm tra ngoại lệ, hồ sơ Mẫu 09 và nghĩa vụ lưu trữ trong nước áp dụng cho hệ thống cụ thể; ngoại lệ lưu dữ liệu nhân viên của tổ chức trên cloud không áp dụng cho hồ sơ bệnh nhân. Region tại Việt Nam hoặc kiến trúc lai là lựa chọn giảm rủi ro, không phải kết luận pháp lý chung cho mọi EMR.

FHIR có đủ để tuân thủ Luật 91/2025/QH15 không?

FHIR cung cấp các cơ chế biểu diễn liên quan (Consent, AuditEvent, Provenance, meta.security) nhưng không thay thế governance. Tuân thủ là tổng hòa của quy trình pháp lý, hợp đồng, đào tạo nhân sự, kiểm tra nội bộ và triển khai kỹ thuật đúng; không có Resource nào tự tạo ra tuân thủ.

Lưu trữ AuditEvent bao lâu là hợp lý?

NĐ 356/2025/NĐ-CP không đặt một thời hạn chung cho mọi nhật ký truy cập y tế. Mốc tối thiểu 5 năm tại Điều 29 áp dụng cho hồ sơ vi phạm dữ liệu vị trí/sinh trắc học kể từ khi khắc phục xong, không tự áp dụng cho mọi AuditEvent. Thời hạn log phải được chốt từ pháp luật an ninh mạng/chuyên ngành áp dụng, phân loại hệ thống, mục đích chứng cứ, threat model và chính sách quản trị hồ sơ; không suy ra 5 hoặc 10 năm chỉ từ thời hạn lưu bệnh án.

15. Đọc tiếp

Các trang trong knowledge hub liên quan trực tiếp tới chủ đề bảo vệ dữ liệu y tế:

Tham chiếu pháp lý chính thức

• L-91-2025 — Luật 91/2025/QH15: Bảo vệ dữ liệu cá nhân (ban hành 26/06/2025, hiệu lực 01/01/2026).
• ND-356-2025 — Nghị định 356/2025/NĐ-CP: Quy định chi tiết Luật BVDLCN, biểu mẫu 08/09/10 (ban hành 31/12/2025, hiệu lực 01/01/2026).
• L-24-2018 — Luật 24/2018/QH14: An ninh mạng (đã được Luật 116/2025/QH15 thay thế từ 01/07/2026).
• L-116-2025 — Luật 116/2025/QH15: An ninh mạng sửa đổi (ban hành 10/12/2025, đang áp dụng từ 01/07/2026).
• ND-137-2024 — Nghị định 137/2024/NĐ-CP: Giao dịch điện tử của cơ quan nhà nước và hệ thống thông tin phục vụ giao dịch điện tử.

Tham chiếu kỹ thuật FHIR R4

• FHIR R4 — Consent Resource
• FHIR R4 — AuditEvent Resource
• FHIR R4 — Provenance Resource
• FHIR R4 — Security & Privacy Module
• FHIR R4 — Signature datatype