FHIR và Luật AI 134/2025 trong y tế

1. Bối cảnh — vì sao Việt Nam ban hành Luật AI

Quốc hội khóa XV thông qua Luật Trí tuệ nhân tạo số 134/2025/QH15 ngày 10/12/2025, hiệu lực từ 01/03/2026. NĐ 142/2026/NĐ-CP có hiệu lực từ 01/05/2026 quy định chi tiết việc phân loại, thông báo và đánh giá sự phù hợp. Nội dung trang này được đối chiếu theo trạng thái văn bản tại ngày 18/07/2026.

Phạm vi và nghĩa vụ cụ thể phụ thuộc vai trò của chủ thể — nhà phát triển, nhà cung cấp, bên triển khai hoặc người sử dụng — và hoạt động AI được thực hiện tại Việt Nam. Với nhà cung cấp nước ngoài, cần tiếp tục đối chiếu yêu cầu về đầu mối hoặc hiện diện tại Việt Nam đối với hệ thống rủi ro cao theo Điều 14 của Luật.

Luật 134/2025/QH15 không thay thế pháp luật chuyên ngành. Tùy sản phẩm và hoạt động, đơn vị triển khai còn phải đối chiếu Luật Khám bệnh, chữa bệnh 2023, Thông tư 13/2025/TT-BYT về bệnh án điện tử, pháp luật về thiết bị y tế, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và NĐ 356/2025/NĐ-CP.

2. Ba mức rủi ro AI theo Luật 134/2025/QH15

Điều 9 Luật 134/2025/QH15 phân loại hệ thống AI thành ba mức. Nhà cung cấp tự phân loại trước khi đưa hệ thống vào sử dụng; chỉ hệ thống rủi ro trung bình hoặc cao phải có hồ sơ phân loại và được thông báo cho Bộ Khoa học và Công nghệ theo Điều 10.

NĐ 142/2026/NĐ-CP quy định tiêu chí chi tiết. Nếu chưa xác định được mức rủi ro, nhà cung cấp có thể đề nghị Bộ Khoa học và Công nghệ hướng dẫn trên cơ sở hồ sơ kỹ thuật; Luật không đặt quy tắc mặc định “tăng một bậc”.

3. Cách đánh giá AI y tế theo mức rủi ro

Không thể phân loại chỉ từ nhãn “AI y tế”. NĐ 142/2026/NĐ-CP yêu cầu xem xét hệ thống cụ thể, mục đích sử dụng, mức tự động, tác động, phạm vi ảnh hưởng và khả năng giám sát, can thiệp của con người.

QĐ 33/2026/QĐ-TTg ban hành danh mục hệ thống AI rủi ro cao, nhưng đến ngày rà soát trang này quyết định chưa có hiệu lực (hiệu lực từ 15/08/2026). Trong lĩnh vực y tế, danh mục nêu các hệ thống hỗ trợ phẫu thuật/rô-bốt phẫu thuật theo đúng các điều kiện về tích hợp, mức tự động và xác nhận của nhân viên y tế; quyết định không xếp toàn bộ AI chẩn đoán hoặc CDS vào nhóm rủi ro cao.

Các use case sau phải được đánh giá theo cấu hình và mục đích cụ thể, không thể gán mức rủi ro chỉ từ tên tác vụ:

• Hỗ trợ chẩn đoán hình ảnh trên X-quang, CT, MRI, siêu âm.
• Sàng lọc bệnh — ung thư, tim mạch, võng mạc đái tháo đường.
• Đề xuất phác đồ điều trị, tính liều thuốc, kiểm tra tương tác thuốc.
• Phân loại cấp cứu (triage), dự đoán xấu đi của bệnh nhân nội trú.
• Hỗ trợ ra quyết định lâm sàng (CDS) ảnh hưởng đến chỉ định cận lâm sàng hoặc thuốc.
• Chatbot trả lời thông tin y tế phổ biến cho người dân.
• AI gợi ý lịch khám, sắp xếp phòng, tối ưu vận hành phi lâm sàng.
• AI nhận dạng giọng nói cho nhập liệu bệnh án.

