Two Basic Approaches to HL7 Interface Conversions

March 22nd, 2010 by Bernard Echiverri Print Friendly

Having recently returned from the annual HIMSS conference in Atlanta, I’ve had a couple of weeks to reflect upon the experience, and in particular the concerns of folks that stopped by the booth to ask questions or watch an HL7 integration engine demonstration.

One of the recurring themes was the uncertainty surrounding the future of various legacy interface engines, especially as related to product support, professional services, and new functionality for future releases. Having recently worked on several integration platform conversions, wherein we evaluate existing interfaces and convert them to interfaces consolidated in our integration engine while keeping the conversion transparent to the end-users, I thought I would share some of what I’ve learned.

While there are certainly a proverbial “thousand ways to skin a cat”, generally, there are two approaches that you can take when considering how to write the logic that will be used to convert the existing interface to the new engine, regardless of whether the original legacy code is in Monk, TCL, or any of the other numerous languages in common use.

The first approach would be to simply replicate the existing logic as closely as possible, regardless of how well you understand the intended workflow at any given point in the logic, and despite any opportunities you see to modify the logic to conform to best practices, more efficient algorithms, etc. I’ll call this the “imitation” method. This method typically has the advantages of:

Faster turn-around on existing interfaces
Preservation of all comments, original logic, and structure as closely as can be imitated

The second approach, which I think of as the “improvement” method, is to first evaluate and understand exactly what the existing logic is attempting to accomplish, and specifically, how it means to do so. Then, the task at hand is to replicate the filtering, mapping, and data normalization steps as closely as possible, while taking advantage of the opportunity to conform to best practices and to leverage the expanded functionality that is inherent in newer engine architectures. Doing so could result in any of the following improvements:

Increased performance (by streamlining the logic that filters, maps, and translates the HL7 data)
Improved readability and documentation, through the consistent application of appropriate comments in a well-defined, organized logic structure. This eases maintenance of the interface, as anomalies are researched and addressed, or as workflow requirements change.

Each approach has advantages relative to the other, and anyone who intends to convert an existing interface should consider them before they dive into a conversion. The last thing anyone wants to do is get halfway through a lengthy and complicated conversion, only to find that they have been reduced to “trial and error” methods of determining the remaining logic needed to complete the interface. Knowing which method you intend to use before you begin can help you avoid such pitfalls.

Finally, during the entire conversion process, I can’t emphasize strongly enough the need for clear communication between the person doing the conversion, and the people who will be using and maintaining the interface on a day-to-day basis, as the needs of the end-user’s organization should always be the defining criteria used when establishing which conversion method should be utilized.

For more information on understanding, developing, and testing an HL7 interface, please search and read this healthcare integration resource site. Also visit HL7 Resources and the Healthcare Interoperability Glossary to learn more.