Beyond Medical Informatics

Hey, I almost missed this one! I recently found out that HL7 version 2.7 came out in May 2011. As an HL7 advocate and implementer in the Philippines, I should have kept tabs on this.

Version 2.7 represents HL7′s latest development efforts to the line of Version 2 Standards that date back to 1989. Due to its widespread use, Version 2 will, no doubt, continue to play an integral part in healthcare messaging, even with the HL7 Version 3 Normative Edition. HL7 is committed to supporting and extending Version 2 in parallel with Version 3, providing continuity for current installations.

The changes look interesting. Read more about it at the HL7 version 2.x site.

(Now, try saying HL7 version 2.7 seven times…)

—

I welcome HL7-related questions for HL7 implementations and integration projects here in the Philippines. Just send me an email!

I gave a talk at the recent Hospital Build Asia 2011 conference in Singapore. I also stayed for the other topics. Two topics I found interesting were clinical data repositories and integration/interoperability standards.

Here are some of the lessons I learned. These are NOT verbatim content. They are from my memory and personal interpretations of the presentations.

Clinical Data Repositories (CDR)

• It had different names during the conference, e.g. Vendor Neutral Architecture, Common Data Repository, Carestream product, but they all shared the same concept.
• They implement an information exchange (IX) software to accept all incoming data.
• The information exchange (IX) software can be a middleware, integration platform, custom software or integration engine. Most common software used here in Singapore is Cloverleaf.
• The IX is setup for both international standards and customized interoperability protocols.
• CDR implementations can either handle clinical data and reports only (text) while others can implement redundant DICOM repositories.

Integration and Interoperability Standards

• In Singapore, even for the National EHR implementation, there are no HL7 v3 implementations.
• Most commonly implemented standards include HL7 v2.x and DICOM.
• But there are a lot of customized XML schemas implemented for documents not available in HL7 v2.x.
• They did not focus on "ideal standards". They avoided theoretical concepts in discussions of standards because it would be almost impossible to force compliance. Plus, they don’t have time to wait for everyone to comply to their "ideal standards" recommendation.
• Instead, they did a survey among hospitals, vendors and other stakeholders for interoperability standards available and/or ready for implementation.
• They also avoided theoretical discussions of implementations. Instead, they’d recommend putting viable ideas through proof-of-concept (POC) activities to provide more tangible better results.
• Decisions are made based on currently available data and results of POC activities.

That’s it. There were other lessons learned about other topics but I focused on these two because they were most useful to my current project plans.

My team and I are now working on HL7 capabilities for The Medical City (TMC). Let me just share the tools I use for HL7 integration work. I’m sure other people will find the list useful.

Most of my work involves HL7 v2.x.

Integration Engine

• Mirth Connect – I primarily use Mirth Connect for integration testing and implementations.

Basic Editing Tools

• Notepad++ – For direct editing of HL7 text files.

XML Editing Tools

XML is an important part of using Mirth Connect. Both editors are free.

• XML Marker
• Exchanger XML Editor

HL7 Editors

• HL7 Tool – A rather rudimentary HL7 tool for editing HL7 text but it works!
• HL7 Inspector – Allows viewing of HL7 v2.x messages in tree structure.
• QuickViewHL7 – Another HL7 v2.x tree viewer with added features.

It also goes without saying that the team should have the right reference materials (HL7 documentation and Application Connection Sheets) during implementation.

I’d be happy to hear about the tools you use.

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, what it does, and what it can do. 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-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 HIT 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, they become inflexible when working with other systems.

***

I had to deal with plenty of misconceptions—and even misgivings—about HL7 in my projects. I’ll share some more in future posts. And maybe include some lessons learned.

On another note, a lot of successful local HIT integration projects use customized protocols. Why? Because HL7 is not that well understood. So there are lots of opportunities for HIT standards education and advocacy. And that’s a challenge I’m ready to take head on.

===

What misconceptions (and misgivings) about HL7 have you encountered? How did you deal with it? What are the challenges in educating people about HIT standards?