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 (tài nguyên) độc lập, có thể được trao đổi qua nhiều paradigm khác nhau: RESTful API (phổ biến nhất), Documents (giống CDA), Messaging (giống HL7 v2), hoặc Operations/Services. Cùng một Patient resource có thể được GET qua REST, đính kèm trong Document, hoặc gửi đi qua message — vẫn cùng schema, cùng semantics.

FHIR được phát hành dưới giấy phép HL7 cho phép sử dụng tự do (FHIR® License + một số nội dung CC0). Spec hiện tại là R4 (4.0.1) phát hành 2019-10 — đây là phiên bản đầu tiên có nội dung "Normative" (Patient, Observation và một số resource cốt lõi đã ổn định, không thể breaking change), phần còn lại vẫn là STU (Standard for Trial Use). VN Core IG, US Core, JP Core, KR Core, AU Core đều dùng R4 làm baseline.

Chữ "Fast" trong tên có hai nghĩa: nhanh trong phát triển spec (release cycle ngắn, feedback từ implementer thường xuyên) và nhanh trong triển khai (DEV web đã quen REST/JSON, không phải học mô hình mới từ đầu).

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

Để hiểu vì sao FHIR thắng thế, 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, đến nay vẫn chạy trên hầu hết HIS/LIS toàn cầu. Điểm yếu: cú pháp khó debug (mọi thứ là chuỗi | và ^), schema lỏng nên mỗi vendor diễn giải một kiểu, transport mặc định MLLP qua TCP nội mạng — không phù hợp với web/mobile và cloud.

HL7 v3 (đầu những năm 2000) cố giải quyết điểm yếu của v2 bằng mô hình RIM (Reference Information Model) cực kỳ chặt chẽ, encoding XML. Vấn đề: learning curve quá dốc, XML quá nặng, và thực tế adoption rất hạn chế ngoài vài quốc gia (đáng chú ý là UK NHS với CDA).

FHIR ra đời với triết lý ngược lại: dùng REST + JSON mà mọi DEV web đã quen, áp dụng "80% rule" — Resource cốt lõi cover 80% use case, phần còn lại 20% xử lý qua extension. Spec ngắn gọn, có ví dụ, có server tham chiếu (HAPI FHIR), có public sandbox để DEV thử ngay. Kết quả: chỉ sau 5 năm kể từ DSTU1, FHIR đã trở thành mandate trong ONC Cures Act (Mỹ) và là backbone của hầu hết national IG mới.

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 (paradigm phổ biến nhất)

FHIR định nghĩa một RESTful API chuẩn cho mọi Resource. Đây là cách triển khai phổ biến nhất, mặc dù 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

CRUD chuẩn: POST tạo mới, GET đọc, PUT cập nhật, DELETE xóa, GET với query string để search. Mã trạng thái HTTP chuẩn (200/201/404/410/422). Nếu bạn đã làm REST API thì FHIR API không có gì lạ.

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)

Cùng một Resource có thể serialize thành JSON (phổ biến nhất, dùng cho web/mobile), XML (backward-compat với HL7 v3 và IHE XDS), hoặc Turtle/RDF (cho semantic web và nghiên cứu y khoa). Spec đảm bảo round-trip không mất dữ liệu giữa các định dạng.

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 nội đị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).

Quy tắc vàng: profile phải vẫn validate được như base Resource. Một client không hiểu VN Core vẫn đọc được Patient cơ bản — chỉ là không hiểu các extension Việt Nam mà thôi. Tương thích ngược được đảm bảo.

Đà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 — sample này tuân thủ ràng buộc của VNCorePatient profile (CCCD slice, ethnicity dùng valueCodeableConcept) và copy-paste-runnable trên server FHIR R4 bất kỳ.

