[醫療信息化][DICOM教程]HL7 V3 Standard-概述-HL7 V3 Standard - A High Level Overview

HL7 V3 Standard-概述

內容

1. 介紹
2. 對V3標準的需求
3. 目標與目的
4. 關于V3發布，接收和關鍵組成部分
5. 參考信息模型（RIM）
6. 臨床文件架構（CDA）
7. 合并臨床文檔架構（C-CDA）
8. 護理連續性文件（CCD）
9. 結構化產品標簽（SPL）
10. 臨床上下文對象工作組（CCOW）
11. HL7開發框架（HDF）
12. 結論

---

這是有關HL7 V3標準的入門教程，主要針對剛剛開始使用它的軟件開發人員。我僅介紹了足夠的基礎知識，因為它是一個大型標準（V3實際上是在一個保護傘下的多個合作標準），因此向您簡要概述了該標準及其中的關鍵組件。在我的HL7系列的后續教程中，我希望從軟件開發的角度看一下該標準的各個部分時，可以深入研究該標準，并希望通過基于Java和Java的基于代碼的具體實現示例回顧一些用例。 C＃編程語言。

介紹

V3標準是HL7小組為解決V2標準中存在的許多挑戰而進行的雄心勃勃的嘗試的結果（有關快速概述，請參閱我之前關于V2標準的文章）。原始的V2標準（注意：沒有正式發布“ V1標準” ，僅是概念證明*）解決了當時存在的一個主要問題，即供應商的互操作性，因為專有協議用于消息交換。這使得實施成本高昂，容易出錯并且難以擴展和維護。在跨部門，醫院間和多學科的醫療機構中尤其如此，其中經常部署來自不同供應商的各種各樣的專用系統，并且仍然需要在它們之間進行數據通信。

V2標準為醫療保健行業贏得了兩項重大勝利。它建議使用一種格式來對消息進行統一編碼，以適應在現場看到的各種醫療情況，例如患者入院，患者出院，命令，觀察和醫療費用。該標準還為稱為MLLP（最小下層協議）的傳輸協議制定了規范。設計用于在當時流行的TCP / IP協議之上。由于這兩項改進，V2標準發布后，在世界范圍內迅速采用。它兌現了減少在醫院和其他臨床環境中所見到的維護大量數據接口的成本和難度的承諾。但是，即使采用它，裂縫也開始出現。

對V3標準的需求

憑借其靈活的管道分隔消息結構，有時甚至可以使用基本文件編碼器和解析器來實現/處理V2接口（請參閱我使用Java或.NET編寫的HL7編程文章）以供參考）。這使得V2標準和消息接口開發非常容易進行，即使對于新手也是如此。但是，從根本上講，V2標準有幾個缺點。它被設計為主要用于查詢/檢索范式（在關系數據庫中可見），并且在如何建模消息以及這些消息可以支持的數據類型方面存在限制。隨著采用V2標準的域的數量不斷增長，對更多特定于域的復雜且可重用的消息結構的需求也越來越多，這些消息結構可以在面向動態事件的消息工作流中使用（V2無法解決） ）。另一個缺點是由于V2消息中允許大量的可選性。這使得對信息交換的一致（“語義”）解釋變得非常困難。也，越來越多地認為 SNOMED CT和 LOINC）是必要的。所有這些挑戰以及醫療保健行業的其他醫療保健和技術創新（以及更多法規）推動了V2標準方法通過了最初設計的處理方式。

我們必須擁抱痛苦，并將其燃燒為旅途的燃料。?宮澤賢治。

目標與目的

為了應對這些挑戰，HL7組開始構想新的HL7標準。該新標準的一些關鍵目標是幫助改善健康系統接口的靜態和運行時特性的設計和實現。新標準將允許應用面向對象的建模過程，從而可以輕松地創建/增強/擴展消息，但同時又將其“約束”到任何醫療領域的特殊需求。而不是像V2標準那樣僅關注消息的結構，該新標準將更多地關注為什么消息首先需要發送。它還將支持使用特定領域的詞匯表（內部和第三方），從而更容易解釋人機之間在各種系統之間交換的任何信息。帶著如此崇高的遠見和一些雄心勃勃的目標，成立了工作組，并在90年代中期開始著手制定新標準。同時，行業界繼續在可能的范圍內發展V2標準（發布了從2.1到2.8.2的版本），同時確保這些修訂版本保持向后兼容。

