Author: Kevin Roy

In Part 1 of this series on HL7 gap analysis, I covered the need to identify gaps before starting to configure an interface, and explained why gaps happen. Today, I’m going to talk about gap analysis steps and the limitations you need to plan for.

Gap Analysis Steps
1. Obtain vendor conformance profile.
Vendor analysts start out with an HL7 conformance profile for the product they’re deploying. The profile documents the specific trigger events and segments used by the application. It wouldn’t necessarily cover every segment mentioned in the HL7 standard — just the relevant ones. The document also includes fields and related tables. The purpose, constraints, pre-requisites and expectations of each field need to be clearly defined in the vendor profile.

2. Obtain hospital specs and/or message log.
If available, the hospital IT team provides up-to-date documentation for the applications and systems that will need to pull or push data to the new product. Because these specifications are often unavailable, incomplete, or outdated (they potentially change with every product upgrade and interface engine tweak), reliable documentation is sometimes hard to get.

An alternative is to have the hospital share a sample message log with the vendor. The message log can be from a test or production system as long as it represents the “real thing” the vendor has to interface with. The sample message log should be relevant in terms of trigger events used, data exchange workflows, reference data (user tables) and customized data elements. The more use cases you can cover in the sample log, the fewer unidentified and unexpected gaps you can expect down the road.

If the log happens to contain protected patient information, both parties are mindful of encryption needs, usage restrictions, and HIPAA compliance.

3. Document gaps between the product and the hospital’s system.
This is mostly a manual task. The analyst simply opens the vendor conformance profile and the hospital spec (or sample message log), then starts comparing the two documents side-by-side on a computer screen. The analyst lists all the items that will need to be configured or customized. See Part 1 of the Gap Analysis series for details about gap types that analysts look for.

Gap Analysis Limitations
1. Complete, up-to-date documentation is hard to find.
That’s just a fact. When documentation exists, it needs to be validated. While it helps to have the documentation on hand, unfortunately, most of the time it’s just not there.

2. Log querying is still manual.
With a manual gap analysis process, the limiting factor boils down to getting a big enough sample to catch rare occurrences of values that would impact the interface configuration. Yet logs need to be small enough to be manageable on a human scale. Even at 5,000 to 10,000 messages, chances are an analyst will have enough time to sample just 50 messages at a time and read through 500 messages per gap issue. In the real world, with tight project timelines, no one would have enough time to parse every single message. Or catch every single gap.

3. Maintenance is repetitive.
Every time an interface (or the data semantics going through an interface) changes, the gap analysis process should be repeated for every single interface. Again, in practice this is very difficult to achieve. It wouldn’t be just one gap analysis but many more. Organizations sometimes choose to work reactively to solve problems on the fly, rather than proactively decrease the risk level.

Of course, this has an impact downstream during software implementations. Other teams encounter bugs and defects due to constrained gap analysis. And the result is that vendors and hospitals spend more time iterating through corrections and fixes both pre and post Go-Live.

These limitations are why we’re seeing a need to automate some of this work and increase gap identification earlier in the process.

Do you see risk reduction in gap analysis as a need in the industry? Do you see any other issues related to the gap analysis phase in HL7 interfacing? Share your thoughts in the comments.

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.