Theo NĐ 142/2026/NĐ-CP, tác vụ chỉ thu thập, xử lý, chuẩn hóa, phân loại, dịch thuật hoặc cải thiện chất lượng dữ liệu mà không trực tiếp tạo quyết định ảnh hưởng quyền và lợi ích có thể không được đề xuất vào danh mục rủi ro cao. Cơ chế giám sát thực chất cho phép người có thẩm quyền xem xét độc lập, can thiệp, từ chối hoặc thay đổi quyết định trước khi có hiệu lực cũng là yếu tố quan trọng. Thay đổi mục đích hoặc tích hợp làm phát sinh rủi ro mới thì phải rà soát, phân loại lại.

4. Năm nhóm kiểm soát cho AI rủi ro cao

Các nhóm dưới đây tóm tắt Điều 14 Luật 134/2025/QH15 và Điều 15–16 NĐ 142/2026/NĐ-CP. Chủ thể phải xác định đúng vai trò nhà cung cấp hay bên triển khai và tiếp tục đối chiếu pháp luật chuyên ngành.

4.1 Quản lý rủi ro và quản trị dữ liệu

Nhà cung cấp phải duy trì hệ thống quản lý rủi ro phù hợp với mục đích và phạm vi triển khai; dữ liệu huấn luyện, kiểm thử và đánh giá phải có chất lượng, tính phù hợp và tính đại diện trong phạm vi cần thiết để hạn chế rủi ro. NĐ 142/2026/NĐ-CP cho phép dùng tài liệu kỹ thuật theo tiêu chuẩn quốc tế nếu đáp ứng đủ hồ sơ luật định, nhưng không bắt buộc công bố toàn bộ dữ liệu huấn luyện hoặc tham số mô hình.

4.2 Minh bạch và giải trình theo phạm vi

Thông tin cần cung cấp phụ thuộc mục đích, bối cảnh và mức rủi ro. Đối với hệ thống rủi ro cao, nhà cung cấp và bên triển khai phải cung cấp mô tả chức năng, cách vận hành, giới hạn và cảnh báo rủi ro; nghĩa vụ giải trình với cơ quan có thẩm quyền được thực hiện khi có yêu cầu. Luật không bắt buộc mọi đầu ra phải kèm một kỹ thuật giải thích cụ thể như feature importance hoặc heatmap.

4.3 Có người giám sát và can thiệp

Hệ thống rủi ro cao phải được thiết kế và vận hành với cơ chế giám sát, can thiệp của con người phù hợp với mức rủi ro. Cách triển khai có thể là phê duyệt trước, khả năng dừng hệ thống, xem xét độc lập hoặc cơ chế bác bỏ; Luật không chỉ định một Resource FHIR hay bắt buộc cùng một quy trình cho mọi use case y tế.

4.4 An toàn và an ninh

Biện pháp kỹ thuật và quản lý phải tương xứng với các rủi ro đã xác định. Kiểm soát phiên bản, kiểm thử khả năng chống tấn công hoặc giám sát sai lệch có thể là biện pháp phù hợp, nhưng lựa chọn cụ thể phụ thuộc hệ thống. Khi có xử lý dữ liệu cá nhân, Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP áp dụng theo vai trò và phạm vi xử lý.

4.5 Hồ sơ kỹ thuật và nhật ký hoạt động

Nhà cung cấp hệ thống rủi ro cao phải lập, cập nhật và lưu hồ sơ kỹ thuật cùng nhật ký hoạt động ở mức cần thiết cho đánh giá sự phù hợp và hậu kiểm. Quy định này không đồng nghĩa mọi lượt suy luận phải được ghi thành AuditEvent FHIR hoặc phải giữ theo một thời hạn cố định của bệnh án; chính sách log cần xác định theo mục đích kiểm soát, pháp luật chuyên ngành và lịch lưu giữ áp dụng.

5. FHIR có thể hỗ trợ quản trị AI thế nào

FHIR R4 (4.0.1) có thể trao đổi dữ liệu lâm sàng và biểu diễn một số artifact liên quan đến hỗ trợ quyết định. FHIR không bao phủ mặc định toàn bộ vòng đời mô hình, hồ sơ đánh giá sự phù hợp, sổ đăng ký nhà nước hay hệ thống quản lý rủi ro; các phần đó có thể nằm ngoài FHIR.

Sơ đồ tích hợp end-to-end:

