Author: Kevin Roy

Tip 10 in the Interoperability Tip Series

In the previous tip, we covered specifications. Another key requirements or scoping document you’ll need is a gap analysis. In this tip, we discuss how to develop an interface gap analysis document.

Many analysts develop their own gap analysis templates in Microsoft Word or Excel. To fill in templates, they look at messages, run queries when they can, and manually document their findings. This can be a fairly onerous process if they’re basing the analysis on real-world messages (as opposed to doing a simple vendor spec walk-through). Another option is to take advantage of software that automates the gap analysis process.

Whatever your approach, you want answers to the following questions so you can identify gaps related to messages:

1. Does the destination system handle all of the message types from the sending system?
2. Are there any differences between the message structures in each system?  If so, what are they?
3. Are there any mandatory data elements on one side that are optional on the other?  If so, what are they?
4. Do both systems use the same code sets? Are they the same values?  Which values do I need to map?
5. Do both systems specify the same maximum length of characters for data fields?
6. What z-segments are in use?
7. Is the data semantically consistent? In other words, does the meaning or significance of an element always match across both systems?
8. What are the requirements for encryption or de-identification, usage restrictions, and HIPAA compliance related to confidential information?

 
In the next tip, we’ll explain why you need a gap analysis.

Download the HL7 Survival Guide

Tip 9 in the Interoperability Tip Series

In Tip 8, we explained what an HL7 interface specification should include. In this tip, learn how to develop an HL7 interface specification, which you’ll need for each interface you develop.

(A quick note about terms. There is no standard term for a spec. Some people call them a profile, conformance profile, schema. We use the term profile or HL7 profile in our software. We use the terms specification, conformance profile, and profile interchangeably in the tip series.)

To build a specification, you have several options.

Messaging Workbench available via HL7 International (look for a file name that includes “MWB release”) is open-source software designed to build conformance profiles. But keep in mind, with Messaging Workbench you need to build out individual profiles for each message type. If you define 10 message types for an interface, you’ll be building 10 separate profiles. You’ll also have to read through messages to get the information you need.

You can also develop templates in Excel or Word and then populate them manually. Or you can take advantage of functionality in Caristix software that automatically creates profiles from HL7 messages. In our world, a profile corresponds to the spec for a source or destination system, with however many message types you need.

Regardless of how you develop a profile, you need to do it. The problem is that there’s no industry-standard template available. That’s why we’ve developed this HL7 profile template kit and made it available to you for download. With it, you can avoid the time and effort to set one up, and make sure you clearly and concisely communicate what your integration environment expects in terms of data exchange. Feel free to download the template and tweak it to suit your needs.