關于V3發布，接收和關鍵組成部分

經過近10年的制定，V3標準終于在2005年發布，引起了混合反應。該標準對許多人來說是令人恐懼的，因為它需要一套全新的技能（例如UML，XML，面向對象的設計思想和一些專用工具）來理解和使用它。許多人也感到失望，因為V3標準與V2標準不向后兼容。事實證明，V3的早期嘗試和實施過于復雜且成本高昂，而這些初始實施的反饋表明，與以前使用V2標準所需的因素相比，需要更多考慮更多因素，從而導致更長的實施時間。

由于V3標準的規模，復雜性和工作時間長短以及它試圖解決的問題，將近十年的工作不僅導致了一個標準，而且在“ V3保護傘”下產生了許多不同的標準，這些標準可以可單獨使用或組合使用以解決醫療保健行業中遇到的許多挑戰。

其中一些標準包括：

1. 臨床文件架構（CDA）
2. 合并臨床文檔架構（C-CDA）
3. 護理連續性文件（CCD）
4. 結構化產品標簽（SPL）
5. 臨床上下文對象工作組（CCOW）

不久之后，衛生組織認可了其中一些標準（例如CDA和CCD，我將在本文的后續章節中介紹），它們為采用許多基于V3的方法提供了“認可印章”。全球標準。一些基于V3的標準已成功采用，以滿足世界各地政府和醫療保健信息學家的一些報告要求（例如，在美國有意義的使用以及相關的法規和促銷）。

在以下各節中，我將嘗試提供這些標準的要點。以后，我將在以后通過重點突出的文章來更詳細地介紹這些領域，這些文章將涉及實際用例以及相關的軟件開發方面。

參考信息模型（RIM）

RIM是V3規范的關鍵組成部分，對于大多數從V2進入V3的人來說，這是最令人生畏的領域。RIM本質上是一種對象建模框架，它允許設計和實現任何V3規范的所有方面，例如消息，文檔，框架和相關服務。希望通過解釋此框架的對象模型中的主要參與者來總結整個領域的“讀者摘要版本”。它們通常被稱為“ RIM骨干”，并通過類和接口定義進行指定，并結合使用，它們有助于定義任何醫療保健工作流程的靜態和運行時特性。首先，有一個法令標準定義為正在完成，已經完成，可以完成，打算要完成或要求完成的事情。然后就是所謂的實體，它可以是物理事物，一組物理事物或能夠參與行為的組織。還有一個角色，定義為實體扮演給定角色所需的技能或能力。然后是一種稱為參與的東西，它可以將任何行為和角色與扮演該行為的實體之間的關聯牢固地聯系起來。一個ActRelationship一個行為鏈接到另一個，最后，一個RoleLink表示整個消息工作流程中涉及的各個角色之間的關系。通過使用這六個核心類及其關聯的接口定義，可以派生出更多的專用類，以滿足特定領域的實現需求。

使用RIM的故事板有助于使用RIM進行任何建模活動，這些故事板有助于捕獲活動期間真實世界中發生的情況，并捕獲系統與所涉及用戶之間的交互的摘要，觸發事件有助于確定發生消息傳輸的各種原因在交互過程中，最后是應用程序角色，這些角色有助于定義此交互過程中涉及的任何發送或接收系統的角色。

通過使用RIM和其他支持框架，例如HDF（HL7開發框架）（我將在本文的下一部分中介紹），可以幫助建模各種內容，例如HL7 V3消息（類似于V2消息）。 ，用于特定領域甚至是新的HL7標準的信息建模框架。RIM本身使用更低的更專業的對象模型進一步完善，以實現所需的結果。例如，要派生V3消息，將使用域消息信息模型（D-MIM），其中圖（這些圖類似于UML，并且比傳統UML圖更緊湊的表示形式）有助于突出顯示各個類之間的關系。使用HL7組指定的約定。D-MIM本身會進一步完善以創建R-MIM（精簡消息信息模型）可用于創建序列化所需消息內容的表示形式，而此過程又借助使用 C-MET（公共消息元素類型）規范的實際消息表示形式而有所幫助，該規范有助于指定這些消息中使用的必要構建基塊和數據類型。所得的消息定義稱為 HMD（分層消息描述符）。這些HMD并未指定消息的實際實現特征，而最終通過使用稱為 ITS（實施技術規范）的另一種規范來實現這些信息。。如您所見，兔子洞變得非常深，這就是為什么RIM規范被視為令人生畏并且在許多方面有些令人困惑的原因。請注意，HL7組提供了大量可使用的預定義D-MIM，R-MIM和C-MET，因此，在嘗試構建自己的目錄之前，請始終參考這些特定于域的目錄。

