Bệnh án điện tử FHIR tại Việt Nam (TT 13/2025/TT-BYT)

1. TT 13/2025/TT-BYT — yêu cầu liên quan khi triển khai EMR bằng FHIR

Thông tư 13/2025/TT-BYT ban hành ngày 06/6/2025, hiệu lực 21/7/2025, thay thế Thông tư 46/2018/TT-BYT về bệnh án điện tử. Văn bản này đặt nền tảng cho đợt triển khai EMR mới và là động lực chính khiến nhiều bệnh viện cần đến FHIR — chuẩn dữ liệu liên thông quốc tế đã được HL7 phát triển cho mục tiêu trao đổi dữ liệu lâm sàng giữa các hệ thống khác nhau.

Về định danh, Điều 1 khoản 3 của Thông tư yêu cầu kết nối thông tin bệnh án điện tử với số định danh cá nhân của công dân Việt Nam và của người nước ngoài đã được cấp tài khoản định danh điện tử; điều khoản không cho phép chọn tài khoản VNeID thay cho số định danh. Điều 2 quy định hạ tầng, bảo mật, phục hồi và khả năng truy xuất; Điều 3 cho phép ký hoặc xác nhận điện tử bằng chữ ký điện tử hợp pháp, kỹ thuật sinh trắc học hoặc hình thức xác nhận điện tử khác theo pháp luật. NĐ 137/2024/NĐ-CP được Thông tư dẫn chiếu cụ thể tại Điều 5 khoản 2 cho việc chuyển đổi hồ sơ giấy đã lập trước ngày Thông tư có hiệu lực sang thông điệp dữ liệu; không nên suy rộng dẫn chiếu này thành một định dạng chữ ký FHIR bắt buộc.

Lộ trình mốc hạn cụ thể

Đối chiếu yêu cầu với một phương án FHIR

2. Kiến trúc FHIR cho EMR

FHIR không thay thế hệ thống EMR sẵn có. FHIR là lớp giao tiếp đặt phía trên kho dữ liệu lâm sàng, cho phép EMR hiện hữu trao đổi dữ liệu với VNeID, cổng BHXH, hệ thống xét nghiệm, và các bệnh viện khác theo một ngôn ngữ chung. Cách tiếp cận này giúp bệnh viện không phải viết lại EMR từ đầu, đồng thời mở ra khả năng tích hợp lâu dài.

Sơ đồ dưới đây mô tả vị trí của FHIR server giữa giao diện EMR và các hệ thống bên ngoài. Lưu ý VNeID nằm ở lớp xác thực và định danh, không nằm trong Patient.identifier của FHIR.

┌─────────────────────────────────────────────────┐
│ Giao diện EMR (bác sĩ, điều dưỡng nhập liệu)    │
└─────────────────────────────────────────────────┘
                     │ FHIR REST
                     ↓
┌─────────────────────────────────────────────────┐
│ FHIR Server (HAPI / Microsoft / Google / ...)   │
│  - Patient, Encounter, Composition              │
│  - Condition, Observation, Procedure            │
│  - MedicationRequest, AllergyIntolerance        │
│  - DocumentReference (PDF lưu trữ)              │
│  - Provenance/AuditEvent/Consent khi áp dụng    │
└─────────────────────────────────────────────────┘
         │                        │
         │ Tích hợp                │ FHIR API
         ↓                        ↓
┌──────────────┐          ┌──────────────┐
│ VNeID        │          │ Cổng BHXH    │
│ auth/định    │          │ (Claim,      │
│ danh         │          │  XML 4210)   │
└──────────────┘          └──────────────┘

Bệnh viện có thể chọn FHIR server mã nguồn mở như HAPI FHIR hoặc dịch vụ quản trị phù hợp. Lựa chọn phụ thuộc quy mô, kỹ năng đội ngũ, threat model, vị trí xử lý dữ liệu và các nghĩa vụ pháp lý áp dụng; không nên suy ra một yêu cầu lưu trữ trong nước chỉ từ việc dùng FHIR.

