[医疗信息化][DICOM教程]HL7 2.x标准的简短介绍-A Very Short Introduction to the HL7 2.x Standard...

[医疗信息化][DICOM教程]HL7 2.x标准的简短介绍-A Very Short Introduction to the HL7 2.x Standard

HL7 2.x标准的简短介绍

内容

1. 介绍
2. 需要V2标准
3. 成立，成长和组织结构
4. 关于V2消息编码和结构组件
5. V2消息确认机制
6. 最低层协议（MLLP）
7. 结论

---

介绍

这是有关HL7 2.x标准（通常称为“ V2”）的入门教程。我只介绍了足够的基础知识来帮助您入门。在后续的教程中，我们将从软件开发或配置的角度来深入研究这些细节。

需要V2标准

缩写“ HL7”代表“ Health Level Seven，Inc.”。它是由美国国家标准协会（ANSI）认可的标准制定组织（SDO）。该组织成立于1987年为交换/集成/共享/检索电子健康信息制定标准。在HL7标准到达之前，医院和其他医疗保健组织通常将有许多不同的软件应用程序在各种操作系统和硬件平台上运行并孤立运行。即使这些应用程序支持某些网络连接，它们也将使用专有协议交换信息。这使得应用程序的集成非常困难，尤其是来自不同供应商的应用程序。例如，患者注册系统将无法与计费系统或实验室系统进行通信，因此，这些系统将无法提供患者个人资料的合并视图以供医疗保健专业人员使用。结果是，

成立，成长和组织结构

自1987年HL7组织成立以来，这一切都发生了变化，其成员已经从1987年的14名成员增加到了全球2200多家成员，其中包括今天的500家公司成员和33个国家的国际会员。该组织发布的V2标准提供了有关如何构造，格式化，传输和接收医疗领域内发生的各种事件的消息的规则（注意：没有正式发布的“ V1标准” ，仅是概念证明） **）。“传输/确认”通信模型构成了遵循HL7标准的系统中信息传递的核心原理。随着医疗机构和供应商意识到其所提供的好处，接受度迅速增长。由于该标准没有为信息传递强加任何特定的网络协议，因此软件系统可以使用各种传输协议（例如LLP，FTP和SMTP）进行通信（稍后会详细介绍）。除了制定标准以提高医疗保健信息传递的有效性，效率和质量外，该小组还与其他标准制定组织以及国家和国际制裁机构合作，以开发支持性和兼容标准（例如DICOM，IHE）。任何人都可以成为会员，并且可以打折的价格使用已发布的标准和其他信息。该小组还开始提供认证考试，以测试标准的核心概念。如果您想使自己更适合作为系统集成商，软件开发人员或顾问来销售，则该证书可能会很有用。请访问组织的网站以获取有关认证的更多信息。

没有什么能比行动更快地消除焦虑了。〜沃尔特·安德森

