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 là ứng dụng định danh điện tử quốc gia do cơ quan thuộc Bộ Công an phát triển. Ứng dụng cung cấp một kênh truy cập cho nhiều dịch vụ công, gồm cư trú, giấy phép lái xe, bảo hiểm xã hội và bảo hiểm y tế; không nên gọi đây là kênh duy nhất khi từng dịch vụ còn có thể có cổng hoặc quy trình được phê duyệt khác.

Sổ sức khỏe điện tử là một mục trong VNeID để hiển thị thông tin y tế theo phạm vi được cơ quan có thẩm quyền công bố. Nội dung do hệ thống y tế cung cấp và Bộ Y tế quản trị, còn VNeID là kênh hiển thị. Không suy ra cardinality “một người — đúng một hồ sơ” ở tầng dữ liệu chỉ từ quan hệ tài khoản ứng dụng; việc hợp nhất hồ sơ cần quy tắc MPI và quản trị định danh riêng.

Việc triển khai Sổ SKĐT đang được mở rộng dần theo các kênh 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 được sửa đổi bởi QĐ 2062/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.

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 số định danh cá nhân

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. Điều 1 khoản 3 yêu cầu kết nối thông tin của hồ sơ 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ử theo pháp luật về căn cước. Đây là yêu cầu kết nối định danh, không phải hai phương án thay thế nhau và cũng không phải điều khoản bắt buộc tích hợp một API VNeID cụ thể.

Tích hợp VNeID là lớp ứng dụng/tích hợp riêng, phải căn cứ QĐ 1551/QĐ-BYT, QĐ 2062/QĐ-BYT và contract áp dụng; không suy ra từ Điều 1 khoản 3 TT 13/2025/TT-BYT. 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ó contract hợp nhất QĐ 1551/QĐ-BYT + QĐ 2062/QĐ-BYT; 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.

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 theo QĐ 1551/QĐ-BYT được sửa đổi bởi QĐ 2062/QĐ-BYT: chiều cơ sở KCB đồng bộ dữ liệu lên Bộ Y tế đã có đặc tả kỹ thuật, 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.

[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 + QĐ 2062/QĐ-BYT Phụ lục 02/03 · Đọc cho dân: contract riêng
       ↓
[App VNeID trên smartphone của bệnh nhân]

Trong mô hình tham chiếu này, hai chiều dữ liệu có thể được thiết kế là Push hoặc Pull. Push là cơ sở KCB gửi dữ liệu theo contract đã được phê duyệt; Pull là hệ thống đích truy vấn theo yêu cầu và phạm vi được phép. Mỗi luồng phải xác định rõ vai trò, mục đích, phạm vi và căn cứ xử lý. Chỉ khi sự đồng ý là căn cứ hoặc quyết định cần trao đổi thì mới mô hình hóa bằng FHIR Consent; không mặc định mọi luồng đều dựa trên consent.

Lớp FHIR ở phía bệnh viện có thể dùng VNCorePatient cho định danh y tế, Composition cho header bệnh án, DocumentReference cho tài liệu, Bundle theo pattern IPS cho tóm tắt, cùng Consent, Provenance và AuditEvent theo chính sách tích hợp. Phạm vi sự kiện phải audit và đối tượng cần provenance phải được quy định trong threat model, DPIA và hợp đồng tích hợp; FHIR server không tự phát sinh các Resource này.

5. FHIR và VNeID trong Sổ sức khỏe điện tử: CCCD là định danh công dân chính

Đâ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 = #pattern
* identifier ^slicing.discriminator.path = "type"
* 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].type = $vn-identifier-type-cs#CCCD
* identifier[BHYT].type = $vn-identifier-type-cs#BHYT
* identifier[BHXH].type = $vn-identifier-type-cs#BHXH
* identifier[GKS].type  = $vn-identifier-type-cs#GKS
* identifier[HC].type   = $vn-identifier-type-cs#HC
* identifier[MRN].type  = $vn-identifier-type-cs#MRN
* 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, hệ thống dùng AuditEvent.agent.who.identifier (hoặc agent.altId khi chỉ có chuỗi định danh); nếu đã có Resource đại diện actor thì dùng Provenance.agent.who. AuditEvent.agent.policy chỉ chứa URI chính sách áp dụng, không phải định danh tài khoản. 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).

6. FHIR IPS — nguồn so sánh cho Patient Summary

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 tài liệu FHIR tóm tắt thông tin thiết yếu để hỗ trợ chăm sóc ngoài kế hoạch, kể cả trong bối cảnh xuyên biên giới. Đây là mẫu tham chiếu đáng đánh giá cho một bản tóm tắt sức khỏe; lựa chọn IPS cho VNeID vẫn phải dựa trên dataset, contract, terminology, kiểm thử khả năng sử dụng và tiêu chí conformance chính thứ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. Một bản thích nghi quốc gia phải xử lý binding terminology và các ràng buộc địa phương mà không tự tuyên bố tương thích IPS. Khả năng trao đổi xuyên biên giới chỉ được xác nhận bằng đúng package/version, terminology và kiểm thử với hệ thống nhận.

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 một thiết kế dùng IPS, DocumentReference có thể đứng cùng các Observation và Condition. Việc VNeID hiển thị bản tóm tắt, liên kết PDF hay chữ ký phụ thuộc dataset, contract và giao diện chính thức; đoạn JSON này chỉ minh họa một phương án FHIR.

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