臨床文件架構（CDA）

HL7小組在2005年創建了一個新標準，稱為臨床文檔體系結構（CDA），以促進更輕松地交換和解釋臨床數據。CDA本身是使用我之前介紹的HL7參考信息模型（RIM）標準以及使用稱為HDF（HL7開發框架）的東西派生的。我將在下一節中介紹。CDA文檔（以XML格式指定）包含一個強制性部分（供人類使用）以及一些供機器使用的可選部分，并且既可以攜帶結構化數據，也可以攜帶非結構化數據（例如圖像，視頻，波形圖和其他二進制數據）。CDA文檔與傳輸無關（并且不僅限于V3）。例如，可以使用其他協議（例如V2，DICOM，HTTP，電子郵件）或使用FTP交換CDA格式的數據。盡管CDA規范的發布對于醫療行業努力實現更高水平的信息交換標準化邁出了重要的一步，但人們認為還需要更多，特別是因為CDA對確切的格式含糊不清，這將使醫療服務更加統一。這些文件如何編碼。

如果一定有麻煩，那就在我的日子里，讓我的孩子有平安吧。?托馬斯·潘恩

合并臨床文檔架構（C-CDA）

為了實現標準化的醫療信息報告和數據交換，HL7組基于被稱為“ 綜合CDA（C-CDA）”的CDA規范創建了另一個標準或規范。C-CDA距CDA標準大約10年了，它提供實施指南以及基于最佳實踐的CDA模板庫，這些模板用于信息捕獲和現場交流的醫療保健信息的最佳實踐，以及指南和建議它來自其他醫療集團，例如IHE（整合醫療企業）和HITSP（醫療信息技術標準小組）。這些C-CDA模板用于實施許多目前在行業中可見的臨床文檔，包括護理連續性文檔（CCD）（我將在下一部分中介紹）和推薦信，它們實際上是包含兩個文件的XML文件。結構化和非結構化的患者數據，可用于支持與其他EHR（電子健康記錄）系統的健康信息交換。

護理連續性文件（CCD）

2007年，兩個標準的統一，即臨床文檔架構（CDA）標準（來自HL7組）和ASTM 的護理連續性記錄（CCR）標準產生了一個新標準，稱為護理連續性（CCD）。這項新標準可以在護理提供者和其他機構之間交換有關患者的全面健康信息（當前和歷史）。在該標準出現之前，在護理現場進行所需的患者醫療保健數據的傳輸非常繁瑣且耗時。

CCD標準極大地簡化了醫療保健提供多個階段所需的信息傳遞過程。例如，當醫生將患者轉診至醫院時，它可以促進信息傳遞，而醫院隨后需要訪問患者病歷的相關部分。當患者最終出院時，可以將醫院信息系統中捕獲的信息傳輸回醫生系統，從而為患者提供更流暢，更簡化的醫療服務。

CCD文檔（在本領域中以“護理文檔摘要”，“情節摘要”之類的一些其他名稱為人所知）以XML格式編碼，從而可以更輕松地在電子病歷（EMR）之間交換醫療保健數據）和電子健康記錄（EHR）軟件系統。CCD文件中交換的信息可能包括人口統計，過敏，程序，藥物，遭遇，問題清單，診斷信息，實驗室結果，免疫數據和健康危險因素。

結構化產品標簽（SPL）

HL7小組開發了一個新的基于文檔標記的標準，以緩解醫療行業中需要管理藥品標簽信息的問題，在該行業中信息經常過時或被錯誤解釋，從而給患者帶來嚴重的健康后果，并且有關的護理人員的風險和財務負債。SPL標準的目標是通過使用在創建過程中使用XML和相關技術而啟用的明確定義的數據結構和術語，來改善由藥品生產商提供的，供監管機構，護理提供者和患者使用的產品信息的完整性，傳播和解釋與毒品有關的信息。