3. Cấu trúc bệnh án điện tử ánh xạ FHIR Composition

Composition là Resource đóng vai trò header của bệnh án. Một Composition gồm metadata (loại tài liệu, bệnh nhân, ca khám, ngày, tác giả, tiêu đề, người chứng thực) cùng danh sách section trỏ tới các Resource lâm sàng khác. Khi kết hợp với Bundle kiểu document, Composition tạo ra một tài liệu y tế đóng gói có chữ ký, sẵn sàng trao đổi giữa các hệ thống.

Ví dụ dưới đây mô tả bệnh án nội trú khoa Tim mạch của bệnh nhân Nguyễn Thị Lan tại một bệnh viện trung ương giả lập, do BS Trần Văn Minh chứng thực. Mọi trường bắt buộc của Composition R4 đều có mặt: status, type, subject, date, author và title. Mỗi section chứa text dạng Narrative với status và div để giúp tài liệu tự đọc được khi xem trong viewer FHIR thông thường.

{
  "resourceType": "Composition",
  "id": "comp-bm-001",
  "status": "final",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "11503-0",
      "display": "Medical records"
    }]
  },
  "subject": { "reference": "Patient/nguyen-thi-lan" },
  "encounter": { "reference": "Encounter/enc-tim-mach-001" },
  "date": "2026-04-30T17:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-tran-van-minh" }],
  "title": "Bệnh án nội trú — Khoa Tim mạch — Bệnh viện Trung ương A",
  "attester": [{
    "mode": "professional",
    "time": "2026-04-30T17:00:00+07:00",
    "party": { "reference": "Practitioner/bs-tran-van-minh" }
  }],
  "custodian": { "reference": "Organization/bv-bach-mai" },
  "section": [
    {
      "title": "Hành chính",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Bệnh nhân Nguyễn Thị Lan, nhập viện 28/4/2026.</div>"
      },
      "entry": [
        { "reference": "Patient/nguyen-thi-lan" },
        { "reference": "Encounter/enc-tim-mach-001" }
      ]
    },
    {
      "title": "Tiền sử",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Tăng huyết áp 5 năm; dị ứng penicillin.</div>"
      },
      "entry": [
        { "reference": "Condition/tha-001" },
        { "reference": "AllergyIntolerance/aller-pcn-001" }
      ]
    },
    {
      "title": "Khám lâm sàng",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "ClinicalImpression/ci-tm-001" }]
    },
    {
      "title": "Cận lâm sàng",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "DiagnosticReport/ecg-001" }]
    },
    {
      "title": "Chẩn đoán",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "Condition/dx-i10" }]
    },
    {
      "title": "Điều trị",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "MedicationRequest/mr-001" }]
    },
    {
      "title": "Tổng kết",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "Observation/summary-001" }]
    }
  ]
}

Với cấu trúc này, hệ thống nhận tài liệu có thể đọc tóm tắt từ section.text ngay cả khi chưa hỗ trợ đầy đủ các Resource liên kết. Khi cần kiểm chứng dữ liệu, hệ thống đi tiếp xuống entry để lấy Resource cấu trúc.

4. 8 thành phần bắt buộc của bệnh án ánh xạ FHIR Resource

Mẫu bệnh án theo TT 13/2025/TT-BYT và các thông tư hướng dẫn của Bộ Y tế gồm 8 phần chính. Mỗi phần ánh xạ sang một hoặc một nhóm Resource FHIR cụ thể. Phần này mô tả chi tiết từng thành phần, kèm Resource tương ứng và chú thích quan trọng về terminology Việt Nam.

4.1 Hành chính

Resource chính là Patient (theo profile VNCorePatient) và Encounter. Bản VNCorePatient trial-use đặt slice CCCD ở mức 1..1 như quy tắc conformance của dự án, kèm cơ chế data-absent-reason và căn cứ thay thế; các slice khác gồm BHYT, BHXH, GKS, HC và MRN. Đây không phải cardinality do TT 13/2025/TT-BYT trực tiếp quy định. VNeID không nằm trong Patient.identifier; quan hệ xác thực nằm ngoài Patient, còn sự kiện cần lưu vết được chọn theo ma trận audit/provenance của triển khai.

