Lyniate Team

Comparing Interface Engines

April 1, 2017

Ecosystem Thinking Accelerates Innovation
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. 

I’m tainted. I’ve spent more than 20 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 by Lyniate 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.

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.


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.

Related Blogs

Lyniate Team

Smooth sailing to the cloud with a hybrid cloud approach  

As you chart a course toward digital transformation, a hybrid approach can help you avoid rough waters. By using both cloud and on-prem capabilities you’ll have the tools you need to stay afloat and safely navigate your cloud journey.

Read more

Lyniate Team

How does an EMPI work to improve patient outcomes and increase revenue?

With an enterprise person master index (EMPI), healthcare organizations can significantly reduce duplicate patient records and correct errors in patient demographic information.

Read more

Chandan Padmanna

How migrating your healthcare integrations to the cloud modernizes your infrastructure 

To benefit from cloud infrastructure modernization, consider how to migrate your healthcare data integrations to the cloud.

Read more