在這種新的信息管理方式中，藥品生產商為產品創建了XML格式的核心文檔。然后，可以通過使用樣式表將其轉換為其他文檔格式，例如HTML，Word，PDF等，以在Web上，在印刷紙上和其他介質上使用，這些樣式表實質上是有關如何執行這些轉換的機器指令。這種方法的使用可確保一致且可重復的過程，從而在監管者，衛生保健從業人員，患者和公眾提交有關產品相關標簽的新信息或修訂信息時，可以提高準確性。XML的使用還可以簡化醫院系統所需的與機器相關的工作流程期間的數據交換和解釋，

臨床上下文對象工作組（CCOW）

CCOW是一種體系結構標準，為在醫療保健應用程序之間進行更輕松的集成和“上下文切換”提供了指南，醫療保健應用程序可能攜帶與患者或任何其他醫療實體在任何給定時刻有關的相關臨床數據的不同方面。基本上，它試圖為部署在任何醫療機構的所有技術和過程投資提高收益實現和信息處理的安全性。實施這些指南可改善患者數據的可訪問性，加快數據檢索的時間需求（通過預測接下來可能需要的數據來預加載數據），并更嚴格地控??制誰和什么可以訪問關鍵醫療信息。

CCOW的應用/使用的實際示例包括使用集成的單點登錄解決方案，精心設計的基于圖形或語音的界面以及現代的可訪問性準則，更嚴格的身份驗證/授權/審核控件，符合HIPAA，警告使用，警報應用程序中的其他消息以及其他消息，以確保用戶正在檢查和/或更新正確的信息，并在可能的情況下預填充任何信息，并減少手動用戶輸入和由此產生的錯誤等。

HL7開發框架（HDF）

盡管您現在已經對V3標準的核心組件有了一定的了解，但是仍然需要大量令人眼花other亂的其他信息來學習和理解，然后才能開始應用它來創建使用它的實現。 為了解決這個問題，HL7小組提供了一個稱為HL7開發框架（HDF）的東西，該框架提供了框架，建議，參與者，工件，工具和指南，可將其應用于與消息相關的工作流程開發的幾乎所有階段。 該框架取代了僅在90年代才設計用于消息開發的舊消息開發框架（MDF），并且開發了新的HDF框架以支持更廣泛的用例，包括在設計和開發新的HL7標準中使用。

HDF的七個階段包括項目啟動階段，該階段涉及定義項目，準備項目計劃，獲得高層項目批準的活動以及項目章程的制定；需求文檔階段涉及問題域的定義需求，領域模型的生成和與HL7參考模型的協調，以及需求規范文檔的生成，即規范建模階段，在此階段，通過由需求規范和后續規范設計驅動的迭代細化過程，將參考模型約束到設計模型中規則，約定和準則，以及一組規范設計模型，規范文檔編制階段，在此階段中，將規范設計模型包裝到邏輯單元中，并附以解釋性文字，并準備批準，并提出了擬議的規范；在“規范批準”階段，編制了旨在解決產品類型的經批準的規范擬議規范的復雜性所需的批準，規范發布階段，在此階段準備批準的規范以供發布和分發，然后正式發布規范，最后進行規范分析 在此階段中，將進一步完善規范模型，并遵循規范制定過程中使用的同一套設計規則，約定和準則，進一步約束規范，以生成規范的配置文件，以供特定的用戶社區在特定環境中使用..

如您所見，根據域的復雜性和所涉及的用例，設計過程可能相當嚴格且漫長。不幸的是，從高層概述的角度來看，這就是我可以涵蓋的全部內容。我將讓您瀏覽官方文檔，以獲取有關如何將這些步驟應用于您的情況的信息。但是，當我們將來查看更多面向代碼的文章中的實際用法示例時，我們將重新審視此領域。

結論

到此結束了有關V3標準的相當冗長的概述文章。該標準的內容遠遠超出我在這里可以涵蓋的范圍，但是我相信我已經觸及了這個大型標準的許多基本理念和關鍵部分（就像我之前說過的那樣，V3實際上是一系列標準）。該標準是HL7小組的一項艱巨任務，并產生了許多有用的框架，這些框架將有助于解決醫療保健行業在未來幾年面臨的許多問題。盡管它有用且可以解決問題，但是接近該標準的任何人都會發現它非常艱巨。通過解釋其起源，標準的目的和宗旨以及其關鍵組成部分，我希望我至少在某種程度上成功了，我的目標是使您能夠深入了解該標準的正式文檔并使其更容易理解。在以后的文章中在我的HL7教程系列中，我將嘗試使用一些基于代碼的示例來更詳細地說明這些領域，您可以在這些標準的任何實際應用中應用這些示例。回頭見！

