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