FHIR và Luật 91/2025 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 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 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 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 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. Đây là cơ sở pháp lý để bệnh viện chia sẻ dataset cho nghiên cứu, đào tạo mô hình AI hoặc báo cáo dịch tễ — với điều kiện kỹ thuật ẩn danh đạt chuẩn và có tài liệu DPIA xác nhận.

3. Tám quyền của chủ thể dữ liệu — ánh xạ sang FHIR

Luật 91/2025 quy định tám quyền cốt lõi của chủ thể dữ liệu. Mỗi quyền cần một cơ chế kỹ thuật cụ thể trong hệ thống EMR và máy chủ FHIR.

4. Consent — biểu diễn đồng ý của người bệnh

Tài nguyên Consent trong FHIR R4 mã hóa sự đồng ý có cấu trúc: ai đồng ý, đồng ý cho ai làm gì, trong phạm vi và thời hạn nào, có thể rút bất cứ lúc nào. Đây là điểm chạm chính giữa pháp lý và kỹ thuật.

Ví dụ thực tế: bệnh nhân Nguyễn Thị Lan (CCCD 12 số) đồng ý cho Bệnh viện Bạch Mai 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ị.

{
  "resourceType": "Consent",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentcategorycodes",
      "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": {
    "type": "permit",
    "period": { "start": "2026-04-30", "end": "2031-04-30" },
    "purpose": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "TREAT"
    }]
  }
}

Khi người bệnh rút đồng ý, hệ thống không xóa tài nguyên Consent mà cập nhật status thành inactive và ghi đồng thời một AuditEvent + Provenance để lưu vết hành động. Lịch sử đồng ý cần truy xuất được trong tối thiểu thời hạn lưu trữ bệnh án theo Luật Khám bệnh, chữa bệnh 2023.

5. AuditEvent — ghi vết mọi truy cập

Luật 91/2025 yêu cầu bên xử lý dữ liệu phải có khả năng chứng minh ai đã truy cập dữ liệu nào, vào lúc nào, với mục đích gì. Tài nguyên AuditEvent chính là cơ chế ghi vết chuẩn hóa của FHIR, tương thích với IHE ATNA và RFC 3881.

Mỗi lần đọc, ghi, tìm kiếm, xuất dữ liệu lâm sàng đều phải sinh ra một AuditEvent. Hệ thống nên ghi log đồng bộ với giao dịch (cùng transaction) để tránh mất vết khi máy chủ gặp sự cố. Nhật ký này là chứng cứ pháp lý khi cần báo cáo vi phạm hoặc trả lời yêu cầu của cơ quan quản lý.