* 如果您有興趣深入了解HL7標準的開始，請在這里閱讀RenéSpronk的出色文章。

 

 

HL7 V3 Standard - A High Level Overview

CONTENTS

1. Introduction
2. The Need for V3 Standard
3. Goals & Objectives
4. On V3 Release, Reception and Key Constituent Parts
5. Reference Information Model (RIM)
6. Clinical Document Architecture (CDA)
7. Consolidated Clinical Document Architecture (C-CDA)
8. Continuity of Care Document (CCD)
9. Structured Product Labeling (SPL)
10. Clinical Context Object Workgroup (CCOW)
11. HL7 Development Framework (HDF)
12. Conclusion

---

This is an introductory tutorial on the HL7 V3 standard mostly aimed at software developers who are just getting started on it. I cover just enough basics to provide you an overview of the standard and the key components in it as it is a large standard (V3 is really several cooperating standards under one umbrella). In the subsequent tutorials of my HL7 series, I hope to dive into more details of this standard when we look at various parts of the standard from a software development perspective, and review some use cases with concrete code-based examples of implementation using Java and C# programming languages.

Introduction

The V3 standard was the result of HL7 group's ambitious attempt to address the many challenges that existed in the V2 standard (see my earlier article on the V2 standard for a quick overview). The original V2 standard (note: there was no official release of a 'V1 standard' and was a proof of concept only*) had helped address a major problem that existed at that time which was vendor interoperability since proprietary protocols were used for message exchange. This made implementations costly, error prone and difficult to scale and maintain. This was especially the case in inter-departmental, inter-hospital and multi-disciplinary healthcare settings where a wide variety of specialized systems from different vendors are often deployed, and data still needed to be communicated between them.

The V2 standard produced two major wins for the healthcare industry. It recommended a format for consistent encoding of messages for a wide range of healthcare scenarios seen in the field such as patient admission, patient discharge, orders, observations, and medical billing. The standard also produced a specification for a transmission protocol known as MLLP (Minimum Lower Layer Protocol) designed to work on top of the TCP/IP protocol which was gaining in popularity at that time. As a result of these two improvements, when the V2 standard was released, it was rapidly adopted around the world. It lived up to its promise of reducing both the costs and difficulty in maintaining the numerous data interfaces that are seen in hospital and other clinical settings. However, cracks were beginning to appear even as its adoption grew.

The Need for V3 Standard

With its flexible pipe delimited message structures, V2 interfaces can sometimes be implemented/processed even using rudimentary file encoders and parsers (see my HL7 programming articles using Java or .NET for reference). This made the V2 standard and message interface development very easy to approach even for newcomers. However, at a fundamental level the V2 standard had several shortcomings. It was designed to work mostly in a query/retrieve paradigm (seen in relational databases) and had limitations in how messages could be modeled and the data types these messages could support. As the number of domains that adopted the V2 standard grew, the need for more domain-specific complex and reusable message structures with rich data types that could be used within dynamic event-oriented message workflows was also growing (which V2 was not capable of addressing). Another shortcoming was due to the sheer amount of optionality permitted in V2 messages. This made consistent ('semantic') interpretation of information exchanged very difficult. Also, a design approach that would allow more seamlessly integration with other standards as well as coding/terminology systems (such as SNOMED CT and LOINC) was increasingly seen as necessary. All these challenges as well as other healthcare and technological innovation (as well as more legislation) around the healthcare industry had pushed the V2 standard way passed what it was originally designed to handle.

We must embrace pain and burn it as fuel for our journey. ~ Kenji Miyazawa.

Goals & Objectives

To address these challenges, the HL7 group began to envision a new HL7 standard. Some of the key goals of this new standard were to help improve the design and implementation of both the static and runtime characteristics of health system interfaces. The new standard would permit the application of an object-oriented modeling process whereby messages could be created/enhanced/extended easily but also be "constrained" to the specialized needs of any healthcare domain at the same time. Rather than focusing on the structure of the messages alone like the V2 standard did, this new standard would focus more on why the messages need to be sent in the first place. It would also support the use of domain-specific vocabularies (both internal and third party) allowing for easier interpretation of any information exchanged between the various systems by both humans and machines. Charged with such a lofty vision and some extremely ambitious goals and objectives, working groups were set up and work began on a new standard in the mid 90s. The industry meanwhile continued to evolve the V2 standard to the extent it could (versions from 2.1 to 2.8.2 were released) while ensuring these revisions remained backward compatible.

