With Meaningful Use in full swing, chances are your hospital organization is implementing an EHR or converting to a new system or upgrade. Watch out: when you implement a new system or migrate from one to another, it can impact your systems’ ability to continue exchanging information. That’s why many organizations call upon third-party vendors for guidance and project assistance. You just need to make sure you stay in control and avoid hidden expenses as you work with these vendors. By getting answers to the following interface-related questions from your clinical system vendor(s), you can maintain the upper hand in the relationship.
Nine Critical Questions You Need to Ask Your Clinical System and Interface Vendors
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. If it does, find out about any hidden costs associated with this extra hardware, and who will maintain it (you or the vendor or another company?). If the vendor or a third party will provide support, what response times do they guarantee when you report an issue? And how does the vendor determine who is accountable for issues that arise? For example, if data exchanges are problematic between the interface and a medication distribution machine, is the vendor going to help troubleshoot it or offload you to the vendor of the third-party software?
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 deviate in several ways (custom messages, Z-segments, customized data types, customized code sets, etc). The list of customizations will help you understand the overall interface and the amount of work required to integrate with the other systems.
4. “Within your HL 7 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. Also, if the vendor doesn’t share this knowledge, you are a candidate for black-box syndrome, wherein the vendor maintains control of the interface. This limits your flexibility and ability to negotiate with the provider, and also reduces your capability to evaluate impacts that a change within the ecosystem might have on this interface and the systems exchanging data.
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. You need a list of those customizations for troubleshooting and maintenance, or your interface analysts will be waiting on vendor trouble tickets while clinician calls are piling up at the hospital IT help desk.
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 not be able to change the interface or re-use the code for another, similar interface project. You will need to engage the vendor for every tweak or new project, and that will likely leaving you paying big bucks…
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.
3 Bonus Technical Questions
While the following questions may not apply to all systems, be sure to ask them of the vendor so nothing is left to chance.
1. “If an application makes an information request, does the replying system acknowledge that it received the message or does it just reply?”
In the case of information requests (query messages for instances), the system will respond with one or several messages containing the information. In most scenarios, no ACK/NACK is involved as few systems implement Query/Response messages.
2. “What happens if the replying system does not have the requested information?”
The response format allows systems to return a message stating no information was available based on the criteria requested, rather than just sending a reply with blank fields.
3. “What happens when a message requests data be updated or inserted?”
Let’s say the lab system sends results to the EHR but the patient ID is not recognized at the EHR – what happens? The role of a message is to publish an event once it occurs and provide related information. How the information is handled is system specific and in some cases, the system might do nothing. While the system is responsible for handling the information received, the interface needs to provide information the system can handle.
Next Steps
After you’ve assessed high-level clinical system interoperability issues, you need to actually build and implement the interfaces. That’s where the next sections of the HL7® Survival Guide come in.
Your Feedback Welcome
We’ll be publishing chapters from the HL7® Survival Guide over the upcoming weeks and months. See a topic that needs more detail? Have a different perspective on interfacing and interoperability? Tell us in the comments!
Read More in the HL7® Survival Guide
Introduction
Chapter 1: How to Integrate and Exchange Healthcare Data
Chapter 2: Pros and Cons of Interfacing Capabilities
Chapter 3: The Heart of the Matter: Data Formats, Workflows, and Meaning
Chapter 4: How to Work with Vendors and Developing Your EHR Strategy
Chapter 5: Vendors, Consultants, and HL7® Interface Specifications
Chapter 6: Interfacing Artifacts: HL7® Conformance Profiles or Interface Specifications
Chapter 7: Interfacing Artifacts: Gap Analysis
Chapter 8: Interfacing Artifacts: Test Scenarios and Test Systems
Chapter 9: Interfacing Artifacts: Message Samples and Test Messages
Chapter 10: Process and Workflow
Chapter 11: Maintenance, Troubleshooting, and Monitoring
Chapter 12: Definitions
Chapter 13: Contributors and Resources
