在HL7通信協議中，有四個基本術語概念:
★觸發事件:當現實世界中的某個事件產生系統間數據流的需求時，稱為觸發事件。
★報文:是系統間數據傳輸的最小單位，由壹組按指定順序排列的段組成。每條消息都使用壹種消息類型來表示其用途。
★段:是數據字段的邏輯組合。每壹段都標有唯壹的三字代碼，稱為段標。
★字段:是壹個字符串，也是壹個段的最小單位。
在HL7通信協議中，消息是系統間數據交換的基本單位，每條消息都有自己的消息類型(V2.4***有112)，用來定義消息的用途。消息類型中有觸發事件。壹條消息由多個段組成，每個段都有壹個對應的名稱，用來定義其內容或功能(V2.4***有138種)。
壹個段由多個數據字段組成。消息中的第壹段總是消息頭段，它指示發送和接收程序的名稱、消息類型和唯壹的消息ID號。下壹個數據段的組成由消息類型決定。例如，PID段(患者識別數據)包括姓名、地址、社會保險號等。數據字段可以由多個部分組成。壹些消息可以通過事件代碼進壹步細分。以下是HL7消息的壹個示例:
實際信息:轉院患者，患者王海於2002年淩晨11從301醫院急診室轉到北醫三院急診外科。301醫院轉診系統在轉診確認後2分鐘將患者轉診信息及基本信息發送至北醫三院:張三，身份證號1108197404012346，男，住址:海澱區復興路38號，電話。轉換成HL7消息後:？
MSH|^？~ \ & amp| 005急診室| 0802 301醫院| 0052急診外科| 0801北醫三院？
PID | | C | | | 330108197404012346 | |張三|19740401|男||| C |海澱區復興路38號。
Pv1 ||||||||急診外科|||||| 0007 Lisi ||||||急診| < cr & gt？
其中MSH是消息頭。
EVN是壹個事件類型？
PID是病人的身份證明嗎？
PV1是患者就診？
& ltcr & gt；結束壹段，表演者不能更改。HL7接口引擎的工作原理如右圖所示:
★發送/接收模塊:支持TCP/IP通信協議，HIS系統向數據中心發送電子病歷信息，信息格式為符合HL7標準的字符串格式。數據中心接收並解析HL7信息，將解析後的信息存儲在數據中心的數據庫中，完成後向發送方返回ACK確認消息，確認信息發送成功。
★HL7適配器模塊:實現字符串格式數據與XML格式的相互轉換，檢查驗證信息格式，保證發送/接收病歷數據的正確性和完整性。
★HL7 API模塊:提供符合HL7標準的應用接口，醫療應用系統可以調用接口函數，按照HL7標準格式填寫參數，從而向其他醫療應用系統發送數據。該模塊還可以調用符合HL7標準的Windows組件應用程序，將醫療信息數據傳送給醫療應用系統，以便接收來自其他醫療應用系統的數據。
★ HL7資源模塊:支持各種實用的HL7醫療信息事件，如查看醫囑、轉診病人等。
★映射模塊:提供翻譯對比功能，可根據醫療應用系統定制。
HL7接口引擎的概念可以理解為壹組支持HL7通信的過程調用函數或控件。應用程序按照HL7接口引擎的規定提供參數，模塊間的通信由HL7接口引擎完成。在國外發達國家，2012的主流醫療信息集成技術是“HL7/XML接口引擎”，是壹種集成多種技術的醫療信息集成技術，用於將各種醫院信息系統數據翻譯成符合HL7標準的XML信息格式，從而實現各種醫療衛生信息系統之間的信息共享和交換。要深入理解HL7接口引擎的原理，還得從數據通信的角度去研究。在數據通信中，有兩個層次的數據交換應用。數據交換應用的第壹級是處理現有的信息，只是“交換”現有系統中存在的信息數據。第二個層次是基於不同系統間數據通信的集成，旨在實現不同系統間數據通信和數據交換應用的無縫連接。這個層次的數據交換不僅要交換各種結果信息，還要交換各種過程信息，從而達到系統間交互的目的。基於以上兩個層次的數據交換，還有兩種基於HL7的數據交換方式。壹種“HL7引擎”模式，主要目的是讓用戶原來運行的、不可替代的系統具備HL7的通信能力。另壹種方式是“HL7 Ready”，即在整個系統中，HL7的接口協議已經在各個應用終端進行了設計和處理，各個終端應該能夠接收和處理HL7消息並進行相關處理。理論上可以實現系統間的實時交互操作，彼此可以在“需要的時候”主動獲取對方可以提供的數據信息。這種組織和醫療服務的提供是信息集中的結果。壹般認為，醫療操作的功效受信息管理功能自動化程度的影響。許多人認為，如果醫療保健提供者不能使他們的信息系統自動化，他們就不能在20世紀90年代的醫療市場上有效競爭。
在過去的20年裏，醫療機構，尤其是醫院，已經開始實現信息管理的自動化。起初，它朝著減少紙張處理、增加資金流和改善管理決策的方向發展。在未來幾年，發展的重點是合理化和改造臨床服務和輔助服務，其中包括臨床(在醫院和其他住院環境)和面向病人(在非固定設置)的系統。近年來，重點是開發和整合與傳輸患者生活護理信息相關的所有信息(如電子病歷)。可以想象，電子病歷的全部或部分將在任何時間和地點進行電子通信。
現在，綜合醫院都安裝了計算機系統，可以完成入院、出院、轉院、臨床檢查、放射、計費、記賬等功能。這些應用程序通常由不同的供應商或組織開發，這些供應商或組織的每個產品都有非常特殊的信息格式。隨著醫院信息管理業務的逐步擴展，關鍵數據共享系統應運而生。由選定的供應商制造的集成系統旨在實現大多數醫療信息管理，即使它們並不完美。這些系統可以設計成集中式或分布式結構。然而，在某種程度上，這樣的系統是完整的，它們的目的是減少對外部數據交換標準(如HL7)的需要。
但是，在模塊化的基礎上從單個部門開發或獲取應用程序的機構會有很大的壓力。壓力的來源之壹是大範圍的廠商不能很好地提供壹些特殊部門(或者全部)的需求。另壹方面的壓力是，醫院的整體制度環境需要通過壹系列的成長和各部門的決心來發展，而不是單壹的革命性收購。壓力會在包含壹個綜合系統或壹個由各個部門補充的完整離散系統的環境中產生。
網絡技術已成為壹種可用的計算機應用程序，它與醫療環境中的功能合成和技術變革密切相關。但這些應用並不是通過壹個類似的邏輯系統開發出來的，而是由市場結構決定的，所以往往非常特殊。對於這些應用在網絡環境中的接口，擴展的特殊定位編程和程序維護是必要的。這對用戶/買家來說需要相當大的開支，阻礙了賣家員工的創新，比如新產品的開發。如果醫療環境中的網絡接口標準可用並被供應商和用戶接受，則可以大大減少對特殊地址接口工作的需求。
壹般來說，重要的是供應商和用戶不再面臨支持不壹致的處理/通信結構的問題。相反，開發了壹個系統間最小不兼容性和最大信息交換的框架。建議將HL7作為這些領域的最高標準來建設，以促進公共規範和規範性方法。這才是醫療機構計算機應用標準接口的真正發展和保障。本標準的規範是根據先驗規定的目標制定的。標準的未來擴展也應該支持這些目標。
HL7的目的是促進醫療環境中的交流。主要目標是為醫療計算機應用程序之間的數據交換提供標準，從而消除或大大減少用戶界面編程和程序維護，否則這些編程和維護是必不可少的。這個主要目標可以用壹系列目標來描述:
a)本標準應支持廣泛技術環境中使用的系統之間的數據交換。它的實現可以應用於許多不同的編程語言和操作系統。它還支持多種通信環境中的通信，可以支持從完整的OSI和第7層網絡堆棧到不完整環境的互連，包括基本的點對點RS 232C，以及通過批處理介質(如軟盤和磁帶)傳輸數據。
b)應支持單個進程的直接傳輸以及多個進程的文件傳輸。
c)最大可能的標準化程度應與使用變化位置和某些數據元素格式相壹致。這個標準應該滿足特殊地址變化的需要。這包括特定於站點的表、代碼定義和可能的特殊位置信息段。(例如HL7 Z段)
d)本標準必須支持不斷增長的新確認要求。這包括支持擴展程序的引入並在現有操作環境中發布它們。
e)本標準應基於現有產品協議的經驗，並接受廣泛的行業標準協議。它不應該支持特定公司的某些利益而損害其他用戶的利益。與此同時，HL7尋求保留這樣壹個獨特的功能，獨立開發者可以將這個功能帶到市場上。
f)當它有用並且與醫院的內部信息系統相關時，長期目標應該是定義醫療環境中所有應用程序的格式和協議。
g)醫療交付系統中存在的不同業務流程的本質是阻止支持HL7目標環境的通用程序或數據模型的開發。此外，HL7沒有預設醫療信息系統的結構，也沒有試圖解決不同醫療信息系統之間的結構差異。至少基於這些原因，HL7不可能成為真正的即插即用接口標準。HL7中的這些差異更像是協商協議。
h)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的行動得到批準，並且經過討論認為有必要增加壹個新的章節，他們可以請求HL7技術委員會主席和執行委員會組成壹個技術委員會。
在前三次會議上，準備了標準版本1.0的草案，涵蓋了所有接口的結構、ADT、醫囑輸入和面向顯示的查詢。雖然病人付費系統被認為是非常重要的，但是時間框架不允許在初稿中引入它。這份草案出現在弗吉尼亞州泰森角召開的1987 10.08全體會議上，所有團體出席。
0版隨後準備了泰森角的全體會議，出現在了9月份圖森的第二次全體會議上，1988。二中全會以來，2.1、2.2、2.3三個版本的編輯修改工作從未間斷，工作組發展到300人，遠遠超過原來的12人。實現了以下內容:
a)細化和擴展了不同功能範圍的詳細規格。
b)與其他幾個標準建立了正式聯系:負責協調醫療標準的ANSI HISPP(醫療信息標準規劃小組)，後來被ANSI HISB(醫療信息標準委員會)取代；ASC X12N團隊負責外部MED標準，ASTM E31.11 0團隊負責臨床數據交換標準，ACR/NEMA DICOM團隊負責放射信息系統相關的其他標準，RIS)，IEEE P1157團隊負責。
c)在備註的基礎上修改通用控制結構，以適應廣泛的不同通信環境，並促進與其他標準組的合作。
d)。增加了壹章描述患者計費系統的界面。
e)編寫了描述輔助結果、臨床試驗、產品體驗和波形數據報告的章節，這些章節與ASTM 1238-91標準協調，並直接和積極地與ASTM E31.11的委員會成員協調。
f)。增加了支持相關信息系統主文件同步傳輸的處理集章節。
g)。關於支持病歷功能的應用程序接口的章節，包括復制管理、圖表定位和跟蹤、缺少分析以及內容和信息的發布。
h)。增加了關於新聞的章節，並通過預約服務或資源利用來支持關於各種事件的交流。
我)。增加了相關章節，以定義獨立醫療實體之間轉診通信的消息集。
j)。為所有數據庫創建了計算機化的數據字典和其他信息組件。附錄A包括從該電子數據字典產生的交叉引用和其他信息。
k)之前2.0和2.1版本中發現的矛盾和錯誤在2.3版本中已被標記和記錄。
l)已在醫囑)/登錄、臨床觀察章節中廣泛添加，包括數據元素、藥房醫囑、管理界面的定向結果。
m)消息確認已經擴展到包括獨立的增強模式，其定義了可接受的確認。當這種確認模式被允許時，HL7如何支持任何環境(例如存儲和轉發服務、執行服務之外的“接口引擎”等)是顯而易見的。)當媒體存在於具有固有時間延遲的網絡中時。直接確認在發送系統中使用，發送系統從請求到重發發出消息。
HL7抽象消息的定義之間存在差異。這個抽象定義完全符合第七層(應用層)的定義，這是HL7編碼規則，用於將抽象消息轉換為包含真實信息的字符串。其實這些編碼規則是壹個潛在的選擇建議，在第六層(表示層)的定義中已經完全定義好了，這裏不存在第六層的定義(比如ISO的ASN.1基本編碼規則(BER))。