openEHR vs FHIR: hai paradigm khác nhau cho hồ sơ sức khoẻ điện tử

1. openEHR là gì

openEHR là một bộ specification mở do openEHR International (trước đây là openEHR Foundation, thành lập năm 2003 tại Anh và Úc) duy trì. Mục tiêu của openEHR không phải là viết một format trao đổi, mà là định nghĩa toàn bộ kiến trúc cho một hệ thống lưu trữ hồ sơ sức khoẻ điện tử có khả năng tồn tại nhiều thập kỷ — gọi tắt là triết lý "viết một lần, dùng cả đời người bệnh".

Triết lý cốt lõi của openEHR là tách phần mềm khỏi tri thức lâm sàng. Phần mềm chỉ implement một Reference Model nhỏ và ổn định; toàn bộ khái niệm lâm sàng (huyết áp, nhịp thở, dị ứng) được mô tả ở tầng archetype có thể cập nhật mà không cần build lại hệ thống. Cộng đồng lâm sàng quốc tế quản trị các archetype này tại Clinical Knowledge Manager (CKM), một kho tri thức công khai được biên soạn theo quy trình peer review.

Toàn bộ specification của openEHR phát hành dưới giấy phép Creative Commons. Các implementation phổ biến gồm EhrBase (mã nguồn mở), Better Platform (Marand, Slovenia) và DIPS Arena (Bắc Âu).

2. Two-level modeling: Reference Model và Archetype

Đặc trưng quan trọng nhất của openEHR là kiến trúc hai tầng. Tầng trên là Reference Model — một mô hình dữ liệu nhỏ, ổn định, được implement trong code phần mềm. Tầng dưới là Archetype và Template — định nghĩa các khái niệm lâm sàng, nằm hoàn toàn ngoài code và có thể tiến hoá độc lập.

Tầng phần mềm   ────  openEHR Reference Model
                       (Composition, Section, Entry, DataValue...)
                       Ổn định, ít thay đổi
                       ─────────────────────────────────
                       Thay đổi liên tục
Tầng tri thức   ────  Archetype + Template
                       (Blood Pressure, Body Temperature, Allergy...)

Ý nghĩa thực tế: khi cộng đồng lâm sàng cần thêm trường "vị trí đo huyết áp" hay "tư thế đo", họ chỉ cần phát hành phiên bản archetype mới. Ứng dụng EHR đọc archetype mới và render form tương ứng — không cần release phần mềm. Đây là điểm khác biệt căn bản so với cách FHIR tiến hoá qua các phiên bản chuẩn (DSTU2, STU3, R4, R5).

Ngữ pháp two-level modeling này không phải sáng kiến độc quyền của openEHR. ISO 13606-2 đã chính thức adopt formalism archetype từ openEHR, nhưng bản thân ISO 13606-1 là một chuẩn riêng dành cho truyền thông EHR giữa các hệ thống. Nói cách khác, openEHR không phải implementation của ISO 13606 — chúng là hai dòng spec song song chia sẻ chung một di sản kiến trúc.

3. Archetype, Template và Clinical Knowledge Manager

Archetype trong openEHR là mô tả tối đa (maximum dataset) cho một khái niệm lâm sàng. Ví dụ archetype Blood Pressure trên CKM định nghĩa hơn 30 trường: tâm thu, tâm trương, vị trí đo (cánh tay phải/trái/đùi), tư thế (ngồi/nằm/đứng), kích cỡ vòng bít, ghi chú về thiết bị đo, độ tin cậy của giá trị đo, lý do nếu không đo được.

Template là cách tổ chức gom nhiều archetype lại thành một biểu mẫu cụ thể cho một use case cụ thể. Ví dụ template "Khám tổng quát ngoại trú" có thể bao gồm archetype Blood Pressure (chỉ chọn một số field bắt buộc), Body Weight, Body Height, Heart Rate, kèm phần ghi chú khám lâm sàng.

Quy trình governance trên CKM khá nghiêm ngặt: một bác sĩ đề xuất archetype mới, cộng đồng review qua nhiều vòng, version được đánh số theo semantic versioning, và mọi thay đổi đều được tracking. Đây là điểm mạnh kép — vừa đảm bảo chất lượng tri thức lâm sàng, vừa là rào cản cao đối với các tổ chức không có chuyên gia clinical informatics đầu tư dài hạn.

