FHIR Resource: 146 đơn vị dữ liệu cốt lõi

1. Resource là gì? Định nghĩa và cấu trúc chung

Trong FHIR, Resource là đơn vị dữ liệu cơ bản dùng để biểu diễn một khái niệm y tế. Một bệnh nhân là một Resource (Patient). Một lượt khám là một Resource (Encounter). Một kết quả xét nghiệm là một Resource (Observation). Mỗi Resource giải quyết đúng một việc — giống như mỗi viên gạch lego có một hình dáng riêng, nhưng tất cả đều ráp được với nhau theo một chuẩn chung.

Mỗi Resource có những đặc điểm bắt buộc sau:

• resourceType — chuỗi xác định loại Resource (ví dụ: "Patient", "Encounter").
• id — định danh logic của Resource đó trong server FHIR (do server gán hoặc client đề xuất khi PUT).
• meta — metadata gồm versionId, lastUpdated, profile, security, tag.
• Schema được định nghĩa bằng StructureDefinition — chính nó cũng là một Resource (loại Foundation).
• Có thể đọc/ghi qua REST API theo các tương tác chuẩn.

Tập tương tác RESTful chuẩn cho Resource trong R4:

read    GET    [base]/[type]/[id]
vread   GET    [base]/[type]/[id]/_history/[vid]
update  PUT    [base]/[type]/[id]
patch   PATCH  [base]/[type]/[id]
delete  DELETE [base]/[type]/[id]
create  POST   [base]/[type]
search  GET    [base]/[type]?[parameters]
history GET    [base]/[type]/[id]/_history

Lưu ý quan trọng: create là POST tới đường dẫn collection [base]/[type] (không kèm id — server sẽ tự sinh), trong khi update mới là PUT tới [base]/[type]/[id]. Lẫn lộn hai endpoint này là lỗi tích hợp phổ biến.

Về URL: phần lớn Resource (Patient, Encounter, Observation…) được định danh bằng logical/location URL dạng [base]/[type]/[id] và bằng business identifier (số CCCD, số thẻ BHYT…). Chỉ một số Resource đặc biệt thuộc nhóm conformance/knowledge như StructureDefinition, CodeSystem, ValueSet, CapabilityStatement mới có trường url đóng vai trò canonical URL để tham chiếu xuyên hệ thống.

2. Anatomy: bốn phần của một Resource

Mọi Resource trong FHIR đều có cùng giải phẫu gồm bốn lớp. Hiểu lớp này một lần, bạn đọc được mọi Resource.

1. Metadata — id, meta, implicitRules, language, text (narrative XHTML render được cho con người đọc).
2. Extensions — extension[] cho dữ liệu mở rộng không phá vỡ ngữ nghĩa, và modifierExtension[] cho mở rộng có thể thay đổi ý nghĩa toàn bộ Resource.
3. Domain data — các trường đặc thù của loại Resource đó: Patient.name, Patient.gender, Encounter.period, Observation.value[x]…
4. Reference — link tới Resource khác qua kiểu dữ liệu Reference, ví dụ Encounter.subject trỏ tới Patient/vn-001.

Ví dụ một Patient hoàn chỉnh tuân thủ profile VN Core (đã rút gọn). Các đoạn {...} chỉ là pseudocode minh hoạ — JSON thật phải có giá trị cụ thể, và Narrative.div phải là XHTML hợp lệ chứ không phải dấu ba chấm:

// pseudocode — minh hoạ cấu trúc 4 lớp
{
  "resourceType": "Patient",
  "id": "vn-001",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2026-04-30T10:00:00+07:00",
    "profile": [
      "http://fhir.hl7.org.vn/core/StructureDefinition/vn-core-patient"
    ]
  },
  "text": {
    "status": "generated",
    "div": "
Nguyễn Thị Hoa, nữ, 1985-03-15
"
  },
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-ethnicity",
      "valueCoding": {
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-ethnicity-cs",
        "code": "01",
        "display": "Kinh"
      }
    }
  ],
  "identifier": [
    {
      "system": "http://fhir.hl7.org.vn/core/sid/cccd",
      "value": "001185000123"
    }
  ],
  "name": [
    {
      "use": "official",
      "family": "Nguyễn",
      "given": ["Thị", "Hoa"]
    }
  ],
  "gender": "female",
  "birthDate": "1985-03-15"
}

Trường meta.profile khai báo Patient này tuân thủ profile vn-core-patient — đó là cách VN Core ràng buộc Patient gốc thành Patient có dấu ấn Việt Nam (CCCD bắt buộc, dân tộc bắt buộc, địa chỉ phải có cấp xã/phường).

3. Phân loại 146 Resource theo 5 nhóm chính

FHIR R4 chia 146 Resource thành 5 nhóm cấp cao theo trang Resource Index chính thức: Foundation, Base, Clinical, Financial, Specialized. Trong đó, các sub-domain như Workflow, Documents, Medications thường được nhắc đến độc lập trong tài liệu cộng đồng nhưng về mặt phân loại chính thức, chúng nằm bên trong Clinical/Base.

