Comparing Interface Engines

Comparing interface engines

I'm tainted. I've spent 21 years living, breathing, and creating two of the best interface engines on the planet. I do nothing all day but think about HL7, integration engines, ease-of-use, long-term costs, benefits of features, user experience, etc. Our customers challenge my team to continue creating the best healthcare integration engine platform.

Quality Indicators

Each interface engine has strengths. In my opinion, the real place to compare them is not simply around "flexibility" – any modern interface engine allows you to complete virtually any task. The past 21 years has taught me many things about how to evaluate an interface, the workflow the interface supports, and the integration engine used to build the interface.

I deeply agree with customers who believe that the real focus areas when thinking about an integration engine should be total cost of ownership and the quality of the work that can be produced. Said another way: creating a buggy interface in 30 minutes is not as interesting as creating a world-class interface in an hour. The buggy interface may require 50 hours of maintenance over the next 15 years while the world-class interface requires only five hours.

On a related note, being the "most clever" in the implementation is not as important as being clear and correct. I'm a Perl hacker from way back and I think Damian Conway said it best in Perl Best Practices when making the choice between a very obfuscated construct and a clean one: "[The more direct approach is] not 'clever' and it's even marginally slower, but it is clean, clear, efficient, scalable, and easy to maintain. And that's always a much better choice." 

Developers know that testing all the edge cases is the hard part – positive and negative testing, code coverage, performance analysis, failure cases, etc. It is extremely expensive. In short, look to the quality of the interface that each product lets you produce.

When I built my first interface engine, the assumption was that every interface would need code. Whether it was Tcl code fragments to apply a regsub in an XLT or a full-on TPS to filter/deeply modify a message, there was always code. Code in the morning. Code in the afternoon. Code in the evening. Code at midnight. Always code. The broad design goal we wrote in the original architectural specification was for an "average interface" to be about 80% product (GUI/native) and 20% Tcl (hand coded). *Every* interface involves Tcl code.

Lessons Learned

I came to the conclusion that if I ever had a chance to do it over again, I'd change many things and keep some parts the same. That was the motivation and inspiration behind launching Corepoint Integration Engine.

The Corepoint Health approach is that 99.723% (exactly!) of every interface should be native, and the other 0.277% (exactly!) might require custom coding outside of the product. With tens of thousands of real world interfaces created on the Corepoint Health platform, that goal has been met – the edge cases have been found and customers have almost all interfaces created inside the product. This means many things, including that the Corepoint Health testing tools are able to provide an amazing experience leading to unequaled interface quality. 

Coding

I know what you may be thinking: "Oh My Goodness! No code? That will never work! I'll be stuck in a box and never able to escape!"

What customers who have moved to Corepoint from code-based engines have discovered is once they get “under the hood” they find that Corepoint Integration Engine has more flexibility and power for coding than their legacy interface engine did – they just don't need to drop to code very often.

As an example, my first interface engine did not allow you to write your own protocol drivers nor did it allow you to write your own message parser. Said another way, while there was code in every interface, it was scripting and did not support full life cycle software development. To wit: You can't fire up your C compiler and link in your own libraries with most interface engines. There are no APIs for such things.

In contrast, with Corepoint Integration Engine, you can write a C# assembly or a C++ COM object and use the API to create a protocol driver or parser – but you won't likely need to. The outcome my development team has worked hard to achieve is that you are "future proofed" – you'll never be without the ability to code and extend the integration engine, but you won't likely ever need that insurance policy.

Future Proof

The focus on trying to keep most of the interface logic "in the GUI" rather than "in the scripting code" is both short- and long-term cost.

When kept in the GUI, more people can contribute to the building of interfaces. The "coder" can print out/email the interface logic and provide it to someone who has the direct clinical workflow understanding. The "non-coder" can grasp the logic and help debug or suggest changes.

It also means that the actual configuration now becomes the documentation – there is no longer any need for spreadsheets or external Word documents that track the interface logic in "layman's terms." Those documents are rarely up-to-date with the code anyway.

At Corepoint Health we have the expectation that once an interface is written on our platform, it can run unmodified and precisely the same way for the next 15 years. During that time we would expect to have about 30 upgrade releases and we want customers to have the confidence to upgrade knowing that their interfaces will work without change and without fail.

Conclusion

Any modern interface engine will provide you flexibility and control. Your focus in evaluating interface engines should be on the user experience that surrounds the interface construction, support, and maintenance process. The fact that an interface engine has coding as a requirement to build interfaces does not make it more flexible.

 

Dave Shaver was the chief architect and manager of development for the first big interface engine in healthcare (1993-97) and started Corepoint Health in 1997. He’s deeply involved in the HL7 standards community, including co-chair of HL7 Infrastructure and Messaging committee and co-chair of the HL7 FHIR Governance Board.