Encounter mô tả lượt khám hoặc nhập viện: thời điểm bắt đầu và kết thúc, loại lượt (ngoại trú, nội trú, cấp cứu), khoa phòng phụ trách, lý do nhập viện. Với bệnh nhân BHYT, Encounter cần kèm extension cho tuyến KCB và loại KCB BHYT.

4.2 Tiền sử

Phần tiền sử dùng Condition với clinicalStatus = inactive hoặc resolved để biểu diễn bệnh sử cũ, AllergyIntolerance để ghi nhận dị ứng thuốc và thực phẩm, và FamilyMemberHistory cho tiền sử gia đình. Mã chẩn đoán tiền sử dùng ICD-10 VN theo QĐ 4469/QĐ-BYT (28/10/2020) cùng các bổ sung sau đó.

4.3 Khám lâm sàng

ClinicalImpression ghi nhận đánh giá tổng quát của bác sĩ sau thăm khám. Sinh hiệu (mạch, huyết áp, SpO2, nhiệt độ, nhịp thở) ghi bằng Observation với mã LOINC chuẩn. Kết quả khám theo cơ quan (tim mạch, hô hấp, tiêu hóa, thần kinh) cũng dùng Observation, có thể nhóm bằng Observation kiểu panel.

4.4 Cận lâm sàng

Kết quả xét nghiệm máu, nước tiểu và sinh hóa dùng Observation, bind tới LOINC kết hợp với danh mục mã chỉ số cận lâm sàng theo QĐ 1227/QĐ-BYT (đợt 1, 11/4/2025) gồm 2.964 chỉ số huyết học, sinh hóa, vi sinh, giải phẫu bệnh và chẩn đoán hình ảnh. DiagnosticReport đóng gói kết quả tổng hợp của một xét nghiệm hoặc một báo cáo chẩn đoán hình ảnh. ImagingStudy trỏ tới hệ thống PACS để lấy hình ảnh DICOM thực tế.

4.5 Chẩn đoán

Chẩn đoán chính và chẩn đoán phụ dùng Condition với code bind tới CodeSystem ICD-10 VN, clinicalStatus = active, verificationStatus = confirmed. Khi cần phân biệt chẩn đoán nhập viện, chẩn đoán xuất viện, biến chứng và bệnh kèm, dùng Condition.category kết hợp ValueSet riêng của VN Core.

4.6 Điều trị

CarePlan mô tả kế hoạch điều trị tổng thể. MedicationRequest dùng cho đơn thuốc, theo TT 26/2025/TT-BYT về kê đơn ngoại trú và TT 27/2025/TT-BYT cho thuốc dược liệu, cổ truyền BHYT. Procedure ghi nhận thủ thuật và phẫu thuật, dùng mã ICD-9-CM bản 2026 theo QĐ 387/QĐ-BYT (05/02/2026) thay thế bản 2020 cũ.

4.7 Diễn biến

Với bệnh án nội trú, mỗi ngày điều trị có thể được mô tả như một sub-Encounter trong cây Encounter của ca nhập viện. Các đợt theo dõi sinh hiệu, đáp ứng điều trị và ghi chú điều dưỡng dùng Observation lặp theo thời gian. Trao đổi giữa bác sĩ điều trị và điều dưỡng có thể ghi qua Communication nếu hệ thống cần lưu vết.

4.8 Tổng kết và xuất viện

Phần tổng kết và xuất viện thường được đóng gói thành một Composition riêng với type bind tới mã LOINC 18842-5 (Discharge summary). Khi bệnh án xuất viện vẫn cần lưu bản PDF có chữ ký, hệ thống tạo thêm DocumentReference trỏ tới file PDF đã ký số, đồng thời liên kết với Composition gốc qua relatesTo.

5. Số định danh cá nhân và lớp tích hợp VNeID

