FHIR và VNeID: Sổ sức khỏe điện tử quốc gia

1. VNeID và Sổ sức khỏe điện tử là gì

VNeID viết tắt của Vietnam Electronic Identification, là ứng dụng định danh điện tử quốc gia do Cục Cảnh sát quản lý hành chính về trật tự xã hội (Bộ Công an) phát triển. Ứng dụng cấp tài khoản định danh điện tử mức 1 và mức 2 cho công dân, gắn chặt với Căn cước công dân 12 số. Đây là cổng truy cập duy nhất cho nhiều dịch vụ công, gồm khai báo cư trú, giấy phép lái xe, bảo hiểm xã hội và bảo hiểm y tế.

Sổ sức khỏe điện tử là một mục trong VNeID, hiển thị thông tin y tế tóm tắt của công dân: tiền sử bệnh, dị ứng, tiêm chủng, đơn thuốc, kết quả xét nghiệm cơ bản và bệnh án xuất viện. Nội dung Sổ SKĐT được Bộ Y tế quy định, do hệ thống y tế cung cấp dữ liệu, còn VNeID đóng vai trò kênh hiển thị tới người dân. Mỗi công dân có một tài khoản VNeID gắn với CCCD 12 số và do đó có một Sổ SKĐT duy nhất.

Việc triển khai Sổ SKĐT đang được mở rộng dần. Một số bệnh viện đầu ngành như BV Bạch Mai, BV K và một số bệnh viện tại TPHCM đã thí điểm hiển thị bệnh án xuất viện lên Sổ SKĐT. Ở phạm vi toàn quốc, lộ trình triển khai gắn với Thông tư 13/2025/TT-BYT và các quyết định triển khai nền tảng số dùng chung của Bộ Y tế.

2. QĐ 1332/QĐ-BYT và phạm vi Sổ SKĐT

Quyết định 1332/QĐ-BYT ban hành Sổ sức khỏe điện tử phục vụ tích hợp trên ứng dụng VNeID, kèm tài liệu kỹ thuật mô tả phạm vi dữ liệu và format hiển thị. Quyết định này đặt Sổ SKĐT là nền tảng do Bộ Y tế quản lý nội dung, trong khi VNeID là kênh phân phối tới công dân. Cấu trúc Sổ SKĐT bao gồm các nhóm thông tin cơ bản, lịch sử khám chữa bệnh, đơn thuốc, kết quả cận lâm sàng và bệnh án xuất viện.

Bên cạnh QĐ 1332, các quyết định triển khai nền tảng số dùng chung của Bộ Y tế tiếp tục mô tả Sổ SKĐT là nền tảng thuộc Bộ Y tế. Cục Quản lý khám chữa bệnh và Trung tâm Thông tin y tế Quốc gia là các đơn vị trực tiếp tham gia vận hành. Đây là điểm cần ghi nhận đúng để tránh giả định nhầm rằng Bộ Công an là chủ quản dữ liệu y tế.

Khi thiết kế VN Core FHIR, bài viết coi QĐ 1332 là căn cứ cho định nghĩa phạm vi dữ liệu Sổ SKĐT. Tham chiếu trong CodeSystem VNLegalDocumentRefCS dùng mã QD-1332-VNeID để khoá đúng văn bản này, không nhầm với các quyết định khác cùng số.

3. TT 13/2025 và yêu cầu kết nối định danh điện tử

Thông tư 13/2025/TT-BYT (ban hành 06/06/2025, hiệu lực 21/07/2025) quy định bệnh án điện tử và thay thế Thông tư 46/2018/TT-BYT. Văn bản này đặt yêu cầu bệnh án điện tử phải liên thông với số định danh cá nhân hoặc tài khoản định danh điện tử của công dân. Đây là yêu cầu định danh, không phải điều khoản bắt buộc tích hợp một API VNeID cụ thể.

