[医疗信息化][DICOM教程]HL7 V3 Standard-概述-HL7 V3 Standard

[医疗信息化][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, .