行业

为什么FHIR是“Better”

发表2017年8月3日
尼克·哈特(Nick Hatt)

HL7并不对FHIR标准中提供的改进感到羞耻(请参阅” 为什么FHIR是better” 在执行摘要中)。我将不研究冗长的FHIR教程,而是研究 HL7’s FHIR变得更好的十大理由,并阐明他们对我们今天在医疗保健领域实际经历的主张。

1.高度重视实施-快速且易于实施。
2.多个实现库,许多示例可用于启动开发。

自从我写第一篇文章以来的过去两年中,供应商已经证明,他们站起来FHIR服务器相对容易,例如 史诗 and 塞纳 沙箱。在Redox,我们仍然缺少一些有关卫生系统实现起来很容易的数据点,但是 我们的第一个FHIR连接已经上线了,并且大多数基础结构已经存在。

剩下的更大的问题之一是每个部署的标准化程度。如果部署不是标准化的,那么实施时间就会延长。我们的第一个实际实现相对容易,但是我们的产品设计灵活。

Argonaut项目的持久影响 是一套实施指南 只有时间会证明他们是否真的坚持不懈,以及EHR供应商需要多长时间才能适应FHIR的新变化。

3.规格是免费的,没有限制。

是的,文档在过去两年中也得到了很大的改进。人们对直到2013年才免费提供HL7标准并没有足够的重视(资源)。对我来说,这是医疗行业落后于互操作性和创新能力的一个被低估的原因。如果一家初创公司需要付费玩游戏,怎么能希望与大型EHR集成?

的 显着的问题 FHIR团队正在研究的内容仍然公开可见,这很棒。

4.开箱即用的互操作性-基本资源可以按原样使用,但也可以适应本地需求。
5. HL7第2版和CDA的演进发展路径-标准可以共存并相互利用

自从我撰写本文的第一个版本以来,扩展已经发展了很多。 患者资源例如,包含有关什么物种,品种以及是否已绝育患者的字段,而不是患者的种族或种族的字段。这可能有些奇怪,但它对于HL7的运行方式来说却是核心。

可能更令人担忧的是,扩展在多个轨道上不断增长,例如 跳频扩展的标准列表,但不同(尽管较小) Project Argonaut扩展列表.

扩展名可以指定为代码,这很好,但是我不会真正将其称为“开箱即用的互操作性”。

6. Web标准的坚实基础-XML,JSON,HTTP,Atom,OAuth等

在这方面没有任何改变,但是仍然缺少实际的实现示例。该标准冒着发布OAuth的风险,但实际上在幕后实际上具有略有不同的EHR实现。

跳频也做奇怪的事情。随着标准的发展,期望有更多未通过任何方式真正标准化的功能(在FHIR之外), 例如车厢 (在给定一种资源的情况下查找所有关联资源的方式)。

7.支持RESTful架构,并使用消息或文档无缝交换信息。

在过去的两年中,有趣的是,消息和文档的开发与标准的其余部分保持同步。这表明在将来,氧化还原样式的事件消息将占有一席之地,并且大量相关内容将以文档的形式出现(例如CDA)。

8.简洁明了的规格。
9.一种易于阅读的有线格式,便于开发人员使用。
10.基于实体的分析,带有严格的形式映射以确保正确性

在过去的两年中,FHIR的规范变得越来越复杂。未来可能会进行一些努力以简化工作,但是仍然有很多需要消化的地方-对于不熟悉现有HL7的人来说,存在误解规格的风险。

令人欣慰的是,EHR供应商文档和沙箱是基本FHIR规范的更现实替代。我很高兴看到这些内容继续在公开场合发展。

什么’s Next?

跳频正在采取适当的步骤成为下一个大事件。开放式开发和公众评论将帮助该标准的制定和替代其前身。

就目前而言,FHIR是对过去HL7标准的增量改进,而不是革命。我们越早摆脱炒作曲线并开始使用它来实际构建事物就越好。

在我们等待FHIR大规模采用和实施的过程中,供应商必须找到足够灵活的集成解决方案来满足当今的需求’明天的需求’的变化。在上查看此帖子 “您需要询问医疗保健API供应商的三个问题” to make sure you’re prepared.

编辑’注意:本文最初于2015年发布,并已进行了更新,以确保准确性和清晰度。