Việc tích hợp với VNeID là một con đường triển khai phù hợp với yêu cầu trên, do tài khoản định danh điện tử quốc gia hiện nay chính là VNeID. Tuy nhiên cách thức kỹ thuật để gọi sang VNeID Health, format payload, cơ chế đẩy hay kéo dữ liệu vẫn chờ Bộ Công an và Bộ Y tế công bố spec chính thức. Vendor và bệnh viện không nên hiện thực hoá scope OAuth hay endpoint cụ thể nếu chưa có hợp đồng tích hợp và tài liệu kỹ thuật từ cơ quan chủ quản.

4. Mẫu tích hợp FHIR với VNeID — mô hình tham chiếu

Phần dưới đây trình bày mô hình tham chiếu, mượn pattern phổ biến của Apple HealthKit và Google Health Records. Đây không phải đặc tả chính thức của VNeID Health. Mục đích là giúp đội kỹ thuật bệnh viện hình dung kiến trúc khả dĩ và chuẩn bị FHIR layer trước khi spec public.

[Bệnh viện EMR (FHIR-native)]
       │
       │ FHIR Bundle / DocumentReference (mô hình tham chiếu)
       ↓
[Cổng tích hợp y tế (Bộ Y tế điều phối)]
       │
       │ Giao thức cụ thể chờ spec VNeID Health
       ↓
[App VNeID trên smartphone của bệnh nhân]

Trong mô hình này, hai chiều dữ liệu khả dĩ là Push và Pull. Push nghĩa là bệnh viện đẩy bệnh án xuất viện và đơn thuốc lên cổng tích hợp ngay sau khi bệnh nhân đồng ý. Pull nghĩa là VNeID hoặc cổng tích hợp chủ động truy vấn bệnh viện theo yêu cầu của bệnh nhân. Cả hai mode đều phải có Consent rõ ràng theo Luật 91/2025 về bảo vệ dữ liệu cá nhân và Nghị định 356/2025/NĐ-CP hướng dẫn thi hành.

Lớp FHIR ở phía bệnh viện cần sẵn sàng các thành phần sau: VNCorePatient với CCCD làm primary identifier, Composition cho header bệnh án, DocumentReference cho file PDF ký số, Bundle dạng IPS để đóng gói tóm tắt, và Provenance cùng AuditEvent ghi nhận mọi truy cập từ phía VNeID.

5. FHIR và VNeID trong Sổ sức khỏe điện tử: Patient.identifier chỉ dùng CCCD

Đây là điểm thường bị hiểu sai khi triển khai. Trong VN Core, Patient.identifier chỉ dùng CCCD làm định danh lõi, kèm các slice phụ trợ như BHYT, BHXH, GKS, hộ chiếu và mã bệnh nhân nội viện. NamingSystem cho VNeID đã được đặt trạng thái retired trong dự án để chặn việc mô hình tài khoản VNeID như identifier ngang hàng với CCCD. Nguyên do là VNeID là kênh xác thực và hiển thị, không phải định danh y tế độc lập của bệnh nhân.

Trích lược từ profile thực tế input/fsh/profiles/VNCorePatient.fsh để minh hoạ slice identifier:

Profile: VNCorePatient
Parent: Patient

* identifier ^slicing.discriminator.type = #value
* identifier ^slicing.discriminator.path = "system"
* identifier ^slicing.rules = #open
* 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 — fallback 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 = $vn-sid-cccd (exactly)
* identifier[HC].system   = $vn-sid-passport (exactly)

// VNeID KHÔNG có slice riêng trong VNCorePatient core (VNVNeIDNS retired).
// Tham chiếu tài khoản VNeID (nếu cần) thực hiện ở integration layer
// qua AuditEvent / Provenance, không qua Patient.identifier core.

Khi cần ghi vết tài khoản VNeID đã đăng nhập (ví dụ trong audit log khi bệnh nhân tự xem bệnh án qua app), hệ thống dùng Provenance.agent hoặc AuditEvent.agent.policy trỏ đến URI tài khoản VNeID ở lớp tích hợp. Cách làm này tách bạch định danh y tế (CCCD) khỏi định danh phiên xác thực (VNeID), phù hợp với khuyến cáo của HL7 về security và với Luật 91/2025.