On V3 Release, Reception and Key Constituent Parts

After nearly 10 years in the making, the V3 standard was finally released in 2005 to a mixed reaction. The standard was intimidating for many as it required a completely new set of skills (such as knowledge of UML, XML, object-oriented design thinking and some specialized tools) to understand and use it. There was also disappointment for many as the V3 standard was not backward compatible with the V2 standard. Early attempts and implementations of V3 proved to be too complex and costly, and feedback from these initial implementations suggested that many more factors needed to be considered upfront than was previously needed with the V2 standard leading to lengthier implementation timelines. It took some more time for the dust to settle on what this new and intriguing standard had to offer even if there was a foregone conclusion for many that most of the existing V2 implementations were not going to be replaced by the new V3 standard anytime soon.

Because of the size, complexity and length of work undertaken on the V3 standard and the problems it attempted to solve, the nearly decade long work had resulted in not just one standard but a number of distinct standards under the "V3 umbrella" that could either be used alone or combined to solve a number of challenges seen in the healthcare industry.

Some of these standards include:

1. Clinical Document Architecture (CDA)
2. Consolidated Clinical Document Architecture (C-CDA)
3. Continuity of Care Document (CCD)
4. Structured Product Labeling (SPL)
5. Clinical Context Object Workgroup (CCOW)

Endorsement of some of these standards (such as CDA and CCD which I will cover in subsequent sections in this article) by health organizations followed soon after, and they helped provide a "stamp of approval" for the adoption of many of these V3-based standards worldwide. Some of the V3-based standards were successfully adopted to address several reporting requirements for governments as well as for healthcare informaticists across the world (for e.g., Meaningful Use and related regulation and promotion in the US).

In the following sections, I will attempt to provide a gist of what these standards are. I will later cover these areas in more detail through more focused articles in the future that will touch on the practical use cases as well as related software development aspects.

Reference Information Model (RIM)

RIM is a key component of the V3 specification and is most intimidating area to most people entering V3 from V2. RIM is essentially an object modeling framework that allows one to design and implement all aspects of any V3 specification such as messages, documents, frameworks and related services. A "Reader's digest version" of this entire area can hopefully be summarized by explaining the major players in the object model of this framework. They are often referred to as the "RIM Backbone", and are specified through class and interface definitions, and combined, they help define both the static and run-time characteristics of any healthcare workflow. First, there is an Act which the standard defines as something that is in the process of being done, has been done, can be done, is intended to be done, or requested to be done. Then there is something called an Entity which can be a physical thing, a group of physical things or an organization capable of participating in an act. There is also a Role which is defined as a skill or competency that the entity requires to plays a given role. Then there is something called Participation which helps firmly link the association between any act and a role with an entity playing it. An ActRelationship links one act to another, and lastly, a RoleLink represents the relationships between individual roles that are involved in the overall message workflow. By using these six core classes and their associated interface definitions, more specialized classes are derived to address the implementation needs for a specific domain of interest.

Any modeling activity using RIM is aided through the use of Storyboards which help capture what happens in the real world during the activity and captures a summary of interaction between the systems and users involved, Trigger Events which help establish the various reasons for message transmissions to occur during the interaction, and finally Application Roles which help define the roles for any sending or receiving systems involved during this interaction.

Through the use of RIM and other supporting frameworks such as HDF (HL7 Development Framework) (which I will cover in a subsequent section in this article), one can help model things as varied as a HL7 V3 message (akin to a V2 message), a framework for information modeling for a specific domain, or even a new HL7 standard. The RIM itself is further refined with lower more specialized object models to achieve the outcomes desired. For instance, to derive V3 messages, the Domain Message Information Model (D-MIM) is used where diagrams (these are 'UML-like' and allow for more compact representation than a traditional UML diagram) help highlight the relationships between the various classes using conventions specified by the HL7 group. The D-MIMs themselves are further refined to create R-MIMs (Refined Message Information Model) which are useful for creating representations of message content needed for serialization, and this process in turn is aided by the representation of actual message using C-MET (Common Message Element Type) specification which helps to specify the necessary building blocks and data types to be used in these messages. The resulting message definition is known as a HMD (Hierarchical Message Descriptor). These HMDs do not specify the actual implementation characteristics of the message which are ultimately realized through the use of another specification called the ITS (Implementation Technology Specification). As you can see, the rabbit hole goes very deep, and is why the RIM specification has been seen as daunting and somewhat confusing for many. Please note that the HL7 group provides a large number of pre-defined D-MIM, R-MIM and C-METs for use, and so, always refer to these domain-specific catalogues before attempting to build your own.