[FHIR Server (EMR / VN Core)]
        │
        │ Bulk Data $export → NDJSON (đã ẩn danh)
        ↓
[Training Pipeline]            ← dữ liệu đa dạng, có cấu trúc, có audit
        │
        │ Mô hình đã huấn luyện + hồ sơ quản trị ngoài FHIR
        ↓
[AI Inference Service]
        │
        │ CDS Hook trigger (patient-view, order-sign…)
        ↓
[FHIR Server] ← có thể ghi resource lâm sàng + Provenance phù hợp
        │
        ↓
[Giao diện bác sĩ] đọc → quy trình xem xét/phê duyệt phù hợp use case

Chuẩn hóa cấu trúc giúp dữ liệu dễ kiểm tra và so sánh hơn, nhưng không tự làm dữ liệu đầy đủ, đại diện hoặc ít thiên lệch. Provenance có thể ghi nguồn gốc dữ liệu; AuditEvent có thể ghi một số sự kiện an ninh hoặc riêng tư; các Resource lâm sàng có thể ghi kết quả và đánh giá. Chỉ cấu hình, quy trình vận hành và bằng chứng tổng thể mới quyết định mức đáp ứng nghĩa vụ pháp lý.

6. Các mẫu FHIR minh họa cho AI y tế

FHIR R4 chưa có Resource dành riêng cho AI và HL7 chưa quy định một mẫu phổ quát kết hợp Device, GuidanceResponse, Provenance, AuditEvent và ClinicalImpression. Các mẫu dưới đây chỉ minh họa lựa chọn có thể dùng khi đúng ngữ nghĩa; triển khai thực tế phải đặc tả trong IG/profiles và không được suy ra là yêu cầu pháp lý.

6.1 Device — một lựa chọn mô tả phần mềm như thiết bị

Device có thể phù hợp khi phần mềm AI được quản lý như một thiết bị hoặc tác nhân kỹ thuật trong hệ thống lâm sàng. Mã định danh do Cổng AI cấp theo NĐ 142/2026/NĐ-CP là mã của hệ thống sau thông báo phân loại, không phải mặc định là “đăng ký model”. Ví dụ dưới đây dùng namespace minh họa, không phải canonical của VN Core.

{
  "resourceType": "Device",
  "id": "ai-cardio-v2",
  "identifier": [{
    "system": "https://example.org/fhir/sid/ai-system",
    "value": "cardio-risk-v2"
  }],
  "type": {
    "coding": [{
      "system": "https://example.org/fhir/CodeSystem/ai-system-type",
      "code": "clinical-decision-support",
      "display": "AI hỗ trợ ra quyết định lâm sàng"
    }]
  },
  "manufacturer": "Example Health AI Vendor",
  "modelNumber": "CardioRiskNet-v2.1",
  "version": [{ "value": "2.1.0" }]
}

6.2 GuidanceResponse — khi đầu ra là phản hồi clinical reasoning

GuidanceResponse là một lựa chọn khi đầu ra thực sự là phản hồi từ việc đánh giá một module hướng dẫn hoặc clinical reasoning. Đây không phải container chung cho mọi lượt suy luận AI. Ở R4, module[x] bắt buộc; outputParameters là Reference(Parameters); và result tham chiếu đến CarePlan hoặc RequestGroup. Với use case khác, Observation, RiskAssessment, DiagnosticReport hoặc artifact ngoài FHIR có thể phù hợp hơn.

{
  "resourceType": "GuidanceResponse",
  "id": "gr-001",
  "status": "success",
  "moduleCanonical": "https://example.org/fhir/PlanDefinition/cardio-risk-v2",
  "subject": { "reference": "Patient/vn-001" },
  "encounter": { "reference": "Encounter/enc-001" },
  "occurrenceDateTime": "2026-04-30T14:00:00+07:00",
  "performer": { "reference": "Device/ai-cardio-v2" },
  "outputParameters": { "reference": "Parameters/gr-001-out" },
  "result": { "reference": "RequestGroup/rg-cardio-001" }
}

Trong mẫu này, Parameters/gr-001-out chứa các giá trị đầu ra, còn RequestGroup tập hợp đề xuất. Cách ghi nội dung giải thích phải được định nghĩa trong profile hoặc Implementation Guide của hệ thống; FHIR base không quy định một cấu trúc giải trình AI chung.