Số lượng Resource trên trang chính thức hl7.org/fhir/R4/resourcelist.html là 146. Đây là số được dùng nhất quán trong title, hero, và toàn bộ trang này. Các tài liệu cũ ghi 145 hoặc 147 thường lệch do tính kèm/loại trừ các abstract Resource như Resource và DomainResource.

4. 12 Resource cốt lõi cho EMR Việt Nam

Triển khai bệnh án điện tử theo Thông tư 13/2025/TT-BYT không cần dùng cả 146 Resource. VN Core IG ưu tiên 12 Resource đáp ứng tối thiểu cho luồng khám chữa bệnh và thanh toán BHYT — ánh xạ sang profile VN Core như sau:

5. Maturity level và Standards Status

FHIR phân biệt hai khái niệm dễ nhầm: FHIR Maturity Model (FMM) và Standards Status.

• FMM 0 — draft, mới chỉ có xương sống.
• FMM 1 — published nhưng chưa có implementer phản hồi.
• FMM 2 — đã có ít nhất một implementer xác nhận.
• FMM 3 — đã được test interoperability ở connectathon.
• FMM 4 — production trên nhiều môi trường, đủ ổn để build trên đó.
• FMM 5 — chỉ còn chờ hoàn tất quá trình review để lên Normative.

Standards Status nằm trên FMM, có ba mức: Draft, Trial Use, Normative. Khi một Resource (hoặc artifact) đã Normative, HL7 cam kết không thay đổi breaking trên nhánh chính của bản đó nữa.

Trong R4, danh sách Normative gồm 13 entries (theo trang resourcelist.html của HL7), bao gồm cả các base abstract như Resource và DomainResource. Các Resource Normative tiêu biểu: Patient, Observation, Bundle. Lưu ý quan trọng: nhiều Resource phổ biến trong thực tế triển khai ở Việt Nam — gồm AllergyIntolerance, Encounter, Practitioner, Organization, Location — vẫn ở mức Trial Use trong R4. Điều này không có nghĩa là chúng không an toàn để dùng, chỉ có nghĩa là HL7 vẫn giữ quyền điều chỉnh giữa các bản phát hành.

Khi chọn Resource cho EMR sản xuất, hãy đọc cả FMM lẫn Standards Status để cân đối giữa độ ổn định và độ phù hợp use case.

6. Resource vs Profile vs Instance

Ba khái niệm này thường gây nhầm lẫn cho người mới. Cách hiểu đơn giản nhất là theo trục trừu tượng:

Resource (FHIR base)          ←  định nghĩa trừu tượng, áp dụng toàn cầu
   ↓ ràng buộc thêm cho ngữ cảnh
Profile (VNCorePatient)       ←  ràng buộc Patient cho Việt Nam
   ↓ điền dữ liệu thật
Instance (Patient/vn-001)     ←  bệnh nhân thật trong hệ thống

Resource là khái niệm gốc — Patient nói chung. Profile là StructureDefinition ràng buộc thêm — VNCorePatient bắt buộc identifier phải có ít nhất một CCCD. Instance là dữ liệu cụ thể — bệnh nhân Nguyễn Thị Hoa với CCCD 001185000123. Một Instance có thể tuân thủ nhiều Profile cùng lúc nếu khai báo trong meta.profile.

7. Bundle: gom nhiều Resource trong một transaction

Bundle là Resource đặc biệt đóng vai trò container — chứa nhiều Resource khác qua trường entry[]. Bundle là cách FHIR gửi nhiều Resource trong một request HTTP, hoặc đóng gói một bệnh án điện tử thành một file ký số duy nhất.

R4 định nghĩa 5 type Bundle (qua trường Bundle.type) phổ biến trong thực tế:

• transaction — atomic. Server xử lý tất cả entry như một transaction; nếu một entry lỗi, toàn bộ rollback.
• batch — không atomic. Mỗi entry độc lập; entry này lỗi không ảnh hưởng entry khác.
• searchset — kết quả trả về của thao tác search (GET /Patient?...).
• document — bệnh án/báo cáo đóng gói: entry đầu tiên là Composition, các entry sau là Resource được tham chiếu. Tương đương khái niệm CDA Document.
• message — gói tin sự kiện workflow, thay thế HL7 v2 message paradigm.

Ngoài 5 type chính kể trên, R4 còn có history, collection, và các type cho subscription notification — nhưng đối với EMR Việt Nam, 5 type kể trên đáp ứng hầu hết kịch bản tích hợp.

8. Versioning với meta.versionId

Mỗi Resource có thể có nhiều phiên bản theo thời gian. FHIR quản lý điều này qua trường meta.versionId — một chuỗi định danh phiên bản do server gán, có tính chất opaque (không bắt buộc là số nguyên tăng dần). Mỗi khi server tạo một phiên bản mới của Resource, versionId được cập nhật, kèm meta.lastUpdated.

