John Traeger, Enterprise Systems Consultant at OTB Solutions outlines eight of the most common pitfalls why hospital HL7 interface engine selections fail.
Selecting an interface engine for your healthcare organization is no trivial matter. The decision you make will impact the reliability and flexibility of healthcare data delivery for years to come. Taking the necessary steps to ensure a good fit for your organization is essential to success. The following explores eight of the most common pitfalls that cause interface engines to fail.
Enterprise Systems Consultant at OTB Solutions
1. Not involving the right people at the beginning
Interface engine replacements are often considered merely plumbing changes, without taking time to identify and engage the right stakeholders. This short-sighted approach results in lackluster support and funding for a major initiative that is critical to the flow of data inside and outside the organization.
Involving the right people on the vendor selection team has a big influence on the success or failure of the selection process. An effective team must include a healthy combination of IT leadership, technical experts and business partners.
2. Incomplete or imprecise requirements used for the selection process
Clearly understanding the requirements will significantly increase the chance of management and developer buy-in at the end of the selection process. If these requirements are not carefully formed, they will have a negative impact on all of the work that follows. Common pitfalls include:
- Requirements that state how instead of what you want accomplish.
- Requirements that reflect the current state instead of the future state.Selection teams view options with technology biases instead of business realities.
- Selection criteria does not account for the skills of existing technical staff or for the cost of acquiring or outsourcing to access new skills.
- Enterprise context is missing.
- Requirements are biased.
3. RFI/RFQ doesn’t ask vendors the right questions
RFI/RFQs are frequently written without understanding the context within which the new interface engine will be placed. Consider the following:
- Interface environment
- Enterprise portfolio
- Organization’s IT guiding principles
- Cultural fit
- Organization’s decision-making process
A good balance of the following question types ensures a look at the offerings from multiple perspectives:
- Subjective – often relate to usability
- Objective – often binary yes/no questions
- Quantitative – can indicate capacity, performance, scalability, etc.
- Qualitative – typically about reliability, customer service, etc.
Relying too much on subjective questions may lead to a biased selection. Focus on questions that are relevant, effective and reflect the context of your organization.
4. RFI/RFQ is ignored by vendors
If the RFI/RFQ is incomplete or poorly written, vendors may not consider the organization as a serious prospect and may be slow or not respond at all. The more information they get that indicates the organization is serious about investing in a new interface engine, the more likely they’ll provide a prompt and thorough response. The RFI and cover letter should:
- Provide a clear business statement.
- Description of the organization’s business goals and timing
- Demonstrate you understand the scope and scale of an interface engine replacement.
- Organization size
- Interface team size and structure
- Number of applications
- Number of interfaces
- Average messages per day
- State at what level the initiative is funded and approved.
- Executive approval
- Capital funded
- Other
- Describe the selection process.
- Purpose of the RFI
- Demo, POC and RFP/RFQ phases
- Scoring process
- Projected timeline
Providing sufficient details about commitment of funds, organization buy-in and timing will elicit more interest and response from qualified vendors. Be clear and up front about your process timing and what you are expecting.
5. Not having a process defined for evaluating RFI/RFQ responses
If the selection team doesn’t have a clearly defined process for reviewing vendor responses to RFI/RFQs, then the process invariably takes too long, confuses vendor sales teams and can result in misguided vendor choice. To avoid this scenario, the team should have a scoring system in place before the vendor responses come in.
6. Insufficient effort on working with the vendor sales teams
A common mistake is failure to engage the vendor sales and technical teams to fully understand their product and how it might fit the organization’s needs. The selection team has to take the time to meet and score the responses. The team should also attend a presentation and demo from each of the top 3. The team should expect vendors to elaborate on the key elements from the RFI and should listen for new approaches to solving interface engine or business challenges.
Immediately following the presentations and demos, the team should do another round of scoring to get an accurate response while information is fresh. It is important to use the same core team of scorers for every vendor to maintain scoring consistency.
The top 2-3 vendors still in the running after the presentation and demos should be invited to an independent week for POC sessions where the team will perform hands-on work using the engine products. This will enable the team to vet at least some of their claims made during the sales demo and learn how the team adapts to the new tools and how their skill sets fits with the product. Yes, that’s right, three vendors = three separate weeks. Remember, this is a major investment for the team and organization. Both will have to live with the selection team’s choice for many years. It is critical you take the time to fully understand the products offered.
7. Underestimating the total cost of installation along with labor required to plan and execute migration onto the new engine
Another common mistake is to assume the vendor’s RFQ response is the cost you can use as a basis for funding decisions. Unfortunately, no, the calculations only start with each vendor’s RFP/RFQ response. The next step is to determine the other internal and external costs to bring the new interface engine online and migrate production interfaces onto it. Hardware purchase and installation will vary depending on vendor system requirements and the scope and scale of the interfaces in the organization. Development and implementation labor costs are less precise to calculate than hardware and installation. And, differences in labor costs between vendors can be dramatic and easily change the value propositions from each. Be sure to look at availability of labor and size of the learning curve for the technology being used by the vendor. Ignoring this can be a costly mistake.
8. Forgetting to socialize the selection within the organization
Most organizations have competing priorities for IT resources, even in calmer times. In our current era of ARRA, HIPAA, business consolidations and transformations, it is harder than ever to retain the commitment from leadership to provide the resources needed to follow through on implementing a new interface engine.
You need to draft a compelling scope document to drive home the importance of the new interface engine deployment. Be sure to highlight the dependencies all of the other major IT and business initiatives have on a reliable, agile interface engine for success.
Once started, make sure the project is visible with consistent status updates. Get an early win on an initial project.
Conclusion
The importance of “fit” cannot be overstated when selecting an interface engine for your organization. The future of healthcare is inextricably linked to the movement of data. Selecting the right engine will deliver improved reliability and flexibility. Engaging the right stakeholders to direct an effective selection process is the keystone for success. Second, understanding the context in which your new engine will perform is crucial to finding the right technology. And finally, once the selection decision is made, promoting the project within the organization will help secure resources required for successful implementation.
Related: Private HIEs and Interoperability: New Connections Demand New Approach
John Traeger is the Enterprise Solutions Consultant at OTB Solutions, a technology and management consulting firm based in Seattle, Washington.
