Steps to a Successful Interface Engine Migration
Posted on behalf of Jeff Ford, Director, Managed Services
Changing your Integration Engine vendor is a big undertaking for any Healthcare system to undertake. There are so many moving parts; downstream vendor coordination, server connectivity, learning a new Integration Engine software, not to mention the Hospital resources that need to be utilized for feature testing confirmation. As the Director of Managed Services at Summit Healthcare, I’ve overseen dozens of these projects and have outlined some of the important steps below for a successful Integration Engine migration.
Integration Audit
The first step in any migration should be a full integration audit. This is the perfect time to evaluate your entire integration landscape. Do you have redundant feeds that can be combined, saving long term maintenance costs? Do you have point-to-point interfaces that you can now point through your new Engine to further leverage in the future and simplify monitoring? Are there inefficiencies in your current interface setup that you’ve been living with that can now be addressed? This is the opportunity to ask and answer all these questions.
This is also the time to think outside the box and evaluate all possible sources that can be run through your new Interface Engine. The Summit Exchange Engine, for example, can natively handle POCT1-A, PDF’s, XML and many more message types. It can also communicate via sFTP, web services, via the Meditech cold feed, and so on. Engines can accomplish much more than just the standard of sending HL7 messages via TCP/IP connections. There are probably numerous manual processes in your Hospital that can be handled by a powerful Interface Engine.
Build the Test System
Now that your Integration Audit is complete, it’s time to implement your grand interface plans. Rather than using a tool to import builds from your previous Interface Engine, I recommend building from scratch. This is the time to get rid of any redundancies, inefficiencies or bad code that build up from years of urgent, quick fixes. Take advantage of this upgrade time to get things right.
This is also a great time to check in with your downstream vendors. They’ve probably had plenty of updates since you first implemented your interfaces with them. There may be some new features you can take advantage of now that were not available then. Maybe they accept more message types or can handle more data fields than you were originally sending. Thoughts like this, along with the Integration Audit, will help ensure that you are getting full value out of your Integration Engine purchase.
Testing in Rounds
Whether you have 5 or 500 interfaces, testing is going to be the most resource-intensive step of this project. You will need buy-in and time from application specialists who are not typically involved in interfaces. To respect and best utilize the resource of their time, I recommend dividing your testing into rounds. This can be done either by vendor or by message type.
If you’re using the same testing resources no matter the application or vendor, I would split the interface testing up by message type. First, test and confirm ADT’s to all vendors. This is the most common message type; therefore, it will touch most of your vendors and you’ll be able to spot common message formatting changes that you’ll need to make across all interfaces.
More commonly, however, your testing resources will be divided by application. You’ll need to borrow a LAB Analyst’s time to test your LAB interfaces, a RAD Analyst for your PACS interfaces, and so on. If this is the case, I would split up your interface testing by vendor. In your first round, test all message types to your PACS vendor. In your second round, test all interfaces to all lab vendors. There may be some overlap, but this testing method should respect everyone’s time the most.
Go-LIVE Options (In Stages vs Big Bang)
After all the hard work of building and testing, it’s time to move everything LIVE. There are two main ways of accomplishing this. If there is no hard deadline, the smoothest way is to go-LIVE in rounds, much like your testing. Going LIVE with one vendor at a time will allow you to more quickly troubleshoot any issues and minimize downtime. You can properly alert the specific users affected and closely monitor the limited number of interfaces for the day.
However, chances are you’re coordinating this with another big change in your Hospital software eco system. Maybe you’re going through an EMR change or your contract is ending with the other Engine vendor. In this case, you’ll need to bring all interfaces LIVE at once. My recommendation is to do this after hours and schedule expected downtime of 2-3 hours. This will allow enough time to troubleshoot any issues you may find, from connectivity issues to message mapping tweaks.
Post LIVE
The last piece of a successful Integration Engine migration is the post go-LIVE coverage. It is important to keep in constant contact with all affected end-users so that any possible issues are found early and can be addressed. Having an open meeting time for 30 minutes twice per week for the first 3 weeks post Go-LIVE can be very beneficial. If possible, keeping the old Engine server available for 60-90 days is extremely helpful as a cross-reference should any issues arise. Keeping all these steps in mind will go a long way to a successful Interface Engine migration for your hospital.
