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 theo các kênh triển khai chính thức của Bộ Y tế. Ở phạm vi toàn quốc, lộ trình gắn với Thông tư 13/2025/TT-BYT, QĐ 1551/QĐ-BYT và các quyết định triển khai nền tảng số dùng chung; trang này chỉ mô tả lớp dữ liệu và tích hợp ở mức công khai, không tự gán tên cơ sở thí điểm nếu chưa có danh sách public ổn định.

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/QĐ-BYT, 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/QĐ-BYT 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 để khóa đú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/TT-BYT 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. Cần tách hai chiều kỹ thuật: chiều cơ sở KCB đồng bộ dữ liệu lên Bộ Y tế đã có đặc tả chính thức trong QĐ 1551/QĐ-BYT Phụ lục 02 và 03; chiều đọc/hiển thị cho công dân qua VNeID Health — scope OAuth, claim trong ID token, phân quyền theo loại tài liệu, refresh và thu hồi quyền — vẫn theo hướng dẫn riêng của cơ quan chủ quản. Nhà cung cấp và bệnh viện không nên hiện thực hóa scope OAuth hay endpoint đọc cho công dân nếu chưa có hợp đồng tích hợp và tài liệu kỹ thuật chính thức.

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 sau QĐ 1551/QĐ-BYT: chiều cơ sở KCB đồng bộ dữ liệu lên Bộ Y tế đã có đặc tả kỹ thuật công khai, còn chiều đọc/hiển thị cho công dân qua VNeID Health vẫn phụ thuộc hợp đồng tích hợp. Mục đích là giúp đội kỹ thuật bệnh viện chuẩn bị FHIR layer mà không tự sáng tác scope hay endpoint phía ứng dụng công dân.

[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)]
       │
       │ Đẩy lên: QĐ 1551/QĐ-BYT Phụ lục 02/03 · Đọc cho dân: chờ spec
       ↓
[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/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.

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/QH15.

6. FHIR IPS — pattern chuẩn hóa 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 hóa 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 hóa 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/QH15 quy định.

10. Xác thực và uỷ quyền — đồng bộ đã có spec (QĐ 1551/QĐ-BYT), đọc cho công dân còn chờ

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 thường được nhắc tới trong các thảo luận triển khai hồ sơ sức khỏe cá nhân.

Cần phân biệt hai chiều dữ liệu. Chiều đẩy lên (cơ sở KCB → Bộ Y tế) đã có đặc tả chính thức: QĐ 1551/QĐ-BYT (31/5/2026) Phụ lục 02 quy định API đồng bộ lên Cổng/Trục dữ liệu sức khỏe Bộ Y tế (RESTful/JSON, OAuth2 + Bearer Token, gói tin base64 + chữ ký số SHA256RSA), Phụ lục 03 quy định tiếp nhận từ BHXH qua NDOP/TTDLQG (dịch vụ G12, API Key, XML ký số). Chiều đọc/hiển thị cho công dân (VNeID Health) — scope/claim trong ID token, phân quyền theo loại tài liệu, refresh, thu hồi quyền — vẫn theo hướng dẫn riêng giữa Bộ Công an và Bộ Y tế, chưa công bố public đầy đủ. 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.

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

VNeID đã có spec API public chưa

Chiều đồng bộ dữ liệu cơ sở KCB → Bộ Y tế đã có đặc tả chính thức trong QĐ 1551/QĐ-BYT (31/5/2026, Phụ lục 02 và 03). Riêng spec đọc/hiển thị cho công dân qua VNeID Health (scope OAuth, claim ID token, endpoint đọc) vẫn theo hướng dẫn riêng, chưa công bố public đầy đủ. Bệnh viện và nhà cung cấp làm việc qua kênh chính thức của Bộ Y tế khi tham gia thí điểm; các API đồng bộ đã được model trong VN Core (LogicalModel envelope Phụ lục 02/03).

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. Nhà cung cấp 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 quy định FHIR là chuẩn bắt buộc 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.
• QĐ 1551/QĐ-BYT (31/5/2026) — liên thông khám sức khỏe định kỳ và đặc tả API đồng bộ Phụ lục 02/03. Mã trong VN Core: QD-1551-2026.
• 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/QH15, 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