{
  "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ố instance này tuân thủ vn-core-patient — server có thể validate strict.
• 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.
• Mọi CodeableConcept đều có text để giữ display tiếng Việt khi terminology server không resolve được code.
• 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:

Bạn không cần học hết 146 Resource. Hầu hết dự án EMR thực tế chỉ dùng 15-25 Resource cốt lõi (Patient, Encounter, Condition, Observation, MedicationRequest, DiagnosticReport, ServiceRequest, Procedure, Practitioner, Organization, Location, Coverage, Claim, Bundle, DocumentReference, Composition, AllergyIntolerance…).

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 đặc biệt dùng để gom nhiều Resource khác trong một payload, có 6 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ộ.
• batch — không atomic, mỗi entry độc lập.
• history — version history của 1 Resource.
• searchset — kết quả search.

Use case Việt Nam (mục tiêu tương lai): một lượt khám gồm Encounter + Condition + Procedure + MedicationRequest + Observation có thể đóng gói thành Bundle transaction để đẩy vào EMR trung tâm hoặc gateway nội bộ.

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

R4 là production baseline hiện tại của hệ sinh thái FHIR. Đây là phiên bản đầu tiên có một phần nội dung được HL7 đóng dấu "Normative" — nghĩa là Patient, Observation, một số Resource nền tảng đã ổn định và sẽ không có breaking change. Phần còn lại của R4 vẫn là STU (Standard for Trial Use). R5 (5.0.0, 03/2023) đã được publish và đang dần adopt, nhưng phần lớn ecosystem (server FHIR, IG quốc gia, HAPI library, Smart on FHIR app) vẫn ở R4 vì stability.

VN Core IG chọn R4 vì cùng lý do: tương thích tối đa với US Core, JP Core, KR Core, AU Core; HAPI FHIR và Microsoft FHIR Server đều có R4 server production-ready; toolchain SUSHI/IG Publisher đã ổn định cho R4.

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

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

Tại Việt Nam, công việc nội địa hóa FHIR có hai dòng song song:

• Repo gốc github.com/hl7vn/vn-core-ig — do nhân sự thuộc Cục CNTT (Bộ Y tế) khởi xướng từ 2024, canonical http://fhir.ehealth.gov.vn/core/, đã có 8 profile cơ bản (Patient, Practitioner, Encounter, ServiceRequest, Specimen, Location, HealthcareDepartment, CodeableConcept). Hiện tại repo có 9 commits, last update 07/2024, và chưa có cộng đồng đóng góp rộng.
• Sáng kiến cộng đồng hl7.org.vn — VN Core IG do Omi HealthTech (OmiGroup) 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 hoàn thiện toàn diện trước khi xin xác lập chính thức với cơ quan quản lý nhà nước.

Bản VN Core IG hiện hành xử lý các đặ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ố, thẻ BHYT 15 ký tự, 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à workflow (chuyển tuyến BHYT, thanh toán theo NĐ 188/2025/NĐ-CP, kết nối VNeID + Sổ sức khỏe điện tử).

Driver pháp lý chính cho FHIR adoption ở VN là Thông tư 13/2025/TT-BYT về Bệnh án điện tử (ban hành 06/06/2025, hiệu lực 21/07/2025), cùng với Luật 91/2025/QH15 về Bảo vệ dữ liệu cá nhân (hiệu lực 01/01/2026) và Nghị định 356/2025/NĐ-CP hướng dẫn chi tiết. Mục tiêu 2026-2027 là xây dựng tầng interop FHIR-based kết nối EMR + BHYT + VNeID.

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

FHIR không thay thế HL7 v2 ngay. Trong 10-15 năm tới, hai chuẩn sẽ tồn tại song song: HL7 v2 trong các tích hợp nội bộ HIS/LIS đã có sẵn; FHIR cho mọi tích hợp mới đặc biệt là EMR cross-org, BHYT API, VNeID, mobile health app, AI/ML pipeline. Hầu hết bệnh viện sẽ vận hành cả hai cùng lúc qua một interoperability gateway.

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

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

Sẽ thay thế dần trong 10-15 năm tới ở các tích hợp mới. HL7 v2 vẫn chạy ổn định trên hàng nghìn HIS/LIS toàn cầu nên việc thay thế hoàn toàn không xảy ra trong ngắn hạn. Mô hình thực tế là gateway tích hợp song song hai chuẩn.

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

Có. Spec FHIR phát hành dưới giấy phép HL7 cho phép sử dụng tự do, một số phần nội dung là CC0. Bạn có thể implement, host server, bán phần mềm dùng FHIR mà không phải trả phí license cho HL7.

Phải mua server FHIR nào?

Tách rõ hai nhóm:

• Open source self-host (miễn phí): HAPI FHIR (Java, server tham chiếu phổ biến nhất), Microsoft FHIR Server (OSS) (.NET, do Microsoft mở mã nguồn), Medplum (TypeScript, OSS + cloud).
• 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?

Nếu chỉ phục vụ nội bộ thì chưa bắt buộc. Tuy nhiên, để liên thông với BHYT (qua chuẩn dữ liệu đầu ra hiện hành), với BV tuyến trên qua chuyển tuyến, với VNeID cho Sổ sức khỏe điện tử, và để tuân thủ TT 13/2025/TT-BYT về Bệnh án điện tử (deadline 31/12/2026 cho cơ sở KCB ngoài bệnh viện), thì nên có lộ trình adopt FHIR ngay từ bây giờ. Các cơ sở quy mô lớn như BV Bạch Mai, BV Chợ Rẫy, BV ĐK Tỉnh đã chủ động thí điểm FHIR cho tích hợp EMR cross-system.

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

R4 cho 2026-2028. R5 mới publish 03/2023, ecosystem chưa đủ stable (HAPI FHIR R5, IG Publisher R5, Smart on FHIR R5 đều mới). Migration R4 → R5 có thể xem xét sau 2028 khi ecosystem chín và các IG quốc gia tham chiếu (US Core, JP Core) cũng đã chuyển.

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ý — 101 văn bản y tế VN.