Clinical Document Architecture (CDA)

In 2005, the HL7 group created a new standard called the Clinical Document Architecture (CDA) to facilitate easier exchange and interpretation of clinical data. The CDA was itself derived using the HL7 Reference Information Model (RIM) standard that I covered earlier and by using something called the HDF (HL7 Development Framework) which I will cover in a later section. A CDA document (specified in XML format) comprises of a mandatory part (for use by humans) as well some optional parts for use by machines, and can carry both structured data as well as unstructured data (such as images, videos, waveforms and other binary data). The CDA document is transport-agnostic (and is not limited to V3 alone). For instance, data in CDA format can be exchanged using other protocols such as V2, DICOM, HTTP, Email or using FTP. Although the release of the CDA specification was a huge step forward for the healthcare industry struggling to achieve a higher level of standardization for information exchange, more was seen as needed especially since the CDA was vague on the exact format that would allow for more uniformity in how these documents were encoded. Many in the industry as well as other healthcare bodies went on to derive more domain-specific templates to fill this void.

If there must be trouble, let it be in my day, that my child may have peace. ~ Thomas Paine

Consolidated Clinical Document Architecture (C-CDA)

To allow for standardized healthcare information reporting and data exchange, the HL7 group created another standard or specification based on the CDA specification known as the Consolidated CDA (C-CDA). C-CDA came some 10 years after the CDA standard, and provides implementation guidelines along with a library of number of CDA-based templates based on best practices for information capture and exchange of healthcare information seen in the field as well as from guidelines and recommendations that emerged from other healthcare groups such as IHE (Integrating the Healthcare Enterprise) and the HITSP (Health Information Technology Standards Panel). These C-CDA templates are used in the implementation of many clinical documents now seen in the industry including the Continuity of Care Document (CCD) (which I will cover in the next section) and the Referral Note which are essentially XML files that contain both structured and unstructured patient data, and can be used to support health information exchange with other EHR (Electronic Health Record) systems.

Continuity of Care Document (CCD)

In 2007, harmonization of two standards namely the Clinical Document Architecture (CDA) standard (from the HL7 group) and the Continuity of Care Record (CCR) standard from ASTM resulted in a new standard known as the Continuity of Care Document (CCD). This new standard enables the exchange of comprehensive health-related information about a patient (both current and historical) between care providers and other agencies. Prior to the emergence of this standard, transfer of patient healthcare data needed at point of care settings was extremely onerous and time consuming.

The CCD standard greatly simplifies the process of information transfer needed during the many stages of healthcare delivery. For instance, it can facilitate information transfer when a physician refers a patient to a hospital which then requires access to the relevant part of the patient’s medical record. And when the patient is finally discharged, the information captured in the hospital information system can be transported back into the doctor's system enabling a smoother and more streamlined approach to patient healthcare delivery.

A CCD document (known in the field by a few other names such as "Summary of Care Document", "Summarization of Episode Note") is encoded in XML format and allows the exchange of healthcare data much more easily between electronic medical record (EMR) and electronic health record (EHR) software systems. Information exchanged in a CCD document may include things such as demographics, allergies, procedures, medications, encounters, problem lists, diagnosis information, lab results, immunization data and health risk factors.

Structured Product Labeling (SPL)

The HL7 group developed a new document markup-based standard to help alleviate the problem of managing drug-labeling information needed in the healthcare industry where information was often out of date or wrongly interpreted leading to severe health consequences for patients as well as causing both reputational risks and financial liabilities for the care givers involved. The goal of the SPL standard is to improve the integrity of product information provided by drug producers for use by regulators, care providers and patients through the use of clearly defined data structures and terminologies enabled by the use of XML and related technologies during the creation, transmission and interpretation of drug-related information.

