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 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.
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.
