HL7系统集成下的医疗信息论文

1HL7的发展与应用

医疗卫生信息化是国内外医疗卫生行业目前比较关注的话题，其核心是规范医学数据格式，使医疗卫生信息系统能够进行数据交换和信息共享。与发达国家相比，我国的医疗数据交换标准研究工作起步较晚，目前完全遵循HL7标准进行医疗信息系统集成的医院、制造商为数不多［7］。医院内部及医院之间的信息系统不能实现互联互通、信息共享，严重阻碍了医疗信息化的发展。因此引入HL7国际标准作为国内统一的医疗信息化标准对解决医疗信息化建设、实现医疗数据互联互通意义重大。

2基于HL7的医疗卫生信息系统集成

国内在基于HL7标准的医疗卫生信息系统集成方面有了初步的实践。文献［8］介绍了北京世纪坛医院在“持卡就医，实时结算”的改造中利用HL7标准实现医院和医保部门的信息交换。文献［9］谈到国内外检查仪器的生产厂商通过HL7标准规范仪器通讯接口来解决各种检验仪器接口的重用性问题，并保证数据交换的准确性。文献［10］提到在不更改现有系统的前提之下，通过外挂中间件模式(HL7中间件、HL7引擎)解决医院信息系统异构的问题。基于HL7标准进行医疗数据整合，实现了医疗信息系统内部及系统之间数据交换和信息共享，主要体现在系统间集成应用上，涉及的关键技术有HL7的本地化和基于HL7的医疗信息系统集成方式。

2．1HL7本地化

HL7本地化是当前医疗信息交换标准的研究热点。HL7是美国开发的标准，与我国的文化、医疗模式存在一定差异。例如，美国人姓名有前缀、后缀等多种成分，在HL7协议中用字段将姓和名分开来存，而我国一般不会将姓和名分开。HL7协议中给每位病人设定账号(accountnumber)，而中国则有公费、自费、医保等多种类型。因此，国内在引入HL7进行医疗信息集成时，不能完全照搬HL7标准文件［11－12］。HL7协议中规定，消息是信息传递的最小单位，由段(segments)、字段(fields)、组件(components)、分隔符(delimiters)等元素组成。一条消息由多个段组成，而一个段由多个具有逻辑关系的字段组成，多种元素又构成了字段［13］。消息机制是实现消息传输、数据交换的关键技术，其主要功能是将应用系统的数据通过机制转换为标准的HL7消息，然后按照机制规定的传输协议将HL7消息发送至接收系统，接收方对传来的HL7消息进行验证、解析，再转化为应用系统的数据。HL7本地化就是要实现消息机制的本地化，它不需要在技术层面上进行改造，主要是对消息内容定义和编码。台湾地区大都通过单个消息来定义某一个接口，实现HL7的本地化。他们在进行转诊系统设计时，考虑到HL7中规定姓名字段与本地区命名存在差异，按照HL7的要求，将姓名分开处理［14］。这种方式依靠几个大型厂商和几家大型医院就可以定下某个接口标准，在某些方面得到快速应用。日本己经建立起了本地化的HL7标准，简称MML［15］。国内一些医院基于HL7标准进行医院信息系统改造，不是对现有HIS系统进行大改造，而是设计HL7网关，实现系统间的数据交换和共享［16］。然而，国内医疗软件厂商众多，医疗信息系统复杂，如果仅依靠某几个消息来定义接口，要编写大量、繁杂的转换程序，工作量非常大，所以这种方法可行但并不实用。目前我国将HL7改造成符合我国国情的HL7本地化标准库，依据标准库开发研制HL7消息构造器/解析器。消息构造器是参照HL7标准的数据结构，从一条HL7消息中抽取出有用的信息放到HL7本地化标准库，最后完成HL7消息和HL7本地化消息的转化。这个过程的逆向实现过程，就是消息解析器的工作过程。采用HL7本地化标准库的方法，编写工作量减小，转换效率高，实现了基于国内的HL7标准，给我国医疗信息系统集成提供了标准数据格式。

2．2基于HL7的医疗信息系统集成

