Why HL7 v2 was required?

Now we know how an HL7 v2 message looks like. We know how to read its specification. We have even designed a message on our own. But we still don’t know why a healthcare messaging standard was needed in the first place.

Healthcare systems were becoming digital

During the 1970s and 80s, healthcare organizations started adopting computer systems to manage different parts of their operations.

A hospital might have one system for the laboratory, another for radiology, another for patient registration, and separate systems for pharmacy and billing. This created one major challenge. A laboratory system might know that a patient’s blood test was complete, but the rest of the hospital still needed a way to receive that result.

This became challenging because these systems were developed independently by different vendors and often represented and exchanged information in different ways.

The integration problem

Imagine a hospital with a laboratory system and an EHR. The laboratory system needs to send test results to the EHR. If the two systems don’t have a common format for exchanging information, someone has to build an interface specifically for those two systems.

Now suppose the laboratory also needs to send information to the billing system. That’s another interface.

If the radiology system needs to communicate with the EHR, that’s another interface again.

The problem isn’t just the number of systems. It is the number of connections between them.

Point-to-point integrations

If every system needs to communicate directly with every other system, the number of connections grows quickly.

For n systems, the number of possible two-way connections is n × (n - 1) / 2

So for just 10 unique systems, it gives us 45. That means up to 45 separate connections could be required if every system communicated directly with every other system.

And each connection could have its own Data mappings, Message formats, Transformation rules, Testing requirements, Monitoring and Maintenance. Adding another system could mean adding several more interfaces.

This is commonly referred to as a point-to-point integration model.

As hospitals added more applications, this approach became increasingly difficult and expensive to maintain.

The need for a common language

Healthcare systems needed a common way to exchange information. Instead of asking every application to understand the internal data format of every other application, systems could agree on a standard way of representing and exchanging healthcare information. This gave birth to HL7 v2. It provided a common messaging format that healthcare applications could use to communicate.

The idea behind it was rather than building a different language for every connection, systems can use a common language for exchanging healthcare information. The systems don’t need to have the same database structure or internal implementation. They only need to understand the structure and meaning of the messages they exchange.

Event-driven communication

HL7 v2 supports event-driven communication, where a system sends a message when there’s an update instead of another system repeatedly checking for updates. For example, when a laboratory result becomes available, the laboratory system can immediately send the result to the EHR.

The same approach can be used for events such as patient admission, discharge, new orders, and appointment updates.

This made HL7 v2 more practical for healthcare integrations. It also addressed a key limitation of point-to-point communication, where systems had to maintain direct connections and custom logic for each integration.

As the number of systems grew, integration engines became an important part of managing these HL7 v2 messages.

Integration engines

As healthcare environments became more complex, another approach became common and that is the use of integration engines.

Instead of connecting every application directly to every other application, systems can connect to a central integration engine.

The integration engine can handle tasks such as routing messages to the appropriate system, transforming data between formats, filtering messages, monitoring message flow, and handling errors.

Each application connects to the central engine rather than creating a separate connection to every other application.

With 10 systems, a point-to-point model could require up to 45 direct connections.

With a hub-and-spoke model, each system can instead connect to the central integration engine. The exact number of connections depends on the architecture, but the key idea is that the systems no longer need to maintain a direct connection with every other system.

HL7 v2 messages became one of the common formats used to move information through these integration environments.

Why HL7 v2 is still important

Healthcare technology has changed significantly since it was first developed, and newer standards such as HL7 FHIR have been introduced to address modern interoperability use cases. Yet HL7 v2 remains deeply embedded in healthcare IT.

Hospitals and healthcare organizations continue to use HL7 v2 for workflows such as patient admissions and discharges, laboratory orders and results, clinical orders, and billing and financial workflows.

A large number of existing healthcare systems already rely on HL7 v2, which means that understanding it is still essential for anyone working with healthcare interoperability. Even as newer standards are adopted, HL7 v2 continues to play an important role in connecting healthcare systems.

In the next module, we’ll go deeper into HL7 v2 fundamentals to learn about data types, cardinality, profiles, and the different types of segments used in HL7 v2 messages.