Versioning chỉ hoạt động nếu server khai báo hỗ trợ. Năng lực này được thể hiện trong CapabilityStatement.rest.resource.versioning với ba giá trị: no-version, versioned, versioned-update. Server có thể tạo phiên bản mới qua nhiều thao tác — không chỉ PUT, mà cả PATCH, DELETE, hoặc các operation định nghĩa riêng.

Hai endpoint quan trọng cho versioning:

GET /Patient/vn-001/_history          # toàn bộ lịch sử (Bundle type=history)
GET /Patient/vn-001/_history/3        # đọc phiên bản số 3 (vread)

Khi cập nhật Resource, client có thể gửi kèm header If-Match: W/"3" để bảo đảm chỉ ghi đè khi phiên bản hiện tại trên server đúng là 3 — chống ghi đè đồng thời (optimistic locking). Đây là cơ chế quan trọng để bảo vệ tính toàn vẹn của bệnh án điện tử khi nhiều bác sĩ cùng cập nhật.

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

Resource có thể tự định nghĩa thêm không?

Không. FHIR khuyến nghị không tạo Resource hoàn toàn mới. Mọi nhu cầu mở rộng nên thực hiện qua Extension trên Resource sẵn có, hoặc qua Profile ràng buộc thêm. Chỉ trong trường hợp thực sự không có Resource nào phù hợp, HL7 mới xét duyệt thêm Resource vào release tiếp theo.

Patient và Person khác nhau thế nào?

Patient là đối tượng được chăm sóc (subject of care) trong một bối cảnh y tế cụ thể — một bệnh nhân tại Bệnh viện Bạch Mai. Person là khái niệm rộng hơn dùng để liên kết identity của cùng một con người qua nhiều hệ thống khác nhau (Patient ở BV A, Practitioner ở BV B, RelatedPerson trong hồ sơ con nhỏ…). Trong EMR đơn lẻ, bạn dùng Patient. Trong HIE liên thông, bạn cần Person.

Encounter và EpisodeOfCare khác nhau thế nào?

Encounter là một lượt khám đơn lẻ — một lần khám ngoại trú, một đợt nội trú từ nhập viện đến xuất viện. EpisodeOfCare là chuỗi nhiều Encounter cho cùng một vấn đề lâm sàng — ví dụ một đợt điều trị ung thư kéo dài 6 tháng gồm 12 Encounter hoá trị. EpisodeOfCare phù hợp khi cần báo cáo tổng hợp chi phí và kết quả điều trị theo bệnh, không theo lượt.

Có cần dùng cả 146 Resource khi triển khai EMR không?

Không. Bắt đầu với 12 Resource cốt lõi VN Core. Khi mở rộng sang quản lý dược, thêm Medication, MedicationDispense, MedicationAdministration. Khi mở rộng sang chẩn đoán hình ảnh, thêm ImagingStudy. Khi mở rộng sang nghiên cứu, thêm ResearchStudy. Triết lý FHIR là add as you grow.

Khi nào nên dùng Bundle thay vì gửi từng Resource riêng?

Dùng transaction Bundle khi cần atomic — ví dụ tạo Patient + Encounter + 5 Observation cùng lúc, không được nửa thành công nửa thất bại. Dùng document Bundle khi cần đóng gói bệnh án điện tử thành một file ký số duy nhất theo TT 13/2025/TT-BYT. Dùng message Bundle khi sự kiện cần xử lý theo ngữ cảnh (admit, discharge, transfer).

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

Nguồn chuẩn quốc tế

• FHIR R4 — Resource Index (146 Resource, 5 nhóm chính)
• FHIR R4 — Resource definition
• FHIR R4 — RESTful API (create, read, update, delete, search, history)
• FHIR R4 — Standards Status (Draft / Trial Use / Normative)
• FHIR R4 — Bundle (transaction, batch, searchset, document, message)
• FHIR R4 — JSON serialization

Văn bản pháp lý Việt Nam tham chiếu

• TT 13/2025/TT-BYT — Bệnh án điện tử (ban hành 06/06/2025, hiệu lực 21/07/2025) — driver chính cho VNCoreComposition và 12 Resource cốt lõi.
• QĐ 4469/QĐ-BYT (28/10/2020) — Bảng phân loại quốc tế bệnh tật ICD-10 phiên bản Việt Nam — binding cho VNCoreCondition.
• QĐ 387/QĐ-BYT (05/02/2026) — Bảng phân loại ICD-9-CM phẫu thuật, thủ thuật bản 2026 — binding cho VNCoreProcedure.
• QĐ 3176/QĐ-BYT (29/10/2024) — Chuẩn dữ liệu đầu ra KCB — input cho VNCoreClaim.
• TT 26/2025/TT-BYT (30/06/2025) — Kê đơn thuốc hoá dược, sinh phẩm ngoại trú — binding cho VNCoreMedicationRequest.
• Tham khảo đầy đủ 101 văn bản tại Khung pháp lý y tế VN.

Đọc tiếp trong knowledge hub