FHIR là gì? Tiêu chuẩn dữ liệu y tế thế hệ mới

1. FHIR là gì? Định nghĩa nhanh

FHIR viết tắt của Fast Healthcare Interoperability Resources — là tiêu chuẩn trao đổi dữ liệu y tế do tổ chức HL7 (Health Level Seven International) phát triển. Bản DSTU1 (Draft Standard for Trial Use) phát hành ngày 30/09/2014, do Grahame Grieve khởi xướng dựa trên dự án "Resources for Health" từ năm 2011.

Thay vì định nghĩa một cấu trúc file độc quyền, FHIR mô tả mô hình dữ liệu y tế dưới dạng các Resource độc lập, có thể tham gia nhiều paradigm: RESTful API, Documents, Messaging hoặc Operations/Services. Việc một Patient có thể được đọc qua REST, đóng trong Document hay dùng trong message phụ thuộc paradigm và contract mà hệ thống triển khai.

FHIR được công bố theo giấy phép CC0. Bản công bố mới nhất của base specification là R5 (5.0.0) và được gắn nhãn Trial Use; các artifact đã Normative từ R4 vẫn giữ nhãn đó. VN Core dùng R4 (4.0.1) làm phiên bản nền để tương thích với toolchain và các tài liệu tham chiếu R4; chẳng hạn US Core 9.0.0 hiện hành vẫn dựa trên R4.

Chữ "Fast" phản ánh mục tiêu rút ngắn vòng phản hồi của đặc tả và tận dụng kỹ năng REST/JSON phổ biến. Tuy vậy, triển khai vẫn đòi hỏi hiểu mô hình Resource, Profile, terminology, security và workflow của use case.

2. Vì sao FHIR ra đời? Bối cảnh sau HL7 v2/v3

Để hiểu bối cảnh thiết kế của FHIR, cần nhìn lại hai thế hệ chuẩn HL7 trước nó.

HL7 v2 (V2.0 phát hành tháng 9/1988) là chuẩn messaging pipe-delimited và vẫn hiện diện trong nhiều tích hợp HIS/LIS lâu năm. Mức sử dụng thực tế thay đổi theo thị trường và nhà cung cấp. V2 thường cần message profile và thỏa thuận song phương để xử lý khác biệt về segment, field và transport.

HL7 v3 (đầu những năm 2000) dùng Reference Information Model (RIM) và XML để tăng tính hình thức. Mô hình này có learning curve và chi phí triển khai cao hơn, nhưng vẫn được dùng trong một số chương trình và sản phẩm cụ thể; CDA cũng phát triển từ nền tảng v3.

FHIR ra đời với triết lý ưu tiên khả năng triển khai: dùng REST + JSON quen thuộc với lập trình viên web, giữ phần tử phổ biến trong Resource và xử lý nhu cầu địa phương qua extension có quản trị. Đặc tả có ví dụ; các triển khai nguồn mở như HAPI FHIR và nhiều sandbox công khai giúp đội kỹ thuật thử nghiệm. FHIR cũng là nền tảng của nhiều yêu cầu liên thông và Implementation Guide, trong đó có các quy định của Hoa Kỳ.

3. Tên gọi "FHIR" — đọc thế nào, nghĩa là gì

FHIR phát âm là "fire" /faɪər/ — như "lửa" trong tiếng Anh. Không đọc rời từng chữ "F-H-I-R". HL7 chọn brand color cam đỏ cho FHIR đúng theo metaphor "fire" — nóng, lan nhanh, năng lượng.

Bốn chữ trong tên đều có ý nghĩa kỹ thuật cụ thể:

• Fast — phát triển nhanh và triển khai nhanh.
• Healthcare — tập trung domain y tế, không phải general-purpose.
• Interoperability — mục tiêu chính: khả năng kết nối giữa các hệ thống.
• Resources — đơn vị dữ liệu, lấy cảm hứng từ "resource" trong REST architecture.

4. Bốn trụ cột thiết kế của FHIR

4.1. REST + HTTP

FHIR định nghĩa mô hình REST và tập interaction như read, create, update, delete và search. Một server không bắt buộc hỗ trợ mọi Resource hoặc mọi interaction: phạm vi thực tế phải được khai báo trong CapabilityStatement. Spec cũng hỗ trợ Documents, Messaging và Operations.

# Đọc Patient
curl -H "Accept: application/fhir+json" \
     https://hapi.fhir.org/baseR4/Patient/example

# Tìm kiếm
curl -H "Accept: application/fhir+json" \
     "https://hapi.fhir.org/baseR4/Patient?family=Nguyen&given=Lan"

