After you’ve assessed clinical interoperability issues (covered in Chapter 4 ), you’ll be ready to start building interfaces. If you’re building your interfaces in house, you’ll be dealing with clinical system vendors. And if you’re outsourcing interface development, you’ll be working with consultants. Either way, you want to know what issues to avoid. That’s where this chapter comes in handy.
Make Sure You Check Off These Boxes
Conduct your due diligence on the following points and your interface project is much more likely to run smoothly.
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 consultants leave. How do you ensure this doesn’t happen? Ask for documentation, 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 for any required changes or updates you’d like to see.
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. 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 the interface. And clearly define your acceptance criteria for the project.
Demand These Deliverables
Beyond addressing the issues above, regardless of whether you work with a vendor or a consultant, ask for these deliverables or interfacing artifacts:
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. Gap analysis sets the scope of the interfacing project. 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 make sure the guide covers real-life and specific scenarios you encounter in your environment.
Test system. Understand how they’re going to 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.
Once you have a vendor or consultant strategy in place, and you’ve identified the artifacts you need, you’ll need to start developing the interfaces. The next chapters walk you through that process.
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