目前国内医疗信息系统集成大都依靠系统开发商提供标准接口，或直接读取对方数据库的数据，部分采用共用数据库的方法。这些方法的优点是实现起来简单、成本低，缺点是通用性、扩展性、安全性等方面存在不足。如果多个应用程序同时读写数据库，难以保证系统的正确性，甚至可能导致灾难性的后果［17］。以上集成方法很难满足多样化的医疗系统应用和频繁的信息交换需求。HL7提供标准的API接口，可以简化应用程序集成接口开发的复杂度和工作量，大大改善系统的安全性和扩展性。引入HL7进行医疗信息系统集成，可以采用HL7Ready和HL7Engine2种方式［18－19］。

2．2．1HL7Ready方式

这种方式是指现阶段在设计或改造医疗信息系统时，充分考虑系统未来发展的需要，完全按照HL7标准设计应用系统的体系架构、数据对象、数据结构。因此，系统的各应用终端都可以接收和处理HL7消息，可以直接或通过中间件与相关软件进行信息交换，在理论上可以达到系统和系统之间的实时交互，可以相互主动地在“需要的时候”获取对方可以提供的数据信息［20］。当然，这种方式属于理想的方式，适合在厂商开发新系统时，进行前瞻性的设计，有利于在多系统应用环境中的应用整合。HL7Ready的工作原理［21］如图2所示。Send/Receivemodule(发送/接收模块支持)采用TCP/IP通讯协议，通过Internet或3G网络进行连接，负责HL7消息的发送和接受;HL7Resourcemodule(HL7资源模块)支持各种实际应用的HL7医疗信息事件，如检查医嘱、转诊、住院、出院等;HL7APImodule(应用接口模块)提供符合HL7标准的应用接口，实现向其他医疗应用系统发送数据。采用HL7Ready方式整合医疗信息系统数据，从技术上看很好实现，但应用起来难度不小。首先，HL7中有不少内容与中国国情不符或有偏差，具体应用之前需要进行本土化;其次，以这种方式实现医疗信息系统集成花费大、时间长、不能很快投入使用;最后，国内已经形成自己的HIS系统，短时间内不可能推翻重新设计。

2．2．2HL7Engine方式

这种方式是对现有的应用系统进行集成，通过提供外挂程序(HL7引擎、HL7中间件等)负责编码或者解析HL7信息，使应用程序之间能实现数据交换。HL7Engine是一组支持HL7通讯的过程调用函数或控件，应用系统按照HL7接口引擎的约定提供参数，模块之间的通讯则由HL7接口引擎完成。这种方式是将整个医疗信息网络的信息交换划分为本系统内和各系统间两类分别处理。HL7Engine并不干扰系统自身各部分正常工作，不会参与内部信息交换过程，也就不会对内部信息处理增加负担，因此无须对既有程序代码作任何改动［22］。只有当系统与外界发生信息交换时才进行数据格式转换，充当翻译角色，在内外部医疗信息交换中构建了一座桥梁。基于HL7Engine应用系统集成主要有两种实现方法［23］(见图3)。一种是采用点对点通讯方式以实现不同系统的对接;另一种是采用HL7服务器的方法，形成居于HL7接口的中心数据库，这样可以减少接口数量，提高系统可靠性。从原理上讲，这2种方法都是在原有系统中增加一个HL7中间件，医疗系统通过中间件与其他系统或HL7服务器进行HL7消息交换。采用点对点的方法适合系统较少时使用。若系统增加时，所需的接口也将成倍提高，集成复杂度相应增加，导致成本过高。因此，可以采用HL7服务器的方法解决系统复杂度的问题。HL7服务器作为系统集成的中心结点，与多个子系统互连，大大减少多个系统互连的接口数量，但是HL7服务器本身的复杂度决定了这种方式只有在十分复杂、异构模块众多的情况下才使用。国内对基于HL7Engine的医疗信息整合进行了一些实践。1996年北京大学人民医院建成了国内第一个大型的医院信息系统，医院在进行HIS和RIS集成时，采用了点对点通信方式，在HIS端使用太平洋医信公司的HL7引擎，在RIS端使用GE公司HL7引擎实现HIS和RIS系统的互连［24］。上海电力医院信息平台项目于2011年11月上线。该项目采用了HL7V2．4标准，以HL7Engine方式将上海电力医院原有业务系统进行了基于HL7标准的改造，通过HL7引擎的处理使非标准的消息变成符合HL7标准的消息，从而实现了医院各业务系统之间基于HL7的信息交换［25］。采用Engine方式实现系统集成，实现简单，投入周期小，成本花费少，而且能够很快发挥作用。虽然系统内的各应用模块终端并不具有处理HL7消息的能力，无法实现系统与系统之间的实时数据处理，以及应用终端的查询请求等功能。但就目前国内医疗状况来看，此方式完全可以满足国内医疗系统集成的需要，是一种简单有效的方法。