6. FHIR IPS — pattern chuẩn hoá Sổ SKĐT

International Patient Summary (IPS) là Implementation Guide do HL7 và CEN cùng phát triển, dựa trên ISO 27269. IPS định nghĩa Bundle FHIR chứa thông tin tối thiểu để cứu trợ y tế xuyên biên giới. Cấu trúc IPS phù hợp tự nhiên với mục tiêu của Sổ SKĐT: gọn nhẹ, tải nhanh trên thiết bị di động, có thể đọc ở nước ngoài khi công dân Việt Nam đi du lịch hoặc công tác.

IPS Bundle là tài liệu (type=document) gắn với một Composition gốc, mô tả các section và liên kết tới các resource lâm sàng. Các resource trong Bundle dùng đúng datatype FHIR R4, không phải định nghĩa mới. Việt Nam có thể profile lại IPS để gắn binding terminology phù hợp (ví dụ ICD-10 VN cho Condition, danh mục thuốc Bộ Y tế cho Medication), nhưng cấu trúc Bundle giữ nguyên để bảo đảm khả năng đọc trên thế giới.

7. Cấu trúc IPS STU2 — Required, Recommended và Optional

Tham chiếu IPS STU2 — phần Structure of the International Patient Summary — định nghĩa rõ ba mức bắt buộc của các section trong Composition.

Required (3 section bắt buộc)

1. Problem List — dùng Condition với clinical-status active/inactive/resolved và verification-status confirmed.
2. Allergies and Intolerances — dùng AllergyIntolerance.
3. Medication Summary — dùng MedicationStatement (ưu tiên) hoặc MedicationRequest.

Recommended (4 section khuyến nghị)

4. Immunizations — dùng Immunization, gắn với chương trình tiêm chủng mở rộng theo Luật Phòng bệnh 2025.
5. Diagnostic Results — dùng Observation (laboratory) và DiagnosticReport.
6. Procedures (History of) — dùng Procedure.
7. Medical Devices — dùng DeviceUseStatement cho máy trợ thính, máy tạo nhịp tim và các thiết bị y tế cấy ghép.

Optional (mục tuỳ chọn theo hoàn cảnh lâm sàng)

• History of Past Illness — Condition với clinical-status resolved hoặc inactive.
• Pregnancy Status / History — Observation.
• Functional Status — ClinicalImpression.
• Plan of Care — CarePlan.
• Advance Directives — mô hình bằng Consent với category phù hợp, hoặc DocumentReference cho văn bản gốc. FHIR R4 không có resource tên AdvanceDirective.
• Vital Signs — Observation (vital-signs category).
• Social History — Observation (social-history category).

Khung skeleton của một IPS Bundle (đã đơn giản hoá làm giả mã, chưa phải JSON đầy đủ chuẩn validate) như sau. Ở triển khai thật, Bundle phải có timestamp, mỗi entry phải có fullUrl, và Composition phải có đủ trường bắt buộc của FHIR R4 (status, type, subject, date, author, title).

// Pseudo-code minh hoạ — KHÔNG dùng trực tiếp để validate
Bundle {
  resourceType: "Bundle",
  type: "document",
  timestamp: "2026-04-30T17:00:00+07:00",
  identifier: { system: "http://fhir.hl7.org.vn/core/sid/skdt-bundle", value: "..." },
  entry: [
    { fullUrl: "urn:uuid:composition-1",
      resource: Composition { status, type, subject, date, author, title, section[...] } },
    { fullUrl: "urn:uuid:patient-1",     resource: Patient { ... } },
    { fullUrl: "urn:uuid:allergy-1",     resource: AllergyIntolerance { ... } },
    { fullUrl: "urn:uuid:condition-1",   resource: Condition { ... } },
    { fullUrl: "urn:uuid:medstmt-1",     resource: MedicationStatement { ... } },
    { fullUrl: "urn:uuid:immun-1",       resource: Immunization { ... } }
  ]
}