在继续阅读我的文章之前，您可能还需要暂停一下[观看Marc Kohli的精彩视频，解释放射线学的典型工作流程，包括HL7标准（以及其他标准，例如DICOM）如何适合其中。我觉得这段视频确实说明了HL7如何集成到任何医院网络中更大的医疗保健工作流程中。

关于V2消息编码和结构组件

发送和接收的V2消息可以是HL7消息词汇表中定义的数百种消息类型中的任何一种。这些HL7消息通常是由信息系统创建和发送的，以响应事件的发生，例如患者入院，患者出院或可能是对另一个系统的查询。每个消息都包含有关该事件的信息。此外，每个HL7消息本身都是由segment组成的。尽管这些段本身又由字段组成，但这些段被认为是HL7消息的真正构建块。段具有三个字符的名称和特定字段的预定义格式。字段之间用“ |”分隔 （竖线）字符，并且可以进一步分为带有“ ^”字符的子组件。“ PID”段例如包含信息患者信息，例如ID号，姓名，地址和出生日期。不同的HL7事件触发不同的消息类型-每种消息类型都有一组定义的段，这些段连接在一起以提供有关该事件的所有必需信息。某些段是必填的，必须包含在消息中，而其他段是可选的。

例如，由于患者正在经历将患者分配到床的入院过程，因此发送“ ADT ^ A01”消息（“ ADT”代表“入院，出院，转院”）。它标志着患者开始在医疗机构住院的信号。此事件可以触发通知其他辅助系统，例如药房系统，该患者已经入院并且可能是合法开具的药物；病人已被接纳并需要制定护理计划的护理系统；计费期开始时的财务系统；患者已被接纳并有权获得服务的实验室，病理学和放射系统。该消息由MSH，EVN，PID，PV1段组成，有时甚至更多。在MSH段包含有关邮件的详细信息，例如发送和接收系统，日期和邮件类型。在EVN段包含了触发的事件，如事件类型，事件的日期/时间，触发事件的人员的详细信息。该PID段包含了相关患者的详细信息。PV1细分包含患者就诊的详细信息，例如就诊编号，病房/床位，主治医生，财务分类。因此，使用该消息将有关患者入院事件的所有相关信息传达到接收系统。以相同的方式，与患者，观察，财务和计费相关信息的其他信息也可以在各种软件系统之间进行通信。HL7 Inc.提供的HL7标准手册提供了有关触发事件，消息类型和段的大量详细信息。本地供应商之间的互操作性。有关更多详细信息，请参考与您所在国家/地区相关的标准机构。

V2消息确认机制

当传入消息（请参见上面的示例ADT A01消息的屏幕截图）到达接收系统时，消息确认（在HL7中称为“ ACK”）被发送回发送系统（如以下我的屏幕截图所示）。根据接收系统处理传入消息的能力，此确认可以采取许多不同的形式。如果消息已成功处理，则为肯定的ACK消息被发送到发送系统，并且该消息的通信结束。在HL7中，通过使用已发送的MSA段的第三个字段中的AA（应用程序确认）值传送肯定的ACK，确认的MSA段中的第三个字段包含与创建的消息中相同的消息控制ID通过发送系统。这允许发送系统将确认与之前发送的原始消息进行匹配。如果在处理传入消息期间出现错误，则为否定确认（在HL7中称为“ NACK”）被发送回发送系统。然后，传输系统可以诊断，修复并稍后将失败的消息重新发送回接收系统。通过在MSA段的第一个字段中使用AE（应用程序错误）值来指示否定ACK。该代码表明消息结构或消息本身有问题。

最低层协议（MLLP）

V2标准提出了一种在称为最小下层协议（MLLP）的TCP / IP协议之上构建的传输协议。。它本质上是一种包装协议，其中核心HL7消息以特殊字符封装，以向接收应用程序发送消息信息传输的开始和结束信号。使用MLLP协议发送的HL7消息以一个起始块字符为前缀，消息段以一个段分隔符终止，然后消息本身以两个字符（即一个终止块和一个回车符）终止。通常，通常用于表示起始块的字符是VT（垂直选项卡），其为ASCII11。FS（文件分隔符）ASCII 28用于表示结束块，而CR（ASCII 13）用于回车。但是，实施站点可以自由自定义这些站点，以在必要时使用不同的字符。

结论

这形成了构建协议的基础。在本系列的下一篇文章中，我将使用Java和C＃的示例说明如何使用MLLP协议发送，接收，解析和确认HL7消息，这是当今最流行的发送和接收HL7消息的形式。

* 如果您有兴趣深入了解HL7标准的开始，请在这里阅读RenéSpronk的出色文章。

A Very Short Introduction to the HL7 2.x Standard

CONTENTS

1. Introduction
2. Need for the V2 Standard
3. Inception, Growth and Organizational Structure
4. On V2 Message Encoding and Structural Components
5. V2 Message Acknowledgement Mechanisms
6. Minimal Lower Layer Protocol (MLLP)
7. Conclusion

---

Introduction

This is an introductory tutorial on the HL7 2.x standard (often to referred to as "V2"). I just cover just enough basics to get you started. In the subsequent tutorials, we will dive into the details more when we look at it from a software development or configuration perspective.

Need for the V2 Standard

The abbreviation “HL7” stands for “Health Level Seven, Inc.”. It is a standards developing organization (SDO) that is accredited by the American National Standards Institute (ANSI). The organization was founded in 1987 to produce a standard for the exchange/integration/sharing/retrieval of electronic health information. Before the HL7 standard arrived, hospitals and other healthcare organizations would typically have many different software applications running on a variety of operating systems and hardware platforms and running in isolation. Even when these applications supported some network connectivity, they would exchange information using proprietary protocols. This made integration of applications, particularly from different vendors, very difficult. For example, a patient registration system would be unable to communicate with a billing system, or a laboratory system, and therefore, these systems would be unable to provide a consolidated view of a patient’s profile for use by healthcare professionals. As a result, most organizations were often locked into proprietary technologies/solutions, and the costs and risks associated with implementing, integrating and maintaining healthcare systems was extremely high.

Inception, Growth and Organizational Structure

All this has changed since 1987 when the HL7 organization was created, and its membership has grown from a modest 14 members in 1987 to over 2200 members worldwide, including 500 corporate members today and International Affiliates in 33 countries. The V2 standard published by this organization provided rules on how messages for various events occurring within the healthcare domain should be structured, formatted, transmitted and received (note: there was no official release of a 'V1 standard' and was a proof of concept only**). The “transmit/acknowledge” communication model forms the core principle of information delivery in systems following the HL7 standard. Acceptance grew rapidly as healthcare organizations as well as vendors realized the benefits it offered. Since the standard did not impose any specific network protocol for information delivery, software systems could communicate using a variety of transport protocols such as LLP, FTP and SMTP (more on all of this later). Besides developing standards to increase the effectiveness, efficiency and quality of their healthcare information delivery, the group also collaborates with other standards development organizations and national and international sanctioning bodies in the development of supportive and compatible standards (e.g., DICOM, IHE). Any one can become a member and can get access to published standards and other information at a highly discounted rate. The group has also begun offering a certification exam testing the standard’s core concepts. The certification might be useful to have if you want to make yourself more marketable as a systems integrator, software developer or a consultant. Please visit the organization’s website for more information on the certification.

Nothing diminishes anxiety faster than action. ~ Walter Anderson

Before you continue reading my article any further, you may also want to take a pause and [watch this excellent video by Marc Kohli explaining the typical workflow in radiology including how the HL7 standard (along with other standards such as DICOM) fits within it. I feel that this video really explains the big picture of how HL7 integrates into the larger healthcare workflow within any hospital network.

On V2 Message Encoding and Structural Components

V2 messages sent and received can be any one of the hundreds of message types that are defined in the HL7 message vocabulary. These HL7 messages are often created and sent by an information system in response to an occurrence of an event such as a patient admission, a patient discharge or a it may be a query to another system. And each message contains information about that event. And further, each of these HL7 messages are themselves made up of segments. These segments are considered the real building blocks of HL7 messages although the segments themselves are in turn comprised of fields. A segment has a three-character name and a pre-defined format of specific fields. The fields are separated by the “|” (pipe) character and may be further divided into sub-components with the “^” character. A “PID” segment for example contains information patient information such as ID numbers, name, address and date of birth. Different HL7 events trigger different message types - each message type has a defined set of segments that are joined together to provide all the required information regarding that event. Some segments are mandatory, and must be included in the message, and other segments are optional.

For example, an “ADT^A01” message (“ADT” stands for “Admission, Discharge, Transfer”) is sent because of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient’s stay in a healthcare facility. This event can trigger a notification to other auxiliary systems, say, a pharmacy system that a patient has been admitted and may be legitimately prescribed drugs; the nursing system that the patient has been admitted and needs a care plan prepared; the finance system of the start of the billing period; the laboratory, pathology and the radiology systems that a patient has been admitted and is entitled to receive services. This message is comprised of the MSH, EVN, PID, PV1 segments and sometimes more. The MSH segment contains details about the message such as sending and receiving systems, dates and message type. the EVN segment contains details about the triggered event such as event type, event date/time, the person that triggered the event. The PID segment contains details about the relevant patient. PV1 segment contains details of the patient’s visit to hospital, such as visit number, ward/bed, attending doctor, financial classification. So, all relevant information about the patient admission event is communicated to the receiving systems using this message. In the same manner, other information pertaining to patient, observation, finance and billing-related information can also be communicated between various software systems. The HL7 standards manual available from HL7 Inc. provides extensive details on trigger events, message types, and segments. interoperability between local vendors. Please refer to the standards body relevant to your country for more details.

V2 Message Acknowledgement Mechanisms

When the incoming message (see screen capture of sample ADT A01 message above) reaches the receiving system, a message acknowledgment (called “ACK” in HL7) is transmitted back to the sending system (shown in my screen capture below). This acknowledgment can take many different forms based on how well the receiving system was able to process the incoming message. If the message was successfully processed, a positive ACK message is sent to the sending system and the communication is concluded for that message. In HL7, a positive ACK is communicated by using an AA (Application Acknowledgment) value in the first field of the MSA segment of the transmitted the 3rd field in the MSA segment of the acknowledgment contains the same message control ID that was in the message created by the sending system. This permits the sending system to match the acknowledgment to the original message that it transmitted earlier. If there were errors during the processing of the incoming message, then negative acknowledgments (called “NACK” in HL7) are transmitted back to the sending system. The transmitting system can then diagnose, fix, and later resend the failed message back to the receiving system. A negative ACK is indicated by using an AE (Application Error) value in the first field of the MSA segment. This code indicates that were either a problem with the message structure, or the message itself.

Minimal Lower Layer Protocol (MLLP)

The V2 standard proposed a transport protocol built on top of the TCP/IP protocol called Minimal Lower Layer Protocol (MLLP). It is essentially a wrapping protocol where the core HL7 message is enveloped in special characters to signal the start and end of transmission of message information to the receiving application. HL7 messages transmitted using the MLLP protocol are prefixed with a start block character, message segments are terminated with a segment separator, and the messages themselves are then terminated with two characters namely an end block and a carriage return character. Most often, the character typically used to signify start block is a VT (vertical tab), which is ASCII 11. The FS (file separator), ASCII 28, is used to signify end block, and CR (ASCII 13), is used for carriage return. However, implementing sites are free to customize these to use different characters as and when necessary.

Conclusion

This forms the foundation on which the protocol is built. In my next article in this series, I will illustrate, using examples both in Java and C#, how to transmit, receive, parse and acknowledge HL7 messages using the MLLP protocol, which is the most popular form of transmitting and receiving HL7 messages today.

*You should read René Spronk's excellent article here if you are interested in digging a little deeper into the beginnings of the HL7 standard, .