The most successful integration engine migration is one that goes unnoticed. If the integration team is doing its job, caregivers should never notice any changes in their workflows.
In order for a migration to a new integration engine to go unnoticed, we take extra precautions that lead to a seamless transition. We’ve successfully helped 100s of providers migrate from a legacy integration engine to Corepoint Integration Engine. Our experienced team has experience migrating 1,000s of legacy interfaces over several months to as few as five interfaces. Following are the steps that have proven successful.
Step 1: Get the data.
Because you have an established ecosystem of applications in the hospital with an EHR and several downstream systems that need to be replicated in the new engine, we need to obtain the log files from the incoming and outgoing interfaces in the legacy system. The only part of the data exchange transaction that needs to be changed is the engine in the middle – we’re going to take out the hub and replace it with no disruption to upstream or downstream systems.
Ideally, we would like the log files from the past 30 days. With a month of incoming messages and a month of outgoing messages for all your different interfaces, we will be able to replicate any message type your organization will encounter.
Depending on the legacy engine, obtaining the log files may be difficult. Unfortunately, not every interoperability vendor makes log files easily accessible.
Step 2: Map the environment
To determine where the data in your environment is going, we’ll need to map all the twists and turns of each interface.
Again, depending on the features in the legacy system, obtaining graphical views of your data flow may not be possible. If this is the case, we will work together to determine all the downstream systems being fed by the EHR, Lab, etc.
This step is important because it will help the team make an informed decision on how to approach the “go live” to the new interfaces, which I discuss in the last step.
Step 3: Compare interfaces
We next take the incoming and outgoing log file messages we collected in Step 1 and begin to develop interfaces in Corepoint Integration Engine. Those incoming messages will be compared to the output to ensure the legacy engine results can be consistently produced.
Thankfully, Corepoint has built-in tools that perform interface comparison so we won’t have to count the pipes and hats in HL7 code or resort to using a text editor. Our engine will simply highlight the differences in the interfaces, which helps tremendously when matching the incoming and outgoing messages.
Another advantage of using a healthcare-centric platform like Corepoint is that it makes it very easy to follow healthcare data standards. By design, it’s actually somewhat difficult to break the standards. Adhering to the standards prevents the transmission of broken data that is unusable by downstream systems or eternal organizations.
Step 4: Test the interfaces
Testing the interfaces prior to go live is not a mandatory step for all new implementations but does provide added peace of mind. If you have successfully matched the log file data when creating the interfaces in Corepoint, it’s going to work 99% of the time. The messages being produced in Corepoint with the log files is identical to the messages that your previous engine were producing.
To provide an added level of confidence, users can deploy the new interfaces in a test environment that runs parallel to the legacy engine and the interfaces in production. We will occasionally find differences in the test environment that are impossible to replicate using the log files. Examples include downstream systems that have made changes to the interfaces thanks to an upgrade that occurred during new interface development.
Testing is especially important in new implementations involving 100s of connections. It’s not as vital for smaller implementations.
Step 5: Go live
After all the interfaces have successfully been tested, it’s time to make the switch to Corepoint.
There are two approaches to go lives. The first one is affectionately known as the “big bang,” where the IT team picks a day and a time, they turn off the old engine, and turn on Corepoint. All five, 20, 500 interfaces go live all at once. Out with the old, in with the new.
The other approach is what we call a rolling go live, which involves turning on the new interfaces in batches.
Each approach has advantages and disadvantages. The big bang inherently carries more risk. If any interface doesn’t work properly, then something was missed during testing. The team then must determine if they need to roll back to the old engine to fix the broken interfaces.
The good news: there’s always a rollback plan.
With a rolling go live there are more opportunities to make corrections along the way. The downside is that this approach takes more time. These mini go lives are typically spaced out days or weeks apart. Another disadvantage is that the intertwined nature of interfaces can make it difficult to carve out 10 or 20 interfaces that are not effected by, or do affect, other interfaces – this becomes evident when a data map is created in step 2.
Each organization has a different level of complexity to deal with when migrating off of a legacy engine and upgrading to Corepoint. The good news is that Corepoint Integration Engine has many features designed specifically with interface conversion in mind and our Professional Services team has helped customers of all sizes successfully upgrade their engine.Tags: interface engine