文章
Claire Zheng · 八月 17 阅读大约需 4 分钟

FHIR标准和国际基于FHIR的互联互通实践(5):FHIR以及InterSystems FHIR参考架构

FHIR是快速医疗互操作资源(Fast Healthcare Interoperability Resources)的缩写,所以FHIR的核心是资源模型。它的颗粒度和结构都优于之前的V2 、V3、CDA标准,而且能够灵活扩展。另外一个优势就是它的API,它不仅提供了针对于资源模型本身的原子化的CRUD(创建、读取、更新、删除的这样一些原子化操作),而且提供了查询这种更复杂操作的能力,同样API是可以扩展的。

此外,之前的互操作标准基本上都不会涉及到数据的保存,而FHIR资源仓库提供了一个全新的架构、全新的思路来使用FHIR,实现这种互操作。

这是InterSystems公司FHIR的参考架构,处于核心的就是FHIR服务器,它向外提供API的接口能力,包括FHIR的事务、FHIR的各种交互跟FHIR操作,底层是FHIR资源仓库,它可以持久化所有的FHIR资源,同时允许FHIR服务器对FHIR资源进行事务性的操作,所有需要使用FHIR API的客户端都可以使用FHIR服务器发布出来的API来进行相应的操作与访问。

上文我们讲到有常见的4种互操作的方式,HL7 FHIR支持所有的这些方式,而且它提供了第5种互操作方式。

首先,通过RESTful API它能够提供一个更紧密的业务集成度、去中心化的互操作能力,比较适合于搭建医疗微服务业务环境,同时比较适合于像云、互联网、物联网这种有紧密业务集成需求的环境。

另外FHIR依然支持以消息、文档方式来进行使用。这两种使用方式兼顾了传统互操作的模式,主要的目标是解决低业务集成度和跨数据管理域的集成和交换需求。

FHIR也可以基于服务来提供这种互操作,例如IHE已经有了大量的场景规范基于FHIR来实现了。

第五种就是我们说的资源仓库。大家可能会觉得奇怪,它怎么会成为一种互操作的方式?

我们先来看看互联互操作需求的起源:上图是比较传统的三层架构的开发模式,从底层的数据模型进行设计,到业务逻辑层,再到用户界面层,创造的是烟囱一样的应用。这种烟囱应用之间就需要通过互操作来打通,实现信息的共享和交换。

假设建设的不是烟囱类型的应用,我们还需要基于消息、文档的交换吗?

来看看生物界。世界上最大的生物是一种巨大的菌丝,在美国的俄勒冈州的蓝山有一种蜜真菌,它被科学家认为这是世界上最大的生物。地下的菌丝是一个整体,连在一起的,看起来独立的一个个蘑菇,其实都是这个巨大生命体的一部分。科学家估计在蓝山的蜜真菌的面积能够达到9.6平方公里,年龄已经差不多1900岁,甚至有人说可能在6500岁之间。

如果说我们把FHIR的资源仓库视为菌丝,基于FHIR资源仓库开发的应用,就是一个个的小蘑菇,它们只需要关注用户界面和业务逻辑,因为它们所有的数据存储和数据访问能力都是由标准的FHIR服务器提供的,而FHIR服务器下面可以接非常多的FHIR资源仓库,也就说资源仓库可以不止一个。这就是虚拟的集中式架构,在虚拟集中式的架构下的所有应用天生就是互联互通的,这就是FHIR的第5种互操作模式。

大家可能会问真有人这么做吗?还真有——SMART on FHIR就是比较典型的这种应用方式。

SMART是 “可替代医疗应用的、可重复使用技术”的缩写,它起初是哈佛医学院跟波士顿儿童医院在2011年开启的一个项目,它这个项目目标是用来创建这种可复用、可替代的应用开发架构。显然FHIR提供的这种标准化的数据模型和API是SMART能够实现的基础——的确是,在2014年SMART 跟 FHIR融合出来一个新的项目就是今天的SMART on FHIR。这个应用程序开发的架构使用标准的FHIR资源模型,使用标准的FHIR API来操作资源数据,使用OAuth2 和OpenID实现统一的认证授权,而开发者只需要关注在业务逻辑和应用层面。它开发出来的SMART应用底层的数据都保存在FHIR服务器和FHIR资源仓库里面,这些应用跟我们的手机的APP一样,都是即插即用的。这些即插即用的应用可以在所有支持 FHIR的服务器和FHIR资源仓库上实现,而且可以复用。

这些应用程序里面并不保存数据,我们不用担心数据跟应用共存亡的问题,因此这些应用其实可以随时被替代。如果你觉得它不好,有一个更好的应用你觉得喜欢,就直接把旧的扔了,插一个新的应用就ok了,这种建设的应用天生就是互联互通的。

 

注:本文根据InterSystems中国技术总监乔鹏演讲整理而成。

10
2 1 0 59
Log in or sign up to continue