6.3 Provenance — nguồn gốc của resource

Provenance có thể ghi ai hoặc tác nhân nào tạo ra một resource, các entity nguồn liên quan và thời điểm ghi nhận. Trường recorded bắt buộc trong R4. Có resource này không tự chứng minh toàn bộ chuỗi kiểm soát hoặc tuân thủ.

{
  "resourceType": "Provenance",
  "target": [{ "reference": "GuidanceResponse/gr-001" }],
  "occurredDateTime": "2026-04-30T14:00:00+07:00",
  "recorded": "2026-04-30T14:00:05+07:00",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "performer"
      }]
    },
    "who": { "reference": "Device/ai-cardio-v2" }
  }],
  "entity": [
    { "role": "source", "what": { "reference": "Observation/ecg-001" } },
    { "role": "source", "what": { "reference": "Observation/troponin-001" } }
  ]
}

6.4 AuditEvent — sự kiện an ninh và riêng tư

AuditEvent biểu diễn sự kiện liên quan an ninh, riêng tư hoặc vận hành có thể kiểm toán. Một lượt gọi inference chỉ nên được ghi thành AuditEvent khi chính sách audit và mô hình sự kiện của hệ thống xác định như vậy; nhiều log kỹ thuật có thể được lưu ở hệ thống ngoài FHIR. AuditEvent không tự đáp ứng nghĩa vụ nhật ký của Luật 134/2025/QH15 hoặc nghĩa vụ bảo vệ dữ liệu.

6.5 ClinicalImpression — khi có đánh giá lâm sàng phù hợp

ClinicalImpression có thể dùng khi bác sĩ thực sự lập một đánh giá lâm sàng có ngữ nghĩa phù hợp với Resource này. Luật AI không bắt buộc bác sĩ tạo ClinicalImpression để chứng minh giám sát con người; tùy workflow, bước xem xét có thể nằm trong Task, ServiceRequest, Observation, chữ ký, phê duyệt y lệnh hoặc hệ thống nhật ký khác.

{
  "resourceType": "ClinicalImpression",
  "status": "completed",
  "subject": { "reference": "Patient/vn-001" },
  "encounter": { "reference": "Encounter/enc-001" },
  "date": "2026-04-30T14:15:00+07:00",
  "assessor": { "reference": "Practitioner/bs-001" },
  "supportingInfo": [{ "reference": "GuidanceResponse/gr-001" }],
  "summary": "AI đề xuất nguy cơ tim mạch cao. BS đồng ý dựa trên ECG và troponin tăng. Chỉ định Holter 24h và CK-MB lặp sau 6 giờ."
}

6.6 meta.tag cho dữ liệu do AI sinh

Một triển khai có thể dùng meta.tag cục bộ để hỗ trợ hệ thống xuôi dòng nhận diện dữ liệu do AI tạo hoặc trạng thái chờ xem xét. Các mã dưới đây chỉ là ví dụ và hiện không phải CodeSystem được VN Core công bố; hệ thống phải quản trị namespace, định nghĩa và vòng đời mã của mình.

"meta": {
  "tag": [
    {
      "system": "https://example.org/fhir/CodeSystem/ai-data-tag",
      "code": "AI-GENERATED",
      "display": "Dữ liệu do hệ thống AI sinh ra"
    },
    {
      "system": "https://example.org/fhir/CodeSystem/ai-data-tag",
      "code": "PENDING-CLINICIAN-REVIEW",
      "display": "Chờ bác sĩ đánh giá lại"
    }
  ]
}

7. CDS Hooks — pattern tích hợp realtime

CDS Hooks là đặc tả HL7 cho phép EMR gọi dịch vụ hỗ trợ quyết định tại các hook đã định nghĩa, chẳng hạn patient-view hoặc order-sign. Đây là một lựa chọn tích hợp; mức hỗ trợ hook, xác thực, dữ liệu context và hành vi ghi nhận kết quả phải được công bố bởi từng hệ thống.

[Bác sĩ mở hồ sơ bệnh nhân trong EMR]
        ↓
[EMR] -- POST /cds-services/cardio-risk + FHIR context --> [AI Service]
        ↓
        ←------- CDS Card (text + suggestion + link giải trình) --------
        ↓
