我是openEHR(以及一般健康信息学)领域的新手,但发现自己仍然坚持这个问题。
HL7 FHIR和openEHR如何相关? 我知道HL7 v2等是互操作性的基本消息。 但是,FHIR似乎以资源的形式为此添加了一些临床数据模型 - 在我的脑海中访问一个临床模型没有? 当你添加一个FHIR服务器概念时,我们没有接近CDR吗?
然后openEHR通过Archetypes模拟相同的临床概念,在模板中聚合。 - 太棒了(我觉得我知道它在openEHR中的位置)
下一步 - 互操作性的交叉在哪里?
openEHR是否设计为 - 将Archetypes提供为屏幕上模型的直接映射? 我的理解是肯定的。(如果你愿意的话,数据源和UI互操作性)...... ie(最简单的形式) - 客户端调用Server - Server对数据运行AQL并返回XML结果,客户端运行XSL以生成HTML -
但FHIR不是关于数据建模的互操作性和openEHR吗? - 现在我们建议openEHR服务器将结果作为openEHR标准提供 - 我们尝试将其映射到FHIR资源并将其提供给前端或任何可互操作的系统。
我们应该选择一个而忘记另一个吗?
这里有很多 - 但正如我所说,我很困惑。
感谢。
答案 0 :(得分:2)
FHIR以数据交换为目的对资源进行建模。
openEHR定义了一个完整的EHR平台架构来管理临床数据结构定义(原型,模板),包括约束和术语/翻译,管理临床信息(规范信息模型),访问临床信息(标准查询语言AQL),定义规则用于临床决策支持(标准规则语言GDL),并定义服务模型(REST API即将获得批准)。
因此,openEHR是允许互操作性(不仅仅是数据交换)所需的所有内部资源,FHIR是一个服务层,可以位于openEHR系统之上,因为其他服务层可以像HL7 v2.x, IHE简介,甚至是DICOM服务。
就FHIR而非openEHR而言,openEHR原型与FHIR资源之间的映射需要技术实施。因此,您可以拥有openEHR CDR并通过FHIR访问它。
在通过openEHR系统建立GUI时,可以自动生成原型GUI,并使用用于生成GUI的原型自动验证输入数据。这有很多实现,一些开源(我的github repos上有很多例子)。
结论:您可以使用openEHR创建您的EHR,并提供API或许多API(自定义,openEHR,FHIR,HL7 v2.x,XDS,...)。