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.