医疗卫生信息标准化技术与应用(第2版)
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

第二节 HL7 V2消息标准

一、HL7 V2消息标准的起源

1987年3月在美国宾夕法尼亚大学附属医院召开了一个由医生、厂商及大学研究人员参加的会议,着重讨论如何在不同厂商的医学信息系统间实现更简单的数据交换,这次会议的参会委员们后来组成了HL7的第一个工作组(HL7 Work Group),于1987年颁布了HL7第1版(Version 1)试用标准框架,覆盖了患者出、入、转院,医嘱及查询等临床常见工作。1988年9月,该工作组颁布了的HL7 Version 2.0 Messaging Standard(HL7 V2.0消息标准),之后,HL7 V2.1、2.2、2.3……在不断修正和补充前一版本的基础上发布,它在美国90%以上的医院得到支持和应用,在世界范围内也成为应用最广泛的医学信息标准之一。HL7 Version 2的各个消息标准又统称为HL7 V2.X标准。

二、HL7 V2消息标准介绍

HL7 V2 消息标准由多个章节组成,按照国际标准规范书写(注:HL7的会员为免费注册制,注册成员可以免费获取HL7已发布的各类标准,包括HL7 V2.X标准。因此,本节仅对HL7 V2消息标准做概要介绍,希望对HL7 V2消息标准有深入了解和掌握的读者可以访问HL7的官方网站下载V2标准进行进一步的学习、研究)。

第一章为标准介绍(introduction),阐述了HL7标准的目的、背景、发展历史、使用范围等。

第二章为控制(Control),定义了应用于所有HL7消息的通用规则,为后续章节定义功能性的具体消息做铺垫,这些消息在确定的应用之间进行交换,是HL7 V2消息标准的核心,对控制章的理解和掌握是正确理解HL7 V2其他各章及正确应用HL7 V2消息的前提。

第三章为患者管理(patient administration),患者管理事务提供了新增或者更新的患者信息,以及患者就诊信息,因为所有与网络相连的信息系统都需要患者的信息,所以患者管理事务是最常用到的。

第四章为医嘱录入(order entry),医嘱录入事务适用于在需要得到医嘱/申请,或者执行医嘱/申请的系统中传输医嘱及相关信息。医嘱是对物品或服务提出的请求,通常针对某一特定患者,本章包括通用、饮食、物品供应、药品和疫苗等。

第五章为查询(query),定义了用于查询和应答的规则及主动显示消息。

第六章为财务管理(financial management),主要描述患者的财务事务,本章适用于划价、收费、付款、折扣、保险以及其他与患者交费相关的信息的交换。在不同的系统间,财务事务可以用于批处理或者在线的方式传送,与第二章中定义的批处理一样,当使用HL7编码规则时,可以将多重事务结合在一起,用文件传输媒介或程序传送。

第七章为检验检查报告(observation reporting),描述了在两个系统之间传送结构化的、面向患者的临床数据所使用的事务集,这些事务集常用于将来源于信息产生系统(如临床实验室系统、心电系统等)的观察报告与临床观察报告传送到医嘱系统(如HIS医嘱录入系统、办公室系统等)。

第八章为通用文件(master files),本章适用于管理和交换应用系统之间共享使用的基础信息,包括机构人员、用户、诊疗项目、地址、编码等。

第九章为医疗记录及信息管理(medical records/information management),医疗记录的目的主要是创建一份正确的、合法易读的文件,以对提供给患者的医疗保健服务作出全面的声明。本章适用于对临床文件状态、内容以及信息发布等的管理,其中文件内容包括与医嘱相关的内容及独立于医嘱的内容。

第十章为计划日程(scheduling),本章定义了抽象消息,目的是传送与服务或资源使用的预约日程安排相关的各种事件。

第十一章为患者转诊(patient referral),本章定义了应用于相互独立的医疗保健实体之间患者转诊信息通信的消息集,这些转诊事务经常发生于采用不同的数据获取和存储方法、系统的实体之间,其中的实体包括社区卫生站、私人诊所、医院、实验室、医疗保健中心、政府卫生管理及其他医疗卫生机构等。

第十二章为患者照护(patient care),本章支持面向问题的记录交换,包括在系统之间用于诊疗过程中通信的临床问题、目标及路径等信息的交换。

