HL7的其他信息

发布网友 发布时间：2022-04-30 05:13

我来回答

共1个回答

热心网友 时间：2023-10-15 17:38

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 mole（发送/接收模块）：支持TCP/IP通讯协议，HIS系统向数据中心发送电子病历信息，信息格式为符合HL7标准的字符串格式。数据中心接收并解析HL7信息，将解析后的信息存到数据中心的数据库中，完成后回复发送端一个ACK确认信息，确认信息已经发送成功。
★HL7 Adaptor mole（转换模块）：实现字符串格式数据与XML格式之间的相互转换，对信息格式进行检查验证，保证发送/接收病历数据的正确完整。
★HL7 API mole（应用接口模块）：提供符合HL7标准的应用接口，医疗应用系统可以调用接口函数，按照HL7标准格式填写参数，实现向其他医疗应用系统发送数据。该模块也可以调用符合HL7标准的Windows组件应用程序，将医疗信息数据传递给医疗应用系统，实现接收其他医疗应用系统的数据。
★HL7 Resource mole（HL7资源模块）：支持各种实际应用的HL7医疗信息事件，如检查医嘱、转诊等。
★Mapping mole（对照模块）：提供翻译对照功能，可以按照医疗应用系统进行定制。
对于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））