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規則數據庫。然後，開發一種代碼生成器，它根據規則數據庫的內容，自動生成某一種計算機語言代碼。最後，可將這些代碼加入實際應用的程序框架。

用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的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^李四|||急診科|?

其中MSH是消息頭（Message Header）?

EVN是事件類型（Event Type）?

PID是病人基本資料（Patient Identification）?

PV1是病人住院情況（Patient Visit）?

；結束一個segment，該值不能被執行者改變。

HL7接口引擎的工作原理如圖1：

★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））