Migration Guide: From Oracle eGate to InterSystems Ensemble®

Migration Guide: eGate to Ensemble

Now available: Migration Guide: From Oracle eGate to InterSystems Ensemble®

Many hospital and health systems are being faced with major decisions and challenges concerning interface engine conversion and migration due to DataGate/eGate and eBiz hitting the end-of-life mark. Interface engines are responsible for the critical flow and orchestration of financial, administrative, and clinical data. Disrupting that data flow takes a high level of project organization. Even if an organization is not being forced to replace their interface engine due to expiration, the smartest organizations are working to expand their interoperability particularly with the increased capabilities of contemporary EHRs.

Our series of Migration Guides is based on recommendations designed to ease the pain of migration projects and looks at the role Caristix Workgroup software in facilitating the process while reducing costs and maintaining project timelines.

Developers commonly jump right into the code with incomplete requirements and a flawed knowledge of the data to be exchanged. Teams quickly run into problems with this reiterative trial and error loop. This chaos makes it impossible to predict project timelines and to guarantee complete coverage of issues before moving into production.

How do you fix those problems? We’re proposing a step by step approach to speed up eGate to Ensemble migration project execution throughout the five stages of interface engine migration:

    1. Gather interface requirements
    2. Setup the new interface
    3. Migrate the interface
    4. Validate the new interface
    5. Move into production

 

These workflow recommendations are scalable in terms of the number of interfaces addressed. We particularly focus on validation to increase overall team productivity and prevent reiterative break-fix repairs in final production. The recommended workflow remains valid even if you do not use the recommended tools and is applicable to migration to different integration engine technologies with some variance.

Download the Interface Engine Migration Guide: From Oracle eGate to InterSystems Ensemble®

Did you miss the first Migration Guide: From Oracle eGate to Orion Health Rhapsody Integration Engine?

Coming soon:

  • Interface Engine Migration Guide: From Oracle eGate to Microsoft BizTalk Integration Engine
  • Interface Engine Migration Guide: From Oracle eGate to Interfaceware Iguana Integration Engine

 

Migration Guide: From Oracle eGate to Orion Health Rhapsody Interface Engine

Inteface Engine Migration Guide

In a previous post, we talked about reducing migration project risks and some of the drivers in interface engine selection. In particular, with DataGate/eGate and eBiz at the end-of-life mark, many hospitals and health systems are faced with major conversion and migration decisions. The interface engines now in place are responsible for the critical flow and orchestration of financial, administrative, and clinical data. Disrupting current critical data flow to take on a migration project is challenging.  And the smartest organizations are working to expand their interoperability particularly with the increased capabilities of contemporary EHRs.

Here at Caristix, we’re developing a series of Migration Guides with recommendations to ease the pain of migration projects and to look at the role Caristix Workgroup software takes in facilitating the process while reducing costs and project timelines. Our first release is the Interface Engine Migration Guide: From Oracle eGate to Orion Health Rhapsody Integration Engine.

It’s common that developers jump right into the code with incomplete requirements and a flawed knowledge of the data to be exchanged. Teams quickly run into problems with this reiterative trial and error loop. It’s impossible to predict project timelines and to guarantee complete coverage of issues before moving an interface into production.

How do you fix those problems? We’re proposing a step by step approach to speed up eGate to Rhapsody migration project execution throughout the five stages of interface engine migration.

    1. Gather interface requirements
    2. Setup the new interface
    3. Migrate the interface
    4. Validate the new interface
    5. Move into production

These workflow recommendations are scalable in terms of the number of interfaces addressed. We particularly focus on validation to increase overall team productivity. The recommended workflow remains valid even if you do not use the recommended tools and is applicable to migration to different integration engine technologies with some variance.

Download the Interface Engine Migration Guide: From Oracle eGate to Orion Health Rhapsody Integration Engine

Watch for our other Migration Guides in the near future!

  • Interface Engine Migration Guide: From Oracle eGate to Intersystems Ensemble Integration Engine
  • Interface Engine Migration Guide: From Oracle eGate to Microsoft BizTalk Integration Engine
  • Interface Engine Migration Guide: From Oracle eGate to Interfaceware Iguana Integration Engine

Interface Engine Migration: Why Now?

90s Integration engine migrationIf 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

Interface Migration projects shouldn’t be disruptive

interface migration projects disruption
If you’re selecting a new interface engine, you know you’re in for some pain as the team migrates interfaces from the legacy engine to the new one. But with the right planning and the right interface migration tools, you can minimize disruption and ensure a smooth transition during interface migration projects.

Reducing migration cycle time

That being said, what if we told you that you can cut 90% of the time it takes to code the schema you’re migrating? Or reduce the time it takes to validate the new interface by 66%?

How believable would that be? You’d be right to be skeptical. But that’s exactly what this post explores.  And those are the real results our customers experience when they include Caristix technology in their migration ecosystem.

How to reduce disruption

Let’s start with the typical engine and interface migration process:

  • Start by manually determining and documenting the interface requirements.
  • Include any and all customizations to the vendor spec
  • Build the interface, usually through trial and error
  • Manually validate and test the new interface
  • Move into production

Because this process relies on eyeballing messages and counting pipes, it sticks your team with risk and rework – and disruption.

This is the kind of disruption that means downtime, extended go-lives, and drawn-out testing cycles. So integration managers and leadership get stuck with rising costs for contractors and outsourcing, so they have to trade off budget overruns against the risk of glitch-ridden, fragile interfaces.

