HL7 FHIR 和 openEHR 有什么关系？我知道 HL7 v2 等是互操作性的基本消息传递。但 FHIR 似乎以资源的形式为此添加了一些临床数据建模 - 在我看来，与有观察的患者就诊是临床模型，不是吗？当您添加 FHIR 服务器概念时，我们不是在接近 CDR 吗？
因此，openEHR 通过在模板中聚合的原型对相同的临床概念进行建模。- 太棒了（我想我明白了，看看它在 openEHR 中的位置）
下一步 - 互操作性的交叉点在哪里？
openEHR 是否旨在提供原型作为屏幕上模型的直接映射？我的理解是肯定的。（如果您愿意，数据源和 UI 互操作性）...即（以最简单的形式）-客户端调用服务器-服务器在数据上运行 AQL 并返回 XML 结果，客户端在其上运行 XSL 以生成 HTML-
但是 FHIR 不是更多关于互操作性，而 openEHR 不是关于数据建模吗？- 所以现在我们建议一个 openEHR 服务器将结果作为 openEHR 标准提供服务 - 我们尝试将其映射到 FHIR 资源并将其提供给前端或任何可互操作系统的系统。
我们是否应该选择一个而忘记另一个？
FHIR 以数据交换为目的对资源进行建模。
openEHR 定义了一个完整的 EHR 平台架构来管理临床数据结构定义（原型、模板），包括约束和术语/翻译，管理临床信息（规范信息模型），访问临床信息（标准查询语言 AQL），定义临床决策规则支持（标准规则语言 GDL），并定义服务模型（REST API 即将获得批准）。
因此，openEHR 是允许互操作性（不仅仅是数据交换）所需的所有内部东西，FHIR 是一个服务层，可以位于 openEHR 系统之上，因为其他服务层可以像 HL7 v2.x、IHE 配置文件、甚至是 DICOM 服务。
就 openEHR 上的 FHIR 而言，需要 openEHR 原型和 FHIR 资源之间的映射才能进行技术实现。因此，您可以拥有一个 openEHR CDR 并通过 FHIR 访问它。
就在 openEHR 系统上具有 GUI 而言，可以从原型中自动生成 GUI，并使用用于生成 GUI 的原型自动验证输入数据。这有很多实现，一些开源（我的 github repos 上有很多例子）。
底线：您可以使用 openEHR 创建您的 EHR，并提供一个或多个 API（自定义、openEHR、FHIR、HL7 v2.x、XDS ......）。