第十三章为临床检验自动化(clinical laboratory automation),本章介绍了实施临床检验自动化通信接口所需的HL7触发事件、消息和段,适用于实验室各种仪器设备及应用系统之间的连接,其中交换的信息包括:各种设备、分析仪、样本、样本容器及容器支架的过程控制和状态信息,与患者、医嘱及检验结果相关的信息和详细数据,以及与样本流程算法及自动化决策相关的信息。

第十四章为应用程序管理(application management),是对支持HL7标准的网络应用进行管理。

第十五章为人员管理(personnel management),本章适用于应用系统之间交换医疗机构的人员信息,如在排程管理、医嘱管理、用户权限等领域都需要使用这部分信息,人事管理事务用于传递医疗服务执行人员及全体支持人员的新的或更新的医疗管理信息。

第十六章为医疗费用申报和报销(claims and reimbursement),用于支持电子交易的医疗费用的申报与报销。

第十七章为供应材料管理(material management),本章定义通信与事务相关的各种事件消息,这些事务来自一个医疗服务设施内的供应链管理。

HL7 V2消息标准的首要目标是为医疗系统间的数据交换提供标准,来消除或明显降低医疗系统间定制化数据交换界面的开发及维护成本,使系统间的数据交换简单、便捷。这个首要目标可以进一步细化为下面的一系列子目标。

1.标准应当支持在巨大差异化的技术环境中应用系统之间的数据交换。标准的实施应当具备实践性,应当适用于各类程序语言及操作系统,应当支持各类通信协议下的数据交换。

2.应当同时支持基于单个事务的数据即时传递和基于多个事务的批量数据传递。

3.在充分考虑用户在某些数据格式和使用上的差异性的同时,应当实现最大程度的标准化。标准应当兼容用户的定制化需求。

4.标准必须支持由于新的需求所带来的标准进化和成长,包括标准的扩展及新版本的发布。

5.标准应当基于现有产品的数据交换协议和业界广泛接受的标准协议之上,同时要避免建于个别公司自己的数据交换协议之上。

6.在不同医疗系统中的不同医疗流程使得开发完全通用的应用程序或数据模型成为不可能,真正意义上的即插即用标准还不存在,数据交换双方仍需进行基于标准的数据交换协议的协商。

HL7 V2的消息由一系列不同长度的数据字段组成,数据字段间由字段分隔符号隔开。HL7消息的编码规则描述了不同的数据类型如何在单个字段或重复字段中进行编码。多个数据字段可以合并为一个逻辑组,称为消息段,多个消息段由消息段分隔符隔开。每个消息段以开头三个字母作为标识符,一个消息包含多个消息段,不同的消息段可以是必须出现的、可选的或可重复的。消息中的单个数据字段是通过包含它的消息段中的位置来确定的。

(一)消息交互概念模型

医疗系统或应用程序间的数据交换可以通过彼此间的消息发送和接收来实现,基于HL7 V2标准的消息交互包括以下组成。

1.触发事件(trigger event)

标准的开发基于一个假设:在实际医疗环境中发生的医疗事件会引发各临床系统间产生数据交换。这个实际医疗环境中发生的医疗事件就称为触发事件,因为它触发了数据在信息系统中的传递。例如,“患者住院”是一个触发事件,它触发患者个人信息被传递到不同的临床信息和管理系统中,如出入院系统、收费系统、检验系统及电子病历系统等。“血常规检查结果报告”也是一个触发事件,它触发检验系统将血常规检验结果的数据传递到电子病历系统。当信息交换和传递是由处理触发事件的程序主动发起时,这类交换和传递称为自动更新(unsolicited update)。HL7的触发事件可以在不同的数据颗粒度和内部关联层面使用。比如大部分患者管理(ADT)触发事件是关于单个对象的(如患者入院所触发的消息和数据传递是关于一个患者和账户的),但有些ADT触发事件则是关于多个对象间的关系(如患者数据融汇会涉及至少两个患者),还有些ADT触发事件是关于一组对象,但对象间没有明显的关联关系(如获取高血压合并2型糖尿病的全部患者记录)。

2.基本确认模式(acknowledgments:original mode)

