Moving Beyond RFPs for HL7 Interface Engine Selection
Proof of Concept Bake-Offs – the Ultimate Proof of Suitability?
“Do your homework to ensure you identify all the vendors who could potentially meet your needs.” A Request for Information (RFI) goes out. That’s the advice and usual start in the multi-step vendor selection process in selecting a HL7 interface engine solution. Next, a massive Request for Proposal (RFP) gets created. It’s a process that has been around in IT for more than 50 years and one that has become more and more counterproductive when looking for the right integration engine solution.
In the world of HL7 interface engines or middleware, every vendor uses the same buzz words – point & click, graphical IDE, drag & drop, high-availability, ease-of-use, rapid deployment, etc. As a search starts at the websites of the major vendors, you find all features and current marketing hype expected, PilotFish included. If there weren’t a company name interspersed throughout and different branding, it’s hard to know where you’ve landed.
Product demos too, are highly polished and designed to put a marketing spin on the product. The fact is – everyone looks and sounds pretty much the same these days. So how do you get to what really matters?
It’s true there are some differentiators that right off the bat may be crucial to the suitability of HL7 interface engine solution to an organization—primarily, differences when it comes to architecture and the technology stack. Solutions that utilize proprietary scripting or are built on an architecture based on a Unix framework do severely limit the resource pool for available developers to using only scarce specialized or experienced Unix coders. Alternatively, using a Microsoft stack burdens an organization with additional licensing costs and can offer questionable performance for ever-increasing healthcare loads. With these types of considerations aside (although significant), it becomes pretty difficult, if not impossible, to assess how well a solution “on paper” will fit an organization’s requirements in the real world.
R.I.P. for the RFP?
Unfortunately, RFPs often end up being more pro forma than revealing of the vendor’s suitability and ability to deliver on an organization’s requirements.
The entire process of drafting and evaluating an RFP can be arduous, time-consuming, and costly. Huge effort gets expended that typically results in RFPs with volumes of pages consisting of lots of requirements, most replicating the current industry marketing hype taken right out of vendor marketing materials. Even if a standard template is adapted in the interest of efficiency, it is also usually still a monstrous RFP consisting of boilerplate questions and checklists of features. Rating and evaluating these voluminous RFPs only adds extra unproductive time and work for selection teams in reviewing those responses without getting any closer to discovering what solution will really get the job done.
The trap for organizations is assuming that a complete superset of every possible feature and function reduces risk and guarantees suitability. Vendors usually figure out a way to answer “yes” to every question and “check off all the boxes” making the criteria only marginally useful. Critically, no matter what the quality of their responses, it’s all still “on paper” – words, not proof, of real-world performance or applicability.
What too often gets lost is that the purpose of selecting a vendor and a solution is to provide the end users with technical capabilities that solve a specific business issue. Ideally, the process should focus not on features, but on these specific capability requirements and determining the product with the right set of tools for meeting these requirements in real use cases scenarios.
So what works, practically speaking, as an alternative to an RFP?
Proof of Concept (POC) Bake-offs for a leaner more agile suitability determination
Ensuring that Proof of Concept is part of the selection process and moving faster to a Proof of Concept Bake-off is how solution providers (who are keenly aware that time itself is money) are achieving a more effective vendor match.
Proof of Concept (POC) Bake-offs that are structured using real-world use cases properly defined with specific requirements outlined and executed by experts in a vendor’s software are a nearly foolproof predictor of a positive outcome and ability to execute going forward.
For one, POC Bake-offs force an organization to clearly define its requirements and success criteria. Meeting those through the POC becomes a tangible and very measurable outcome.
Secondly, there are too many variables within an integration project for determining from an HL7 interface engine product’s feature set how easily or how well it can handle these variables. The POC makes it definitive as to how well a product actually fits the requirement.
Lastly, POCs well-defined and executed are the closest you can come to actually implementing a solution. That takes a great deal of the guesswork and risk out of the equation. They address how the vendor would bring value and competitive advantage as well as prove that the engagement would be successful along its journey.
It’s true that lots of organizations are still holding on to the old ways of doing things, but many are foregoing the RFP process while still rigorously evaluating vendor product capabilities and references in order to assess performance through a POC Bake-off. In this new Uber world of efficiency, the case for POC bake-offs vs traditional RFPs is pretty compelling and one we are happily seeing a lot more of.