[醫療信息化][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, .