# Tạo mới
curl -X POST -H "Content-Type: application/fhir+json" \
     -d @patient.json \
     https://hapi.fhir.org/baseR4/Patient

Khi endpoint hỗ trợ, POST có thể tạo mới, GET đọc hoặc search, PUT cập nhật và DELETE xóa. Mã trạng thái và OperationOutcome phụ thuộc interaction cùng kết quả xử lý. Client phải đọc CapabilityStatement và kiểm thử contract thay vì suy ra toàn bộ CRUD từ base spec.

4.2. Resource modular

R4 có 146 Resource — mỗi Resource là một loại dữ liệu y tế độc lập (Patient cho bệnh nhân, Observation cho kết quả xét nghiệm/sinh hiệu, Encounter cho lượt khám, MedicationRequest cho đơn thuốc…). Mỗi Resource có một StructureDefinition mô tả schema, có URL canonical, ví dụ http://hl7.org/fhir/StructureDefinition/Patient.

Tư duy LEGO: bạn ráp các Resource với nhau qua reference (Encounter.subject trỏ tới Patient, Observation.encounter trỏ tới Encounter…) để mô tả một ca khám hoàn chỉnh.

4.3. Đa định dạng (JSON / XML / Turtle)

FHIR định nghĩa cách biểu diễn Resource bằng JSON, XML và Turtle/RDF. Các representation được thiết kế để mang cùng nội dung FHIR, nhưng implementation vẫn phải validate việc chuyển đổi, extension và dữ liệu ngoài đặc tả thay vì mặc định round-trip luôn không mất dữ liệu.

4.4. Profile + Extension (mở rộng có kiểm soát)

Đây là chìa khóa để FHIR vừa chuẩn hóa toàn cầu, vừa cho phép bản địa hóa. Profile là ràng buộc thêm vào base Resource (ví dụ: VN Core Patient yêu cầu CCCD là Must Support, slicing identifier theo type). Extension là field mới mà base FHIR chưa có (ví dụ: vn-ext-bhyt-card cho thông tin thẻ BHYT, vn-ext-ethnicity cho 54 dân tộc Việt Nam).

Profile vẫn dẫn xuất từ base Resource. Client chỉ biết base FHIR có thể parse các phần tử cơ sở, nhưng phải xử lý extension và modifierExtension theo quy tắc an toàn; điều đó không tự động bảo đảm conformance hoặc tương tác ngữ nghĩa với VN Core.

Đào sâu: Profiling và Implementation Guide.

5. Một Resource trông như thế nào?

Dưới đây là một Patient theo VN Core IG với CCCD, dân tộc Kinh và tên Việt. Ví dụ dùng cú pháp FHIR R4; để kiểm tra tuân thủ đầy đủ, máy chủ hoặc validator phải nạp package VN Core và các dependency tương ứng.

{
  "resourceType": "Patient",
  "id": "vn-001",
  "meta": {
    "profile": [
      "http://fhir.hl7.org.vn/core/StructureDefinition/vn-core-patient"
    ]
  },
  "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"
          }
        ],
        "text": "Kinh"
      }
    }
  ],
  "identifier": [
    {
      "use": "official",
      "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"
          }
        ],
        "text": "Căn cước công dân"
      },
      "system": "http://fhir.hl7.org.vn/core/sid/cccd",
      "value": "001234567890"
    }
  ],
  "name": [
    {
      "use": "official",
      "family": "Nguyễn",
      "given": ["Thị", "Lan"]
    }
  ],
  "gender": "female",
  "birthDate": "1985-03-15",
  "address": [
    {
      "use": "home",
      "city": "Hà Nội",
      "country": "VN"
    }
  ]
}

Vài điểm đáng chú ý:

• meta.profile tuyên bố profile mà instance dự kiến tuân thủ; đây là assertion, không phải bằng chứng. Validator vẫn phải kiểm tra payload với đúng canonical và version của vn-core-patient.
• identifier.system dùng URI http://fhir.hl7.org.vn/core/sid/cccd theo NamingSystem VN Core (không phải URL NamingSystem/...).
• Extension dân tộc dùng valueCodeableConcept (không phải valueCoding) — bắt buộc theo VNCoreExtEthnicity, và CodeSystem có suffix -cs.
• CodeableConcept.text là phần tử tùy chọn; profile hoặc hướng dẫn triển khai có thể yêu cầu điền khi cần giữ display tiếng Việt ngoài coding.
• JSON UTF-8 — tên có dấu "Nguyễn" lưu trực tiếp, không cần escape.