[Giao diện EMR] hiển thị card; bác sĩ chấp nhận, bỏ qua hoặc đặt câu hỏi

Với hệ thống thuộc nghĩa vụ minh bạch tương ứng, CDS Card có thể hiển thị mục đích, giới hạn, cảnh báo và liên kết tài liệu kỹ thuật phù hợp. Việc người dùng chấp nhận một card không bắt buộc EMR phải ghi đồng thời GuidanceResponse, Provenance và AuditEvent; resource cần ghi phụ thuộc thiết kế workflow và chính sách audit.

8. Bulk Data API cho dữ liệu huấn luyện

FHIR Bulk Data Access là một Implementation Guide riêng cho thao tác $export và NDJSON; server chỉ hỗ trợ khi đã triển khai và công bố capability tương ứng. Dữ liệu xuất có thể dùng cho phân tích hoặc huấn luyện nếu mục đích, quyền truy cập và biện pháp bảo vệ đều hợp lệ. Mẫu yêu cầu cơ bản:

GET [base]/Patient/$export?_type=Patient,Observation,Condition,DiagnosticReport
Accept: application/fhir+json
Prefer: respond-async

→ 202 Accepted
  Content-Location: https://server/.../status/abc

→ Polling status URL → 200 OK + danh sách NDJSON URL

Trước khi huấn luyện, đơn vị xử lý phải xác định cơ sở pháp lý, mục đích, tối thiểu hóa dữ liệu, kiểm soát truy cập và biện pháp bảo mật. Khử nhận dạng có thể đưa dữ liệu ra khỏi phạm vi dữ liệu cá nhân khi dữ liệu mới không còn xác định hoặc giúp xác định một người cụ thể; dữ liệu được mã hóa hoặc tách định danh nhưng còn khả năng liên kết lại vẫn là dữ liệu cá nhân. Theo Điều 21 Luật 91/2025/QH15, bên kiểm soát và bên kiểm soát-xử lý lập hồ sơ đánh giá tác động; bên xử lý thực hiện theo thỏa thuận, với ngoại lệ cho cơ quan nhà nước có thẩm quyền tại khoản 6.

9. Đánh giá thiên lệch — FHIR hỗ trợ nhưng không tự giải quyết

Công bằng, không thiên lệch và không phân biệt đối xử là các nguyên tắc của Luật 134/2025/QH15. Hiệu năng của mô hình có thể thay đổi giữa cơ sở, thiết bị, thời kỳ và nhóm dân số; mức thay đổi phải được đo bằng dữ liệu kiểm thử phù hợp thay vì suy đoán từ nguồn gốc địa lý của tập huấn luyện.

VN Core có thể giúp biểu diễn nhất quán một số biến phục vụ phân tầng đánh giá, như tuổi, giới tính, dân tộc, địa lý và thuật ngữ lâm sàng. Tuy nhiên, terminology bản địa không bảo đảm mẫu đại diện, nhãn chính xác, đủ cỡ mẫu, không thiếu dữ liệu hoặc không có thiên lệch chọn mẫu. Các biến nhạy cảm cũng phải được xử lý trên cơ sở pháp lý và mục đích phù hợp.

Kế hoạch đánh giá nên xác định trước các nhóm có ý nghĩa lâm sàng, kiểm tra chất lượng và missingness, rồi báo cáo các chỉ số như độ phân biệt, hiệu chỉnh và sai số kèm khoảng bất định. FHIR hỗ trợ trao đổi biến đầu vào và kết quả; phương pháp thống kê và biện pháp giảm thiên lệch nằm ngoài đặc tả FHIR.

10. Tương quan Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP

Khi một hệ thống AI y tế xử lý dữ liệu cá nhân, Luật AI 134/2025 áp dụng theo mức rủi ro của hệ thống, còn Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP áp dụng theo vai trò và hoạt động xử lý. Dữ liệu đã được khử nhận dạng theo Luật cần được phân biệt với dữ liệu chỉ được mã hóa hoặc tách định danh nhưng còn khả năng liên kết lại.