8. DocumentReference cho file PDF xuất viện

Bệnh án xuất viện ở Việt Nam thường tồn tại ở dạng PDF có ký số của bác sĩ và lãnh đạo khoa. Khi đẩy lên Sổ SKĐT, file PDF được tham chiếu qua resource DocumentReference. Loại tài liệu sử dụng mã LOINC tương ứng — ví dụ 18842-5 Discharge summary — kèm subject trỏ tới Patient và author trỏ tới Practitioner ký xác nhận.

{
  "resourceType": "DocumentReference",
  "status": "current",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "18842-5",
      "display": "Discharge summary"
    }]
  },
  "subject": { "reference": "Patient/vn-001" },
  "date": "2026-04-30T17:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-001" }],
  "content": [{
    "attachment": {
      "contentType": "application/pdf",
      "url": "https://bv.local/discharge/abc.pdf",
      "hash": "...",
      "size": 245000
    }
  }]
}

Trong Bundle IPS, DocumentReference có thể đứng song song với các Observation và Condition đã được FHIR-ize. Bệnh nhân khi mở Sổ SKĐT trên VNeID sẽ thấy bản tóm tắt cấu trúc kèm liên kết tới file PDF gốc nếu cần đầy đủ chi tiết và chữ ký số.

9. Consent cho Sổ sức khỏe điện tử VNeID

Luật 91/2025/QH15 về bảo vệ dữ liệu cá nhân và Nghị định 356/2025/NĐ-CP hướng dẫn thi hành đặt yêu cầu cao về sự đồng ý có thông báo. Dữ liệu y tế được phân loại là dữ liệu cá nhân nhạy cảm, do đó việc chia sẻ với bên thứ ba — gồm cả cổng tích hợp VNeID — phải có Consent rõ ràng và có thể truy vết. FHIR resource Consent là nơi mô hình hoá quyết định này.

{
  "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": "vneid-data-sharing",
      "display": "Chia sẻ dữ liệu với Sổ SKĐT trên VNeID"
    }]
  }],
  "patient": { "reference": "Patient/vn-001" },
  "dateTime": "2026-04-30T16:00:00+07:00",
  "policy": [{ "uri": "https://vneid.gov.vn/policy" }],
  "provision": {
    "type": "permit",
    "actor": [{
      "role": { "coding": [{ "code": "VNEID" }] },
      "reference": { "reference": "Organization/vneid" }
    }],
    "action": [{ "coding": [{ "code": "access" }] }]
  }
}

Consent cần ghi nhận trước khi đẩy bất kỳ Bundle hoặc DocumentReference nào lên cổng tích hợp. Khi bệnh nhân thu hồi đồng ý, hệ thống bệnh viện cập nhật Consent.status thành inactive và tạo Provenance ghi nhận hành động thu hồi. Cơ chế này hỗ trợ quyền truy cập, chỉnh sửa và xoá dữ liệu mà Luật 91/2025 quy định.

10. Xác thực và uỷ quyền — chờ spec VNeID Health

Hướng tích hợp khả dĩ là OAuth 2.0 kèm OpenID Connect, với VNeID đóng vai trò Identity Provider phía công dân. Bệnh nhân đăng nhập VNeID, nhận access token, sau đó cổng tích hợp y tế dùng token này để uỷ quyền cho bệnh viện đẩy hoặc lấy dữ liệu. Mô hình này tương tự Apple HealthKit và Google Health Records, vì vậy được nhắc đến nhiều trong cộng đồng vendor Việt Nam.

Tuy nhiên scope cụ thể, claim trong ID token, cách phân quyền giữa các loại tài liệu (bệnh án, đơn thuốc, kết quả xét nghiệm), tần suất refresh, mô hình thu hồi quyền, tất cả đều thuộc spec VNeID Health API mà Bộ Công an và Bộ Y tế chưa công bố public tại thời điểm tháng 04/2026. Bài viết không sáng tác tên scope như health-record.read để tránh dẫn lệch các đội phát triển. Khi spec chính thức ra, trang này sẽ được cập nhật với các claim, scope và endpoint thật.

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

