[医疗信息化][DICOM教程]HL7 V3 Standard-概述-HL7 V3 Standard - A High Level Overview
HL7 V3 Standard-概述
V3标准是HL7小组为解决V2标准中存在的许多挑战而进行的雄心勃勃的尝试的结果（有关快速概述，请参阅我之前关于V2标准的文章）。原始的V2标准（注意：没有正式发布“ V1标准” ，仅是概念证明*）解决了当时存在的一个主要问题，即供应商的互操作性，因为专有协议用于消息交换。这使得实施成本高昂，容易出错并且难以扩展和维护。在跨部门，医院间和多学科的医疗机构中尤其如此，其中经常部署来自不同供应商的各种各样的专用系统，并且仍然需要在它们之间进行数据通信。
V2标准为医疗保健行业赢得了两项重大胜利。它建议使用一种格式来对消息进行统一编码，以适应在现场看到的各种医疗情况，例如患者入院，患者出院，命令，观察和医疗费用。该标准还为称为MLLP（最小下层协议）的传输协议制定了规范。设计用于在当时流行的TCP / IP协议之上。由于这两项改进，V2标准发布后，在世界范围内迅速采用。它兑现了减少在医院和其他临床环境中所见到的维护大量数据接口的成本和难度的承诺。但是，即使采用它，裂缝也开始出现。
凭借其灵活的管道分隔消息结构，有时甚至可以使用基本文件编码器和解析器来实现/处理V2接口（请参阅我使用Java或.NET编写的HL7编程文章）以供参考）。这使得V2标准和消息接口开发非常容易进行，即使对于新手也是如此。但是，从根本上讲，V2标准有几个缺点。它被设计为主要用于查询/检索范式（在关系数据库中可见），并且在如何建模消息以及这些消息可以支持的数据类型方面存在限制。随着采用V2标准的域的数量不断增长，对更多特定于域的复杂且可重用的消息结构的需求也越来越多，这些消息结构可以在面向动态事件的消息工作流中使用（V2无法解决） ）。另一个缺点是由于V2消息中允许大量的可选性。这使得对信息交换的一致（“语义”）解释变得非常困难。也，越来越多地认为 SNOMED CT和 LOINC）是必要的。所有这些挑战以及医疗保健行业的其他医疗保健和技术创新（以及更多法规）推动了V2标准方法通过了最初设计的处理方式。
通过使用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，因此，在尝试构建自己的目录之前，请始终参考这些特定于域的目录。
尽管您现在已经对V3标准的核心组件有了一定的了解，但是仍然需要大量令人眼花other乱的其他信息来学习和理解，然后才能开始应用它来创建使用它的实现。 为了解决这个问题，HL7小组提供了一个称为HL7开发框架（HDF）的东西，该框架提供了框架，建议，参与者，工件，工具和指南，可将其应用于与消息相关的工作流程开发的几乎所有阶段。 该框架取代了仅在90年代才设计用于消息开发的旧消息开发框架（MDF），并且开发了新的HDF框架以支持更广泛的用例，包括在设计和开发新的HL7标准中使用。
HL7 V3 Standard - A High Level Overview
- The Need for V3 Standard
- Goals & Objectives
- On V3 Release, Reception and Key Constituent Parts
- Reference Information Model (RIM)
- Clinical Document Architecture (CDA)
- Consolidated Clinical Document Architecture (C-CDA)
- Continuity of Care Document (CCD)
- Structured Product Labeling (SPL)
- Clinical Context Object Workgroup (CCOW)
- HL7 Development Framework (HDF)
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.
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:
- Clinical Document Architecture (CDA)
- Consolidated Clinical Document Architecture (C-CDA)
- Continuity of Care Document (CCD)
- Structured Product Labeling (SPL)
- 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.
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, .