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中国技术总监乔鹏演讲整理而成。