{
  "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.

Theo NĐ 137/2024/NĐ-CP về giao dịch điện tử, bệnh án điện tử và các văn bản quan trọng cần được ký số. FHIR Provenance.signature mang chữ ký số dạng base64Binary, phổ biến nhất là PKCS#7 detached signature. Dưới đây là ví dụ Provenance cho một Composition bệnh án ra viện được bác sĩ điều trị ký số:

{
  "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ụ chứng thực số (CA) công cộng được Bộ Thông tin và Truyền thông cấp phép — Viettel-CA, FPT-CA, BKAV-CA, VNPT-CA hoặc CA chuyên dùng của Chính phủ.

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 — 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 yêu cầu bên xử lý dữ liệu nhạy cảm áp dụng biện pháp kỹ thuật phù hợp để bảo đảm bảo mật. Hai lớp mã hóa tối thiểu:

• Mã hóa trên đường truyền (in transit): bắt buộc HTTPS với TLS 1.2 trở lên (khuyến nghị TLS 1.3); cấu hình chữ ký HSTS; cấm fallback HTTP. Kết nối nội bộ giữa các microservice cũng phải dùng mTLS hoặc service mesh có mã hóa.
• Mã hóa khi lưu trữ (at rest): mã hóa toàn bộ ổ đĩa máy chủ cơ sở dữ liệu (LUKS, BitLocker), thêm mã hóa cấp ứng dụng cho các trường nhạy cảm cao (số CCCD, số thẻ BHYT, kết quả HIV, gen). Khóa mã hóa quản lý qua HSM hoặc dịch vụ KMS đặt tại Việt Nam.

Đối với chữ ký số, NĐ 137/2024 công nhận chữ ký số PKCS#7 detached được dùng phổ biến cho bệnh án điện tử và đơn thuốc điện tử. Hệ thống nên lưu cả chữ ký và chứng thư số tại thời điểm ký để hỗ trợ xác minh dài hạn (LTV — Long-Term Validation).

9. DPIA — Đánh giá tác động bảo vệ dữ liệu (Mẫu 10)

Đánh giá tác động bảo vệ dữ liệu cá nhân (DPIA) là tài liệu phân tích rủi ro mà bên kiểm soát dữ liệu phải lập trước khi triển khai một hoạt động xử lý dữ liệu nhạy cảm. NĐ 356/2025 quy định Mẫu số 10 là mẫu DPIA chuẩn.

Bệnh viện triển khai EMR mới, hệ thống AI hỗ trợ chẩn đoán, hoặc tích hợp với VNeID đều cần DPIA riêng cho từng dự án. Các trường thông tin cốt lõi:

• Mục đích, phạm vi và bối cảnh xử lý dữ liệu.
• Loại dữ liệu cá nhân, số lượng chủ thể dữ liệu dự kiến.
• Cơ sở pháp lý: sự đồng ý, hợp đồng, nghĩa vụ pháp luật, lợi ích công cộng.
• Đánh giá rủi ro: khả năng xảy ra và mức độ tổn hại nếu vi phạm.
• Biện pháp giảm thiểu: kỹ thuật (mã hóa, phân quyền), tổ chức (đào tạo, hợp đồng).
• Quan điểm của DPO và phương án thông báo cho chủ thể dữ liệu.

DPIA là tài liệu sống — cần rà soát định kỳ ít nhất hằng năm hoặc khi có thay đổi quy mô, công nghệ. Lưu trong hệ quản trị tài liệu của bệnh viện và cung cấp cho cơ quan chức năng khi yêu cầu.

10. DPO — Cán bộ bảo vệ dữ liệu

Cán bộ bảo vệ dữ liệu (Data Protection Officer — DPO) là vị trí bắt buộc với tổ chức xử lý dữ liệu cá nhân nhạy cảm khối lượng lớn. Bệnh viện công lập tuyến tỉnh trở lên, bệnh viện tư có quy mô EMR đầy đủ, nhà cung cấp HIS/EMR đa khách hàng đều thuộc nhóm bắt buộc.

Trách nhiệm chính của DPO:

• Tư vấn ban lãnh đạo về nghĩa vụ tuân thủ Luật 91/2025 và NĐ 356/2025.
• Giám sát quá trình xử lý dữ liệu, rà soát DPIA, đánh giá nhà cung cấp.
• Là đầu mối liên lạc với cơ quan quản lý nhà nước về bảo vệ dữ liệu cá nhân.
• Tiếp nhận khiếu nại của chủ thể dữ liệu và phối hợp xử lý.
• Báo cáo trực tiếp cho lãnh đạo cao nhất, không chịu chi phối lợi ích từ các bộ phận nghiệp vụ.

DPO có thể là nhân sự nội bộ hoặc thuê ngoài (DPO-as-a-Service). Với bệnh viện vừa và nhỏ, mô hình DPO bán thời gian hoặc dùng chung giữa các đơn vị thuộc cùng tập đoàn y tế là khả thi và đã có tiền lệ tại châu Âu theo GDPR.

11. Thông báo vi phạm trong 72 giờ (Mẫu 08)

Khi xảy ra vi phạm dữ liệu cá nhân có khả năng gây hại đến an ninh quốc gia, trật tự xã hội, hoặc tới tính mạng, sức khỏe, danh dự, nhân phẩm, tài sản của chủ thể dữ liệu, bên kiểm soát dữ liệu phải thông báo cho cơ quan quản lý trong vòng 72 giờ kể từ khi phát hiện. Quy định cụ thể tại Điều 23 Luật 91/2025 và Điều 28 NĐ 356/2025; Mẫu số 08 là biểu mẫu thông báo.

Quy trình kỹ thuật gắn với FHIR:

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 phạm vi: dùng AuditEvent.entity để liệt kê các Patient bị ảnh hưởng.
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 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).
5. Thông báo cho các chủ thể dữ liệu bị ảnh hưởng theo phương thức đã đăng ký trong Patient.telecom.

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

NĐ 356/2025 quy định việc chuyển dữ liệu cá nhân ra khỏi lãnh thổ Việt Nam phải có hồ sơ đánh giá tác động riêng theo Mẫu số 09, bên cạnh DPIA chung theo Mẫu 10. Đây là điểm rất quan trọng vì nhiều bệnh viện và nhà cung cấp đang dùng dịch vụ cloud quốc tế.

Các tình huống thực tế cần Mẫu 09:

• 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).

Khuyến nghị từ OmiGroup và các đối tác triển khai EMR tại Việt Nam: ưu tiên kiến trúc data-residency tại Việt Nam — máy chủ chính đặt trong nước, chỉ chuyển ra nước ngoài các dữ liệu đã ẩn danh hoặc tổng hợp. Hiện trạng region của các cloud provider tại Việt Nam thay đổi theo từng thời điểm và từng nhà cung cấp — đội triển khai cần kiểm tra trang thông tin region/data residency chính thức của provider trước khi quyết định kiến trúc. Luật 24/2018 An ninh mạng và Luật 116/2025 (hiệu lực 01/07/2026) củng cố thêm yêu cầu lưu trữ dữ liệu trong nước với hệ thống thông tin quan trọng về an ninh quốc gia.

13. Checklist 30 điểm tuân thủ Luật 91/2025

