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 planned and executed conversions for engine environments with as few as five interfaces, such as those for a small practice, to those with over 1,000 interfaces, which serve multiple hospitals within a diverse and complex healthcare system.
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 seven days. With a week of incoming messages and a week 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. Despite this, with Corepoint Integration Engine, we can set up pass-through connections before the migration begins, and gather the incoming and outgoing data passively, for later use in the migration process.
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 is discussed in the last step.
Step 3: Compare interfaces.
Next, we’ll take the incoming and outgoing log file messages collected in Step 1, and begin to develop interfaces in Corepoint Integration Engine. The inbound messages will be used to generate new outbound messages in Corepoint, and those will be compared to the original engine’s outbound messages, to ensure we are processing messages as expected.
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 external organizations.
Step 4: Test the interfaces.
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 using the above methodology should be identical to the messages being produced from the previous engine.
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.
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 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. All Corepoint interfaces are brought into production during this single go-live event.
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.