But with the right technology in place, you can transform this process so you eliminate disruption and ensure a smooth transition, at a lower cost.

Our customers – including large IDNs – have seen significant reductions in time and cost during migration projects, including the numbers we mentioned above.

Migration workflows

The most effective migration teams don’t stick with the manual workflow described above. They work on incorporating interface management software (such as Workgroup and connectors from Caristix) in order to reduce risk and disruption. We’re now sharing their high-level processes as a series of brief migration workflows for the most common interface engines, including Sun eGate, Orion Rhapsody, Intersystems Ensemble, iNTERFACEWARE Iguana, Mirth Connect, and Microsoft BizTalk.

Contact us to learn more about these migration workflows and ask for our upcoming Migration One-pagers. They’ll walk you through the process of delivering migration projects faster and at lower cost.

Interface Engine Selection: Reducing Migration Risk

reducing migration riskNew interface selection: a big decision

Is your team selecting a new interface engine? If so, you’re in good company. With DataGate/eGate and eBiz at the end-of-life mark, many hospitals and health systems are faced with major conversion and migration decisions. The engines they have in place now are responsible for the flow and orchestration of financial, administrative, and clinical data. They can’t afford to disrupt their current capabilities. And the smartest organizations are working to expand their interoperability.

This leaves hospitals and IDNs with some major decisions. Which vendor should you go with? What should the selection committee look for? When you implement, what should you prioritize? The wrong decision can have a devastating impact on interoperability and how data flows – short-term and long-term.

Interface engine selection guidance

Which is why there is a lot of guidance out there on how to pick a new engine. One of the better resources we’ve come across (and it’s vendor-neutral) is a 37-page white paper from OTB Solutions, a consulting firm. The paper pays a lot of attention not just to technical requirements but also business requirements. And it offers great advice on communicating the selection and the accompanying change management. Download the OTB Solutions white paper on interface engine selection.

High risk: interface migration

One area we see a need to expand on: the actual migration process. It’s a risky process.  And depending on your needs, not all engine vendors are created equal here. You have to pay attention to documenting your needs and your requirements.

How do you reduce risk and cost?

When you’re purchasing a new interface engine, the biggest investment isn’t the engine software licensing or your incremental hardware costs. Your biggest line items will be the development and implementation time – labor costs. Look for solutions that will reduce complexity and development risk, and you’ll automatically impact cost.

Just as Agile methodologies have reduced project risk in software development, interface lifecycle management can reduce risk with interface development. And it starts with better requirements. Read this article on HL7 requirements to learn more.

Also, consider purpose-built software such as connectors and converters. You can automate the migration process by pulling messages and schemas directly from the legacy engine, and generate requirements, including specifications for new development easily. Learn more about interface conversion projects and connectors.

What are some ideas you’ve successfully used to overcome migration risk? Let us know in the comments.

Interface Conversion Projects and Connectors

Interface Conversion Projects: 10 or More Steps

What are connectors?

If you’ve ever worked on converting from a legacy interface engine to a new one, you know one thing: this is one complex project. With a lot of moving parts. You’re easily facing 10 or more different workflow steps — per interface.  The workflow can start with simply backing up the legacy production interface and can end with testing and deploying the new interface. But between Step 1 and 10, there is a lot of room for error and rework.

Documenting the legacy interface

After backup, you document the legacy interface. And that can be a chore. Some engine vendors simply state, “Open a text file.” Then you’re supposed to get a copy of the application specification from the application vendor (just bear in mind that the spec isn’t always available) and start reading to get a sense of which messages and content types are involved.

Was the spec fully implemented? No

Of course, you’ll also be aware that more often than not, the spec was either not fully implemented in the legacy interface or it was customized during implementation. So, with your text file still open and the specification on the screen, you have to go to the schema or definition in the old engine and start noting transformation rules, message structure, and message content including code sets.

Implement the new interface via trial and error

Once you’ve documented your interface, you’re supposed to re-read your notes. You then hunt through their HL7 standard library, and pick a schema that’s kind of close to your message structure. You start your coding based on this library schema.

Add more code and stir

Then you add transformations, routing, transport protocols.
And you’re meant to spend the next few days and weeks first, tweaking the schema, and second, coding until….

Then test

Finally you get to test. The testing is iterative. You test so you can check if your new interface comes close to matching the legacy interface.

What does this get you?

For all this work, you end up with:

  • Incomplete requirements. Incomplete documentation. And no way to really compare your legacy interface with the new one.
  • A lot of trial and error – especially since this whole process is manual. And that means you can end up introducing new errors with the click of a button. That’s the real slowdown.

There is a better way: automate conversions

With Caristix technology, you can automate and streamline this entire process. The technology that lets you do this is called a connector.

A connector lets you pull messages and schemas directly from the legacy interface engine into the Caristix platform, where you can generate a specification (what we call a profile) automatically. Some Caristix connectors can also extract the transformation and mapping code.

Using a connector for your new interface engine, you can generate a schema to import directly into the engine, saving multiple trial-and-error cycles.

The connector and platform also let you automate your requirements gathering. Learn more about HL7 requirements in this post.

As an add-on to Caristix Workgroup and other Caristix products, this technology can save an analyst hours during a conversion project and streamline the entire process. An IDN organization with 80 hospitals used Caristix connector technology on a major 1000+ interface conversion project. They saved 18 hours per interface – which multiplied out to millions in project savings. Interface conversion projects and connectors are an effective solution to the trial-and-error approach.

Connectors map

Connectors and interface assets

Learn more about Caristix connectors, including the engines we support.  And contact us for a demo