当消息从一个系统发送到另一个系统时,我们需要知道底层的通信系统是否将消息正确送达,以及接收系统是否成功处理了发送的消息,基本确认模式是为支持以上需要而制定的,由接收系统向消息发送方返回确认消息,以确认发送方送出的消息已被成功接收,确认消息是HL7 V2消息的一种。确认消息可以包含消息发起系统所感兴趣的一些数据,如医嘱系统处理触发事件“为患者下检验医嘱”时,会向检验信息系统(laboratory information system,LIS)发送包含患者、检验项目及其他相关数据的消息,LIS在成功接收检验医嘱消息后,会向医嘱系统发送确认消息,为让医嘱系统更好地追踪检验医嘱,确认消息中可以包含LIS中该检验记录的流水号。

3.增强确认模式(acknow ledgments:enhanced mode)

是基本确认模式的扩展。增强模式区分了接收方对消息的接收确认(accept acknowledgement)和应用程序处理确认(application acknowledgement),并且允许消息发送方要求消息接收方对消息的接收和/或应用程序处理分别进行确认。当接收方将消息成功存储,不再需要发送方重复发送消息时,接收方会返回消息接收确认,当接收方将接收的消息成功的解析处理后,接收方可以返回应用程序处理确认并将处理结果返回到发送方。

两种不同模式的确认均通过HL7 V2的ACK消息来实现。图8-1表示了患者入院时,触发出入院系统发送ADT^A01消息到护士工作站系统,护士工作站系统接收到ADT^A01消息后,发送确认消息ADT^ACK到出入院系统的消息交互流程。

图8-1 HL7 V2消息交互概念模型

(二)通信环境

HL7 V2消息交换在ISO OSI模型的第七层——应用程序层进行,HL7V2对消息的内容和格式、消息间的关系、交换过程中的错误报告及处理予以了主要关注。通信环境可以是基于RS-232通信连接(系统间点对点通过数据线直接连接)进行消息交换,也可以是基于TCP/IP、DECNET和SNA等其他通信协议。针对RS-232通信连接,HL7制定了底层协议(lower level protocols,LLP)和最小底层协议(minimum lower layer protocol)标准[6],以支持此类通信环境中的消息交换。HL7标准假定通信环境应当提供以下功能。

1.无错误的数据传输

接收方可以假定所接收的是按正确顺序发送的完整数据。发送方收到接收方返回的确认消息后,即可假定接收方成功地收到消息。

2.字符转换

如果两个系统间交换的数据基于同样的字符集,但有不同的表现形式,则通信环境应当可以将一种表现形式转化为另一种表现形式。

3.消息长度

HL7不对消息的长度加以限制。标准设想通信环境能够传输任意长度的消息。但在实际环境中,实施方可以对消息的长度进行上限规定。对于超过该上限的消息,也可以使用消息延续协议(message continuation protocol)。

(三)消息框架

1.消息(message)

是系统间数据交换的最小单位,由一组按顺序排列的消息段(segment)组成,每个消息段以〈cr〉(回车符)结束。每个消息中的第一个消息段为消息头,其中包含一个消息类型代码(如ADT,代表消息应用目的),和一个触发事件代码(A01,代表引起此消息发送的触发事件),如图8-2所示。在HL7 V2消息标准的附件A(appendix A)中的A.3列表(表8-1)列出了全部的消息类型。在HL7 V2消息标准第二章中的0003表(表8-2)列出了全部的触发事件代码。

图8-2 消息由多个消息段顺序排列构成,每个消息段以<cr>结束

表8-1 附录A中消息类型列表

表8-2 HL7 V2第二章中触发事件代码表格

2.消息段(segment)

是具有逻辑联系的一组数据元素。消息中的消息段可以是必须的(required),也可以是可选的(optional),既可单次或重复出现,也可同其他消息段成组出现。消息中的第一个消息段是消息头(message header,MSH),携带关于消息本身的信息(metadata),如消息的发送方、接收方、消息类型代码、触发事件代码、版本信息等,图8-5列出了消息头的部分信息。消息头中的消息类型(message type)代码定义了消息的应用场景和目的,触发事件代码规定了触发此消息的临床事件,在图8-3中为A01,代表患者入院。一个消息类型可以有多个触发事件,但一个触发事件只能对应一个消息类型。

