Health Level Seven组织成立于1987年,由SamSchultz博士在宾夕法尼亚州大学医院主持的一次会议促成了HL7组织和通信标準的诞生。随着许多用户、厂商、顾问组织的加入,HL7队伍在逐渐壮大,于是成立了HL7工作组。
基本介绍
- 外文名Health Level Seven
- 英文简称HL7
- 成立时间1987年
- 组织人SamSchultz博士
基本信息
简介
HL7 卫生信息交换标準(Health Level 7)
标準化的卫生信息传输协定,是医疗领域不同套用之间电子传输的协定。HL7汇集了不同厂商用来设计套用软体之间接口的标準格式,它将允许各个医疗机构在异构系统之间,进行数据互动。
HL7的主要套用领域是HIS/RIS,主要是规范HIS/RIS系统及其设备之间的通信,它涉及到病房和病人信息管理、化验系统、药房系统、放射系统、收费系统等各个方面。HL7的宗旨是开发和研製医院数据信息传输协定和标準,规范临床医学和管理信息格式,降低医院信息系统互连的成本,提高医院信息系统之间数据信息共享的程度。
Health Level 7中的“Level 7”是指OSI的七层模型中的最高一层,第七层。但这并不是说它遵循OSI第七层的定义数据元素,它只是用来构成它自己的抽象数据类型和编码规则。它也没有规定规范说明如何支持OSI第一到第六层的数据。
HL7并没有提供一个完全的“即插即用”解决方案,因为在医疗机构的传输环境中有两个重要的影响因素
⑴医疗机构的传输环境中缺乏处理的一致性;
⑵产生的结果需要在用户和厂商间进行协商。
,它提供的是一个可在较大範围内选择数据和处理流程的灵活系统,并儘可能的包括所有已知的程式(触发器Trigger)和数据(段Segment和域Field)要求。
在HL7通信协定中,讯息(Message)是数据交换的基本单位。HL7的讯息是自动生成的,它将HL7标準文档自动转化为一个HL7规则资料库和部分程式数据结构代码。实现一个通信标準的具体工作是生成数据结构,以及实现一个构造器(Builder)和一个解析器(Parser)。数据结构表现了标準中各个数据对象的相互关係。构造器将数据结构中的数据转化成能在电子数据交换媒介中传输的数据串。而解析器能够将数据串解析回原来的数据结构。HL7标準是一个文本结构的文档。,利用一些文字处理工具将文档中的各个数据定义抽取成数据结构,再将结构的形式存入预先定义的HL7规则资料库。然后,开发一种代码生成器,它根据规则资料库的内容,自动生成某一种计算机语言代码。,可将这些代码加入实际套用的程式框架。
图1说明的是用HL7标準实现各种医疗设备互连,其中的ADT指的是入院、出院和转移,通常简称为ADT(Ad-mission、Discharge、Transfer)。ADT主要是关于病人个人信息的生成和更新,以及病人来访等信息数据的交换。由于任何加入医疗系统网路的设备都需要病人的个人信息,ADT是HL7标準中套用最广泛的一个方面。通常,进入一个ADT系统的数据总是要传递给医院的各种系统,2013年甚至要传递给保险公司。
委员会及发展史
HL7(Health Level 7)作为一个机构,成立于1987年,从1994年起是美国国家标準局(ANSI)授权的标準开发组织(SDO)之一,是从事医疗服务信息传输协定及标準研究和开发的非盈利组织。
HL7现有会员2200多,其中团体会员超过1500个,代表世界上主要国家和包括医疗方面90%的信息系统供应商。参与HL7技术合作与推广的国家和地区除美国外,还有澳大利亚、加拿大、中国、芬兰、德国、日本、荷兰、纽西兰、英国、印度、阿根廷、南非、瑞典、韩国、中国台湾等。
HL7委员会的目的是开发和研製医院数据信息传输协定及标準,最佳化临床及其管理数据信息程式。
HL7委员会(截至2002年12月为止)设立了21个技术委员会
技术指导、构建回溯体系、 临床上下文对象工作组(CCOW), 临床诊断支持,控制、查询,教育,财务管理, 国际会员接纳, 行销,病历记录、信息管理,建模和方法学,医嘱、观察资料,病人管理,病人护理, 人员管理,处理步骤改善, 出版, 临床研究信息管理,工作安排和后勤,结构化文档,术语。
15个特殊兴趣委员会(Special Interest Groups,SIGs)
阿登语法,附属档案,临床指导方针, 临床基因, 社会基本健康服务,兼容性,电子病历(EMR),政府计画,图像集成,Java,实验室自动化和测试,药物治疗,安全和责任,模板,XML。
HL7的委员会并不是固定不变的,特别是SIGs是可以由会员自由申请成立的。
标準目标
HL7作为标準它是开放系统互联(OSI)七层协定第七层(套用层)的协定。
是作为规范各医疗机构之间,医疗机构与病人、医疗事业行政单位、保险单位以及其它单位之间各种不同信息系统之间进行医疗数据传递的标準。
作为信息交换标準,HL7自1987年发布V1.0版后相继发布了v2.0 v2.1 v2.2 v2.3 v2.3.1 ,2000年发布了v2.4版,现已用XML开发了v3.0版,但HL7 v2.4版本仍是ANSI正式发布的版本。
HL7目标
⑴ HL7标準应该支持各种技术环境下的数据交换,也应支持各种程式语言和作业系统,以及支持各种通讯环境。
⑵ 支持单数据流和多数据流两种通讯方式。
⑶ 最大限度的兼容性,预留了供不同使用者 使用的特殊的表、编码定义、和讯息段(如HL7的Z-segments)。
⑷ 标準必须具有可扩展性,以支持新的要求,这包括协定本身的扩展及与现有系统和新 系统的兼容。
⑸ 标準应该是在充分参考现有的产品通讯协定基础上,被广泛接受的工业标準。
⑹ HL7的长期目标就是制定一种用于医疗机构电子数据交换的标準或协定。
标準背景
第七层是国际标準组织(ISO)的开放式系统互联(OSI)模型的最高层。这不是说HL7与ISO定义的OSI的第七层原理完全一致。而且,HL7也没有指定一套ISO批准的规范,以便占领HL7抽象讯息规范作用的1-6层。HL7符合位于OSI模型的第7层内的这种从套用端到套用端接口的概念定义。
在OSI概念模型中,通讯软体和硬体的功能被分在第7层。HL7标準主要关注在第7层发生的或是套用层发生的问题。这些就是在应用程式之间被交换的数据、交换时间以及应用程式间通讯的特殊应用程式错误的定义。,与OSI模型协定低层有关的协定有时也被提到帮助系统理解标準的上下文,这是必须的。他们有时也被提到以帮助实现者建立基于HL7工作的系统。
HL7工作组是由志愿者组成的,他们是在个人时间或僱主倡导的时间内做的。HL7工作组的成员已经,并且愿意继续为那些有志于建设、发展、精炼医疗系统网路技术的第7层接口标準的人开放。
这个标準可以在不同的系统中进行接口的编址,这些系统可以传送或接收一些信息,包括就诊者入院/登记,出院或转院(ADT)数 据,查询,就诊者的资源和计画安排表,医嘱,诊断结果临床观察,费用,主档案的更新信息,医学记录,安排,就诊者的治疗安排以及就诊者的护理。这不是试图 假设一个在应用程式中与数据的布置有关的特殊体系结构,而是被设计用来支持一个中心就诊者护理系统,以及支持数据在部门系统中的分散式环境。
如果我们认为多数的医护信息系统应用程式和传送医疗的各种环境一样,那幺很明显这会有很多接口可以受益于这种标準化的定义。参与了编写标準过程的成员对接口的选择有很高的优先权。HL7的目的就是为这些接口準备一个完整的标準,其建立在可以有力的支持很多其它接口的一般构架的基础上。这个标準已经投入使用而且做为扩展现存接口定义的基础,并增加了一些其它定义。
这篇文档是按以下方式编排的。本章的余下部分包括发展标準的基本理由,标準的发展目标,工作组从属的範围和操作入门的方法。希望可以帮助读者理解决定发展此标準的依据。以后的章节分别说明
a)所有接口(包括通用查询接口)的全部结构
b)就诊者入院,出院,转院和登记
c)医嘱输入
d)就诊者记帐(帐目)系统
e) 临床观察数据,如化验结果,做为能识别的数据元素被传送(而不是显示定向文本)
f)为同步的公共参考档案(主档案)设立的通用接口
g)医学信息管理
h)就诊者和资源的安排计画
i)有关两个机构间的转诊病人的转诊讯息
j) 支持面向问题通讯的就诊者护理讯息,在计算机信息系统中为临床途径的实施提供功能
特点
完整性-对基本的医嘱,财务,检验信息都有了规范的描述,而且做得非常详细,如病人的饮食忌讳,宗教信仰等按照相应的ISO标準描述。
可实现性-选择OSI第七层做标準,保证其可实现性。
兼容和扩展性-包括对中药计量单位的支持。
安全性-由于HL7的开发和兼容性导致安全性很难保障,儘管支持数字签名,但主要还是要靠网路底层协定保证。
实现方法
一、採用点对点通讯方法以实现不同系统的对接;
二、採用HL7伺服器的方法实现,HL7 Server实际上是套用伺服器,形成居于HL7接口的中心资料库,这样可以减少接口数量,提高系统可靠性。
其他信息
讯息结构
HL7标準包含256个事件、116个讯息类型、139个段、55种数据类型、408个数据字典,涉及79种编码系统。
HL7通讯协定中,有四个最基本的术语概念
★触发事件(trigger events)当现实世界中发生的事件产生了系统间数据流动的需求,则称其为触发事件。
★讯息(message)它是系统间传输数据的最小单位,由一组有规定次序的段组成。每个讯息都是用一个讯息类型来表示其用途。
★段(segment)它是数据栏位的一个逻辑组合。每个段都用一个唯一的三字元代码所标誌,这个代码称作段标誌。
★栏位(field)它是一个字元串,是段的最小组成单位。
在HL7通讯协定中,讯息(Message)是数据在系统之间交换的基本单元,每条讯息都有各自的讯息类型(V2.4共有112种),用于定义讯息目的讯息类型中有触发事件。一个讯息由多个段(Segment)组成,每一段都有相应的名称,用于界定其内容或功能(V2.4共有138种)。
而一个段又由多个数据栏位(Data Field)组成。一个讯息中的第一个段总是讯息头段(Message head segment),它指明了传送和接收的程式名、讯息类型、以及一个唯一的讯息ID号码等,接下去段的构成由讯息的类型决定。如,PID段(Patient Identification Data)包括姓名、地址、社会保险号等。一个数据栏位又有可能由多个组件组成。有些讯息可进一步由事件码(event code)细分。以下为一个HL7讯息实例
实际信息转院患者,患者王海于2002年12月1日上午11点12分由301医院急诊室转往北医三院急诊外科李四。301医院转诊系统转诊确认后2分钟向北医三院发出患者转诊信息和患者基本情况张三,身份证号110108197404012346,男性,住址海淀区复兴路38号,电话85591234。转成HL7讯息后为?
MSH|^?~\&|005^急诊室|0802^301医院|0052^急诊外科|0801^北医三院?
PID|||| 330108197404012346||张三|19740401|男||C|海淀区^复兴路^38号
PV1||急诊外科||||0007^李四|||急诊科|<cr>?
其中MSH是讯息头(Message Header)?
EVN是事件类型(Event Type)?
PID是病人基本资料(Patient Identification)?
PV1是病人住院情况(Patient Visit)?
<cr>;结束一个segment,该值不能被执行者改变。
工作原理
HL7接口引擎的工作原理如右图
★Send/Receive module(传送/接收模组)支持TCP/IP通讯协定,HIS系统向数据中心传送电子病历信息,信息格式为符合HL7标準的字元串格式。数据中心接收并解析HL7信息,将解析后的信息存到数据中心的资料库中,完成后回复传送端一个ACK确认信息,确认信息已经传送成功。
★HL7 Adaptor module(转换模组)实现字元串格式数据与XML格式之间的相互转换,对信息格式进行检查验证,保证传送/接收病历数据的正确完整。
★HL7 API module(套用接口模组)提供符合HL7标準的套用接口,医疗套用系统可以调用接口函式,按照HL7标準格式填写参数,实现向其他医疗套用系统传送数据。该模组也可以调用符合HL7标準的Windows组件应用程式,将医疗信息数据传递给医疗套用系统,实现接收其他医疗套用系统的数据。
★HL7 Resource module(HL7资源模组)支持各种实际套用的HL7医疗信息事件,如检查医嘱、转诊等。
★Mapping module(对照模组)提供翻译对照功能,可以按照医疗套用系统进行定製。
对于HL7接口引擎的概念,可以这样理解,它是一组支持HL7通讯的过程调用函式或控制项,应用程式按照HL7接口引擎的约定提供参数,模组之间的通讯则由HL7接口引擎完成。在国外已开发国家中,2012年主流的医疗信息整合技术为“HL7/XML接口引擎”,它是整合多种技术合成的医疗信息整合技术,用以转译各种医院信息系统数据至符合HL7标準的XML信息格式,以实现各种医疗卫生信息系统之间的信息共享与交换。要深入了解HL7接口引擎的原理,我们还是必须要从数据通讯这个方面来研究。在数据通讯方面,有两种层次的数据交换套用。第一层次数据交换套用,是对现有信息进行处理,只是"交换"现有的系统中存在的信息数据。第二种层次的是基于不同系统之间进行整合的数据通讯,其目的达到不同系统之间的无缝连线而进行的数据通讯和数据交换套用。在这个层次的数据交换不仅要交换各种结果信息,还要交换各种过程信息,从而达到系统之间的互动目的。基于以上两个层次的数据交换方式,对应基于HL7的数据交换也存在两种方式。一种“HL7 Engine”方式,主要目的是使得用户原有正在使用运行的且不能替换的系统具有HL7的通讯能力。另一种是“HL7 Ready”方式则是在整个系统中,在各个套用终端已经对HL7的接口协定进行了设计和处理,各个终端都应当可以接收和处理HL7讯息,并进行相关的处理。在理论上可以达到系统和系统之间实时的互动运作,可以相互主动地在"需要的时候"获取对方可以提供的数据信息。
医院对标準需求
这个组织和医疗服务的提供是信息集中化的结果。通常认为医护操作的功效受信息管理功能自动化程度的影响。许多人相信如果医护提供机构不能使他们的信息系统自动化,那幺在90年代的医疗市场中就不能进行有效的竞争。
在过去的20年 中,医疗机构,尤其是医院,已经开始在他们的信息管理方面进行自动化处理。最初,是朝着减少纸张的加工,增加资金的流动以及改善管理决策方面发展。在以后 的几年中,发展的焦点在于合理化改造临床服务和辅助服务,这些服务包括临床的(在医院和其它住院病人环境中)和病人方面(在非固定的设定中)的系统。在近 几年,热点在于发展综合所有与传送就诊者一生的护理信息(如一个电子医学记录)有关的信息。可以想像全部或部分电子医学记录将在任何需要的时候和地点进 行电子通讯。
现 在,一般的医院都安装了计算机系统,可以进行入院、出院、转院、临床检验、放射、开票以及记帐功能。这些套用时常由不同厂商或组织开发,这些厂商或组织的 每个产品都有非常特别的信息格式。随着医院逐渐扩展信息管理操作,在系统中共享关键数据就应运而生了。被选中的销售商所製作的综合系统都是针对大部分医疗 信息管理的实施,即使并不完善。这些系统可以被设计在一个集中或分散式的体系结构中,,从某种程度上来说,这样的系统是十分完整的,其用途是减轻了对 外部数据交换标準(如HL7)的需要。
然 而,在模组化的基础上发展或获得单个部门应用程式的机构会有很多压力,压力的来源之一是由于广泛的销售商不能很好的(或全部)提供一些特殊部门的需要,另 外一方面的压力就是需要通过一系列的增长、各部门的决心而非一个单一的、革命性获得物来发展医院的整体系统环境。压力会在包含一个由各部门系统相互补充的 综合系统或一个完整的离散系统的环境中产生。
网 络技术作为一种可用的、接近功能综合以及在医学环境中技术变化的计算机应用程式已经出现。,这些应用程式与其通过一个相近的逻辑系统发展起来,不如依 靠市场结构发展,他们经常是很特别的。为了这些应用程式在网路环境中的接口,扩展的特殊定位编程和程式维护是很必要的。这对用户/买方来说,都需要有相当的费用,从而阻碍了销售商员工的创新,例如新产品的开发。如果医疗环境中的网路接口标準是可以获得的,并被销售商和用户接受的话,那幺特殊地址接口工作的需要就可以大大减少了。
,销售商和用户不再面临支持不一致的处理/通讯结构这样的问题,这是很重要的。相反,在系统之间,具有最小不相容和最大的信息交换的框架已经发展起来了。有人建议把HL7建成一个这些领域中的最高标準以促进公共规范和规范方法。这才是真正为医疗机构的计算机套用的标準接口提供了切实的和经济的发展与保证。
发展目标
这个标準的规范是按apriori指定的目标发展的。标準未来的扩展也应该支持这些目标。
HL7的目的是促进医疗环境中的通讯。主要的目标是提供在医疗计算机应用程式之间进行数据交换的标準,这些应用程式是除去或从本质上减少用户接口编程和程式维护,否则这些编程和维护必不可少。这个主要目标可以用一系列目标来描述
a) 这个标準应该支持使用在多种广泛的技术环境系统之间的数据交换。它的实施可以套用在多种不同的程式语言和作业系统上。它也支持在广泛的多种通讯环境下的通讯,可以支持从完整的遵循OSI,第7层网路堆叠到不完整的环境包括基本的点到点的RS 232C的互连和由批量介质(如软碟和磁带)传送数据。
b)直接传送单个处理应当与多个处理的档案传送一样被支持。
c) 最大可能的标準化程度应该达到与用法变异位置和一定数据元素格式一致。这个标準应该适应特殊地址变异的需要。这包括,特殊位置(site-specific)表,编码定义和可能的特殊位置信息段。(如HL7 Z-段)
d)这个标準必须支持不断增长的获得确认的新要求。这包括支持介绍扩展的程式并发布在已存在的操作环境中。
e)这个标準应该建立在现有的产品协定的经验上并且接受广泛的工业标準协定。而不应该支持特定公司的某些利益以至损害到其他用户。HL7寻求保存这样一个唯一的特性,即独立开发商的可以把这种特性带向市场
f)当它有用并与医院内部的信息系统有关时,长期的目标就应该是定义所有医护环境中的应用程式的格式与协定。
g)存在于医疗传送系统中的不同商业过程的本质是阻止支持HL7目标环境的通用程式或数据模型的发展。,HL7并不预先假设医疗信息系统的结构,也不尝试去解决不同医疗信息系统间的结构差异。至少因为这些原因,HL7不能成为一个真正的即插即用的接口标準。HL7中的这些不同更像协商过的协定。
h)HL7工作组的主要兴趣已经儘可能转到了套用标準上。为达到这一点,HL7也发展了一个支持一致投票过程的基层组织并已经由美国国家标準协会(ANSI)认可为一个授权的标準组织(ASO)。
i)与其它相关的医护标準(如ACR/NEMA DICOM,ASC X12,ASTM,IEEE/MEDⅨ,NCPDP等)一起合作已成为HL7的优先活动。HL7自从1992年建立后就参与到ANSI HISPP(健康信息系统计画工作组)进程中。
发展历史
从1987年3月以来,HL7工作组大约每三到四个月就聚在一起来开发和讨论这个规范。工作组加入到委员会指定开发下的每个功能接口,,辅助委员会指定所有的控制结构和小组的不同管理。这些委员会有责任编制和维护HL7界面标準中的章节。,在HL7内部经常形成不同的兴趣小组来发展他的思想,并且发起一些专门委员会没有涉及的特殊看法。如果一个特殊的兴趣小组
的行动得到批准并且一个新的章节经过讨论认为是必须的,他们可能请求HL7技术委员会主席和执行委员会组建一个技术委员会。
在最初的三个会议上,版本1.0标準草稿準备覆盖所有接口的结构、ADT、医嘱输入、面向显示的查询。儘管就诊者记帐系统被认为非常重要,时间框架并不允许在第一个草稿中就引入它。这个草稿出现在Tyson’s Corner,VA召开的所有小组出席的1987年10月8日全体会议上。
⒉0版本随后被準备到Tyson’s Corner的全体会议,并出现在1988年9月的Tucson的第二次全体会议上。从第二次全体会议以来,2.1、2.2、2.3版本的编辑和修改就没有间断过,工作小组已经发展到300个人,远远超过了原来的12个人。接下来的内容已经被实现
a).不同功能範围的详细规范已经经过精练和扩展。
b).发展了同其他几个标準的正式联络协调医疗标準的ANSI HISPP (医疗信息标準计画小组),以后被ANSI HISB (医疗信息标準委员会)取代;ASC X12N小组负责外部EDI标準,ASTM E31.11小组负责临床数据交换标準,ACR/NEMA DICOM小组负责与影像和放射信息系统(Radiology Information System,RIS)有关的其他方面的标準,IEEE P1157小组负责医学数据交换(MEDⅨ).
c).在备注的基础上修改一般的控制结构,以适应广泛的、不同的通讯环境并促进与其他标準组的合作
d).增加了描述就诊者记帐收费系统接口的章节。
e).準备了描述辅助结果、临床试验、产品经验和波形数据报告的章节,同ASTM 1238-91标準进行了协调,并直接、积极地同ASTM E31.11 委员会成员进行了协调。
f).增加了在相关信息系统中支持主档案同步传输的处理集合章节。
G).有关支持医学记录功能的应用程式接口的章节,这些功能包括抄写管理,图表定位和跟蹤,缺乏分析,内容和信息的发布。
h).增加了有关讯息的章节,支持对服务或资源利用进行预约安排的有关各种事件的通讯。
i).增加了有关章节,这些章节用于定义就诊者在相互独立的医护实体间转诊通讯的讯息集合。
j).创建了所有数据基础电脑化的数据字典和其他讯息组件。附录A包括从这个电子数据字典中产生的交叉索引和其他信息。
k).在以前的2.0,2.1版本中发现矛盾的事物和错误,已经在2.3版本中做出标着并记录。
l) 在医嘱(Order)/登录和临床观察章节中已有了广泛的添加,包括数据元素的定向结果,药房医嘱和管理接口。
m) 讯息确认已经被扩展到包括独立的增强模式内,这种模式定义了可接受的确认。当这种确认的模式已被允许,很明显 ,当媒介物带有固有的时间延迟存在于网路中时,HL7是如何支持任何环境(例如存储和向前服务,执行服务以外的“接口引擎”等)。直接确认被利用到发布从需求到再传送讯息的传送系统
n) HL7抽象讯息定义之间是有区别的,这种抽象定义完全是按照第七层(套用层)定义,为把一个抽象讯息转化成包含真实信息的字元串的HL7编码规则。这些编码规则事实上是一种建议成潜在的选择,它是完全定义在第6层(表示层)的定义中,第6层的定义在这是不存在的(如ISO的ASN.1 基础编码规则(BER))