4. AQL: ngôn ngữ truy vấn ngữ nghĩa

AQL (Archetype Query Language) là ngôn ngữ truy vấn riêng của openEHR, cho phép viết câu lệnh dựa trên archetype thay vì dựa trên schema database vật lý. Cú pháp AQL gần giống SQL nhưng mọi path đều trỏ tới node trong archetype.

SELECT
  obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value AS systolic,
  obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value AS diastolic
FROM EHR e
   CONTAINS COMPOSITION c
      CONTAINS OBSERVATION obs[openEHR-EHR-OBSERVATION.blood_pressure.v2]
WHERE c/context/start_time > '2026-01-01T00:00:00Z'
ORDER BY c/context/start_time DESC

Một câu AQL viết hôm nay có thể chạy trên dữ liệu được ghi cách đây 10 năm với version archetype cũ hơn, miễn là path archetype còn tương thích — đó là lời hứa "future-proof" mà openEHR đặt làm điểm bán hàng chính. So sánh với FHIR: bên FHIR sử dụng FHIR Search cho truy vấn REST, trong khi FHIRPath là ngôn ngữ biểu thức phục vụ invariant, slicing và định nghĩa search parameter — không phải một query API tổng quát qua REST.

5. Bảng so sánh 10 trục

Mỗi cột tóm tắt cách openEHR và FHIR tiếp cận một khía cạnh kỹ thuật cụ thể. Lưu ý: bảng so sánh chứ không phải bảng cho điểm — không có cột "thắng".

6. Khi nào chọn openEHR

openEHR phát huy giá trị nhất khi tổ chức có cam kết dài hạn về governance tri thức lâm sàng và sẵn sàng đầu tư vào nhân sự chuyên trách. Một số tình huống điển hình:

• Quốc gia hoặc vùng triển khai EHR backbone — như Slovenia (national EHR), một số ICB của NHS England, các region tại Brazil. Khi dữ liệu cần tồn tại nhiều thập kỷ và cần thay đổi mô hình lâm sàng mà không re-build hệ thống, openEHR là kiến trúc phù hợp.
• Hệ thống bệnh viện lớn có clinical informatician — tổ chức có ít nhất 2-3 chuyên gia toàn thời gian phụ trách archetype design, template review, và làm việc với CKM cộng đồng quốc tế.
• Project nghiên cứu hoặc registry chuyên ngành — đăng ký bệnh ung thư, đái tháo đường, bệnh hiếm. Các use case này cần mô tả lâm sàng giàu ngữ nghĩa và data tồn tại lâu hơn vòng đời phần mềm.
• Ngân sách và timeline cho phép — thường mất 18-36 tháng từ khi quyết định chọn openEHR đến khi production ổn định, do cần xây dựng template suite, đào tạo đội ngũ, và tích hợp với hệ thống nguồn.

7. Khi nào chọn FHIR

FHIR phù hợp với phần lớn các tình huống thực tế hiện nay tại Việt Nam và đa phần thế giới đang phát triển. Bốn dấu hiệu nên ưu tiên FHIR:

• Cần API mở — kết nối ứng dụng di động, AI, cổng BHXH, sổ sức khoẻ điện tử trên VNeID. FHIR REST là cách trao đổi dữ liệu chuẩn được chấp nhận rộng rãi.
• Greenfield và deadline gấp — TT 13/2025/TT-BYT yêu cầu các cơ sở khám chữa bệnh ngoài bệnh viện hoàn thành EMR chậm nhất 31/12/2026. Triển khai FHIR-first nhanh hơn openEHR đáng kể.
• Đội ngũ developer chuẩn web — backend đã quen REST + JSON. Đường cong học FHIR ngắn hơn nhiều so với học RM + AQL.
• Tránh vendor lock-in — FHIR có hệ sinh thái tooling đa dạng (HAPI FHIR, Firely, Microsoft FHIR Service). Chuyển dữ liệu giữa các vendor dễ hơn so với data store openEHR proprietary.