3HL7在国内医疗信息系统的应用趋势

3．1HL7版本的选择

系统间互联互通主要分为功能(语法)互联互通性和语义互联互通性。文献［26］指出，功能互联互通性是指两个或多个系统间通过设定功能和定义报文结构进行信息交换的能力;语义互联互通性指两个或多个系统共享的信息能够按原有定义被理解的能力，是信息共享的前提条件，涉及数据的整合、概念、术语、域模型和数据模型以及信息框架的一致性问题，确定信息的结构和内容。在HL7V2．x协议中，消息的编码方式复杂繁琐，不易阅读;协议采用自然语言去描述触发事件，缺乏明确的方法指导，而且数据域导致消息重定义和数据结构关系不明确，在实现语义互联互通上面临很大困难。HL7CDA提供一个基于XML的文档架构，统一遵循RIM模型。一个CDA文档由ClinicalDocument元素封装，包含文档头(Header)和文档体(Body)两部分，CDA文档中定义text部分的是人读部分，entry则是机读部分，更为符合医护人员的认知。CDA文档的词汇集可以包含医学术语等语义标准，从而实现语义上良好的互通性［27］。在进行医疗系统集成时，美国选择两种体系标准混合使用，因为HL7v2．x已经在美国医疗卫生系统中广泛运用［28］，如果推倒后再重新按照CDA的标准来实施成本太高。HL7在国内应用并不广泛，所以区域卫生的健康档案、电子病历标准、医疗信息系统中的化验检验报告等需要大量文档交互的系统，可以完全使用CDA。

3．2基于HL7集成方式的选择

HL7Engine和HL7Ready是基于HL7医疗信息系统集成的2种途径［29］。现阶段，在国内医院管理水平低、HL7的本地化程度不高的情况下，采用Engine方式是最可取的。即使未来标准发生了改变，包括HL7本地化以及未来采用HL7V3．0的XML格式编码化，都只需通过修改外挂程序，就能满足要求。这样既可以不用对现有的应用系统进行大改造，又可以利用HL7的标准实现数据交换和共享，不失为一种简便的方法。从长远发展考虑，HL7Ready方式无疑是最好的选择。因为它可以使医院的相关医疗数据全面推行实现HL7标准，医疗信息系统无需再做多余的转换或接口编写，就可以实现完全的HL7数据交换。它是未来医疗信息系统集成的发展方向。因此，我们应该把HL7Ready方式作为未来重点研究的方向。

4总结

国内对HL7的研究和运用起步较晚，实际运用的案例不多。但是我国医疗信息化、医疗保险、社区医疗和区域卫生信息系统等，都需要标准化的支持。HL7作为国际公认的医疗电子数据交换标准，在国内也得到了认可。但是，HL7标准与我国的医疗模式、文化等存在差异，我们在引入HL7应用时，需要对它进行本地化改造，设计符合国情的HL7标准库，可以给我国医疗信息系统集成提供标准的数据格式。国内医疗信息系统众多，各自分离，而医疗业务需要系统间进行数据交换和信息共享，现阶段采用HL7Engine方式比较合适，从长远看，HL7Ready将代表未来研究的方向。

作者：吴寿刚1王晓华2工作单位：1.贵州大学计算机科学与信息学院2.贵州遵义医学院医学信息工程系