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 hóa độ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 hóa 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

Khả năng tái sử dụng một câu AQL qua các phiên bản dữ liệu phụ thuộc vào tính ổn định của archetype path, quy tắc versioning và chiến lược migration của kho dữ liệu; đặc tả không tạo ra bảo đảm thời gian cố định. So sánh với FHIR: FHIR Search định nghĩa cơ chế truy vấn qua REST, còn FHIRPath là ngôn ngữ biểu thức dùng trong invariant và nhiều định nghĩa computable — không phải API truy vấn REST tổng quát.

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 là một ứng viên kiến trúc khi yêu cầu cốt lõi là hồ sơ dọc thời gian, quản trị mô hình lâm sàng theo archetype và truy vấn AQL. Trước khi chọn, tổ chức cần xác minh các điều kiện sau bằng prototype hoặc pilot:

• Governance lâm sàng: có vai trò, quy trình review, versioning và phê duyệt archetype/template rõ ràng.
• Yêu cầu dữ liệu: truy vấn dọc thời gian và tái sử dụng mô hình đã được chứng minh trên dữ liệu đại diện, kể cả khi archetype thay đổi phiên bản.
• Năng lực vận hành: đội ngũ có thể quản trị mô hình, terminology, API, migration và an toàn dữ liệu; quy mô nhân sự phải được ước lượng từ pilot.
• Khả năng thay thế: xuất dữ liệu, chuyển nền tảng và tương thích phiên bản phải được kiểm thử; nhãn “vendor-neutral” không tự động loại bỏ lock-in ở mức sản phẩm.

7. Khi nào chọn FHIR

FHIR là ứng viên phù hợp khi yêu cầu chính là một hợp đồng trao đổi dữ liệu có thể kiểm thử giữa các hệ thống. Các dấu hiệu cần đánh giá gồm:

• Biên tích hợp: đối tác thống nhất FHIR/IG/package, canonical URL, terminology và các interaction trong CapabilityStatement.
• Nhiều kênh trao đổi: RESTful API, document hoặc message được chọn theo workflow; không suy ra mọi use case phải dùng REST.
• Năng lực triển khai: đội ngũ có thể profiling, validate, vận hành terminology và quản trị phiên bản; biết REST/JSON chỉ là nền tảng ban đầu.
• Tính thay thế: test suite chứng minh khả năng nhập/xuất đúng Profile và xử lý extension; dùng FHIR không tự động loại bỏ lock-in của sản phẩm.

FHIR Resource có thể được lưu bền vững, nhưng đặc tả không quy định kiến trúc cơ sở dữ liệu hay bảo đảm rằng một bộ Resource bất kỳ đáp ứng toàn bộ yêu cầu EHR. Cần đánh giá bằng Implementation Guide, CapabilityStatement, mô hình truy vấn, yêu cầu lưu giữ và dữ liệu thử của tổ chức.

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

Đây là một pattern kiến trúc khả thi, không phải mô hình mặc định của openEHR hay FHIR. Tài liệu chính thức của RNDS Brazil chứng minh việc dùng FHIR R4 ở lớp liên thông; tài liệu đó không đủ để suy ra công nghệ lưu trữ phía sau của từng bang hoặc bệnh viện. Tương tự, một chương trình chia sẻ dữ liệu không tự chứng minh rằng các hệ thống nguồn dùng openEHR.

[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]

Có thể kết hợp một openEHR CDR như EHRbase với FHIR server hoặc adapter. Tuy nhiên, tính năng và mức conformance phải được xác minh trên phiên bản sản phẩm cụ thể. Lớp FHIR chỉ tạo hợp đồng trao đổi khi Resource đầu ra tuân thủ Profile, terminology và CapabilityStatement đã công bố.

Chi phí của hybrid là độ phức tạp: phải duy trì hai mô hình dữ liệu, mapping hai chiều, terminology và quy tắc xử lý phần không thể biểu diễn tương đương. FHIR không tự tạo ra tuân thủ pháp lý; xác thực, phân quyền, audit, consent và lưu giữ vẫn là các kiểm soát triển khai riêng.

