郑林：基于FHIR的医疗机构间数据交换

工作中常遇到医疗机构间转诊、委外检查/检验等跨医疗机构数据交换的需求。区域内上下级转诊通常通过区域平台实现，但三甲医疗机构之间的数据交互面临很多挑战。系统对接成本高、接口类型及数据标准不一致是重要原因之一。有没有接口规范、操作成本低的方案呢？本篇介绍的FHIR就是方案之一。

什么是FHIR

FHIR是Fast Healthcare Interoperability Resources的缩写，由HL7在2012年发布的，其目的是规范和标准医疗机构间数据交换格式，降低对接成本。

以医疗机构间转诊为例，假设最简单的情况，医疗机构间转诊时只包含患者基本信息。即医疗机构A发起转诊业务时，同时将患者信息发送给医疗机构B，以便患者信息的建档。那发送过去的患者信息应该包括哪些内容呢？可能会考虑到：姓名、性别、证件类型、证件号、联系方式、出生日期、家庭地址等内容，数据的样例（注：本篇涉及的数据为功能演示所用，非真实数据），如下图所示：

但患者可能同时使用身份证及护照建档，也可能有多个地址及联系方式，上面的内容和组织形式就不满足了，所以需要对患者信息进一步优化。完善后的数据及格式如下图所示：

完善后可能还会存在一些异常情况。例如：患者之前登记的手机号停用、身份证号过期等，所以还应该包含状态信息、有效期信息等。这仅是患者信息，还有诊断、文书、医嘱、报告、输血、病理等各环节的信息需要讨论并制定标准，这是个细致且耗时的过程。那FHIR是如何做的？

如何通过FHIR表示医疗信息

FHIR将医疗过程中各类信息归纳总结成一个个资源（Resource），以刚才提到的患者信息为例，FHIR中定义了一个名为Patient的资源表示患者信息。其部分定义见下图：

类似开发中定义的Model类，Patient资源详细的定义了各种“属性”，以便直接使用。从上图中能够看到其定义的非常详细，医疗业务中所需的内容它基本都考虑到了。那FHIR中有多少个类似Patient的资源呢？目前的R5版本中共定义了157个资源（见下图），涵盖了医疗过程中的各方面。

有小伙伴可能会问，FHIR资源中定义的各种属性，能覆盖所有场景、满足所有需求吗？答案是不会也不能。这涉及到FHIR扩展机制。FHIR原则是资源已定义的属性满足80%的互操作需要，剩下的20%需求则通过扩展来解决，因此FHIR通过提供扩展机制，满足本地化或个性化的需求。以Patient资源为例，其未包含民族的定义，而实际业务中往往又需要民族信息。这部分需求就可以通过FHIR的扩展机制实现，扩展的样式及例子如下图所示：

实际医疗场景中会包含各类信息，而非简单的单一资源（例如Patient资源），FHIR是如何实现的？类似开发中的嵌套类，FHIR也是通过定义用于包裹其他资源的资源（Bundle资源）来实现。逻辑如下图所示，Bundle是最外侧的资源，里面按需包括各类资源。

下面以一份门诊记录单为例说明。首先先梳理门诊记录单中包含哪些信息（下图中灰色部分），然后将这些信息找到合适的FHIR资源（下图中蓝色部分）完成映射。

最后按照Bundle资源规范，将各类资源包裹其中，并形成最终的文档，见下图所示：

在实际的映射过程中，需要考虑的内容会更多。例如：明确所需的资源、各资源中元素的基数要求、是否需要扩展、定义数据集等步骤，整个过程需要与临床医务人员、医疗信息化专家多次沟通讨论。整个过程的流程如下图所示：

将一份医疗记录转换为FHIR资源的过程需要讨论的细节非常多，北京友谊医院的李俊伟老师曾经在CHIMA大讲堂中以《电子医疗记录的内容与分级及医疗机构端系统的处理功能》做过专题汇报。（注：CHIMA大讲堂第101期）

如何实现基于FHIR的医疗机构间数据交换

再次回到文章最开始的三甲医疗机构间的数据共享问题，三甲医疗机构往往考虑数据及网络安全等因素，不会对外提供接口和服务。因此有没有一种方式，既能保证数据安全，又能使用FHIR标准数据交换格式呢？因此课题组比照光盘分享DICOM影像方式，提出基于介质的医疗机构间数据共享的方案。流程如下图所示：

具体过程是：患者通过医疗机构的App下载符合FHIR标准的文件，存储到手机上，再通过另一家医疗机构的App，实现FHIR文件的上传、解析以及后续处理，这样就能很大程度上减少医疗机构对于网络安全、数据安全的担忧。刘海一主任在CHIMA大讲堂中对此方案有过详细的背景介绍、安全考虑的介绍。（注：CHIMA大讲堂第100期）

为什么推荐FHIR

FHIR除了制定和规范医疗数据外，对于开发人员而言，还有两个优点。

（1）对开发人员友好。FHIR将各类信息总结成各类资源，而对资源的处理，就天然符合Restful风格的WebAPI方案。因此在开发过程中，可以使用Get、Post、Delete等Http操作处理各类资源。例如，http://localhost:8080/fhir/Patient/10001，就能获得id=10001的患者信息；Post一个Patient资源就可以实现本文最开始的转诊中的患者信息建档功能。对于开发人员而言，技术上手成本非常低。

（2）开源项目的支持。在GitHub上以FHIR为关键词搜索，有9500多的开源项目。包括各种资源的定义、资源的解析与处理等，都能找到开源的项目。这些开源项目能大大缩短开发时间。

如何在本地部署FHIR服务

我们也可以在本地部署一套FHIR服务，以便了解、熟悉和测试FHIR各项功能。这部分以GitHub的HAPI-FHIR开源项目为例，在本地搭建一个HAPI Server。基本的配置如下表所示： 

项目运行后的效果如下图所示：

因为步骤较多无法一步步进行展示，在CHIMA大讲堂由笔者分享过详细的操作步骤及各软件的安装包。（注：CHIMA大讲堂第102期）

总结

能够看到，FHIR基本覆盖了医疗场景中各类信息的数据标准化的需求，并且具备详细及标准化的各种资源，灵活的可扩展性、规范化的FHIR本地化流程以及对开发人员的友好，为医疗机构间的数据共享提供了切实可靠的方案。

作者简介

郑林，软件工程师，北京清华长庚医院软件开发科科长。