CHIMA本项研究课题于2018年6月7日在首都医科大学附属北京友谊医院正式启动。北京友谊医院作为本项课题的主牵头单位，近年来信息化建设获得飞速进展，建立了以病人为中心、以医疗流程优化为目的的信息系统，已建成并运行包括HIS、PACS、LIS等在内的几十个应用系统。
医院的集成平台和数据中心项目已基本完成符合互联互通四甲等级的改造建设，为本项目技术的研究开发以及应用提供了良好的信息化环境和数据基础。
1.研究背景
“十二五”以来，我国围绕医院信息化建设、区域卫生信息化建设等多个方面分期分批编制完成了283项国家医疗健康信息标准。截止2018年，我国已有54个区域信息平台和90个医院信息平台通过了互联互通测评，互联互通测评标准逐步被医疗信息化领域认可，并越来越多地推广应用。
2018年8月28日，国家卫生健康委员会医政医管局印发《关于进一步推进以电子病历为核心的医疗机构信息化建设工作的通知》中明确提出，到2020年，三级医院要实现电子病历信息化诊疗服务环节全覆盖，实现院内各诊疗环节信息互联互通，达到医院信息互联互通标准化成熟度测评四级水平，建立紧密型医联体，实现医联体内各医疗机构电子病历信息系统互联互通。
从医院层面来看，医院也面临更多的互联互通需求，如监管部门数据上报，电子病历等级评审中临床辅助决策支持需要与电子病历或HIS进行集成，互联网医院中大量的移动端应用需要访问医院的数据、同一资源多应用访问、预约挂号、检验检查结果、随访计划等多种新形势和环境下的信息发展均需要更高水平、更灵活的互联互通标准。
2.当前医疗信息化标准应用与挑战
2.1国际医疗信息化标准与应用现状
HL7从1978年创建开始到现在，HL7标准经历了从V2到V3，再到最新的FHIR的发展变化，并且每一版本也在不停的更新。如下图（见图1）所示：
图1HL7标准发展历史
图2FHIR支持互联互通的4个范式
图3HL7标准发展趋势预测
2.2国内医疗信息化标准及应用现状
2.2.1互联互通测评标准简介
2017年9月，国家卫生计生委统计信息中心印发了《国家医疗健康信息区域（医院）信息互联互通标准化成熟度测评方案（2017年版）》。医院信息互联互通标准化成熟度测评是对医院信息化建设的全面综合评价体系，主要分为四部分：数据资源标准化建设、互联互通标准化建设、基础设施建设和互联互通应用效果。
医院信息互联互通测评的项目应用评价分为七个等级，由低到高依次为一级、二级、三级、四级乙等、四级甲等、五级乙等、五级甲等。目前所有医院评测的依据是2017版《医院信息互联互通标准化成熟度测评指标体系》。具体明细如下：
近几年，随着互联互通工作的深入展开，国家评测管理机构已经行程一套科学的评价方法。对于评测的各个阶段都有各自考察的侧重点。2018年重点提出平台必须建成并运行半年以上才能申报医院信息互联互通成熟度测评。
实验室测试阶段重点针对数据资源（电子病历数据集、共享文档）标准化建设和互联互通标准化建设中的互联互通服务功能等定量测试指标，在实验室模拟环境中进行标准符合性验证。
2.2.2互联互通应用现状
自2013年以来，国家医疗健康信息互联互通标准化成熟度测评已经开展了四期，共有54个区域信息平台和90个医院信息平台通过互联互通标准化成熟度测评。
图42013-2018年区域和医院测评数量走势图
和往年相比，2018年度参与测评的医院数量为历史最多，这也在一定程度上反映了国内医疗机构越来越重视医疗信息化的发展建设，信息互联互通水平正在逐年提升。
图5参与测评医院区域分布情况
从地域上看，上海的医院成为了互联互通的集中推行地区。北京、广东及江浙一带地区的医院互联互通情况处于第二梯队，其他城市的潜力还尚待挖掘。
图6参与测评医院等级分布情况
从等级上看，绝大部分参与测评的医院是三甲医院，其他等级的医院偏少，提升空间较大。
综合医院信息互联互通标准化成熟度测评的情况可以发现，医疗数据的质量和共享水平，将成为国内各级医院信息化发展和标准化建设的重中之重。
2.3医疗信息化标准问题与挑战
HL7标准为国际上公认的医疗卫生领域信息交换协议标准体系。1994年，HL7V2.3标准被美国国家标准局（ANSI）认可，并于同年成为美国国家标准。HL7V3标准基于RIM模型，高度抽象了医疗事务活动，不但提供了数据交换标准，更是提供一套数据模型及方法论。我国医疗领域现行的互联互通测评方案参照HL7V3和CDA标准建立，并得到了广泛的推广和使用。
虽然HL7系列标准由于技术及业务上的优势，已经成为当前国内外医疗行业参照采用的信息数据标准。但当前标准在实际应用实施时，仍存在如下一些问题：
（1）扩展机制不够灵活
HL7V3标准是基于特定医疗使用场景制定的，交互内容在域模型中有所固定。当HL7V3数据模型不能覆盖某场景下全部交互的内容需要增加元素节点时，由于模型设计机制不易于扩展，导致无法增加相应内容，即便能够扩展，也可能会破坏原有标准机制。
（2）对移动互联网应用支持力度欠缺。
HL7历代标准的推行都是为了更适应于行业的需求和发展。HL7V2标准、HL7V3标准针对现在兴起的移动互联网应用技术不够友好。
（3）数据传输格式单一，数据内容冗余复杂，难于理解。
HL7V3标准只支持以XML为载体的交互消息，且消息内容层级繁多、复杂，部分节点属性抽象，致使对于新接触V3消息的学者和实施者来说难于理解，且系统封装和解析难度都相对较大。
（4）HL7V3入门难度较大，学习成本高
以RIM模型为核心的HL7V3标准内容体系庞大抽象，概念繁多，且每一个域模型都致力于定义医疗活动中涉及到的全部数据信息模型，无论是在标准研究学习上还是后期项目实施过程中，对研究者和实施者来说HL7V3标准难度都是相对较大，需要投入较高的学习成本。
（5）CDA文档的使用性局限大
CDA是HL7V3定义的临床文档架构，CDA的出现为医院、医疗机构、国家平台之间的跨平台临床文档共享提供了很好的支持，但是CDA仅适宜不同系统平台的大文档的交互，不便于部分临床信息的交换，而且开发也较为复杂，在使用上会有局限性。
针对以上情况，HL7发展了一套新的标准理念HL7FHIR。FHIR技术规范本身能够满足过去所有主要的HL7互操作性标准（V2、V3和CDA）所涵盖的需求，且在已有的基础之上进行了众多改进：
（1）支持灵活扩展
FHIR标准只定义“大多数”数据元素为相应核心资源定义的组成部分，其他元素采用扩展机制。实施使用时，支持不同资源及扩展资源的任意组合，具有非常好的可扩展性和灵活性。
（2）适用于对移动互联网应用。
FHIR标准基于成熟的网络标准构建，支持最新互联网RESTful体系架构、支持XML、JSON等主流的数据交换格式，尤其是在SMARTonFHIR架构应用上，更是借助于FHIR的优势致力于服务微小医疗应用，实现“即插即用”的可用性。
另外，FHIR标准实施简便快捷、技术规范自由可行、对于现成可用的互操作性基础资源，既可原样使用，亦可针对本地需求对其加以改编、与之前的标准之间既可共存，亦可相互利用。
3.医疗信息化新标准研究目的与意义
当前，互联互通成熟度测评对共享文档标准化及互联互通服务功能的标准制定上，分别参考了HL7CDAR2架构及HL7V3标准。但在医院信息化建设过程中，存在着医院信息平台底层交互标准统一性不够，各集成系统厂商对HL7标准的理解程度参差不齐，导致实施成本高、周期长。如何推进新标准的落地应用，减少各集成系统厂商的学习成本、实施成本，提升各临床科室数据的共享和互操作性，是本课题研究的首要目的。
FHIR作为HL7新一代医疗健康数据交换和信息模型标准，其灵活易扩展性的设计理念和高度融合互联网技术的特性优势，已快速成为国内外医疗信息化互操作性领域的研究热点。
目前国内缺乏对FHIR标准实施方法论的系统性研究，本课题参照国家卫生健康委发布的医院信息互联互通标准化成熟度测评方案，结合医院实际临床患者信息交换与共享业务场景，致力于制定基于FHIR标准的互联互通医院信息平台交互规范，以期开拓FHIR标准在国内的传播和应用。
4.FHIR标准介绍
4.1FHIR标准核心概念
“Resource-资源”是FHIR的基础，每一个资源定义医疗领域的涉及到的每一个业务实体，是业务实体的抽象，到版本R4为止，FHIR一共定义了143个资源，包含基础技术资源、基本资源、临床资源、财务资源及特定领域资源五大类，FHIR资源的定义不是一蹴而就的，FHIR利用敏捷开发的思想，逐步完善资源的定义，因此，FHIR标准的每个发布版本中，所有的资源都有一个成熟度标识，用来标明资源定义的完整性，成熟度从0到5以及N（Normative）一共7个等级，0代表初始化概念，5代表定义的资源已经相对比较稳定，并且在至少5个产品中实现，N表示该资源已经稳定，经历了严格的校验和审核机制。
资源与资源之间通过引用的方式表达之间的关系，FHIR通过这种方式实现两个系统之间不同的交互范式，比如Message（消息）和Document（文档），并且保持在不同的交互范式中针对相同的资源实例内容的一致性。
4.2FHIR标准定义原则
图7FHIR标准扩展使用步骤
首先根据需求，定义一个扩展，每一个扩展都是脱离于资源独立存在的，其目的是为了保证相同的概念在不同的资源中能够得到重用（当一个扩展只会应用在某一个特定的资源的时候，我们可以其使用范围为该资源），每一个资源都有一个唯一的id，通过url来唯一识别，并通过该url来获取该扩展的定义。一旦定义好了扩展，需要将该扩展注册到一个中心的扩展库中，目的是为了不出现重复定义，保证相同概念扩展定义的一致性。当我们在一个实际的项目中需要用到这些扩展的时候，我们需要在Profile中明确定义该扩展会针对哪个资源进行扩展，出现的基数，数据字典等。最后在具体的交换实例中使用这些扩展进行实例化。
Profile是FHIR标准本地化实现的基础，FHIR标准本身定义了相对比较通用的需求，然而在实际的应用过程中，往往需要根据实际的需求对这些资源进一步约束，这些约束包括：资源中元素出现的基数的限制、元素对于的数据字典取值范围、是否使用扩展、元素数据类型限制（多个可选的数据类型）、元素切片（Slicing）等。针对资源的Profile是通过StructureDefinition来定义的，同时StructureDefinition本身也是一个资源，通过这种方式，交互的双方可以在交互之前就可以获知双方对一个资源的约束条件，从而保证交互的一致性和有效性。除了对资源进行约束以外，Profile需要对数据接口能力进行约束，通过CapabilityStatement定义一个FHIR服务器或客户端数据交互的能力，比如是否支持数据的增、删、改、查等，是否支持自定义的“操作-Operation”，是否支持安全认证体系等等。同样，CapabilityStatement本身也是一个资源，让交互的双方在交互之前就可以获知双方的接口能力。
4.3FHIR标准交互模式
FHIR支持互联互通的四中不同的范式，API、消息、文档以及服务，而其中API是FHIR交互资源的核心能力，FHIR通过定义RESTfulAPI的方式进行资源数据的交互，其交互方式如下：
VERB[base]/[type]/[id]{_format=[mime-type]}
表1FHIR支持的API交互方式表
Interaction
Path
Request
Verb
Content-Type
Body
Prefer
Conditional
read
/[type]/[id]
GET
N/A
O:ETag,If-Modified-Since,If-None-Match
vread
/[type]/[id]/_history/[vid]
update
PUT
R
Resource
O
O:If-Match
patch
PATCH
R(maybeapatchtype)
Patch
delete
DELETE
create
/[type]
POST
O:If-None-Exist
search
/[type]/_search
application/x-www-form-urlencoded
formdata
search-all
capabilities
/metadata
transaction
/
Bundle
history
/[type]/[id]/_history
history-type
/[type]/_history
history-all
/_history
(operation)
/$[name],/[type]/$[name]or/[type]/[id]/$[name]
Parameters
FHIR不仅仅支持针对单个资源的API操作，还支持基于Message和Document的交互方式，但FHIR本身并没有限定用什么样的技术实现消息或文档的交互，在具体实现的时候可以使用FHIR的API（Message和Document本身也是资源），也可以通过WS、tcp/ip、文件等形式进行交互。FHIR在医疗信息化互联互通的4个领域对比情况（表2）：