Điều 1 khoản 3 TT 13/2025/TT-BYT yêu cầu kết nối thông tin bệnh án với số định danh cá nhân của công dân Việt Nam và của người nước ngoài đã được cấp tài khoản định danh điện tử. Cụm “đã được cấp tài khoản định danh điện tử” xác định nhóm người nước ngoài, không tạo một identifier VNeID thay thế. Trong VN Core, CCCD/số định danh cá nhân là định danh hành chính trên Patient; mọi tài khoản hoặc phiên VNeID cần truy vết nằm ở lớp ứng dụng/tích hợp theo contract tương ứng.

VNCorePatient định nghĩa 6 slice định danh: CCCD, BHYT, BHXH, GKS (giấy khai sinh — cho trẻ chưa có CCCD), HC (hộ chiếu — cho người nước ngoài) và MRN (mã bệnh nhân nội bộ, có thể lặp theo cơ sở). Slice hộ chiếu có tên HC, không phải passport. NamingSystem cho VNeID đã được đánh dấu retired và không nằm trong Patient.identifier.

Profile: VNCorePatient
Parent: Patient
* identifier ^slicing.discriminator.type = #pattern
* identifier ^slicing.discriminator.path = "type"
* identifier contains
    CCCD 1..1 MS and
    BHYT 0..1 MS and
    BHXH 0..1 MS and
    GKS  0..1 MS and    // Giấy khai sinh — cho trẻ chưa có CCCD
    HC   0..1 MS and    // Hộ chiếu — cho người nước ngoài
    MRN  0..* MS

* identifier[CCCD].system = "http://fhir.hl7.org.vn/core/sid/cccd" (exactly)
* identifier[CCCD].type = $vn-identifier-type-cs#CCCD
* identifier[BHYT].system = "http://fhir.hl7.org.vn/core/sid/bhyt" (exactly)
* identifier[BHYT].type = $vn-identifier-type-cs#BHYT
* identifier[BHXH].system = "http://fhir.hl7.org.vn/core/sid/bhxh" (exactly)
* identifier[BHXH].type = $vn-identifier-type-cs#BHXH
* identifier[GKS].system  = "http://fhir.hl7.org.vn/core/sid/gks"  (exactly)
* identifier[GKS].type = $vn-identifier-type-cs#GKS
* identifier[HC].system   = "http://fhir.hl7.org.vn/core/sid/passport" (exactly)
* identifier[HC].type = $vn-identifier-type-cs#HC
* identifier[MRN].type = $vn-identifier-type-cs#MRN
// VNeID không có slice riêng. Tài khoản VNeID được model ở lớp xác thực,
// không phải Patient.identifier. VNVNeIDNS đã retired trong VN Core.

Với VNeID, cần tách lớp định danh khỏi lớp đồng bộ dữ liệu. Xác thực công dân vẫn là mô hình tham chiếu: ứng dụng VNeID cấp token định danh cho công dân; bệnh viện xác thực token qua kênh định danh được phê duyệt, đối chiếu số định danh trong token với Patient.identifier theo contract. QĐ 1551/QĐ-BYT là đặc tả nền; QĐ 2062/QĐ-BYT ngày 07/7/2026 đã thay thế các Phụ lục 01–03 và bổ sung Phụ lục 04–05. Theo trạng thái hợp nhất hiện hành, luồng khám sức khỏe dùng Phụ lục 02 (data-sync/push), còn đồng bộ tài nguyên sức khỏe dùng Phụ lục 03 (resource-sync/push); scope và endpoint đọc/hiển thị cho công dân qua VNeID Health vẫn là hợp đồng tích hợp riêng. Triển khai phải lập ma trận sự kiện từ căn cứ pháp lý, threat model và chính sách; chỉ biểu diễn bằng AuditEvent hoặc Provenance khi vai trò ngữ nghĩa và contract yêu cầu.

Khi cần ghi nhận quá trình kiểm tra định danh (ví dụ: nhân viên bàn tiếp đón quét CCCD chip, đối chiếu với VNeID), bệnh viện có thể profile VerificationResult để mô tả kết quả kiểm tra; đây là Resource hợp lệ trong R4 và phù hợp cho mục đích này. Tuyệt đối không dùng tên Resource không tồn tại như IdentityVerification.