Danh mục rà soát nhanh để Giám đốc CNTT, DPO và đội phát triển EMR tự đánh giá mức độ sẵn sàng trước 01/01/2026. Mỗi điểm cần có bằng chứng tài liệu hoặc cấu hình hệ thố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. Xác thực đa yếu tố (MFA) bắt buộc cho mọi tài khoản truy cập dữ liệu nhạy cảm.
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ý khóa mã hóa qua HSM hoặc KMS đặt tại Việt Nam.
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. Giao diện ký đồng ý có chữ ký số hoặc xác nhận VNeID.
8. Lưu trữ Consent theo phiên bản, có dấu thời gian và chữ ký.
9. Cơ chế rút đồng ý dễ dùng cho người bệnh (qua VNeID, qua quầy lễ tân).
10. Kiểm tra Consent trước mỗi giao dịch chia sẻ dữ liệu ra ngoài tổ chức.
11. Ghi AuditEvent cho mọi thay đổi Consent.status.

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

12. Chính sách lưu trữ: bệnh án điện tử lưu theo thời hạn quy định tại Luật KCB và văn bản hướng dẫn; thời hạn lưu AuditEvent hiện chưa có quy định cụ thể trong NĐ 356/2025 — khuyến nghị vận hành tối thiểu 5 năm, đồng bộ với chu kỳ lưu hồ sơ y tế.
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. Kỹ thuật ẩn danh đạt chuẩn cho dataset chia sẻ nghiên cứu.
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ỳ.

DPIA và DPO (17–21)

17. DPIA Mẫu 10 cho EMR và mỗi tích hợp lớn (BHYT, VNeID, AI).
18. Lịch rà soát DPIA hằng năm và khi có thay đổi quan trọng.
19. DPO được bổ nhiệm chính thức, báo cáo trực tiếp cho lãnh đạo.
20. Đào tạo bảo vệ dữ liệu cá nhân định kỳ cho toàn bộ nhân viên có truy cập EMR.
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 mỗi luồng xuyên biên giới.
24. Hợp đồng xử lý dữ liệu (DPA) với mọi nhà cung cấp cloud, SaaS, dịch vụ phân tích.
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ý nhà cung cấp phụ (sub-processor): danh sách công khai và quyền phản đối của bệnh viện.
29. Yêu cầu nhà cung cấp tuân thủ ISO 27001 hoặc tương đương; có chứng chỉ công khai.
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 và GDPR khác nhau ở điểm nào?

Hai khung pháp lý có nhiều điểm tương đồng: yêu cầu cơ sở hợp pháp để xử lý, các quyền chủ thể dữ liệu, nghĩa vụ DPO và DPIA, thông báo vi phạm trong 72 giờ. Khác biệt chính nằm ở phạm vi áp dụng địa lý, mức xử phạt (Luật 91/2025 dùng tỷ lệ doanh thu Việt Nam; GDPR dùng tỷ lệ doanh thu toàn cầu), và yêu cầu lưu trữ dữ liệu tại Việt Nam theo Luật An ninh mạng đi kèm.

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

NĐ 356/2025 yêu cầu DPO khi xử lý dữ liệu cá nhân nhạy cảm khối lượng lớn. Trên thực tế, bệnh viện nào triển khai EMR đầy đủ đều thuộc nhóm này. Mô hình DPO bán thời gian hoặc DPO dùng chung trong cùng tập đoàn y tế là khả thi để giảm chi phí.

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

Được, nhưng phải có hồ sơ Mẫu 09 cho mỗi luồng dữ liệu và phải bảo đảm yêu cầu lưu trữ dữ liệu tại Việt Nam theo Luật An ninh mạng. Khuyến nghị thực tế: chọn cloud có vùng (region) đặt tại Việt Nam, hoặc dùng kiến trúc lai với máy chủ chính trong nước.

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

FHIR cung cấp các tài nguyên kỹ thuật cần thiết (Consent, AuditEvent, Provenance, meta.security) nhưng không thay thế cho 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. FHIR là công cụ; tuân thủ là kết quả của cả tổ chức.

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

Chưa có quy định cụ thể trong NĐ 356/2025 về thời hạn tối thiểu cho nhật ký truy cập y tế. Khuyến nghị thực tiễn: lưu tối thiểu 5 năm (tương đương thời hạn lưu trữ một số hồ sơ y tế cơ bản theo Luật KCB), tốt hơn là 10 năm và đồng bộ với chu kỳ lưu trữ bệnh án. Luật 116/2025 (hiệu lực 01/07/2026) có thể bổ sung yêu cầu cụ thể — cần theo dõi.

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: Hướng dẫn 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 (hiện hành).
• L-116-2025 — Luật 116/2025/QH15: An ninh mạng sửa đổi (ban hành 10/12/2025, hiệu lực 01/07/2026 — future-effective).
• ND-137-2024 — Nghị định 137/2024/NĐ-CP: Giao dịch điện tử và chữ ký số.

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