• Dữ liệu huấn luyện chứa thông tin sức khỏe — thuộc dữ liệu cá nhân nhạy cảm theo Điều 4 NĐ 356/2025/NĐ-CP. Cần sự đồng ý bao quát rõ mục đích huấn luyện AI hoặc cơ sở pháp lý khác phù hợp với Luật 91/2025/QH15.
• Mỗi lượt inference trên dữ liệu bệnh nhân là hoạt động xử lý dữ liệu cá nhân và phải nằm trong mục đích, cơ sở pháp lý cùng biện pháp bảo vệ đã xác định; pháp luật không yêu cầu mỗi lượt phải tạo một AuditEvent FHIR.
• Hồ sơ đánh giá tác động xử lý dữ liệu theo Mẫu số 10 áp dụng cho bên kiểm soát và bên kiểm soát-xử lý theo Điều 21 Luật 91/2025/QH15; bên xử lý lập, lưu theo thỏa thuận. Khoản 6 Điều 21 quy định ngoại lệ cho cơ quan nhà nước có thẩm quyền.
• Bộ phận hoặc nhân sự bảo vệ dữ liệu cá nhân (DPO) tham gia lập, lưu và nộp hồ sơ DPIA theo NĐ 356/2025/NĐ-CP; vai trò này không thay thế trách nhiệm pháp lý của bên kiểm soát dữ liệu.
• Mốc 72 giờ tại Điều 23 Luật 91/2025/QH15 áp dụng khi chủ thể có trách nhiệm phát hiện vi phạm có thể gây các loại tổn hại được điều luật liệt kê và phải thông báo cơ quan chuyên trách. Nghĩa vụ thông báo chủ thể dữ liệu trong 72 giờ tại Điều 29 NĐ 356/2025/NĐ-CP có phạm vi riêng đối với dữ liệu vị trí hoặc sinh trắc học.

Nếu AI được tích hợp vào hệ thống bệnh án điện tử thuộc phạm vi Thông tư 13/2025/TT-BYT, đơn vị triển khai còn phải đối chiếu yêu cầu về hồ sơ, định danh, lưu trữ, an toàn và quy trình chuyên môn của hệ thống bệnh án điện tử.

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

AI sàng lọc tim mạch chạy trên cloud nước ngoài có vi phạm Luật 91/2025/QH15 không?

Không thể kết luận chỉ từ vị trí cloud. Nếu hoạt động thuộc chuyển dữ liệu cá nhân xuyên biên giới theo Điều 20 Luật 91/2025/QH15, bên chuyển phải có cơ sở xử lý phù hợp, áp dụng biện pháp bảo vệ và lập/gửi hồ sơ Mẫu số 09 trong thời hạn luật định, trừ trường hợp thuộc ngoại lệ tại khoản 6. Hồ sơ đánh giá tác động xử lý dữ liệu được xác định riêng theo vai trò tại Điều 21. Dữ liệu chỉ được mã hóa hoặc tách định danh nhưng còn khả năng liên kết lại vẫn là dữ liệu cá nhân.

AI có thể tự ký Composition (báo cáo lâm sàng) không?

Luật 134/2025/QH15 yêu cầu khả năng giám sát và can thiệp của con người đối với hệ thống rủi ro cao, nhưng không trực tiếp quy định cardinality hoặc loại actor của Composition.attester. Việc AI có thể tạo bản nháp, ai được ký/chứng thực báo cáo và loại chữ ký phải theo pháp luật khám chữa bệnh, giao dịch điện tử, quy trình chuyên môn và profile áp dụng. Trong FHIR R4, Composition.attester là 0..* và base spec cho phép nhiều loại actor; IG có thể ràng buộc chặt hơn khi có căn cứ.

Phải đăng ký AI model với cơ quan nào?

Luật không gọi thủ tục này là “đăng ký model”. Theo Điều 14 NĐ 142/2026/NĐ-CP, nhà cung cấp hệ thống rủi ro trung bình hoặc cao thông báo kết quả phân loại cho Bộ Khoa học và Công nghệ qua Cổng AI một cửa trước khi đưa hệ thống vào sử dụng; Cổng ghi nhận và cấp mã định danh hệ thống. Nếu Cổng chưa được công bố vận hành chính thức, Điều 46 của Nghị định cho phép dùng kênh điện tử, dịch vụ công hoặc phương thức tiếp nhận do Bộ công bố.

FHIR có Resource native cho AI không?

