If you’re in the hospital or health system world, you’ve probably noticed: the topic of interface engine migration is big right now. And no wonder. Because of the Meaningful Use carrot and stick, we now have a baseline foundation of EHRs to work with. That foundation paves the way for more sophisticated capabilities than ever before, including the promise of analytics, population health management, and the ability to access new sources of clinical and operational data to improve both care and margins. Whether or not you personally agree with the need for new capabilities, they’re technologically feasible today, in a way that would have been impossible back in the managed-care 90s.
But we still have 90s technology blocking our way. What is that technology? The legacy interface engine. In a previous post, we discussed the fact that with DataGate/eGate and eBiz at the end-of-life mark, many hospitals and health systems are faced with major conversion and migration decisions. Even if you are not dealing with an end-of-life necessitated migration, having an older legacy interface engine means that in order to fulfill the promise of those new capabilities, hospitals and health systems are faced with the need to upgrade to a new integration technology.
3 additional scenarios that call for interface engine migration
1. Mergers and acquisitions
With physician practice acquisition and also health system consolidations or mergers, there is a real need to standardize on a single technology and single engine. Think of a major health system that grew through mergers over the course of a decade. They may have 5, 7, 9 integration engines in use. That’s 5, 7, or 9 code bases to support, technology skill sets to maintain, and license maintenance agreements to manage and also fund. If you reduce that number to just one system, you’re automatically saving dollars and resources. That decision to consolidate will also trigger the need for a migration project.
2. Private HIEs
Many large IDNs and health systems are creating private HIEs to make data exchange and data sharing easier. Again, standardizing on a single platform will bring cost savings. But health systems also do this for continuity of care and related competitive advantage in local markets. If they’re standardizing on a single technology or engine, they will definitely not choose an integration technology that is no longer supported. Which again triggers an engine and interface migration project.
3. Upgrade within current vendor technology
Even when a hospital organization is happy with an incumbent integration technology vendor, they will sometimes need to upgrade to a newer version. The need usually surfaces when they need to leverage new capabilities. But here again, they’ll be triggering an interface migration project.
What’s the common thread?
In all of these cases, the underlying need is the same: slim down costs associated with old-school infrastructure, and upgrade because you need to do more.
What’s the biggest Issue?
The biggest issue with migration, regardless of the scenario: not capturing the business and transformation requirements. If you skip capturing requirements, there is a huge impact downstream, especially when you need to migrate code.
Read more about HL7 interface requirements in this blog article.
If you do nothing else, do this one thing
We’re working on an Integration Engine Migration Guide to share best practices and recommendations for these critical projects. Here’s one thing we wanted to share from the guide.
Complex interfaces contain a fair amount of code. Legacy interfaces sometimes suffer from several years of enhancements, tweaking and possibly patching. Requirements that were perfectly valid years ago (and implemented years ago) may no longer be applicable today. What’s worse, if you need to re-engineer the way data is exchanged or transformations are handled (due to message standardization, canonical model usage, or related need), some of your legacy code will simply no longer work.
Each programming language has its own strengths, so in each language you’ll use different ways to accomplish similar tasks. Consider leveraging the strength of the newly acquired technology instead of carrying over non-functional artifacts and outdated work from previous interfaces.
For instance, in the case of a migration from eGate to another technology, the Monk code is very important for one primary reason: validating and completing the requirements list. If you do nothing else, review the code. Make sure the new interface includes the incremental detail and small cumulative changes from years of legacy interface use. This will help you improve data exchange quality as your ecosystem changes with the migration.
Of course, we think the easiest way to review the code and capture requirements is to automate the spec creation process with Caristix technology, including Caristix connectors.
Watch this space for more on the Integration Engine Migration Guide. It’ll walk you through:
- The key workflow steps you’ll encounter during a migration project
- Step-by-step recommendations for dealing with specific vendor technology
- Tips to improve team productivity effortlessly