图8-3 消息头详解

每个消息段拥有一个唯一的由3个字母组成的消息段ID,如消息头(MSH)、触发类型消息段(EVN)、患者信息消息段(PID)等。以字母Z开头的消息段代表用户自定义消息段。以Z开头的消息段不属于HL7 V2消息标准的一部分。

3.字段(field)

字段是以由预先定义的分隔符隔开的字符串。一个消息段由多个字段组成。字段之间通常以“|”(竖杠)分隔符隔开。字段在消息段中的位置、长度、数据类型、可选性(必需的或可选的)以及含义在对应的消息段属性表中有明确的定义(图8-4)。

图8-4 消息段中的数据元素

消息段中相邻字段之间通过分隔符“|”隔开。字段根据所拥有的数据类型的不同,可以包含不同的部分(component),每个部分可以包含子部分(subcompoment)。消息段、数据字段、部分、子部分等各以不同的分隔符隔开(表8-3及图8-5)。字段的结构和内容由字段的数据类型决定,数据类型为简单型或复合型,详细的数据类型描述请参考HL7 V2标准的各个不同章节。

表8-3 HL7消息中的分隔符

图8-5 HL7V2消息分隔符示例

(四)与医学术语的关联

为提高系统间数据共享的水平,HL7 V2消息支持标准医学术语代码与数据的关联使用,消息中医疗数据可以通过与标准医学术语代码的关联来清晰明确地表达数据的含义。如此一来在不同的临床信息系统中,同一个医学概念虽然可能会有不同的表达和称呼方式,但通过与标准医学术语代码的关联,参与数据交换的各系统可以通过对所关联的标准医学术语代码的解读获得准确一致的定义,从而实现系统间的数据共享。HL7 V2消息标准2A章中的表0440(HL7 Table 0440)——数据类型表列出了全部HL7 V2的数据类型,其中,CE、CF、CNE、CWE、CX、XCN均支持标准医学术语代码关联。图8-6是HL7 V2中CE数据类型的定义。图8-7展示了CE数据类型在消息段OBX中对术语代码的支持——用LOINC医学术语系统中的肌酐代码表示肌酐。

图8-6 CE数据类型定义

图8-7 CE数据类型下医学术语代码的应用(肌酐的LOINC代码)

三、HL7 V2消息标准总结

HL7 V2消息标准是第一个在医疗卫生信息领域得到广泛应用的数据交换标准。从诞生之日起,它就不断地进行更新以支持持续增长的医疗信息系统数据交换和共享的需要。目前,HL7 V2消息标准主要应用于医院内各部门信息系统之间的数据交换,以支持医院日常业务的开展。HL7 V2消息标准的特点是容易使用、学习周期短,同时有大量成熟的开源或商业化的消息处理软件供实施者采用。

HL7 V2消息标准的不足是缺乏基本的一致性的医学信息模型。虽然通过消息、消息段、字段、分隔符、消息类型、消息段唯一标识符,以及标准术语代码的关联支持等机制,实现了一定程度的数据交换过程中对数据格式和数据内容的约束性规范,但在实际应用中,内容表达仍存在太多的可变性;HL7 V2消息标准对数据和消息的模型化表达缺乏正式的方法学,造成了在应用中对同一数据或消息理解和表达不一致的问题,基于同样的消息类型,不同的实施者仍会产生内容差异明显的消息实例,造成数据交换、处理,和共享过程中的障碍;HL7 V2消息标准没有清晰定义的系统角色和用户角色,这就导致了在实践中采用HL7 V2消息标准的那些部分及那些消息用于数据交换的支持完全依赖于实施者对HL7 V2的理解及对业务需求的主观判断,从而造成了不同厂商针对同一组临床功能所采用的HL7 V2消息类型有很大的不同,造成了数据互通、共享的障碍。HL7 V2消息标准起源于美国,其时HL7还不是一个国际化的标准组织,这就导致了HL7 V2消息标准对国际化的支持及对在其他国家和地区进行本地化实施的支持比较薄弱。

针对以上不足,近十年来HL7 V2消息标准工作组做了大量的工作,HL7 V 2.5之后的版本有了明显的改善。