VNeID đã có spec FHIR public chưa

Tới tháng 04/2026, spec API chính thức cho VNeID Health vẫn chưa được Bộ Công an và Bộ Y tế công bố public. Bệnh viện và vendor làm việc qua kênh chính thức của Bộ Y tế khi tham gia thí điểm. Mọi hướng dẫn kỹ thuật trong bài này là mô hình tham chiếu, chờ xác nhận chính thức.

Bệnh nhân không có VNeID thì xử lý thế nào

CCCD 12 số vẫn là định danh lõi trong VNCorePatient. Bệnh nhân không sử dụng VNeID vẫn có hồ sơ FHIR đầy đủ trong hệ thống bệnh viện. VNeID chỉ là kênh hiển thị bổ sung, không thay thế bệnh án nguồn ở bệnh viện.

Có sandbox để test VNeID API không

Hiện chưa có sandbox public. Vendor cần đăng ký với Bộ Công an hoặc thông qua chương trình thí điểm của Bộ Y tế. Khi tham gia, đội phát triển sẽ nhận được tài liệu kỹ thuật, môi trường test và scope tài khoản dành riêng cho dev.

Sổ SKĐT lưu trữ ở đâu

Theo các văn bản công khai (gồm QĐ 1332/QĐ-BYT về Sổ sức khỏe điện tử trên VNeID), Sổ SKĐT là nền tảng do Bộ Y tế quản lý, hiển thị trên VNeID. Vị trí lưu trữ vật lý chính thức cần được xác nhận qua tài liệu kiến trúc cụ thể, không nên kết luận khi chưa có nguồn xác thực.

FHIR có bắt buộc cho Sổ SKĐT không

Văn bản pháp lý hiện hành chưa bắt buộc FHIR cho Sổ SKĐT. Tuy nhiên IPS là pattern phù hợp nhất về mặt kỹ thuật, đồng thời tương thích với hướng đi của VN Core và xu hướng của các quốc gia có hồ sơ y tế quốc gia trên smartphone.

12. Tham chiếu pháp lý và kỹ thuật

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

• QĐ 1332/QĐ-BYT — Sổ sức khỏe điện tử trên VNeID. Mã trong VN Core: QD-1332-VNeID.
• TT 13/2025/TT-BYT (06/06/2025, hiệu lực 21/07/2025) — Bệnh án điện tử, yêu cầu liên thông số định danh cá nhân hoặc tài khoản định danh điện tử.
• Luật 91/2025/QH15 — Bảo vệ dữ liệu cá nhân, hiệu lực 01/01/2026. Mã trong VN Core: L-91-2025.
• NĐ 356/2025/NĐ-CP — Hướng dẫn Luật 91/2025, hiệu lực 01/01/2026.
• NĐ 102/2025/NĐ-CP — Quản lý dữ liệu y tế số, hiệu lực 01/07/2025.
• Tham khảo đầy đủ tại trang corpus pháp lý của VN Core.

Đặc tả kỹ thuật quốc tế

• FHIR R4 (4.0.1) — phiên bản dùng trong VN Core.
• International Patient Summary STU2 — pattern Bundle FHIR cho hồ sơ tóm tắt.
• Structure of the International Patient Summary — danh sách Required, Recommended, Optional.
• LOINC — mã loại tài liệu cho DocumentReference.
• FHIR Security — khuyến cáo về AuditEvent và Provenance.

Nguồn từ project VN Core

• input/fsh/profiles/VNCorePatient.fsh — định nghĩa slice identifier CCCD/BHYT/BHXH/GKS/HC/MRN.
• input/fsh/naming-systems/VNVNeIDNS.fsh — NamingSystem VNeID đã retired, ghi rõ lý do không dùng làm identifier core.
• input/fsh/terminology/VNLegalDocumentRefCS.fsh — CodeSystem các văn bản pháp lý tham chiếu trong IG.

Đọc tiếp