Health Level Seven组织成立於1987年，由SamSchultz博士在宾夕法尼亚州大学医院主持的一次会议促成了HL7组织和通信标准的诞生。随着许多用户、厂商、顾问组织的加入，HL7队伍在逐渐壮大，于是成立了HL7工作组。
简介
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））
|
|