Health Level Seven組織成立於1987年，由SamSchultz博士在賓夕法尼亞州大學醫院主持的一次會議促成了HL7組織和通信標準的誕生。隨著許多用戶、廠商、顧問組織的加入，HL7隊伍在逐漸壯大，於是成立了HL7工作組。
基本介紹
- 外文名：Health Level Seven
- 英文簡稱：HL7
- 成立時間：1987年
- 組織人：SamSchultz博士
基本信息,簡介,委員會及發展史,標準目標,標準背景,特點,實現方法,其他信息,訊息結構,工作原理,醫院對標準需求,發展目標,發展歷史,
基本信息
簡介
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現有會員2200多，其中團體會員超過1500個，代表世界上主要國家和包括醫療方面90%的信息系統供應商。參與HL7技術合作與推廣的國家和地區除美國外，還有澳大利亞、加拿大、中國、芬蘭、德國、日本、荷蘭、紐西蘭、英國、印度、阿根廷、南非、瑞典、韓國、中國台灣等。
HL7委員會的目的是開發和研製醫院數據信息傳輸協定及標準，最佳化臨床及其管理數據信息程式。
HL7委員會（截至2002年12月為止）設立了21個技術委員會
技術指導、構建回溯體系、 臨床上下文對象工作組（CCOW）， 臨床診斷支持，控制、查詢，教育，財務管理， 國際會員接納， 行銷，病歷記錄、信息管理，建模和方法學，醫囑、觀察資料，病人管理，病人護理， 人員管理，處理步驟改善， 出版， 臨床研究信息管理，工作安排和後勤，結構化文檔，術語。
15個特殊興趣委員會（Special Interest Groups，SIGs）：
HL7的委員會並不是固定不變的，特別是SIGs是可以由會員自由申請成立的。
標準目標
是作為規範各醫療機構之間，醫療機構與病人、醫療事業行政單位、保險單位以及其它單位之間各種不同信息系統之間進行醫療數據傳遞的標準。
作為信息交換標準，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是如何支持任何環境（例如存儲和向前服務，執行服務以外的“接口引擎”等）。直接確認被利用到發布從需求到再傳送訊息的傳送系統
