I’ve been working with HL7 for the past 3 years. And although I am not an expert (yet), I know enough to have successfully integrated several systems, including legacy ones, using HL7 version 2.x.
Project sponsors and stakeholders often have many misconceptions about HL7 — what it is and what HL7 does. Below are some of the common misconceptions I’ve encountered.
Misconception 1: HL7 is a software
“How do we install HL7? Is the software free? Where can we download it?”
HL7 is NOT a software. It is a messaging standard. Something like a common language among systems so they can understand each other.
For the non-Information Technology (IT) side of the healthcare business, IT is about software and hardware. If HL7 is not hardware, then it must be software. Otherwise, why all the fuss about it?
Correcting this misconception involves impromptu lectures about system communication and messaging protocols. About integration and interfaces. About stand-alone systems sharing information.
Still, HL7 integration commonly involves software. Some of these software can be interface engines, messaging platforms and file managers. We use Mirth Connect as our HL7 interface engine.
Misconception 2: Integration is easy with HL7
“I thought you were using HL7. Why are you still having integration problems?”
Healthcare IT integration projects will always be challenging. HL7 makes it easier but NOT easy.
Choosing HL7 is like going to a grueling negotiations meeting with an agreement to talk in English. It’s a good starting point, but it doesn’t guarantee a win.
Decisions, processes and activities in health IT integration projects can include database preparations, staging tables, data dictionaries, field-to-field mapping and data migration. The integration may use HL7, but critical errors in these other areas can kill a project.
Misconception 3: HL7 compliance is a sign of quality software
“If it’s HL7-compliant, it must be good!”
Project clients, vendors and even Healthcare IT professionals can have this misconception. HL7 addresses the need for a common protocol between systems. It does NOT address the features, functions and usability of the software itself.
HL7 compliance doesn’t even mean seamless integration. It just means the software has methods of handling HL7 messages — hopefully both incoming and outgoing. Sometimes, those HL7-compliant systems can be the most challenging to work with because their compliance is based on strict usage and formatting standards of specific segments and fields. They become too compliant to their own HL7 implementation, that they become inflexible when working with other systems.
What misconceptions (and misgivings) about HL7 have you encountered? How did you deal with it? What are the challenges in educating people about health IT standards? We love you hear your thoughts. Send us your feedback by leaving a comment below.
Written by Michael “Doc Mike” Muin MD