9. Đọc bằng chứng triển khai quốc tế

Ảnh chụp nguồn công khai được rà soát đến ngày 18/07/2026. Thay vì suy diễn thị phần theo quốc gia, bảng dưới tách điều một nguồn chính thức chứng minh khỏi điều nguồn đó không chứng minh.

Sự hiện diện của một standard, affiliate hoặc vendor không tương đương với adoption toàn quốc. Khi dùng số liệu triển khai, cần nêu ngày chụp, đơn vị đo, mẫu khảo sát và nguồn sơ cấp.

10. Bối cảnh Việt Nam: tách chuẩn trao đổi khỏi kiến trúc lưu trữ

QĐ 2146/QĐ-BYT ngày 15/07/2026 nêu HL7 FHIR R4 trong lộ trình liên thông dữ liệu y tế. Đây là căn cứ cho lớp trao đổi; văn bản không bắt buộc bệnh viện phải dùng FHIR hay openEHR làm mô hình lưu trữ nội bộ. Vì vậy quyết định kiến trúc cần tách thành các câu hỏi sau:

• Hợp đồng trao đổi: API và tài liệu trao đổi phải pin phiên bản FHIR/IG, CapabilityStatement và terminology.
• Kho dữ liệu nội bộ: lựa chọn relational, document, FHIR-native hoặc openEHR dựa trên truy vấn, lifecycle và governance dữ liệu.
• Lớp ánh xạ: nếu dùng hai mô hình, phải sở hữu mapping có version, provenance, kiểm thử round-trip và quy tắc xử lý mất mát dữ liệu.
• Bằng chứng vận hành: benchmark về nhân lực, chi phí và hiệu năng phải lấy từ pilot của chính tổ chức, không suy ra từ xu hướng quốc tế.

Khuyến nghị kỹ thuật cho một dự án đang áp dụng VN Core:

• Dùng FHIR R4 cùng VN Core IG làm data contract trial-use ở biên tích hợp khi đối tác thống nhất package và CapabilityStatement.
• Đánh giá openEHR độc lập cho use case cần governance archetype hoặc truy vấn dọc thời gian; không quyết định chỉ từ nhãn “EHR”.
• Chỉ chọn kiến trúc hybrid khi tổ chức chấp nhận vận hành hai mô hình và đã chứng minh mapping bằng fixture đại diện.
• Không dùng trang này thay cho hồ sơ kiến trúc, đánh giá an toàn hoặc quyết định mua sắm của một cơ sở cụ thể.

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

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

Không nên đặt quan hệ thay thế ở mức toàn bộ đặc tả. openEHR tập trung nền tảng EHR và governance archetype; FHIR tập trung mô hình thông tin cùng các hợp đồng trao đổi. Có thể triển khai riêng hoặc kết hợp, tùy phạm vi cần conformance; lựa chọn này không thể suy ra từ mức độ áp dụng toàn quốc vì chưa có phép đo công khai phù hợp.

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

FHIR có thể được lưu bền vững, nhưng đặc tả không quy định một kiến trúc cơ sở dữ liệu hay mô hình hồ sơ dọc duy nhất. Mức phù hợp phụ thuộc use case, truy vấn, lifecycle và governance; cần đánh giá bằng profile suite và dữ liệu thử đại diệ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 nên trì hoãn yêu cầu liên thông để chờ một công nghệ khác, nhưng cũng không nên suy ra kiến trúc lưu trữ từ yêu cầu trao đổi. Có thể triển khai data contract FHIR ở biên và đánh giá openEHR cho use case riêng, với điều kiện mapping và vận hành được kiểm thử.

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
• openEHR Affiliates và danh mục công cụ/sản phẩm — openehr.org/affiliates, openehr.org/tools-and-products
• 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