Quan trọng: FHIR R4 hoàn toàn đủ cho lưu trữ EHR ở mức bệnh viện trung bình. Mặc dù FHIR không có cơ chế governance tri thức kiểu CKM, một Implementation Guide tốt với Profile và Extension được tài liệu hoá bài bản có thể đáp ứng phần lớn yêu cầu thực tế.

8. Mô hình hybrid: openEHR cho lưu trữ, FHIR cho exchange

Đây là mô hình mà một số quốc gia tiên tiến đang theo đuổi để lấy ưu điểm của cả hai. Brazil — qua hệ thống quốc gia Rede Nacional de Dados em Saúde (RNDS) — sử dụng FHIR R4 làm lớp interoperability quốc gia, trong khi nhiều bang và bệnh viện vẫn duy trì kho lưu trữ openEHR phía sau. NHS England triển khai openEHR ở mức từng Integrated Care Board (ICB) hoặc vendor cụ thể, kết hợp với chương trình Connecting Care Records dùng FHIR cho chia sẻ liên cơ sở.

[Bác sĩ nhập liệu]
       │
       │ Form (openEHR Template)
       ▼
[openEHR EHR Server (lưu trữ giàu ngữ nghĩa, AQL query nội bộ)]
       │
       │ AQL → mapping logic
       ▼
[FHIR Façade] ──── REST API ───→ [Mobile app, AI, cổng quốc gia, BHYT]

Bộ công cụ phổ biến cho mô hình này gồm EhrBase (lưu trữ openEHR mã nguồn mở) ghép với một FHIR server hoặc adapter; Better Platform thương mại cũng có FHIR endpoint built-in. Lợi ích là dữ liệu nội bộ giàu ngữ nghĩa và có governance, còn bên ngoài chỉ thấy các FHIR Resource chuẩn.

Chi phí của hybrid là độ phức tạp: phải duy trì hai mô hình dữ liệu, viết và bảo trì lớp mapping, xử lý khác biệt về terminology giữa archetype và profile. Mô hình này chỉ có ý nghĩa khi tổ chức đã cam kết với openEHR vì lý do khác (governance, lifecycle dữ liệu) và cần expose ra ngoài qua FHIR vì lý do tuân thủ hoặc kết nối.

9. Adoption trên thế giới

Bức tranh adoption tính đến đầu năm 2026, dựa trên tài liệu công khai của các cơ quan y tế quốc gia:

Lưu ý: bảng trên thể hiện trạng thái công khai; tình hình thực tế có thể khác do nhiều dự án không công bố. Nguồn cho row Brazil và Anh xem mục Tham chiếu cuối bài.

10. Bối cảnh Việt Nam: vì sao FHIR là path khả thi

Tính đến tháng 05/2026, theo khảo sát công khai của OmiGroup, Việt Nam gần như chưa có triển khai openEHR ở mức bệnh viện hay quốc gia. Có vài lý do cấu trúc:

• Thiếu chuyên gia clinical informatics — đào tạo về archetype design, AQL, ADL gần như không có tại các trường đại học y và CNTT y tế trong nước.
• Vendor HIS chưa hỗ trợ openEHR — các vendor lớn tại Việt Nam (Vietsens, Hợp Nhất, FPT.eHospital, OmiGroup) đều đang đầu tư vào FHIR R4. Chưa có vendor nào công bố lộ trình openEHR.
• Khung pháp lý nhắm vào interoperability — TT 13/2025/TT-BYT về bệnh án điện tử, NĐ 102/2025/NĐ-CP về quản lý dữ liệu y tế số, NĐ 278/2025/NĐ-CP về kết nối chia sẻ dữ liệu — tất cả đều tập trung vào trao đổi dữ liệu, không đặt ra yêu cầu cụ thể về kiến trúc lưu trữ.
• Lộ trình EMR rất gấp — bệnh viện hoàn thành EMR chậm nhất 30/9/2025 (đã qua deadline cho nhóm này), cơ sở khám chữa bệnh khác chậm nhất 31/12/2026. Quỹ thời gian không đủ cho một cuộc dịch chuyển sang openEHR có ý nghĩa.

