HL7 International is an ANSI accredited standards development organization focused on electronic health information. However, you’ll often hear people referring to HL7 not as the organization itself, but as the standards it produces. Here, we’ll refer to HL7 as the outputs and standards produced by the Health Level Seven International organization, rather than the organization itself.
HL7 consists of a series of standards that specifies standards, methodologies, and guidelines for interoperability in healthcare systems. These various standards within the HL7 cover conceptual standards, messaging standards, document standards, and application standards.
- HL7 V3
- HL7 v2.x
- Arden Syntax
- Clinical Context Object Workgroup (CCOW)
- Clinical Document Architecture (CDA)
- Electronic Health Record (EHR) / Personal Health Record (PHR)
- Structured Product Labeling (SPL)
Reference Information Model
Before we get into each of these standards, it is important to understand HL7’s Reference Information Model (RIM). According to HL7, “ the RIM is a large, pictorial representation of the HL7 clinical data (domains) and identifies the life cycle that a message or groups of related messages will carry[1].” The pictorial representation can be seen in the HL7 Billboard below:
Yes, we know it is impossible to read this, but we just wanted to give you a better idea of the scale of the Reference Information Model. If we want a closer look, we can check out the message control domain below. Both of these images are available for download at the HL7 site at http://www.hl7.org/implement/standards/rim.cfm.
The RIM is the basis of the HL7 v3 and models how domains create their messages. With HL7 Version 3, a complete set of specifications including specifications for messages, terminologies, and data types can be used to integrate healthcare information in a large variety of settings. These specifications are “built around subject domains that provide storyboard descriptions, trigger events, interaction designs, domain object models derived from the RIM, hierarchical message descriptors (HMDs) and a prose description of each element” and expressed in eXtensible Markup Language (XML).
XML can be used to mark up specifications, such as one that sets generator properties in V3, as seen below:
HL7 V3
Version 3 of HL7 was published in 2005 and was created based on the HL7 Development Framework (HDF) and grounded by the Reference Information Model (RIM). It addresses some of the challenges associated with V2 by implementing stricter standards and developing an explicit data model along with more use cases and clearer definitions.
HL7 V2.x
Before, HL7 V3, there was HL7 V2.1, V2.2, V2.3, and so on and so forth. Before V2.x, vendors created their interfaces based on their own requirements and would understandably not share their proprietary information or code with those that wanted to build compatible applications. Luckily, HL7 was born out of a group who realized that this could become a problem and there had to be a better way to allow applications to communicate with one another.
HL7 V2 grew more comprehensive with each version and consequently a larger user base, but was still focused mostly on the clinical interface (V3 was created with informatics in mind). HL7 V2 continues to be adopted and refined, and with “looser” standards than HL7 V3, it is much less expensive to build interfaces with.
Choosing Between HL7 V3 and V2.x
V3 and V2.x are not compatible with each other. So then, which does your organization adopt? Here are some benefits and drawbacks of each you may want to consider:
V2
- Benefits: “looser” guidelines, can be build in an ad-hoc fashion, backwards compatible between other V2 versions
- Drawbacks: loose guidelines can lead to discrepancies, lacking consistency in application data models, vendors may not have updated to latest version of V2.x yet, not compatible with V3
V3
- Benefits: Standards are stricter and more consistent, guidelines are clear and concise with less “wiggle room”
- Drawbacks: Not compatible with V2.x, cost, training and resources needed for adoption, will still need to concurrently maintain any V2 systems
Both HL7 V2.x and V3 are messaging standards.
Arden Syntax
Arden syntax is “standard for representing and sharing clinical knowledge in Medical Logic Modules[2]” that is typically used in Clinical Decision Support Systems (CDSS) to generate alerts, messages, prompts and other executable formats. Arden syntax follows Medical Logic Module (MLM) rules that include the logic for a single medical decision.
Clinical Context Object Workgroup (CCOW)
CCOW is a protocol for syncing applications in real-time to maintain context such as information about a patient or encounter in the user interface[3]. Rather than signing on to multiple programs on the same computer, CCOW allows the user to sign on just once and sync the context of the current situation (such as which patient is pulled up) to each application.
Simple in theory but difficult in reality, CCOW requires an architecture that includes components that deal with the active applications, map agents to identify users, patients, and others, and manages the context between applications.
Clinical Document Architecture (CDA)
CDA standardizes the structure and semantics of clinical documents for easy exchange between patients and providers[4]. According to CDA standards, clinical documents meet the following six characteristics:
- Persistence
- Stewardship
- Potential for Authentication
- Context
- Wholeness
- Human Readability
What kinds of documents meet these characteristics? Referrals, reports, discharge summaries, admission and physical, are some typical clinical documents.
Electronic Health Record – System (EHR-S) Functional Model (FM)
EHR-S FM “outlines important features and functions that should be contained in an EHR system[5]”. EHR-S promotes a common understanding between vendors, users, developers, and others so that they may better plan for and evaluate EHR functions.
Structured Product Labeling (SPL)
SPL is “ document markup standard that specifies the structure and semantics of the content of authorized published information that accompanies any medicine licensed by a medicines licensing authority[6].” The content of the label is defined in an XML format and includes elements such as product/generic name, ingredients, ingredient strengths, dosage form, administration, appearance, DEA schedule, and packaging quantity and type.
[1] http://www.hl7.org/implement/standards/rim.cfm
[2] http://www.hl7.org/documentcenter/public/wg/Arden/Arden%20Syntax%20Mission%20and%20Charter-2013-09-24.doc
[3] http://www.hl7.org/documentcenter/public/wg/sigvi/CCOW_Mission_and_Charter_Statement2010%20DRS%20-%20SSD-SD%20Approved.doc
[4] http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
[5] http://www.hl7.org/implement/standards/product_brief.cfm?product_id=18
[6] http://www.hl7.org/implement/standards/product_brief.cfm?product_id=96