Dữ liệu y tế thuộc nhóm dữ liệu cá nhân nhạy cảm theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Mỗi luồng chia sẻ phải xác định chủ thể xử lý, bên nhận, mục đích, phạm vi và căn cứ xử lý theo trường hợp áp dụng. Khi quyết định đồng ý cần được trao đổi giữa các hệ thống, FHIR Consent có thể mô hình hóa quyết định đó; Resource này không tự tạo ra căn cứ pháp lý.

{
  "resourceType": "Consent",
  "status": "active",
  "scope": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentscope",
      "code": "patient-privacy"
    }]
  },
  "category": [{
    "coding": [{
      "system": "http://loinc.org",
      "code": "59284-0",
      "display": "Patient Consent"
    }]
  }],
  "patient": { "reference": "Patient/vn-001" },
  "dateTime": "2026-04-30T16:00:00+07:00",
  "policy": [{ "uri": "https://vneid.gov.vn/policy" }],
  "policyRule": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "OPTIN"
  },
  "provision": {
    "provision": [{
      "type": "permit",
      "period": { "start": "2026-04-30", "end": "2027-04-30" },
      "purpose": [{
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-consent-purpose-cs",
        "code": "EHRSHARE",
        "display": "Chia sẻ hồ sơ sức khỏe"
      }],
      "actor": [{
        "role": { "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
          "code": "IRCP",
          "display": "information recipient"
        }] },
        "reference": { "reference": "Organization/vneid-health-gateway" }
      }]
    }]
  }
}

Khi sự đồng ý là căn cứ xử lý, quyết định phải được ghi nhận và thực thi trước khi chia sẻ dữ liệu. Việc rút lại đồng ý phải đi qua workflow và kênh thực tế; bản ghi FHIR Consent được cập nhật theo policy phiên bản hóa áp dụng. Chỉ tạo AuditEvent hoặc Provenance khi ma trận sự kiện (event matrix) và semantics của luồng yêu cầu. Các quyền truy cập, chỉnh sửa hoặc xoá dữ liệu vẫn cần workflow riêng.

10. Xác thực và uỷ quyền — contract đồng bộ hợp nhất QĐ 1551/QĐ-BYT + QĐ 2062/QĐ-BYT

Các contract chiều đẩy đã công bố sử dụng OAuth2 Bearer cho những endpoint đồng bộ tương ứng. Thông tin này không xác lập một luồng OpenID Connect công khai phía công dân, token issuer, scope hay mô hình uỷ quyền đọc hồ sơ sức khỏe; các chi tiết đó thuộc contract tích hợp chính thức riêng.

Cần phân biệt hai chiều dữ liệu. Chiều đẩy lên (cơ sở KCB → Bộ Y tế) theo QĐ 1551/QĐ-BYT và phần sửa đổi hiện hành tại QĐ 2062/QĐ-BYT: Phụ lục 02 dùng luồng data-sync/push cho dữ liệu KSK; Phụ lục 03 dùng resource-sync/push, OAuth2 Bearer, payload ký RSA-SHA256 và metadata routing. Chiều đọc/hiển thị cho công dân (VNeID Health) vẫn là contract riêng giữa cơ quan chủ quản và đơn vị tích hợp. Bài viết không tự đặt scope như health-record.read.

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ế phải triển khai theo QĐ 1551/QĐ-BYT đọc hợp nhất với QĐ 2062/QĐ-BYT (Phụ lục 02 và 03 hiện hành). Riêng contract đọc/hiển thị cho công dân qua VNeID Health vẫn theo hướng dẫn riêng. Các envelope hiện hành được mô hình hóa trong VN Core bằng LogicalModel tương ứng.

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

Corpus công khai được rà soát chưa cung cấp sandbox hay đặc tả API VNeID dùng chung cho nhà phát triển. Điều kiện tham gia, tài liệu, môi trường thử nghiệm và tài khoản phải được xác nhận trực tiếp với cơ quan/chương trình có thẩm quyền; trang này không suy đoán quy trình đăng ký.

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 hoặc IPS là chuẩn bắt buộc cho Sổ SKĐT. IPS có thể được đánh giá như một pattern tóm tắt hồ sơ xuyên biên giới; việc dùng IPS, một profile nội địa khác hay định dạng do cơ quan có thẩm quyền công bố phải dựa trên dataset, endpoint, workflow và tiêu chí conformance thực tế.

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) — nền chương trình liên thông khám sức khỏe định kỳ. Mã: QD-1551-2026.
• QĐ 2062/QĐ-BYT (07/7/2026) — thay Phụ lục 01–03, bổ sung Phụ lục 04–05 và là căn cứ cho contract kỹ thuật KSK hiện hành. Mã: QD-2062-2026.
• TT 13/2025/TT-BYT (06/06/2025, hiệu lực 21/07/2025) — Điều 1 khoản 3 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ử; không quy định API VNeID.
• 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