FHIR R4 chưa có Resource đặt tên trực tiếp cho AI và không có một tổ hợp Resource được HL7 quy định làm mẫu chung cho mọi hệ thống AI. Device, GuidanceResponse, Observation, RiskAssessment, Provenance, AuditEvent hoặc ClinicalImpression có thể được chọn tùy ngữ nghĩa. IG triển khai phải mô tả rõ profile, liên kết, capability và phần hồ sơ nằm ngoài FHIR.

Bệnh nhân có quyền yêu cầu giải thích kết quả AI không?

Hai quyền cần được phân biệt. Luật 134/2025/QH15 yêu cầu nhà cung cấp và bên triển khai hệ thống rủi ro cao cung cấp thông tin công khai ở mức mô tả chức năng, cách vận hành và cảnh báo rủi ro; trách nhiệm giải trình với cơ quan có thẩm quyền áp dụng theo yêu cầu và phạm vi luật định. Luật 91/2025/QH15 bảo đảm chủ thể được biết về việc xử lý dữ liệu cá nhân, nhưng không tự tạo quyền nhận một kỹ thuật giải thích riêng cho từng output AI. Quyền tiếp cận hoặc giải thích cụ thể còn phụ thuộc use case và pháp luật chuyên ngành; không bắt buộc phải cung cấp qua GuidanceResponse.

12. Tham chiếu và đọc tiếp

Văn bản pháp lý Việt Nam

• Luật Trí tuệ nhân tạo số 134/2025/QH15 — ban hành 10/12/2025, hiệu lực 01/03/2026 (mã VN Core: L-134-2025).
• NĐ 142/2026/NĐ-CP — quy định chi tiết Luật Trí tuệ nhân tạo, hiệu lực 01/05/2026.
• QĐ 33/2026/QĐ-TTg — danh mục hệ thống AI rủi ro cao, hiệu lực từ 15/08/2026 (chưa có hiệu lực tại ngày rà soát 18/07/2026).
• Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 — hiệu lực 01/01/2026 (L-91-2025).
• Nghị định 356/2025/NĐ-CP hướng dẫn Luật Bảo vệ dữ liệu cá nhân — hiệu lực 01/01/2026 (ND-356-2025).
• Thông tư 13/2025/TT-BYT về bệnh án điện tử — hiệu lực 21/07/2025 (TT-13-2025).
• Luật Khám bệnh, chữa bệnh năm 2023 — đang áp dụng.
• Quyết định 4469/QĐ-BYT ban hành Bảng phân loại quốc tế bệnh tật ICD-10 phiên bản Việt Nam — 28/10/2020.

Danh sách đầy đủ các văn bản tham chiếu được cập nhật trong corpus pháp lý của VN Core.

Đặc tả HL7/FHIR

• FHIR R4 (4.0.1) Specification — phiên bản chuẩn cho VN Core.
• GuidanceResponse Resource (R4).
• Provenance Resource (R4).
• Clinical Reasoning Module.
• CDS Hooks Specification.
• FHIR Bulk Data Access (Flat FHIR).

Đọc tiếp trong knowledge hub

Thuật ngữ

• Risk class — mức rủi ro của hệ thống AI theo Luật 134/2025/QH15 (cao, trung bình, thấp).
• Model card — tài liệu mô tả mô hình, mục đích, phạm vi, giới hạn, dữ liệu và kết quả đánh giá; việc công khai nội dung nào phụ thuộc nghĩa vụ áp dụng.
• CDS Hooks — đặc tả HL7 cho phép EMR gọi dịch vụ ra quyết định lâm sàng tại thời gian thực.
• Explainability — khả năng cung cấp thông tin giúp người nhận hiểu đầu ra hoặc hoạt động của hệ thống trong phạm vi kỹ thuật và pháp lý phù hợp.
• Human oversight — cơ chế giám sát và can thiệp của con người phù hợp với mức rủi ro; không đồng nghĩa luôn phải dùng một quy trình phê duyệt duy nhất.
• DPIA — Đánh giá tác động xử lý dữ liệu cá nhân theo Mẫu số 10 NĐ 356/2025/NĐ-CP.
• DPO — bộ phận hoặc nhân sự bảo vệ dữ liệu cá nhân theo NĐ 356/2025/NĐ-CP.