Khuyến nghị từ OmiGroup cho giai đoạn 2026-2028:

• Triển khai FHIR R4 cùng VN Core IG làm chuẩn quốc gia chính thức cho EMR và trao đổi dữ liệu.
• Theo dõi openEHR cho các registry chuyên ngành nơi giá trị governance tri thức lâm sàng vượt trội — ví dụ đăng ký ung thư quốc gia, theo dõi bệnh hiếm, registry tim mạch can thiệp.
• Cân nhắc hybrid (EhrBase + FHIR façade) cho chuỗi bệnh viện lớn 5+ cơ sở, khi đó chi phí governance archetype có thể amortize qua nhiều cơ sở.
• Nếu một bệnh viện nghiên cứu (BV Bạch Mai, BV K, BV Chợ Rẫy, BV ĐHYD TP.HCM) muốn tiên phong openEHR, ưu tiên use case nghiên cứu thay vì thay thế HIS sản xuất.

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

openEHR có thay thế FHIR được không?

Không, vì hai chuẩn giải bài toán khác nhau. openEHR thiết kế cho lưu trữ EHR giàu ngữ nghĩa với governance archetype; FHIR thiết kế cho trao đổi dữ liệu qua REST API. Có thể dùng openEHR mà không cần FHIR (nội bộ một bệnh viện) hoặc dùng FHIR mà không cần openEHR (đa số trường hợp Việt Nam hiện nay), nhưng "thay thế" là cách đặt vấn đề sai.

FHIR có đủ cho lưu trữ EHR không?

Có, ở mức đa số bệnh viện. FHIR R4 cung cấp 146 Resource với mô hình dữ liệu đủ phong phú cho phần lớn use case lâm sàng. Hạn chế chính là không có cơ chế governance tri thức kiểu CKM — thay vào đó, phải dựa vào quy trình review Implementation Guide tốt và một profile suite bài bản.

ISO 13606 vs openEHR vs FHIR khác nhau ra sao?

ISO 13606 là chuẩn quốc tế cho truyền thông EHR (đặc biệt phần ISO 13606-1). openEHR là một specification và platform mở độc lập, không phải implementation của ISO 13606 — cả hai chia sẻ ngữ pháp two-level modeling và ISO 13606-2 đã adopt formalism archetype từ openEHR. FHIR là paradigm khác dựa trên Resource và REST API. Cả ba có thể coexist trong một kiến trúc.

Việt Nam có nên chờ openEHR mature trước khi triển khai EMR không?

Không. Khung pháp lý đã chốt deadline (TT 13/2025), cộng đồng và vendor trong nước đã chọn FHIR. Chờ đợi đồng nghĩa với việc trễ tuân thủ. Nếu sau này cần openEHR cho use case cụ thể, có thể bổ sung lớp lưu trữ openEHR phía dưới mà không phải bỏ đi đầu tư FHIR.

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

Nguồn chính

• openEHR International — openehr.org
• openEHR Specifications (Reference Model, ITS-REST 1.0.3 phát hành 19/12/2022, ITS-REST 1.1.0 trial) — specifications.openehr.org
• Clinical Knowledge Manager — ckm.openehr.org
• EhrBase open source openEHR backend — ehrbase.org
• RNDS Brazil (FHIR-based national interoperability) — rnds-guia.saude.gov.br, rnds-fhir.saude.gov.br
• NHS England Connecting Care Records Programme — england.nhs.uk
• ISO 13606-1:2019 — iso.org/standard/67868.html
• HL7 FHIR R4 Search — hl7.org/fhir/R4/search.html
• HL7 FHIR R4 FHIRPath — hl7.org/fhir/R4/fhirpath.html

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

• Thông tư 13/2025/TT-BYT — Bệnh án điện tử (ban hành 06/06/2025, hiệu lực 21/07/2025)
• Nghị định 102/2025/NĐ-CP — Quản lý dữ liệu y tế số (hiệu lực 01/07/2025)
• Nghị định 278/2025/NĐ-CP — Kết nối chia sẻ dữ liệu bắt buộc (hiệu lực 22/10/2025)

Đọc tiếp trong knowledge hub