6. 146 Resource trong FHIR R4 — phân loại

FHIR R4 (4.0.1) định nghĩa 146 Resource, được HL7 phân vào các "module" theo domain. Bảng dưới gom chúng thành 6 nhóm dễ nhớ cho người mới:

Một implementation thường chỉ chọn tập Resource cần cho use case và IG áp dụng, chẳng hạn Patient, Encounter, Observation hoặc MedicationRequest. Không có số lượng lõi chung cho mọi EMR; tập hỗ trợ phải được công bố trong CapabilityStatement.

Bảng đầy đủ và use case theo từng Resource: Danh sách FHIR Resource.

7. Bundle — gom nhiều Resource một lần

Trong thực tế, một thao tác y tế thường liên quan nhiều Resource cùng lúc. Bundle là Resource dùng để gom các entry trong một payload; R4 định nghĩa 9 loại:

• document — Composition + các Resource liên quan (giống CDA document).
• message — workflow event (giống HL7 v2 message).
• transaction — atomic, tất cả thành công hoặc rollback toàn bộ.
• transaction-response — kết quả của transaction.
• batch — không atomic, mỗi entry độc lập.
• batch-response — kết quả của batch.
• history — version history của 1 Resource.
• searchset — kết quả search.
• collection — tập entry không mang semantics transaction, document hoặc message.

Ví dụ thử nghiệm tại Việt Nam: một lượt khám gồm Encounter + Condition + Procedure + MedicationRequest + Observation có thể đóng gói thành Bundle transaction nếu endpoint công bố hỗ trợ interaction này và các entry tuân thủ IG áp dụng.

8. Các phiên bản FHIR (DSTU1 → R5) và vì sao VN Core chọn R4

R4 là một nền triển khai trưởng thành và là phiên bản đầu tiên có nội dung Normative; các artifact này chịu quy tắc thay đổi liên phiên bản chặt hơn. R5 (5.0.0, 03/2023) là bản base specification được công bố mới hơn nhưng toàn chu kỳ phát hành được gắn nhãn Trial Use. Vì vậy quyết định R4 hay R5 phải dựa trên CapabilityStatement, IG áp dụng và khả năng tương thích đầu-cuối, không chỉ dựa vào số phiên bản.

VN Core IG chọn R4 để giữ khả năng so sánh với repo VN Core năm 2024, tận dụng hệ sinh thái R4 trưởng thành và giảm chi phí phối hợp giữa các bên triển khai. Việc dẫn xuất hoặc tái sử dụng profile từ IG khác vẫn phải được kiểm tra theo đúng package, phiên bản và dependency cụ thể.

Chi tiết: FHIR Versions — DSTU1 đến R5.

9. FHIR tại Việt Nam — VN Core IG

Tại Việt Nam hiện có hai nguồn công khai cần phân biệt rõ về provenance và canonical:

• Repo github.com/hl7vn/vn-core-ig — metadata được công bố trong repo/IG ghi publisher là “Cục Công nghệ thông tin - Bộ Y tế” và canonical http://fhir.ehealth.gov.vn/core/. Hai trường metadata này mô tả nguồn phát hành và namespace kỹ thuật; tự chúng không phải bằng chứng repo hoặc nội dung của repo đã được cơ quan có thẩm quyền công nhận là chuẩn quốc gia chính thức.
• Sáng kiến trial-use hl7.org.vn — VN Core IG do Omi HealthTech khởi xướng và phát triển mở dưới giấy phép CC-BY-4.0. Canonical http://fhir.hl7.org.vn/core/, mục tiêu đạt baseline kỹ thuật có thể kiểm chứng trước khi đi vào quy trình governance chính thức với cơ quan có thẩm quyền.

Bản VN Core IG trial-use mô hình hóa các nhu cầu đặc thù Việt Nam mà base FHIR không cover sẵn: định danh (CCCD theo Luật Căn cước, mã BHXH 10 số, mã số BHYT 10 chữ số hiện hành hoặc số thẻ BHYT 15 ký tự legacy, hộ chiếu, MRN nội bộ), terminology (54 dân tộc theo TCTK, ICD-10 VN theo QĐ 4469/QĐ-BYT, danh mục đơn vị hành chính 34 tỉnh sau Nghị quyết 202/2025/QH15), và các use case tham chiếu về chuyển tuyến, thanh toán BHYT, VNeID và Sổ sức khỏe điện tử. Khả năng tích hợp thực tế còn phụ thuộc đặc tả và governance của từng hệ thống đích.

