FHIR Resource: 146 loại tài nguyên trong FHIR R4

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

Trong FHIR, Resource là đơn vị trao đổi thông tin cơ bản có định nghĩa cấu trúc và ngữ nghĩa riêng. Patient biểu diễn chủ thể được chăm sóc; Encounter biểu diễn tương tác chăm sóc; Observation biểu diễn phép đo hoặc nhận định. Các loại Resource dùng chung mô hình dữ liệu nền và có thể liên kết để tạo hồ sơ, tài liệu hoặc workflow, nhưng không phải loại nào cũng có narrative, modifier extension hay reference.

Các đặc điểm chung cần phân biệt:

• resourceType — bắt buộc trong biểu diễn JSON để xác định loại Resource; XML dùng tên phần tử gốc tương ứng.
• id — phần tử 0..1, dùng làm logical id khi instance có định danh logic trong ngữ cảnh trao đổi hoặc lưu trữ.
• meta — phần tử 0..1; có thể chứa versionId, lastUpdated, profile, security và tag.
• Schema được định nghĩa bằng StructureDefinition — chính nó cũng là một Resource (loại Foundation).
• Có thể được trao đổi qua REST, document, message hoặc cơ chế khác theo đặc tả và Implementation Guide áp dụng.

FHIR R4 định nghĩa các tương tác RESTful sau; một máy chủ có thể chỉ hỗ trợ một tập con cho từng loại Resource và phải công bố tập đó trong CapabilityStatement:

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

Nếu máy chủ hỗ trợ các tương tác tương ứng, create dùng POST tới đường dẫn collection [base]/[type]; update dùng PUT tới [base]/[type]/[id]. Client phải kiểm tra cả tương tác, điều kiện và profile được công bố thay vì giả định mọi endpoint đều khả dụng.

Về định danh: một instance được lưu trên FHIR server thường có location URL dạng [base]/[type]/[id]; business identifier như số định danh cá nhân hoặc mã BHXH có ngữ nghĩa khác với logical id. Các canonical Resource như StructureDefinition, CodeSystem, ValueSet và CapabilityStatement có phần tử url làm canonical URL ổn định để tham chiếu xuyên hệ thống.

2. Cấu trúc kế thừa: Resource và DomainResource

Không có một mô hình “bốn lớp” bắt buộc cho mọi Resource. Cấu trúc chung được xác định bằng quan hệ kế thừa trong đặc tả:

1. Resource — lớp nền có các phần tử tùy chọn id, meta, implicitRules và language.
2. DomainResource — lớp con bổ sung text, contained, extension và modifierExtension. Phần lớn Resource lâm sàng và hành chính, bao gồm Patient, kế thừa lớp này; một số loại như Bundle kế thừa trực tiếp Resource.
3. Phần tử theo miền — mỗi loại định nghĩa các trường riêng, ví dụ Patient.name, Encounter.period hoặc Observation.value[x].
4. Reference và terminology — chỉ xuất hiện ở những phần tử được định nghĩa tương ứng. Ví dụ Encounter.subject có thể tham chiếu Patient/vn-001; không phải mọi Resource đều chứa reference.

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ác phần tử thường gặp của DomainResource
{
  "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": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Nguyễn Thị Hoa, nữ, 1985-03-15</div>"
  },
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-ethnicity",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-ethnicity-cs",
            "code": "01",
            "display": "Kinh"
          }
        ]
      }
    }
  ],
  "identifier": [
    {
      "type": {
        "coding": [
          {
            "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-identifier-type-cs",
            "code": "CCCD",
            "display": "Căn cước công dân"
          }
        ]
      },
      "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. Trong v0.9.0, slice CCCD có cardinality 1..1 (có thể mang data-absent-reason trong ngoại lệ hợp lệ); extension dân tộc là tùy chọn nhưng phải dùng danh mục VN khi xuất hiện. Địa chỉ, nếu có, phải tuân thủ VNCoreAddress: mã tỉnh và xã/phường đều 0..1 MS, với invariant mức warning yêu cầu mã tỉnh cho địa chỉ có country = "VN".

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 loại Resource thường gặp trong phạm vi EMR

Phạm vi Resource phải được xác định từ use case, yêu cầu trao đổi, hồ sơ conformance và quy định áp dụng. Bảng sau là một tập minh hoạ gồm 12 loại thường gặp trong EMR và BHYT, không phải danh sách tối thiểu do Thông tư 13/2025/TT-BYT quy định:

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 — nội dung được công bố trong bản build hiện tại.
• FMM 1 — nhóm công tác đánh giá nội dung đã cơ bản hoàn chỉnh, sẵn sàng cho phản hồi và không còn cảnh báo build thuộc phạm vi tiêu chí.
• FMM 2 — đã được kiểm thử bởi ít nhất ba hệ thống phát triển độc lập trên phần lớn phạm vi.
• FMM 3 — đáp ứng tiêu chí chất lượng conformance, đã qua ballot chính thức và đạt ngưỡng phản hồi/substantive change quy định.
• FMM 4 — đã được kiểm thử trên toàn phạm vi, được công bố chính thức, có nhiều dự án nguyên mẫu và phải tham vấn implementer trước thay đổi không tương thích.
• FMM 5 — đã trải qua ít nhất hai chu kỳ phát hành chính thức ở FMM 1 trở lên và được dùng trong ít nhất năm hệ thống production độc lập tại hơn một quốc gia.

Standards Status là trục phân loại khác với FMM. FHIR dùng các trạng thái Draft, Trial Use, Normative, Informative và Deprecated tuỳ artifact hoặc phần nội dung. Nội dung Normative chịu các quy tắc tương thích liên phiên bản chặt chẽ; thay đổi vẫn có thể xảy ra trong giới hạn mà quy trình chuẩn cho phép, vì vậy không nên diễn giải là “đóng băng tuyệt đối”.

Trạng thái được công bố ở từng trang Resource và có thể khác nhau giữa các phần của đặc tả. Một Resource ở Trial Use vẫn có thể phù hợp cho production nếu profile, kiểm thử, quản trị phiên bản và kế hoạch nâng cấp được xác định rõ; ngược lại, trạng thái Normative không thay thế việc kiểm tra mức phù hợp với use case.

Khi chọn Resource cho EMR production, cần đọc FMM, Standards Status, CapabilityStatement của hệ thống và các ràng buộc trong IG đang áp dụng.

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 yêu cầu slice CCCD hiện diện với cardinality 1..1; trong ngoại lệ hợp lệ, slice có thể không có giá trị scalar nếu mang data-absent-reason và có căn cứ thay thế theo invariant. 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; meta.profile ghi nhận tuyên bố conformance nhưng URL được liệt kê không tự tạo hoặc chứng minh conformance.

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

Bundle là Resource container chứa các entry. Tuỳ Bundle.type, nó có thể biểu diễn một giao dịch, kết quả tìm kiếm, lịch sử, tài liệu hoặc thông điệp. Việc serialize hay ký Bundle không tự động làm cho nội dung trở thành một hồ sơ có giá trị pháp lý; chữ ký, định dạng lưu trữ và quy trình xác thực phải tuân theo chính sách và pháp luật áp dụng.

R4 định nghĩa chính xác 9 giá trị cho Bundle.type:

• 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?...).
• transaction-response — phản hồi cho transaction.
• batch-response — phản hồi cho batch.
• history — kết quả lịch sử của instance, type hoặc toàn hệ thống.
• document — tài liệu FHIR; entry đầu tiên phải là Composition và các entry cần đáp ứng quy tắc tài liệu của đặc tả.
• message — thông điệp sự kiện có MessageHeader ở entry đầu; đây là một mô hình FHIR, không phải tuyên bố thay thế mọi triển khai HL7 v2.
• collection — tập hợp entry không mang semantics của các loại trên.

subscription-notification không phải giá trị của Bundle.type trong FHIR R4. Chọn loại Bundle dựa trên semantics của trao đổi, không dựa trên một danh sách “phổ biến” cố định.

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        # vread với versionId opaque "3"

Khi máy chủ hỗ trợ version-aware update, client có thể gửi If-Match: W/"3" để yêu cầu chỉ cập nhật khi version hiện tại khớp giá trị opaque "3". Nếu không khớp, server trả 412 Precondition Failed. Đây là một cơ chế optimistic locking; phạm vi hỗ trợ phải được xác nhận trong CapabilityStatement.

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

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

Không nên tự đặt một loại Resource ngoài đặc tả rồi coi đó là FHIR interoperable. Trước hết cần đánh giá Resource hiện có, Profile, Extension và trong một số trường hợp Resource Basic. Đề xuất thêm một Resource lõi mới phải đi qua quy trình quản trị và ballot của HL7; Extension cũng chỉ phù hợp khi ngữ nghĩa thực sự là phần mở rộng của Resource đã chọn.

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

Patient là chủ thể được chăm sóc trong một bối cảnh y tế. Person có thể liên kết các vai trò và identity của cùng một con người, chẳng hạn Patient, Practitioner hoặc RelatedPerson. Một HIE hoặc MPI có thể dùng Person, nhưng cũng có thể áp dụng mô hình liên kết định danh khác; đây không phải Resource bắt buộc cho mọi HIE.

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 hóa 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. Hãy xác định tập Resource và profile tối thiểu từ use case, payload cần trao đổi, các dependency tham chiếu và yêu cầu pháp lý. Danh sách 12 loại trên chỉ là điểm tham khảo; một use case hẹp có thể cần ít hơn, trong khi tài liệu, dược, hình ảnh hoặc thanh toán có thể cần thêm nhiều loại khác.

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

Dùng transaction khi yêu cầu nghiệp vụ cần tính atomic và server công bố hỗ trợ. Dùng document khi cần semantics của tài liệu FHIR với Composition ở đầu. Dùng message khi thỏa thuận tích hợp chọn mô hình thông điệp FHIR. Thông tư 13/2025/TT-BYT không tự động biến mọi bệnh án thành document Bundle hay quy định Bundle phải là một file ký số duy nhất.

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) — bối cảnh nghiệp vụ cho triển khai EMR; văn bản không quy định tập 12 Resource trên.
• 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 đủ 206 văn bản/mục pháp lý tại Khung pháp lý y tế VN.

Đọc tiếp trong knowledge hub