Để hiểu sâu hơn về cách VN Core mô hình hóa định danh và VNeID, xem trang FHIR và VNeID.

6. Ký, xác nhận điện tử và Provenance

Điều 3 TT 13/2025/TT-BYT cho phép ký hoặc xác nhận điện tử bằng chữ ký điện tử hợp pháp, kỹ thuật sinh trắc học hoặc hình thức xác nhận điện tử khác theo pháp luật. NĐ 137/2024/NĐ-CP là một phần của khung giao dịch điện tử và được TT 13 dẫn chiếu cụ thể cho việc chuyển đổi hồ sơ giấy cũ sang thông điệp dữ liệu. Hai văn bản không bắt buộc dùng Provenance hoặc một định dạng chữ ký mật mã cụ thể. Composition.attester có thể ghi metadata về người chứng thực; Provenance.signature có thể mang biểu diễn chữ ký như CMS/PKCS#7 hoặc JOSE/JWS khi contract chọn mô hình đó.

Provenance trong FHIR mô tả nguồn gốc, tác nhân, biến đổi hoặc chứng thực của dữ liệu. AuditEvent mô tả sự kiện bảo mật/quyền riêng tư của hệ thống. Hai Resource có mục đích khác nhau; có dùng cả hai, một trong hai hay không dùng ở một interaction cụ thể phải được quyết định trong ma trận kiểm soát dựa trên căn cứ pháp lý, threat model và chính sách của workflow.

Đoạn JSON dưới đây chỉ minh họa một cách mang chữ ký CMS/PKCS#7 trong Provenance.signature khi contract tích hợp chọn cách biểu diễn này. Chuỗi data đã rút gọn nên đây không phải instance dùng để trao đổi hoặc xác minh. Trong FHIR R4, targetFormat, sigFormat và data đều có cardinality 0..1; ví dụ có targetFormat để khai báo định dạng target, không phải vì FHIR base bắt buộc trường này.

{
  "resourceType": "Provenance",
  "target": [{ "reference": "Composition/comp-bm-001" }],
  "recorded": "2026-04-30T17:00:00+07:00",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "author",
        "display": "Author"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-minh" }
  }],
  "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-minh" },
    "targetFormat": "application/fhir+json",
    "sigFormat": "application/pkcs7-signature",
    "data": "MIIHpwYJ...BASE64_TRUNCATED..."
  }]
}

Ví dụ rút gọn này không chứng minh chữ ký xác minh thành công, chứng thư đáng tin cậy hay hồ sơ có giá trị pháp lý. Nếu contract chọn JOSE/JWS thay vì CMS/PKCS#7, biểu diễn FHIR có thể dùng sigFormat = application/jose và mang JWS trong data. Việc đổi MIME type chưa đủ để tương tác hoặc xác minh: hai bên còn phải chốt chính xác payload và version được ký, canonicalization, thuật toán, quản lý khóa/chứng thư, dấu thời gian, kiểm tra thu hồi và quy trình xác minh.

Cơ sở phải chọn hình thức ký hoặc xác nhận phù hợp với loại nội dung, chủ thể ký, quy chế bệnh án và pháp luật áp dụng. Nếu dùng chữ ký dựa trên chứng thư, cần kiểm tra điều kiện của nhà cung cấp, chứng thư và dịch vụ tin cậy trong đúng phạm vi pháp lý. Không nên giả định mọi SmartCA, USB token, CCCD chip hoặc luồng VNeID dùng cùng một container chữ ký hay có API public nếu chưa có đặc tả và kết quả kiểm thử tương thích.

7. Bảo mật theo Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP

Luật 91/2025/QH15 (hiệu lực 01/01/2026) và NĐ 356/2025/NĐ-CP phân loại dữ liệu y tế gắn với người có thể xác định là dữ liệu cá nhân nhạy cảm. Nghĩa vụ và chế tài phụ thuộc vai trò, hành vi và bối cảnh xử lý cụ thể. Kiến trúc bệnh án điện tử cần đưa yêu cầu bảo vệ dữ liệu vào threat model, DPIA khi áp dụng, kiểm soát truy cập và vận hành; dùng FHIR không làm thay đổi nghĩa vụ đó.

Cơ sở phải xác định vai trò xử lý và các nghĩa vụ tổ chức theo Luật 91/2025/QH15, NĐ 356/2025/NĐ-CP và văn bản áp dụng, gồm đầu mối bảo vệ dữ liệu hoặc hồ sơ đánh giá khi điều kiện pháp lý yêu cầu. Danh mục dữ liệu cần phân loại theo trường và mục đích xử lý; không nên coi tên Resource FHIR tự động quyết định mức nhạy cảm. Ma trận kiểm soát phải chỉ rõ căn cứ xử lý, sự kiện cần AuditEvent, dữ liệu cần Provenance và trường hợp cần Consent.

8. Audit log truy cập (AuditEvent)

Phạm vi sự kiện cần audit phải được xác định từ phân tích pháp lý, threat model, vai trò truy cập và chính sách an toàn của hệ thống. FHIR định nghĩa AuditEvent để biểu diễn sự kiện bảo mật/quyền riêng tư, nhưng máy chủ không tự sinh Resource này cho mọi interaction. AuditEvent khác Provenance: AuditEvent mô tả sự kiện hệ thống; Provenance mô tả nguồn gốc, biến đổi hoặc chứng thực dữ liệu.

{
  "resourceType": "AuditEvent",
  "type": {
    "system": "http://terminology.hl7.org/CodeSystem/audit-event-type",
    "code": "rest",
    "display": "RESTful Operation"
  },
  "subtype": [{
    "system": "http://hl7.org/fhir/restful-interaction",
    "code": "read"
  }],
  "action": "R",
  "recorded": "2026-04-30T17:30:00+07:00",
  "outcome": "0",
  "agent": [{
    "who": { "reference": "Practitioner/bs-tran-van-minh" },
    "requestor": true,
    "network": { "address": "10.20.30.40", "type": "2" }
  }],
  "source": {
    "site": "Benh vien Trung uong A",
    "observer": { "reference": "Device/emr-frontend-bm" }
  },
  "entity": [{
    "what": { "reference": "Composition/comp-bm-001" },
    "type": { "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type", "code": "2" }
  }]
}

9. Lộ trình triển khai theo cổng kiểm soát

Lộ trình dưới đây sắp xếp công việc theo bằng chứng hoàn thành, không ấn định số tháng. Thời lượng và chi phí phụ thuộc phạm vi workflow, chất lượng dữ liệu nguồn, mua sắm, yêu cầu an toàn và mức sẵn sàng của đối tác; phải được ước lượng sau discovery và pilot.

Business case phải tách chi phí xây dựng, license, terminology, migration, kiểm thử, an toàn thông tin, vận hành và thay đổi quy trình. Không sử dụng khoảng chi phí hoặc thời gian chung nếu chưa có bill of materials, dữ liệu hiện trạng và báo giá cùng phạm vi.

10. Câu hỏi thường gặp về bệnh án điện tử FHIR

Bệnh viện chúng tôi đã có EMR rồi, cần làm gì thêm với FHIR?

Bắt đầu bằng gap assessment đối với TT 13/2025/TT-BYT và contract liên thông: kiểm tra khả năng kết nối thông tin bệnh án với số định danh cá nhân cho các nhóm đối tượng được Điều 1 khoản 3 quy định, cùng cơ chế ký/xác thực, kiểm soát truy cập, audit và lưu trữ. Nếu phạm vi có luồng VNeID, đánh giá riêng theo đặc tả tích hợp áp dụng thay vì suy ra từ Thông tư. Có thể dựng FHIR façade trên hệ thống hiện có nếu mô hình dữ liệu hỗ trợ mapping ngữ nghĩa, reference, versioning và search cần thiết; nếu không, cần refactor hoặc migration có mục tiêu. Không thể kết luận trước rằng luôn phải viết lại hoặc luôn không cần viết lại EMR.

