HL7 standards are used worldwide for health system integration. There are 5 fundamental standards: HL7 V2, HL7 V3, FHIR, CDA, and CCOW. Keep reading to learn about them, discover their main features, and access key resources to master them.
What is HL7®? #
HL7 is the acronym for the Health Level Seven International organization. It is a non-profit organization dedicated to the creation of health informatics standards.
HL7 was founded in 1987 and has over 1,600 members from 50 countries. Among the members, there are more than 500 organizations from all areas of health. There are different national branches of HL7, for example, the Spanish branch or the Argentine branch.
You may wonder: did HL6 or HL5 exist?
The answer is “no”. Health Level Seven refers to layer 7 of the OSI model, the application level, for the health sector. According to Wikipedia, layer 7 “offers applications the possibility to access the services of the other layers and defines the protocols that applications use to exchange data“. Therefore, Health Level Seven means “Application Level in Health” and refers to the protocols and standards for exchanging information between health applications.
In summary, HL7 is responsible for defining a framework and standards for the exchange, integration, and access to electronic health information.
What are HL7 standards? #
HL7 standards or HL7 protocols indicate how information is organized and communicated between two parties. These standards define the language, structure, and data types required for smooth integration between health systems.
Thousands of hospitals worldwide use these standards daily to exchange information between their systems. When we talk about HL7 standards, we talk about health interoperability.
In addition to HL7 standards, there are many others that often appear alongside them. You can consult our guide to health interoperability standards to learn more.
What are the most important HL7 standards? #
The most important HL7 standards are HL7 V2, HL7 V3, FHIR, and CDA. These are known as primary standards (HL7 primary standards) and are the most used for system integration and interoperability.
HL7 CCOW (Context Management Specification) was part of the HL7 primary standards. But, this specification has been retired, and is being replaced by HL7 FHIRCast.
There is a lot of information about the primary standards on the HL7 website.
The HL7 V2 standard #
The HL7 V2 standard (or HL7 V2 protocol) is a messaging standard that allows the exchange of information between different systems. It is undoubtedly the most widespread and used of the interoperability standards.
It is used in 95% of US healthcare organizations and present in more than 35 countries.
Its first version was published in October 1987, since then multiple updates have been published. The versions are usually named in the form V2.X. In 2019 the HL7 V2.9 version was published which is the most recent to the date of this article.
A very commonly used versions of HL7 version 2 is V2.5, although versions V2.3, V2.6, and V2.7 are also very common.
HL7 V2 messaging #
There are many types of HL7 V2 messages, but the most used are patient management (ADT), orders (ORM), and results (ORU). The messages are strings of text divided into segments. The most important segment is the header or MSH segment, which appears first and contains, among other data, the type of message it is.
HL7 V2 messages have a very characteristic appearance, they are several long lines of text similar to the following:
MSH|^~\&|HOSPITAL|CMQUI|EXTSYS|CMQUI|20180906175029||ADT^A31^ADT_A05|79854440|P|2.5|||AL|NE||8859/1
EVN|A31|20180906162458|||HL7_cib^^^^^^^^^^^^^^^ PID|1|127912359^^^CAMD^JHN^^^^MD&&ISO3166-2|1235340^^^^PI^|NCHR123^^^MS^HC^^^^ESP&&ISO3166|ANCA^JOHN|SMITH|19930803000000|M|||STREET&MAIN&1^2 D 2ºD^79^28^28018^724^^16||912233595^PRN^PH^^^^^^^^^12333595~12328569^ORN^PH^^^^^^^^^634728569~^PRN^Internet^|123728569^PRS^CP|||||28/13668662-41|12399976Y|||UNKNOWN|||ESP^SPAIN||||N
PD1|||^^^^^^FI^^^16012810~CENTRAL HOSPITAL^^^^^^XX^^^281270|^^^^^^^^^^^^^^^1231280107M PV1|1|NIn these messages, each line corresponds to a segment that is identified by its first three letters. Following the segment identification, come the fields of that segment. These fields, in turn, are made up of components and subcomponents.
Fields, components, and subcomponents are separated by special separator characters. The recommended characters are:
- “
|“: field separator (bar or pipe). - “
^“: component separator (hat). - “
&“: subcomponent separator. - “
~“: separator in field iterations. - “
\“: escape character.
From version 2.3 of the HL7 standard, messages can also be encoded in XML format. This encoding is called v2.xml.
Resources on HL7 V2 at Health Level Seven International:
- Standard summary.
- XML v2.xml encoding guide for HL7 Version 2.5 messaging and earlier.
HL7 V2 vs HL7 V3 #
The HL7 V2 standard is the most used but it has some drawbacks. Because HL7 V2 has great flexibility and is very adaptable, the differences between different implementations require deep analysis and a lot of negotiation to achieve integration. On the other hand, these differences and flexibility also make it complicated to test and carry out conformity tests.
This situation prompted the development of the HL7 V3 standard. This standard is much more ambitious and broad than the previous version. The approach of this new standard is much more formal and aims to solve some of the drawbacks of its previous version.
The HL7 V3 Standard #
The HL7 V3 standard aims to cover all aspects of implementation: messaging, data types, and terminologies. These features make it a very ambitious initiative within the interoperability standards. This version of the standard has a semantic, model-based approach that is much stricter and normative than in version 2. The first version of HL7 version 3 was launched in 2003 and has been updated several times since then. Each new version is identified by the year it was released, e.g., “HL7 V3 2017”.
The messaging and documents of version 3 are defined in XML syntax, unlike the pipe format used in HL7 V2. It also insists a lot on the use of controlled vocabularies (such as ICD-11, LOINC, and SNOMED CT), in addition to its own encodings.
The complexity and extension of HL7 version 3 make it not easy to implement or migrate from version 2. In addition, it has to compete with version 2 itself, which is satisfactorily in production almost everywhere. Perhaps for these reasons, version 3 of the standard is not as widespread as the previous version, however, it is used in several public health services such as the United Kingdom, the Netherlands, and Canada.
Resources on HL7 V3 on the Health Level Seven International website:
HL7 V3 RIM: Reference Information Model #
One of the main features of the HL7 V3 standard is that it is based on the RIM (Reference Information Model), a broad model of reference objects for clinical data.
The RIM is a model of all the information of health services, which identifies the life cycle of messaging within clinical activity. This model is the reference that is used for the development of the entire standard.
Information about RIM on Health Level Seven International:
The HL7 CDA® Standard #
The HL7 CDA® standard is a clinical document standard. This specification aims to facilitate the exchange of information in the form of documents between health providers and patients. CDA can contain any type of clinical information, for example: discharge reports, radiology reports, pathology reports, or the patient’s examination and anamnesis. CDA is based on the RIM data model and the HL7 V3 working methodology
CDA is the abbreviation for Clinical Document Architecture. The first version (CDA Release 1) was launched in 2000, the second version (CDA Release 2 or CDAR2) was launched in 2005 and adopted as ISO/HL7 27932:2009 standard.
Features of a CDA Document #
According to the CDA standard, the six characteristics that a clinical document must have are:
- Persistence: the document remains unchanged over time, regardless of external changes.
- Custody: the document must be managed by an organization or entity.
- Potential for authentication: the document must have legal validity.
- Context: the document defines a context of participants (such as the patient or doctor), act, health service provider, etc.
- Completeness: the document must be understood as a unit of content.
- Human readability: although it can be processed by computer systems, the document must retain the ability to be read by people.
Structure of a CDA Document #
The objective of the HL7 CDA standard is to define the structural and semantic part of the document, but it does not deal with the content of the documents. The creation, storage and exchange of the documents are beyond the scope of the standard.
A CDA document is specified in XML format and consists of two parts: the header and the body.
The header contains meta-information about the document:
- Header attributes: identification, date, title, language, etc.
- Participants: the author, the patient, the provider, etc.
- Related acts: other documents, authorizations, etc.
The body contains the information of the document. This information must always contain a textual part that ensures human readability. The standard defines three levels of structure for the body:
- Level 1: unstructured content. For example, the content can be an embedded PDF document.
- Level 2: structured and coded content in sections.
- Level 3: fully structured and coded content.
The encoding of the content of the documents is done through coding standards, such as SNOMED-CT, ICD-11 , and LOINC. The higher the level of coding of the document content, the greater its degree of interoperability with other systems.
Resources on CDA Release 2 on the Health Level Seven International website:
The HL7 FHIR® Standard #
HL7 FHIR® is an interoperability standard that combines the best of HL7 V2, HL7 V3, and CDA and focuses on facilitating its implementation. In addition, it uses the most common web standards, such as XML, JSON, and HTTP.
FHIR was born in 2011 and evolved rapidly until, in 2019, its first version with normative content FHIR Release 4 (version 4.0.1) was published. As of 2023 FHIR 5 is the most recent version.
You can follow the evolution of the different published versions in the FHIR version history.
FHIR is the abbreviation for Fast Healthcare Interoperability Resources. The resources are the key pieces of FHIR.
What are FHIR resources? #
The Resources are the building blocks of all information exchanges in FHIR. Each resource represents a concept of healthcare reality, such as patients, appointments, organizations, or test results.
Resources can be represented in both XML and JSON, and all have certain common characteristics:
- A URL that identifies the resource.
- Common metadata.
- A human-readable summary.
- An extensibility framework that allows for differences in healthcare.
We see a representation of a patient resource where the characteristic parts have been highlighted:
Using these resources, clinical and administrative procedures can be modeled quickly and with less complexity than with other alternatives.
It is possible to consult the complete list of resources, where more than 150 resources are defined. In addition, each resource includes documentation and examples.
How are FHIR resources managed and exchanged? #
From its conception, FHIR is designed for interoperability and defines a REST API for the exchange, manipulation, and search of resources. Through this API, it is possible to create, modify, delete, and search for resources.
For example, to create a patient, we would have to create the resource and send it via a POST request to the corresponding REST endpoint:
POST https://path-server/PatientTo request a patient, we would use a GET request:
GET POST https://path-server/Patient/{id}There is a lot of documentation on the FHIR website:
- Documentation on the REST API.
- Developer guide, which is a good place to start.
The organization of FHIR: levels and modules #
The FHIR standard is organized into modules that represent the different functional areas of the specification. The modules, in turn, are grouped into levels, where each level corresponds to a higher level of abstraction.
The levels are, from the most fundamental to the most abstract:
- Level 1: Basic framework on which the specification is based.
- Level 2: Support for implementation and relation with external specifications.
- Level 3: Relation with real-world concepts in the healthcare system.
- Level 4: Registration and data exchange for the healthcare process.
- Level 5: Provision of the ability to reason about the healthcare process.
In the following image extracted from the FHIR website, you can see the different levels and the modules that compose them:
Resources on FHIR at Health Level Seven International:
Conclusion #
Although they are not the only ones, in this article we have seen the main HL7 standards. Among all, HL7 V2 messaging stands out, which we can find in almost any health information system. In addition, it is advisable to closely follow the FHIR standard, which promises to be the great heir in the future of health interoperability.
HL7, FHIR, CDA, and their logos are registered trademarks of Health Level Seven International.