In this new way of managing information, a core document in XML format is created for the product by the drug producers. This document can then be transformed into other document formats such as HTML, Word, PDF, etc. for use on the web, on printed paper, and other mediums through the use of stylesheets which are essentially machine instructions on how to perform these transformations. The use of such an approach ensures a consistent and repeatable process leading to a higher level of accuracy when new or revised information about product-related labeling is submitted for use by regulators, health care practitioners, patients and the general public. The use of XML also allows for easier exchange and interpretation of data during machine-related workflows required in hospital systems, drug prescription systems and during any data analysis processes that need to be performed on drug-related data and treatment results by governments and other scientific bodies.

Clinical Context Object Workgroup (CCOW)

CCOW is an architectural standard which provides guidelines for easier integration and "context switching" between healthcare applications that may carry different aspects of related clinical data pertaining to a patient or any other healthcare entity that one is interested in at any given moment. Basically, it attempts to increase the benefit realization and safety of information processing for all technology and process investments that are deployed at any healthcare facility. These guidelines when implemented improve accessibility of patient data, speed up of time need for data retrieval (pre-loading data by anticipating what might be needed next) and provide stricter controls on who and what can access critical healthcare information.

Practical examples of the application/use of CCOW include the use of integrated single sign-on solutions, well designed graphical or voice-based interfaces with modern accessibility guidelines, stricter authentication/authorization/audit controls, HIPAA-compliance, use of warnings, alerts and other messages within the applications to ensure that the user is examining and/or updating the correct information and pre-filling any information wherever possible and reducing manual user entry and errors as a result, etc.

HL7 Development Framework (HDF)

Although you now have some understanding of the core components to the V3 standard, there is still a dizzying array of other information required to learn and understand before one can begin to apply it to create implementations using it. To help with this, the HL7 group provides something called the HL7 Development Framework (HDF) which provides frameworks, recommendations, actors, artifacts, tools, and guidelines to apply in nearly all stages of developing a message-related workflow development. This framework replaced the older Message Development Framework (MDF) which was designed for message development only in the 90s, and the newer HDF framework was developed to support more wide ranging use cases including use in the design and development of even new HL7 standards in the future.

The seven-stage process of the HDF includes a Project Initiation stage which involves activities to define the project, prepare a project plan, receive high level project approval, and the production of a project charter, a Requirements Documentation stage which involves definition of problem domain requirements, production of the domain model and harmonization with HL7 reference models, and the production of a requirements specification document, a Specification Modeling stage during which reference models are constrained into design models through a process of iterative refinement driven by requirements specifications and following specification design rules, conventions, and guidelines and a set of specification design models are produced, a Specification Documentation stage during which the specification design models are packaged into logical units, supplemented with explanatory text, and prepared for approval and a proposed specification is produced, a Specification Approval stage during which an approved specification is produced which is designed to address the type of approvals required for the complexity of the proposed specification, a Specification Publication stage during which the approved specification is prepared for prepared for publication and distribution and the specification is formally published, and finally a Specification Profiling stage during which specification models are further refined and specifications furthered constrained following the same set of design rules, conventions, and guidelines used in the development of the specification to produce a profile of the specification for use in a particular environment by a defined community of users..

As you can see, the design process can be fairly rigorous and lengthy depending on the complexity of the domain and the use cases involved. Unfortunately, that is all I can cover on this topic from a high level overview perspective. I will leave you to explore the official documentation for information on how to apply these steps to your situation. However, we will revisit this area when we will look at practical examples of usage in more code-oriented articles in the future.

Conclusion

That concludes this rather lengthy overview article on the V3 standard. There is a lot more to the standard than what I could cover here but I believe I have touched on the many fundamental philosophy and key parts of this large standard (like I said before, V3 is really a family of standards). This standard was an enormous undertaking by the HL7 group and produced many useful frameworks that will help solve many problems faced by the healthcare industry for years to come. Despite its usefulness and the problems it helps solve, anyone approaching this standard will find it to be very daunting. By explaining its origins, the standard's goals and objectives as well as its key constituent parts, I hope I at least somewhat succeeded in my goal which is to enable you to dive into the official documentation of this stnadard and make sense of it a bit more easily. In the future articles in my HL7 tutorial series, I will try to illustrate these areas in more detail using some code-based examples that you can apply during any practical application of these standards. See you then!

*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, .