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

I also want to mention the Services Aware Interoperability Framework (SAIF) here since it is an essential framework designed to ensure effective interoperability and consistent implementation of healthcare standards. SAIF provides a comprehensive methodology for achieving semantic, syntactic, and process interoperability within healthcare IT systems. This framework is instrumental in guiding the development, deployment, and integration of HL7 standards across different healthcare applications and platforms. By focusing on a service-oriented architecture, SAIF facilitates a more structured approach to designing and implementing healthcare interfaces, ensuring that they are not only technically compatible but also semantically coherent. This ensures that data exchanged across various healthcare systems is interpretable and usable, leading to enhanced efficiency, reduced errors, and improved patient care. SAIF's role in supporting the HL7 standards is pivotal in addressing the complexities of healthcare data exchange and in promoting a more integrated, patient-centric approach to healthcare IT.

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