5 Common mistakes when converting integration engine

I can relate to the insurance commercial on TV - "We know a thing or two because we have seen a thing or two." In my experience, I have seen a thing or two when organizations migrate systems, and while most of these apply to any system conversion, I want to apply them to migrating from one integration engine to another.

Lack of Standards - this can come in different forms. It can be no standards, undocumented standards, individual standards (I know, that is an oxymoron, but I have seen it!), unenforced standards, or the opposite of so many standards that productivity is hindered. Standards must be developed as a team, enforced by review or change control and provide benefit to productivity. Standards should be reviewed during a migration to determine what needs to be added, removed or modified.

Naming Conventions - You may be asking, "Isn't that included in standards?". The answer is yes, but I want to pull this one out specifically. This mistake has the biggest impact! I cannot tell you how many conversions I have been a part of where naming convention are either forgotten, not enforced, communicated or reviewed and the impact to the future state of the engine is chaos. I just came off an integration engine migration where this was missed, and the cleanup was costly in time, resources, and money. Naming conventions need to be applied to every part of the integration system where an engineer can name a component. It needs to be documented for everyone to follow and it must be enforced.

---

Virtual Sites - There are several integration engines like Ensemble and Cloverleaf that now allow you to have virtual sites. This allows you to organize your engine instead of one massive group of interfaces. While virtual sites can be a great asset, I have seen them also be a great determent if they are not organized.  You spend valuable time looking for interfaces.   I have seen them organized by hospital, interface types (ADT, ORM, etc.), and systems. Again, it needs to be documented and it must be enforced.

Migration Plans - I need to place a disclaimer on this one. Many organizations will migrate the integration engine as part of an EMR migration or during a merger/acquisition. The migration plans may be dictated by other projects going on. However, if you have the luxury of planning your own migration, you need to map out how you will migrate the interfaces. While the integration vendor will assist you with the setup of your integration engine, they do not necessarily help you with how to implement it. My personal recommendation is by interface types. Do all the ADTs in the first phase. They are the easiest to convert and it usually is the largest group of interfaces. After that, I recommend the results interfaces. Now you have most of the interfaces converted, you have experience with the new engine, and you can go after the more difficult interfaces like scheduling, orders, pharmacy, etc.

---

The Silo Affect - This has more to do with the culture of the team as it does the technology. Remove the silo effect of people working individually versus a team. I have walked into many organizations where they are working as a team. However, I have also walked into quite a few organizations where this does apply. You determine if this applies to your team. If you have people doing their own thing, and no one else has a clue of how their interfaces work, you have silos! Here is some suggestion to break the silos affect. 1) Determine all the standards as a team so that everyone as a say in them. 2) Determine a backup coverage for each area. The primary must train the secondary for times of vacations, LOA, or other emergencies. 3) Peer review for change control. This helps enforce the standards and can be as simple as a check off list. 4) If your organization has goals as part of their review, have at least one departmental goal that ties everyone together. It can be as simple as to review and document standards twice a year.

I have learned in my career that if you don't plan to go in a different direction, you will always end up in the same place. I have seen countless number of migrations where the end product was identical to the original system and the benefit of moving to a new platform was lost. For those who are looking at an integration engine migration, list out where you want to go during this migration and what the outcomes will be. Then execute your plan accordingly.