Now we’re coming full circle. Throughout Chapters 6 through 10, we talked about creating interfacing artifacts, assets, and documentation: profiles, gap analyses, test plans, test messages, test systems, and workflow maps. In this chapter, we explain how you can get maximum value from all the work you put into creating all of those.
Why Document?
By documenting your profiles and specs, you can much more easily troubleshoot issues and tweak configuration once your interface is live. Plus, if you created electronic – i.e., machine readable – versions of your profiles, you can use them in your monitoring. For example, you could shoot a message through a profile using the Caristix Message Player to see if there’s anything anomalous, such as an extra segment or a field that is too long. Or you could run problematic messages against the test scenarios you developed during the validation phase of the interface lifecycle.
All that’s good and well but no one can use your profiles and spec unless they’re readily available. So be sure to store them in a central repository for your support team. Make the files read-only if necessary. What’s important is that anyone can quickly access them when needed.
By using the assets you built in the earlier phases of the interface lifecycle, you can quickly and proactively address issues and avoid additional costs. Plus you can keep users happy. Imagine rapidly troubleshooting an issue to avoid downtime rather than forcing clinicians to log a help desk ticket because the interface went down.
Maintenance, Monitoring and Troubleshooting
Another benefit to documenting profiles is that it streamlines processes when you are performing a system upgrade. Let’s say you’re changing or upgrading your pharmacy system – that change affects the interface of any other system that communicates with the pharmacy system. Imagine ten different systems connect to your pharmacy system – you’d need to tweak those ten interfaces.
But you’re smart and you already documented the pharmacy system and the other systems through the use of profiles/specifications. That means all you need to do is create a new profile for the new/changed pharmacy system. Then when you redo the associated 10 interfaces, you will perform a new gap analyses, but the hard scoping work (those specs) will already be done.
Once your interfaces are in place, you want to monitor them to ensure they’re supporting your processes as designed. The value of monitoring is that it empowers you to be proactive in troubleshooting issues. You can set up thresholds and then be alerted to potential issues. For example, you could say that only a certain number of messages should pass through the system for a certain process and if that number is exceed, you get alerted.
Many interface engines include monitoring capabilities but some are limited to that particular engine. If that’s all that you have at your disposal, take advantage of it. But if you have the option and your environment includes multiple interface engines, look for vendor-agnostic solutions that cover the entire integration environment. That’s the easiest way to get a global overview of your environment.
Just remember – when you’re sharing data across your infrastructure, sometimes an HL7® message is the problem. But the network or a specific system could also be the problem. For example, perhaps a nurse is not seeing orders in the pharmacy system. This may be because the network is down. Or it could be an issue with the ADT system or with the medication admin system. Or one HL7® message could be holding up the queue. You want to be able to quickly eliminate the HL7® message as the issue. Just remember that ideally your monitoring should link back to your test cases and interface specifications.
4 Best Practices for Extracting Maximum Value from Your Artifacts
The fact is that the value of your interface-related artifacts increases over time. While they’re useful for development and go-live, they are essential down the road, in a year or two or more. Here’s how to get the most from these artifacts.
- Work with real-world messages. When you’re developing deliverables such as profiles, it’s important to start with real-world messages for the reasons we covered earlier in this chapter on HL7® interface specifications. You will refer back to these deliverables over and over throughout the interface life cycle. If you start with placeholders or fictitious information, you’ll struggle when it comes time to troubleshoot issues.
- Share your work. Share your artifacts. Encourage diligence in documenting all aspects of your interface project. Consider a common scenario – the interface project wraps up and a key analyst or engineer leaves your organization. You want the new employee to be able to easily take over for the departing employee. And that means having all related documentation on hand. This practice helps in another way: by documenting what changes have been made to the interface over time, it’s much easier to quickly troubleshoot any issue. And keep an on-going to-do list, especially around gap analysis as this will help you better approach maintenance tasks. And make it easy for people to share their work and documentation. Use SharePoint, or look for collaboration functionality in the software you purchase.
- Archive your work. Upgrades and updates to the interface engine will happen. You don’t want to get stuck being the victim of Frozen Interface Syndrome, which occurs when you are trying to implement a new interface and need all participants to switch over at the same time but can’t get their cooperation. You also want to avoid Black Box Syndrome, when you lack full visibility into all the work that has gone into interface development handled by a third party, making it nearly impossible to upgrade, tweak, and manage the interface without spending lots of money and time. Don’t make the mistake of thinking you won’t need certain documentation in the future. In fact, you’ll probably re-use it for your next project or for an interface or system update.
- Understand content management. Effective documentation requires that you think beyond message structure and troubleshooting. You need to think about clinical content and how it changes over time. For example, lab orders have their own codes and these codes get updated over time. You want ready access to the most up-to-date list as needed. And you need them reflected in your HL7® tables. That means you need to plan from the start how you’ll map the code sets to the right fields and build that into your interface and the system at go-live.
To make all easier for your organization to take full advantage of its interfacing artifacts, assets, and documentation, download this checklist of what to look for when you’re researching collaboration software.
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
