FHIR 和 openEHR 的关系

relationship between FHIR and openEHR

HL7 FHIR 和 openEHR 有什么关系? 我知道 HL7 v2 等是互操作性的基本消息传递。 但是 FHIR 似乎以资源的形式为此添加了一些临床数据建模——在我看来,对患者进行观察是一种临床模型,不是吗? 当您添加 FHIR 服务器概念时,我们不是在 CDR 上吗?

然后 openEHR 通过原型对相同的临床概念进行建模,并在模板中聚合。 - 太棒了(我想我明白了它在 openEHR 中的位置)

接下来 - 互操作性的交叉点在哪里?

openEHR 是否旨在 - 提供原型作为屏幕上模型的直接映射? 我的理解是肯定的。(数据源和 UI 互操作性,如果你愿意的话)... 即(以最简单的形式)- 客户端调用服务器 - 服务器对数据和 returns XML 结果运行 AQL,客户端对其运行 XSL 以生成 HTML -

但是 FHIR 不是更多关于互操作性,而 openEHR 不是更多关于数据建模吗? - 所以现在我们建议 openEHR 服务器将结果作为 openEHR 标准提供 - 我们尝试将其映射到 FHIR 资源并将其提供给前端或任何可互操作系统。

我们是否应该选择一个而忘记另一个?

FHIR 以数据交换为目的对资源建模。

openEHR 定义了一个完整的 EHR 平台架构来管理临床数据结构定义(原型、模板),包括约束和 terminology/translations、管理临床信息(规范信息模型)、访问临床信息(标准查询语言 AQL ), 定义临床决策支持规则(标准规则语言GDL),定义服务模型(REST API 即将获批)

因此,openEHR 是允许互操作性(不仅仅是数据交换)所需的所有内部内容,FHIR 是一个服务层,可以在 openEHR 系统之上,因为其他服务层可以像 HL7 v2.x、IHE 配置文件,甚至 DICOM 服务。

就 openEHR 上的 FHIR 而言,openEHR 原型和 FHIR 资源之间的映射需要技术实现。所以你可以有一个 openEHR CDR 并通过 FHIR 访问它。

就在 openEHR 系统上拥有 GUI 而言,可以从原型自动生成 GUI,并使用用于生成 GUI 的原型自动验证输入数据。这有很多实现,一些是开源的(我的 github 存储库中有很多示例)。

底线:您可以使用 openEHR 创建您的 EHR,并提供一个 API 或多个 API(自定义、openEHR、FHIR、HL7 v2.x、XDS、.. .).