8.3 北京友谊医院基于FHIR的互联互通标准研究项目
8.3.1 背景
（1）单位简介
北京友谊医院始建于1952年，原名为北京苏联红十字医院，是新中国成立后，由党和政府建立的第一所大型综合性医院。医院已发展为集医疗、教学、科研、预防和保健为一体的北京市属三级甲等综合医院。2014年10月，医院获批成为国家消化系统疾病临床医学研究中心，2018年牵头成立北京市医院管理中心消化内科学科协同发展中心。
医院目前拥有国家临床重点专科8个，博士点27个，硕士点31个，国家住院医师规范化培训专业基地17个，国家专科医师规范化培训试点基地4个,“扬帆”重点专业7个，北京市重点实验室4个，北京市研究所4个，医学转化中心1个，还拥有支撑临床研究发展的国际标准化临床研究质控平台、ISO9001认证生物样本库、多中心互认医学伦理平台、研究型病房。医院设有西城院区、通州院区（包括副中心门诊部）和顺义院区，“一院三址”已初具规模，现通州院区基建二期工程和顺义院区主体工程正在建设中，计划于2023年6月开诊。全院现有编制床位数三千余张，年均门诊量逾29万人次，年均出院患者近8万人次，年均手术量超过4万例次。
（2）当前信息化概况
北京友谊医院的信息化建设开始于1982年，经过多年发展医院信息系统建设已能覆盖大部分医院业务，并随着各院区的建立、建设逐步形成了多院区一体化架构的信息系统。我院信息系统建设整体遵循医疗信息化标准体系和安全体系，在统一基础设施的支撑下，建立有临床诊疗、运营管理、科研教学、医疗协同和患者服务等5大业务领域系统，各业务系统间通过信息集成平台进行数据标准管理和信息互联共享，生产的全部数据统一归集在临床大数据中心、科研大数据中心、运营大数据中心中，应用大数据技术为临床辅助、运营决策、科研分析提供统一的数据应用服务。医院已通过了电子病历系统功能应用水平5级、医院信息互联互通标准化成熟度测评四级甲等、医院智慧服务分级评估3级等医疗行业信息化测评，具备了智慧医院深化建设和落地应用的基础条件。
8.3.2 需求分析
我院建成集成平台后，大大提升了信息化发展速度，随着接入系统增加，出现了两个显著的特点，一是数据量极大增加；二是数据存储分散性加大。为让存储在不同环境和服务器中的数据能够被快速、有效调取和阅读，实现各系统间数据的互操作性，我院基于临床实际需求开展基于HL7 FHIR标准的落地实践应用。
应用场景分析
为便于诊疗工作，我院建立了面向医生的移动患者360视图（以下简称移动360）。移动360按照患者基本信息、就诊信息、检查报告、检验报告、医嘱信息等多角度展示患者的诊疗情况。医生在临床使用时，在手机移动端可以随时随地按照所需要进行查询并获取患者相关诊疗信息。
HL7 FHIR标准的优势之一是易于支持移动端设备应用。如何将FHIR标准应用于移动360将是我院信息化发展现阶段需要关注的问题之一。
8.3.3 实现过程
平台上交互场景众多，我们基于FHIR R4版本的基础规范，结合医院信息平台交互规范如《医院信息平台交互规范 第2部分：个人信息注册、查询服务》、《医院信息平台交互规范 第7部分：就诊信息交互》、《医院信息平台交互规范 第9部分：申请单信息交互服务》等制定适用于本院的FHIR本地化标准。按照“数据模型分析”，“资源模型设计”，“交互设计和规范发布”，“项目验证”四个步骤研究实践基于FHIR标准规范的可行性。
由于操作端及展示均在移动端，为保证性能及效果，需要尽可能按照展示模块进行数据组织。为实现移动360查询的简单快捷，我们选取患者信息、过敏信息、检查报告信息、检验报告信息、用药医嘱、手术信息、患者信息、标本信息，通过FHIR标准实现其交互获取。
8.3.3.1 工具及平台
Forge是FHIR官方指定的用于创建、编辑和验证Profile、Extension等文件维护资源一致性的工具。强大的图形用户界面，允许使用者轻松创建、编辑和验证FHIR Profile约束文件、Extension扩展和 implementation guides实现指南。且Forge与Simplifier做了集成，提供了与在线FHIR服务器和FHIR注册表的平滑集成，可以方便的下载和发布配置文件。我们在标准设计定义过程中使用Forge作为我们的标准设计工具，以便保证标准定义的规范和准确。
图8.3.1 Forge工具
Ensemble是我院目前信息平台的集成引擎，作为HL7标准的重要参与者，已经完成对FHIR标准的内置支持。我们将完成设计的FHIR本地化标准在Ensemble上进行开发实践，完成项目场景使用。
8.3.3.2 数据模型分析
数据模型分析是对实际临床业务交互内容的详细分析，包括交互的数据元素，每个数据元素的数据类型、长度、默认值、相对应的数据字典、m..n基数（允许出现的最小次数m，最大次数n）等，即确定患者信息包含的业务节点内容及约束信息。我们将交互场景中涉及到的数据模型内容与FHIR资源元素做映射，同时标记出需要扩展的业务元素及需要定义的ValueSet值集。下图展示的是Patient资源映射关系的部分截图。
图8.3.2 Patient资源映射关系
8.3.3.3 资源模型设计
资源模型设计根据需求分析阶段的《资源映射关系表》的分析结果，设计出相应Extension扩展文件、ValueSet值集文件和Profile集成规范文件。
1）定义Extension扩展，包括扩展项内容、扩展项数据类型、扩展项基数、扩展项值域、扩展项值域强度等。任何一个资源都可以包含一个或多个扩展元素，任何一个元素或数据类型也可以包含一个或多个扩展子元素。结合互联互通交互规范和医院实际使用场景，本次针对Patient资源共扩展了性别（扩展值集）、民族、出生日期（FHIR规范已定义）、职业类别、工作单位、工作单位联系方式、学历、学位、医疗保险类型、国籍、宗教信仰等11个扩展元素；
2）定义值集，当元素的数据类型为Code、Coding、CodeableConcept或者 Quantity时，需要对该元素绑定相应的值集。值集可对应理解为互联互通测评中数据元值域，值集的内容根据实际使用场景，可以是相应的国家标准、行业标准，也可以是自定义的院内标准；
3）定义Profile集成规范，根据《资源映射关系表》利用Forge工具对标准资源的Profile文件进行引用Extension扩展、绑定ValueSet值集等进一步约束，从而生成特定医疗业务场景中资源的Profile集成规范。Profile集成规范对应理解为互联互通测评交互规范中的接口规范模型。本阶段生成的Patient患者资源Profile集成规范共包含19个标准元素、 11个扩展元素，绑定了11个值集。下图展示了Patient资源的Profile集成规范部分内容。
图8.3.3 Patient资源的Profile集成规范部分内容
8.3.3.4 交互设计和规范发布
交互设计涉及到四个活动，分别是定义交互方式、定义资源访问的API、定义资源操作（Operation）和定义查询参数。FHIR标准支持Restful API、Messaging、Document等多种交互方式，根据使用场景选取合适的交互方式。以Restful API交互方式为例，FHIR规范里定义了大量了的API交互接口，需结合医院实际医疗场景，如新建、更新、查询等场景定义资源访问的API接口；除基本的API接口之外，FHIR标准还定义了相对复杂的Operation操作接口，并支持使用者根据实际情况自定义Operation；FHIR标准定义了资源的查询参数，使用者可根据实际应用情况选择相应的查询参数，同时支持自定义查询参数。下表是FHIR患者资源基于RESTful的API接口信息。
表8.3.1 FHIR患者资源基于RESTful的API接口信息
| Patient 患者 | ||||
|---|---|---|---|---|
| 交互方式 | 场景描述 | VERB | 参数 | 参数描述 |
| Create | 新建患者信息 | POST | ||
| Update | 更新患者信息 | PUT | _id | 患者资源ID |
| Read | 查询患者信息 | GET | Identifier、_id | 患者ID、患者资源ID |
| Operation | 合并患者信息 | POST | Identifier、name | 患者身份证号、患者姓名 |
交互方式、API接口、Operation操作接口和查询参数都需在交互规范中明确说明，并分别形成服务器端和客户端的CapabilityStatement交互能力声明文件供客户端查询使用。
通过之前的步骤，已经设计并形成了包含Profile约束文件、API接口及相关声明的FHIR 规范文件，如需发布给厂商使用还需要进一步细化交互规范明细，形成系统间交互文档。此交互文档及FHIR规范文件评审完善后发布供厂商。
交互文档中以文字说明的形式，描述了两交互应用系统间FHIR标准的使用场景及各自请求、响应消息交互明细。下表描述了HIS系统通过RESTful API接口，发送新建患者信息至EMPI系统请求交互及EMPI收到请求之后的响应交互明细。
表8.3.2 新建患者信息交互明细规范
| 交互规范明细 | 参数描述 | |
|---|---|---|
| HIS系统 —— EMPI系统 | ||
| 请求消息头 | POST[base]Patient | Base为EMPI系统的根路径 |
| 请求消息体 | JSON格式的Patient资源内容 | 符合基于文章前部分研究方法设计的Profile约束文件。 |
| EMPI系统 —— HIS系统 | ||
| 响应成功状态码 | 201 Created | |
| 响应成功消息体 | JSON格式的Patient资源内容 | 包含分配的资源id |
| 响应失败状态码 | 400 Bad Request | 404 Not Found |
| 响应失败消息体 | 包含具体错误信息的OperationOutcome资源 |
移动360,主要是通过API的方式获取患者信息、过敏信息、检查报告等信息，具体接口及设计到的资源如下表所示。
表8.3.3 移动360 FHIR资源表
| 序号 | 信息 | 接口 | 涉及资源 |
|---|---|---|---|
| 1 | getPatient | 患者信息 | Patient、Extension |
| 2 | getAllergic | 过敏信息 | AllergyIntolerance |
| 3 | queryAbnormal | 异常值信息 | Observation |
| 4 | getExamination | 检查报告信息 | DiagnosticReport_Exam、Observation_Exam |
| 5 | getLab | 检验报告信息 | DiagnosticReport_Lab、Observation_Lab、Specimen |
| 6 | queryMedicationOrder | 用药医嘱 | MedicationRequest |
| 7 | getOperation | 手术信息 | Procedure |
8.3.3.5项目验证
基于已发布的本地化标准，我院在集成平台使用Ensemble引擎进行了实地开发及测试验证。以HIS和CDR系统进行FHIR标准下的临床信息数据交互业务端。实施方案如下图3所示。具体方式为由HIS作为资源产生端，将生成的FHIR标准资源以消息的模式传递至集成平台，由集成平台将资源发送至CDR，CDR以FHIR资源模式存储。移动360通过集成平台直接调取CDR中API资源进行展示。开发接口服务如图4所示，以就诊为例的FHIR标准API资源，如下图所示。
图8.3.4 FHIR标准实施方案
图8.3.5 基于FHIR的互联互通集成平台接口服务
图8.3.6 基于FHIR的互联互通标准消息格式—就诊消息实例
8.3.4 实际应用情况与问题分析
8.3.4.1 实施效果
经过对开发人员培训和测试，基于FHIR标准的集成平台服务正式上线运行。FHIR API稳定运行，累计消息量超过60万次。系统集成厂商反馈基于FHIR标准的交互消息学习成本相对较小、REST交互方式易实施，且整个交付实施周期短。
由于官网提供了免费测试使用的HAPI FHIR开源 Java实施规范，在开发阶段HAPI FHIR既可以作为服务器端，作为客户端供开发者调试和调用。大量的开源开发代码样例极大的缩短了了开发周期，提升了开发效率。
8.3.4.2 问题及解决方式
尽管一直强调FHIR标准相对易学习、易实施，但因其内容体系庞大，以及与本国医疗政策体系的差异性，在实践过程仍存在很多难点和需要重点考虑的问题：
（1）如果要达到各医疗场景中涉及到的数据模型与FHIR资源及其资源元素的精准映射，需要对FHIR标准中资源的相关知识有充分了认知；
（2）FHIR标准注重资源的互操作性，如何利用Operation及Search等交互促进系统间数据的互操作性；
（3）近年来业界越来注重数据安全及患者隐私数据保护，在落地FHIR标准时需要充分考虑如何确保数据安全使用；
（4）FHIR标准是一个不断发展的标准，迭代过程中，有时候前一版本的资源，在后一版本中可能会被优化掉，如何保证版本间的兼容性，需要各实施者慎重考虑；
（5）定义Extension扩展、Profile规范文件的Forge工具版本迭代差异较大，有时候基于前一Forge版本定义的文件，在Forge的后一版本中将无法打开查看。Forge工具版本的差异性、不兼容性不容忽视。
8.3.5 未来展望
FHIR标准进展速度很快，使用FHIR将有利于降低医疗机构对于数据交换的门槛。且由于FHIR易于学习，很快就能被掌握和使用。对FHIR将来的推广应用作了坚实基础。有效利用基于FHIR标准整合的多数据源，能够尽可能从临床医生的角度，将临床数据更有意义的呈现出来，大大提升医生的满意度。本实践作为当前FHIR技术的一个尝试，未来的大规模推广使用，还需要在以下方向做多努力：
8.3.5.1 更多的标准应用
要想最大限度地利用FHIR，需要将互联互通交互规范中的其他场景及医院实际业务涉及到的数据元素通过上述方法论整合到FHIR标准当中。虽然这方面取得了进展，实践中选取的业务场景涉及到的FHIR标准已经落地投入使用，但还是有相当多的工作需要完成，需要业界投入人力和时间来补充和完善本土化FHIR交互规范。
8.3.5.2 更广泛的参与
FHIR降低了知识和技能方面的门槛，这就能让更多的开发人员开发信息解决方案，尤其是Web平台上，以便更容易跨不同的系统来访问数据。患者和医疗服务机构就能更方便地调阅健康数据，从而确定最佳诊疗方案。但FHIR面临的最大挑战是，要让更广泛的医疗行业人员（医生、IT部门、甚至软件开发人员）了解FHIR对临床的应用价值。只有更广泛参与才能更广泛的推动和发展。