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是如何支持任何環境（例如存儲和向前服務，執行服務以外的“接口引擎”等）。直接確認被利用到發布從需求到再發送消息的發送系統
n) HL7抽象消息定義之間是有區別的，這種抽象定義完全是按照第七層（應用層）定義，為把壹個抽象消息轉化成包含真實信息的字符串的HL7編碼規則。這些編碼規則事實上是壹種建議成潛在的選擇，它是完全定義在第6層（表示層）的定義中，第6層的定義在這是不存在的（如：ISO的ASN.1 基礎編碼規則（BER））