[caristixbtn style=”orange” text=”Download The Kit” url=”https://hl7-offers.caristix.com/hl7-profile-kit/” blank=”1″]

Why Leaders Should Require Project-Specific Interface Specifications

• Profiles or specs gets analysts, developers, internal customers, vendors, and consultants on the same page.
• Populating a profile identifies risks before interface development.
• A profile also serves as a list of requirements.
• Develop an accurate list, and your team eliminates time spent on coding, testing, and on trial and error during go-live.
• A profile makes it possible to easily generate your gap analysis report as well as test and validation plan.

The Dangers of a Missing HL7 Interface Specification

Without an interface spec outlining your requirements, you’ll be stuck implementing a generic interface.

Let’s say you work for a health system. If your organization is like most, your clinical resources are already stretched thin – and the last thing you can afford is to dedicate those resources to testing. But that’s what you’ll find yourself doing if you go with a generic spec. After all, your interface will likely be buggy when it goes live because your true requirements weren’t gathered up-front. As a result, you’ll find yourself bogged down with extensive troubleshooting after go-live, especially when you run into issues with clinical workflows because the interface doesn’t work as expected and clinicians report a lack of data, orders, lab results, and/or medication as a result.

On the vendor side, you don’t want to be putting your clients through this. They’ll turn to other organizations that can eliminate this pain.

Download the HL7 Survival Guide

Tip 8 in the Interoperability Tip Series

Critical Elements in an HL7 Interface Specification

These are critical elements a developer needs to create a interface that works (almost) out of the box with minimal testing. The more accurate the HL7 interface specification, the faster it’ll be implemented – and the less costly the work will be.

1. Interface name
How do you refer to your interface in your integration environment? Some organizations manage thousands of interfaces. If you’ve got 10 or 20 interfaces, no big deal. But if you’ve got thousands, devise a naming system for easy name recognition and tracking.

2. Source or destination system name and version
System versions (and even product names) change over time. Make sure you’ve got a way to track this in your spec.

3. Message types used in the interface
A message type is essentially a trigger event, such as patient admission, lab request, lab results available, new appointment, etc. How you use and implement events is completely up to you – it depends on your system and hospital workflow. Each of the HL7 v2.x reference specifications contain hundreds of trigger events. Just focus on the ones you need for your interface.

4. Message definitions including segments, fields, data types
You need a list of the segments, fields, and data types used in each message type.

5. Segment and field attributes
These are optionality, repeatability, data type associated with a field, field length, tables associated with field.

6. Z-segments
Custom segments, if a vendor or your facility uses them.

7. Data types
Apart from a list of data types, you will also need attributes and customizations.

8. HL7 tables with field and data type content
Within your HL7 interface specification, you need the real-world data or code sets that are actually implemented – such as gender, race, and lab codes – not what the standard provides. Otherwise you’ll find yourself wasting lots of time trying to figure out what’s really going on in your system, especially when data such as lab codes change over time. You can solve this problem by keeping track of the actual data and code sets used, along with where and how they’re used, and the meaning of the information.

9. Specialized interoperability challenges
Without getting all necessary information upfront, your challenges around interoperability become greater and more insurmountable. Consider lab interoperability and the example of Logical Observation Identifier Names and Codes (LOINC) codes – the LOINC dictionary contains more than 42,000 codes and some codes mean similar things. That means two systems exchanging data could refer to that data differently – leading to confusion and information-exchange problems. Read more about addressing the challenges of lab interoperability in this Clinical Innovation and Technology article: Lab Interoperability Plays Catch Up.

Download the HL7 Survival Guide

Tip 7 in the Interoperability Tip Series

Communicating These Needs to Leadership

These are the most important assets you’ll need when you’re working on creating new interfaces or converting existing ones from one system to another. You’ll need to create them manually, or automate this work via interface lifecycle software.

Why These Assets?

Besides making sure that you have complete requirements so that you can accurately scope a project, you need to make sure you have all the parts and piece lined up and built into your project planning to prevent unforeseen roadblocks. These are the interfacing artifacts or assets that a project requires. Know what they are and what you need to do to get them in place to keep your project on track.

Interfacing Project Assets

HL7 conformance profiles (also known as profiles or interface specifications). HL7 profiles should at a minimum provide a list of messages, segments (including z-segments), fields, data types, and typical code sets or data.

Gap analysis between systems to connect. Big picture: gap analysis sets the scope of the interfacing project. Nitty-gritty: make sure you have field mapping tables. Read more about gap analysis in this Caristix white paper.

Test scenarios. Vendors typically provide you with a boilerplate validation guide to ensure the interface works as expected. But your team needs to ensure that your organization’s clinical workflows are covered. For example, let’s say you have a duplicate patient record in the system. Some hospitals are going to perform a merge to get rid of the duplicate; others are going to ignore it; and yet another batch might delete one of the duplicates. But the boilerplate guide might just say to merge. So create your own.

Test system. Make sure you can document test results and don’t sign off on acceptance criteria unless your clinical workflows are covered.

Message samples and test messages. Critical for testing prior to go-live as well as post-go-live for troubleshooting.

Process and workflow maps. This rounds out your view of your interfacing ecosystem. Complement the message structure and content details from HL7 profiles with good process and workflow maps for future interfacing asset management.

What other interfacing project assets do you use? Let us know in the comments.

Download the HL7 Survival Guide

 

Tip 6 in the Interoperability Tip Series

This tip is for hospital or provider analysts and team leads.

You’ve got a firm grasp of the technical ins and outs of system and application interfacing. Because you’ve got the background, you know that contractual and cultural issues can affect your team’s ability to deliver on time and on budget. 

Make sure these issues are on the table with your leadership, ideally during negotiation before a deal is signed. Your leadership will thank you for thinking ahead — focusing on the good and avoiding the bad and the ugly. Use your operational expertise to avoid expensive problems down the road.

6 Points for Due Diligence

Is your leadership aware of these points?

1. Negotiating an Interface
When a hospital buys a clinical system, interoperability and HL7 are usually not addressed during the negotiation. The vendor’s sales rep often glosses over the requirements and simply mentions the “thousands of interfaces they’ve got in a library.” The problem is that analysts like you get pulled into the project after the contract has been executed only to discover it’s challenging to interface with the new system – but you’re stuck with making it work. Approach your manager before the negotiation phase and ask to be involved. By highlighting the issues that can arise when interoperability and HL7 are not addressed during the vendor negotiation, you can help avoid lots of project complications and will set you and your manager up for a smoother, more successful project.

2. Black-box Syndrome
In this scenario, the vendor keeps control of the project and interface, leaving you to pay for any tweaks or additional needs going forward, including documentation. Just as painful is the fact that the knowledge walks out the door when the vendor implementation team or consultants leave. How do you ensure this doesn’t happen? Ask for documentation specific to your site, including the interface specification, as part of the contract. This should detail which systems are linked/interfaced, which messages are exchanged, and which message formats are used, at a minimum.

3. Vendor Lock-in
Some interface vendors or consultants introduce their own intellectual property into the interface. In such cases, your organization has license to use the interface, but not full ownership of the interface, which means you need to pay the vendor on an ongoing basis for any required changes or updates you’d like to see. We’ve come across situations where providers are stuck paying five figure fees for gaining access to their own interfaces and data.

4. Who Drives the Interface Specification?
In the past, the clinical technology vendor would drive the spec and customers had to conform to the requirements. Nowadays, the opposite approach is increasingly common: the hospital drives the spec and vendors must conform. While this approach is more expensive initially, down the road it makes the process smoother for the hospital, especially as hospitals are increasingly part of HIEs and merge to form large hospital groups or IDNs. This is good for hospitals and providers but you need the right infrastructure (i.e., the right HL7 software and integration engine, configured to meet your organization’s needs) and culture to support this approach, whether you handle interface implementation in house or outsource it.

5. Supporting Technology
A good integration engine is a great building block, as we mentioned in Chapter 2 of the HL7 Survival Guide. But you also need supporting technology and a culture that help you – and anyone else who gets involved at any time – manage and update the engine and interfaces over time. Look for software and technology that simplify the process of generating, updating, and managing specifications, requirements, test scenarios and other documentation associated with your engine and data exchange work. You’ll also want a repository that provides a central location for anyone with permission to access the documentation. A detail that may seem nit-picky at the beginning of a project just might be the essential connectivity information you need a year later, when an interface goes down at 5 pm and you are the Tier 3 support on call.

6. Culture
Your organization’s culture and approach can make or break a consulting engagement or in-house project. Ideally you want to drive the show with consultants. Set clear expectations. Control deliverables by coming to clear agreement as to their definition and due dates. Use your project documentation from Point 5 above to ensure clarity and accountability throughout the interface lifecycle. Ensure a structured methodology is used to test and validate the interface. And clearly define your acceptance criteria for the project.

How to Use Caristix Software to Get Answers

Laying the foundation for interoperability, these are the questions that Caristix Workgroup software organizes for analysts and developers. By creating specs automatically from messages, the software helps analysts provide answers with little to no manual work, while enabling developers to get interfaces into production faster. We think it’s a win-win for both vendors and providers.

Download the HL7 Survival Guide

Tip 5 in the Interoperability Tip Series

9 Critical Questions You Need to Ask Your Clinical System and Interface Vendors

Like our last two tips, this week’s tip is geared to hospital teams asking their vendors the right questions. Vendors who are on the ball will have the answers at their fingertips.

Why Should Health System Leadership Care About This?

These lay the foundation for interoperability. They are the basic format and content scoping questions that kick off each and every interfacing project. Your teams will work with your vendors to answer these questions for every system they work with. Your managers will be tracking answers, and the quality of the information they get will impact risk, timelines, and costs.

1.    “Who provides the hardware, if any?”

When you implement a new EHR or clinical system, validate it doesn’t need extra hardware for data exchange. You want to find out about hidden costs.  

2.    “What standard does your system use for data exchange? HL7? Which HL7 2.x version are you using?”

These questions lay the groundwork for the next one.

3.    “Can you supply a list of customizations you made to the HL7 v2.x standard you are using?”

While most vendors will claim they deviated very little from the standard, you will probably find they deviated in several ways (custom messages, Z-segments, customized data types, customized code sets, etc). The longer the list of customizations, the longer and more risky the project.

4.    “Within your HL7 2.x based interface, can you tell me which elements and values are configurable?”

You need the details. If they can’t provide details on configurability, you might be facing a longer test cycle than anticipated. Trial-and-error interface validation can slow down implementation. 

5.    “When you send us the interface spec for sign-off, do we get a fully documented list of gaps and exceptions for specific data values and data elements?”

You want a full list, or you’ll be facing a lengthy validation process, waiting for super-users and clinical testers to flag bugs in the test system.   

6.    “Will you provide a list of the interface customizations you create for us?”

No interface specification works perfectly out of the box; it has to be customized to your environment. Keep this list for troubleshooting and maintenance, or risk extra downtime. 

7.    “How do you document changes and upgrades throughout the lifecycle of the interface? Do you automatically provide us with updated documentation?”

If there’s anything worse than missing documentation, it’s partial or out-of-date documentation. What you get at go-live will not be usable two years out. Make sure the responsibility for documentation updates is clearly spelled out. 

8.    “Does the interface you built contain any intellectual property?”

This is crucial! Validate if a license will apply to the code and you will own the interface – or if the vendor will own it. If the vendor owns it, you might need to pay big bucks in licensing fees if you ever need to access that feed. 

9.    “How guaranteed is message delivery? Does each message get an “acknowledge” (ACK) or “no acknowledge” (NACK) reply?”

This is part of the HL7 standard and is an important piece of the message delivery process as you cannot guarantee the message was delivered without it.

How to Use Caristix Software to Get Answers

Laying the foundation for interoperability, these are the questions that Caristix Workgroup software organizes for analysts and developers. By creating specs automatically from messages, the software helps vendors provide answers with little to no manual work, while enabling provider teams to get interfaces into production faster. We think it’s a win-win for both vendors and providers.

Download the HL7 Survival Guide