Có phải chuyển toàn bộ bệnh án lịch sử sang FHIR không?

Phạm vi migration phụ thuộc nghĩa vụ lưu trữ, use case truy xuất, chất lượng dữ liệu và kế hoạch chuyển đổi đã phê duyệt. DocumentReference có thể tham chiếu một tài liệu được bảo quản, nhưng không tự biến bản quét thành dữ liệu có cấu trúc hoặc tạo giá trị pháp lý; chữ ký, xác thực và bảo quản dài hạn phải được xử lý theo quy định áp dụng.

VNeID kết nối thế nào về mặt kỹ thuật?

Mô hình tham chiếu là: ứng dụng VNeID cấp token định danh; hệ thống bệnh viện xác thực token qua kênh định danh được phê duyệt; CCCD trong token được đối chiếu với Patient.identifier slice CCCD. VNeID không trở thành identifier riêng trên Patient. Với trao đổi dữ liệu, QĐ 1551/QĐ-BYT là nền tảng và QĐ 2062/QĐ-BYT là bản sửa đổi hiện hành: Phụ lục 02 quy định luồng data-sync/push cho khám sức khỏe, Phụ lục 03 quy định resource-sync/push cho tài nguyên sức khỏe. Endpoint đọc/hiển thị cho công dân qua VNeID Health vẫn là hợp đồng tích hợp riêng. Bệnh viện nên thiết kế đầu nối như bộ chuyển đổi thay thế được, không gắn vào định danh Patient.

Có khác biệt gì giữa Provenance và AuditEvent?

Provenance mô tả nguồn gốc, tác nhân, biến đổi hoặc chứng thực của dữ liệu; AuditEvent mô tả sự kiện bảo mật/quyền riêng tư như truy cập hoặc thao tác hệ thống. Chúng không hoán đổi cho nhau, nhưng cũng không mặc định bắt buộc cùng xuất hiện cho mọi Resource. Ma trận kiểm soát của workflow phải xác định sự kiện nào dùng loại nào và dữ liệu tối thiểu cần ghi.

FHIR có thay XML 4210 không?

Chưa. Dữ liệu đầu ra KCB BHYT vẫn theo chuỗi quy định XML hiện hành kế thừa từ QĐ 4210/QĐ-BYT và các văn bản sửa đổi/thay thế liên quan. Nếu hệ thống nguồn dùng FHIR, bệnh viện cần mapping và bộ chuyển đổi đã kiểm thử sang đúng phiên bản XML mà BHXH tiếp nhận. Chưa có văn bản chính thức thay toàn bộ luồng này bằng FHIR.

11. Tham chiếu pháp lý và đọc tiếp

Bản đồ trích dẫn

Đọc tiếp trong knowledge hub

Thuật ngữ

• EMR / EHR: Bệnh án điện tử / Hồ sơ sức khoẻ điện tử.
• Composition: Hợp phần — Resource đóng vai trò header bệnh án trong FHIR.
• Provenance: Resource mô tả nguồn gốc, tác nhân, biến đổi hoặc chứng thực; có thể mang chữ ký khi contract yêu cầu. Khác với AuditEvent.
• AuditEvent: Resource mô tả sự kiện bảo mật/quyền riêng tư. Phạm vi ghi log do ma trận pháp lý, rủi ro và chính sách quyết định; Luật 91/2025/QH15 không tự bắt buộc một AuditEvent cho mọi interaction.
• VerificationResult: Resource FHIR R4 hợp lệ để mô hình kết quả xác minh định danh hoặc chứng chỉ. Không nhầm với IdentityVerification — không tồn tại trong R4.
• VNeID: Ứng dụng định danh điện tử quốc gia. Trong VN Core, VNeID nằm ở lớp xác thực, không phải Patient.identifier.
• IPS: International Patient Summary — chuẩn FHIR cho tóm tắt sức khoẻ bệnh nhân xuyên biên giới.