Author: Kevin Roy

HL7 Interfacing Advice from the Indiana Health Information Exchange

The largest health information exchange (HIE) in the US is located in Indiana. It connects 80 hospitals, and serves 10 million patients as well as 19,000 physicians. IHIE members participated in a recent meeting of the Central Indiana Beacon Community and posted their slide decks here. The presentation that resonated for us was Mapping Interfaces by Dr. Mike Barnes, Dan Vreeman, and Amanda Smiley (PDF).

Their killer quote: “Interface programmers are the only barrier between a successful interface implementation and your organization appearing on the front page of your local paper.”

That’s part of the reason HL7 interfaces take so long to write. The authors also say that it’s not just about the writing, the coding, or the configuration. It’s about understanding the interface: scoping, gap analysis, and sometimes, getting the buy-in to change source systems. Their deck included a useful 9-step overview of the HL7 interface development process. Here it is, along with a few comments from us:

1. You have to get examples (+/- specs).
Get as many examples as you can. Cover as many HL7 messaging and workflow scenarios as needed. And get those interface specs if you can. But keep in mind they might be out-of-date.

2. You have to study them (in detail).
Study everything in detail. Make sure you have a system to track your findings. Have a repeatable gap analysis process to cover the examples and logs you might get. Just because one system is using PID segments as a primary patient identifier, doesn’t mean that another system won’t be using PV1 segments. For a deeper dive, we’ve got a white paper on HL7 integration and gap analysis.

3. You discover problems, or have questions.
Have a process for dealing with them. It’s not always easy because interfaces, HL7 messages, and system workflows are so disparate. What you learn with one provider’s EMR won’t port over to another provider’s system.

4. Request fixes or answers to questions.
It helps to document your problems and then those fixes.

5. Time passes (days to weeks).
You bet it does. That’s why it helps to document it all.

