Nine times out of ten when a hospital deploys a new software system, the new system will need to exchange data with existing information systems in order to deliver on expected value. Even with fully integrated vendors like Epic and others, hospitals still have data from flowsheets from monitoring systems and medical devices to pull in through an interface.
Many vendors provide connectivity libraries and most hospital deploy interface engines to cope with connectivity and interfacing issues. But before they can use these tools, they need to work through a gap analysis phase.
What is Gap Analysis?
In this context, gap analysis is the phase in a deployment project where analysts map the data elements between the product they are installing to the elements in the hospital’s existing information systems. In most software or medical technology deployments, vendors are responsible for configuring and delivering a testable interface to the hospital.
Even when the new and legacy systems are based on the same HL7 version, the gap can be considerable:
Why Do Gaps Exist?
Fundamentally, because HL7 v2.x is a loose standard. HL7 was built to adapt to the many different environments where healthcare data integration was needed (as you know, every single provider organization is unique… 😉 ). Standards developers aimed to ensure that messaging stayed independent of system architecture and that custom interfacing development was minimized. The HL7 standard recommends an exchange format but also provides capabilities to extend and adapt the standard to real-world use.
The result is an 80-20 situation. An HL7-compliant product will probably allow you to complete 80% of the interface with 20% of the effort. For the remainder, you don’t need to change existing organizational processes or data structures. Instead, you adapt the way data is exchanged. This strategy was fine for promoting adoption. But over the long run, as the number of interfaces grows and they become more complex, hospital IT teams can face significant challenges. Especially when that custom 20% is different for each and every system…
Gap Sources
Gaps happen for several reasons.
1. Data structure: HL7 specifies/recommends usage of a data structure that includes trigger events, segments, fields and data types. Because clinic processes and representative data are fairly complex, the recommended structure must account for that complexity. The result is that deployed systems can’t fully conform to the recommendation. One example: a data structure gap based on the maximum length of data elements. What does the new system do if it receives a patient name longer than what its database can store? Do you truncate the data? How will clinical end-users react?
2. Data tables: HL7 suggests (…this is the term used in the specification) data sets. You probably already know that HL7 v2.6 “suggests” 6 different values for patient gender. But most installed systems don’t handle the whole list. Even worse, they might use a completely different set of terms to indicate gender.
3. Data meaning (or data semantics): There is a well known rule in the data exchange world: “It’s not because you call it the same thing that you mean the same thing.” HL7 interfaces will interpret the standard using their view of the world. For instance, which information would a system use to uniquely identify a patient? Several fields are potential candidates: PID-2 Patient ID, PID-3 Patient Identification List, PID-18 Patient Account Number, PV1-19 Visit Number, and so on. Even a combination of more than one field can be used. But would the same information, from a semantic point of view, always be at the same location within the various messages?
4. Z-segments: These segments are used when the standard doesn’t provide guidance for a piece of information you need to exchange. But sometimes, development teams resort to Z-segments when they need to cut delays and costs and/or work around technical limitations. When you come across Z-segments, any piece of data you need will probably result in a gap.
5. Legacy: Here the thought process is, “If it ain’t broke, don’t fix it.” Systems and data exchange mechanisms evolve. For instance, the way allergies were handled in early HL7 standard versions is different than the most recent. If you don’t have an interface engine or if the software system doesn’t make changes transparent, you’re going to be facing some gaps.
In the next blog post, I’ll be covering gap analysis steps and limitations. But there’s so much more to discuss. We want to hear about your experience with gap analysis – please let us know in the comments.