Thông tư 13/2025/TT-BYT về Bệnh án điện tử, Luật 91/2025/QH15 về Bảo vệ dữ liệu cá nhân và Nghị định 356/2025/NĐ-CP đặt ra yêu cầu về EMR, dữ liệu nhạy cảm và quản trị bảo vệ dữ liệu; các văn bản này không bắt buộc sử dụng FHIR. VN Core trial-use đang kiểm thử FHIR như một lớp trao đổi; kết nối BHYT hoặc VNeID còn phụ thuộc chuẩn dữ liệu, API và governance chính thức của từng hệ thống.

10. FHIR vs HL7 v2 — bảng so sánh

Không có mốc chung để FHIR thay thế HL7 v2. Hai chuẩn có thể cùng tồn tại khi thiết bị, nhà cung cấp hoặc đối tác còn dependency khác nhau. Mỗi interface phải chọn chuẩn theo use case, hợp đồng dữ liệu và năng lực endpoint; gateway song song là một phương án chuyển tiếp, không phải mô hình bắt buộc.

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

FHIR có thay thế HL7 v2 không?

Không có timeline thay thế chung. Quyết định giữ, chuyển đổi hoặc chạy song song phụ thuộc thiết bị, đối tác, message profile, IG đích và bằng chứng kiểm thử. Gateway là một lựa chọn khi cần bridge v2 và FHIR, không phải yêu cầu cho mọi hệ thống.

FHIR có miễn phí không?

Có. Base specification FHIR được công bố theo CC0. Sản phẩm, package terminology và thư viện đi kèm có thể có giấy phép riêng, nên vẫn cần kiểm tra dependency cụ thể.

Phải mua server FHIR nào?

Các lựa chọn thường gồm:

• Open source self-host: HAPI FHIR (Java), Microsoft FHIR Server (OSS) (.NET), Medplum (TypeScript, OSS + cloud). Chi phí vận hành và hỗ trợ vẫn phải được dự toán.
• Managed service (trả phí): Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake — tính phí theo storage/request, KHÔNG phải free và KHÔNG self-host được.

FHIR có lưu được tiếng Việt có dấu không?

Có. JSON FHIR mặc định UTF-8, lưu trực tiếp "Nguyễn Thị Lan" không cần escape. XML cũng UTF-8. Các trường name, address, display tiếng Việt không gặp vấn đề mã hóa nếu server và client cùng chuẩn UTF-8.

Bệnh viện tuyến huyện/xã có cần FHIR không?

FHIR chưa được TT 13/2025/TT-BYT quy định là chuẩn bắt buộc. Cơ sở chỉ cần triển khai khi use case, đối tác hoặc IG áp dụng yêu cầu; giao dịch BHYT hiện vẫn theo chuẩn dữ liệu đầu ra pháp lý. Sandbox với dữ liệu giả lập có thể dùng để đánh giá Patient, Encounter hoặc Observation trước production, nhưng phạm vi phải dựa trên nhu cầu và năng lực thực tế.

R4 hay R5 — VN Core nên dùng version nào?

VN Core hiện dùng R4. Chưa có lịch chuyển R5 được phê duyệt; quyết định chỉ nên được đưa ra sau đánh giá tác động package/profile, khả năng của các hệ thống tham gia, bằng chứng thử nghiệm và quy trình quản trị phát hành. Không nên suy ra mốc chuyển chỉ từ roadmap của một IG nước ngoài.

12. Đọc tiếp

Trong knowledge hub hl7.org.vn

Nguồn chính thức

• FHIR R4 specification (4.0.1) — hl7.org/fhir/R4
• Danh sách 146 Resource trong R4
• FHIR Version History — DSTU1 30/09/2014
• FHIR R5 specification (5.0.0)
• HAPI FHIR public sandbox — server test miễn phí

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

• Thông tư 13/2025/TT-BYT (06/06/2025) — Bệnh án điện tử, hiệu lực 21/07/2025.
• Luật 91/2025/QH15 (26/06/2025) — Bảo vệ dữ liệu cá nhân, hiệu lực 01/01/2026.
• Nghị định 356/2025/NĐ-CP (31/12/2025) — Hướng dẫn Luật BVDLCN, hiệu lực 01/01/2026.
• Quyết định 3176/QĐ-BYT (29/10/2024) — Chuẩn dữ liệu đầu ra KCB cho BHXH.
• Nghị quyết 202/2025/QH15 (12/06/2025) — Sắp xếp ĐVHC 34 tỉnh.
• Tham chiếu đầy đủ: Khung pháp lý — 206 văn bản/mục pháp lý y tế VN.