6. You forgot the details of the interface (Rpt #2).
There are those pesky details again. Documentation (and the ability to share) can really help.

7. Fix problem or resolve questions.
This is on-going. When you think you’re done with an interface after the go-live, it’ll come back to haunt you once one of the sending systems is tweaked. You’ll need troubleshooting tools and processes to account for changes.

8. Repeat steps 3-7 until interface is ready to write.

9. Write interface.
By now, writing the interface is a piece of cake. Especially if you’ve got solid integration technology that makes the actual writing easy.

The key takeaway… You can have the best interfacing engine in the world, the HIE infrastructure with the most bells and whistles, and the coolest SOA and ESBs. But a good interface starts with an analyst’s ability to dig into the details and document her findings.

Read the rest of the Mapping Interfaces PDF deck on the Indiana Health Information Exchange site.

Jean-Luc Morin, VP R&D at Caristix, has a guest post on Shahid Shah’s blog, Healthcare IT Guy. Shahid’s top-ranked blog covers healthcare IT, EMR, EHR, PHR, medical content, and document management.

Jean-Luc’s article covers 6 questions hospital CIOs and IT directors should be asking vendors about interface documentation.

Here’s an excerpt:

At first glance, documentation doesn’t seem like a CIO-level concern. In a typical implementation cycle, the team gets a few specs from a vendor. Someone signs off on an interface configuration document. Then you implement and go-live. The role of documentation in the larger scheme of things? Seems like a project management checkbox at best.

But it isn’t.

Your vendor’s interface documentation practices can have a major impact on the speed and success of implementation and on the maintainability of your new system after go-live.

Go read the rest here…

A few weeks ago, I was working on an HL7 v3 project with an outside partner and the discussion turned to market adoption. We came to the conclusion that it’s not exactly taking off — at least, not as quickly as you might expect. Apart from meaningful-use initiatives around CDA in the US and the big push by Canada Health Infoway, I don’t really see much traction in North America. I’m going to come right out and say this: from a vendor perspective, the incentives to embrace the new standard are just not there in 2011.

My thoughts were kicked off by a post from HL7 guru René Spronk. René wrote that the focus to date has been on modeling and that implementation-related material is missing. René also listed 5 improvements that would help implementers adopt HL7 v3. He raises some great points. Even if the post is almost a year old, the list still holds… In a large volunteer organization like HL7, there are no quick changes.

So what exactly is limiting HL7 v3 adoption? To build on René’s list, here are a few more points to consider.

1. Cultural Hurdle: HL7 V.3 Implementation Needs a Change in Mindset

HL7 v3 is a completely different standard than HL7 v2.x. Because HL7 v3 isn’t backward-compatible, when you migrate, you need to change the way you look at interfaces. In the HL7 v2.x world, many analysts treat HL7 messages as strings of data elements. They see their key task as follows: look for the data, find it in the “right string”, and map the string to the right data element in the new system under deployment. What about the semantic gaps, you may ask? The answer in this world: we’ll worry about them during system validation and patch in a workaround. What’s more, in this world, message schemas are manually specified in Microsoft Word documents much of the time.

So from a provider perspective, HL7 v3 is going to demand a change in mindset. The message schema is programmatically specified and modified (if needed). If you’re a big Word fan, you’ll probably have a hard time finding your schema in a familiar format. Most likely, you’ll be encountering a new set of tools for data element mapping. This is a big shift from business-as-usual in the HL7 v2.x world.

2. Steep HL7 V3 Learning Curve

Interface analysts in the HL7 v2.x world are a mixed bunch. Some come from the clinical side of the business, others from the development side. A surprising number are non-technical (which is terrific — we need a range of skill sets in our industry). This works fine for now, since the HL7 v2.x format is quite straightforward. At a minimum, as long as you’re able to count pipes and basically grasp the data being exchanged, you’re good to go. You can start quickly with minimal training. With some help from basic open-source or home-grown tools, you don’t really need deep technical knowledge.

But migrate to HL7 v3 and the game changes. Again, you need a new mindset. The technical skills are different and the way you build or configure interfaces is different as well. Just take a look at this HL7 v3 primer. It’s perfect if you want to understand where the standard comes from. But it’s far too complex if all you need is to learn how to configure an interface. So there’s a learning curve, and it’s not just for analysts. Implementers need to create new material to support analyst learning. And that won’t happen overnight, especially if the market is slow to materialize.

3. No Clear Benefits for Most Healthcare Systems

Healthcare systems have been using v2.x interfaces for decades. Sure, the standard and related processes are issue-laden, and the typical interface deployment process is bumpy at best. HL7 v2.x is far from perfect. It’s probably more expensive and intense to run an HL7 v2.x environment than a future-state HL7 v3.

But most organizations have learned to live with these faults. For most organizations, HL7 v2.x works. It feels safe. It’s become standard business practice.

So HL7 v3 comes along. It’s unknown. And the unknown feels risky, right? Very few healthcare systems are going to jump in with both feet as long as the ROI remains elusive. From what I’m seeing in the field, organizations are not rushing to spend money to fix what amounts to a non-broken process.

The Caveat: CDA and Document Exchange

Despite what I said about the unknown, there is a pretty encouraging caveat to all this. And that is the push for CDA templates and the need for document/data exchange. This is new, and driven by meaningful use in the US, so organizations have to act. HL7 v3 seems to be answer here, and I predict greater adoption related to data exchange.

4. HL7 V2.x Compatible Interfaces Still Needed

Obviously, supporting HL7 v3 doesn’t mean you’re going to be done with HL7 v2.x. HL7 v2.x interfaces are going to stick around, well into any foreseeable HL7 v3 future. Some will start by integrating v3 components, but vendor and hospital infrastructures will remain HL7 v2.x centric over the course of migration. Even if the upgrade benefits were clear, the process could take over 20 years. Meanwhile, related HIS technology will keep rolling along and evolving, and vendors would get stuck with even more to support.

5. Missing Tools

As we speak, the HL7 v3 toolset is thin on the ground, compared to the rich pickings in the v2.x world. We need a more robust toolset in order to get to the productivity levels and skill sets that HIT vendors and healthcare providers expect. Tools will emerge as adoption grows. But for now, the missing toolset is yet another risk for early adopters to manage.

What’s Next for HL7 V3?

Now that I’ve said my peace, don’t get me wrong.

HL7 v3 is an elegant step forward in healthcare system interoperability. But the design quality of the standard isn’t a compelling migration driver. We’ve been using HL7 v2.x for so long that we’re used to its weaknesses. For us to shift, we’re going to need stronger, clearer market drivers. Change — even good change — is risky within organizations. We shouldn’t underestimate our own reactions to risk.

Comments

Readers, what are your thoughts? Does HL7 v3 adoption touch a nerve? Let’s hear it in the comments.