One of the things we realized when we formed Caristix is that the biggest pitfall in HL7 interfacing isn’t coding or setting up the interface. With modern interface engines, that’s relatively easy. The real struggle is knowing how a system is constructed, where the gaps are, and what needs to be coded – this drives the work. In fact, when this scoping is handled effectively, all other aspects of interface creation and management go well. But when this stage is not well-managed, the impact trickles down to affect all other phases.
Avoiding the Pitfalls: Effective HL7 Interface Scoping
The scoping stage largely revolves around coming to terms with data-exchange requirements. On average, for each message transferred between two systems, over a thousand pieces of data are exchanged. To make sure data is entered correctly in the receiving system, developers need to understand the data being received along with its format and meaning.
For example, the gender of a patient can be indicated using up to six different attributes or coded values in HL7 v2.6. That said, very few systems use all six possibilities, instead using three or four. Even then, each hospital can choose different signifiers for the options and remain HL7 compliant. While one may designate male as “M” and female as “F,” another might use a “1” and a “2.”
Then, there are the variations possible for lab requests and result codes. In one system, the code for white blood cell count might be “ABC” while in another it might be “456.” In light of the fact that LOINC contains more than 42,000 codes, it’s easy to see how quickly permutations can occur from one system to the next.
As a result of the many variances and adaptations of the HL7 standard, there’s no truly standard way that systems are implemented and data is handled. In response, analysts and interface engineers are forced to undertake lots of manual, tedious work: read the specification document, ask the customer for feedback, and hope to catch major differences between the two. This assumes the spec is available, which is often not the case. Even when a spec is available, it’s often not up to date.
To validate data, technical consultants and teams spend inordinate amounts of time counting pipes instead of tackling a known list of what needs addressing.
HL7 Trial and Error Has Run Its Course
To make matters worse, this arduous process only addresses the first phase of an interfacing project. By basing this process on manual efforts and trial and error, organizations set themselves up for issues every step of the way.
With the tidal wave of data coming about due to initiatives such as Meaningful Use – which will force data integration among numerous systems – the problem will only be exacerbated.
Interfacing is often on the critical path within a major implementation project. Improving the interfacing process can boost the overall effectiveness of EMR implementations, leading to better use of project resources, and higher levels of hospital user adoption and customer satisfaction.
What are your thoughts? How can analysts and their managers drive some of these pitfalls out of the process? Let us know in the comments.
