By Janice Ahlstrom, RN, BSN, CPHIMS, Partner; Kurt Hahlbeck, Partner; and Scott Owens, PMP – Wipfli LLP
The selection of electronic medical record (EMR/EHR) or other enterprise application software is one of the most important decisions a health care organization will make. New application software that is responsible for clinical, patient, operational, and financial information will have a huge impact on the organization and its clinicians. Besides the financial investment, which is likely to be in the hundreds of thousands or millions of dollars, a well-implemented system will change workflow (business processes) of physicians, nurses, ancillary staff, and management. With an implementation timeline that typically stretches over 18 to 24 months for an enterprise system and a useful system life that can span 7 to 15 years, the collective impact on an organization is far from trivial. This is why it is so important to make sure the decisions about selecting an enterprise system are made carefully.
Research suggests that organizations that invest in a methodical selection process significantly reduce the risk of common issues, such as lack of critical software functionality, lack of clinician buy-in, missed deadlines, budget overages, and the failure to achieve business goals. A disciplined approach can provide objective analysis regarding the differences between solutions and their fit to your organization’s requirements and can help determine the feasibility of various options. It aids in separating the emotion from the real substance of a solution to ensure that sound decisions will be made. A reasonable rule of thumb for this selection process is to budget 10%-20% of the cost of the implementation to selecting the solution. This approach is geared toward system selection in larger health care organizations. However, the approach can be tailored to fit smaller organizations by focusing on a smaller vendor pool. The approach is flexible and components of it may occur in parallel during the selection effort. Advanced practitioners leading system selection efforts can fine-tune the approach based on the organization’s decision-making style and understanding of how much information is needed to make decisions. Variables that will influence decision making include organizational risk tolerance, cost, and time to market.
The software selection process is trying to answer five basic questions for your organization:
1. Define requirements — “What do we need? What do we want?”
In order to identify and evaluate appropriate solutions, you must have an understanding of what your needs and wants are. Functions and features of sexy technology are irrelevant if they have no bearing on the business issues or objectives you are trying to address.
2. Identify constraints — “What do we already have?”
In a perfect world, you get to start with a clean slate and no baggage to carry. Oftentimes, however, we are not afforded the opportunity to start from scratch. Existing investments in hardware, software, or
skills may have to be leveraged because the investment capital
simply is not available to discard existing assets.
3. Evaluate options — “What can we get?”
There is usually more than one category of solutions to a problem and, frequently, more than one choice within a solution category. Identifying and prioritizing requirements and constraints help to narrow the seemingly endless number of choices.
4. Develop budget and plan — “What will it cost, who will do it, how will it be done, and how long will it take?”
The goal of a software selection process is not just to pick a solution. That is only a part of it. The second major reason for going through the selection process is to understand the costs, the players, the process, and the time frames involved in the implementation. It should not always be a foregone conclusion that just because the solution is identified, it is worth making the investment. It’s important to remember that the technology solution is only a part of the total cost involved in an implementation project. Expenses related to people (training and external resource utilization) and processes (process design or process improvement) can oftentimes cost more than the technology itself.
5. Evaluate benefit — “What are we going to get for this
The other major reason for going through a software selection process is to make sure there is justification for making the investment. In other words, define your criteria for success, define how you will measure and monitor success, and then perform the measurement. If you don’t define ahead of time what you are expecting to get in return for the investment, how will you know it was worthwhile? The following steps can guide an organization through the process of making sure the solution it selects is the right one.
Build the business case
The first and perhaps the most important step in the process is to secure full support from all the stakeholders in the organization in order to understand organizational readiness. Stakeholders include individuals inside and outside the organization who are responsible for strategic, medical practice, clinical, operational, and financial functions. Without proper support from the community of users, a project of this magnitude is likely to be compromised. There must be clarification, understanding, agreement, and alignment of organizational objectives and priorities. The business case obviously needs the support of tangible goals and true business issues (clinical and non-clinical) that will be addressed by the final solution.
Common business reasons for embarking on an enterprise
EMR/EHR software selection project may include the following:
- Implementation of particular functionality, such as an EMR to support patient care delivery documentation and storage of a longitudinal record of care, support for billing, and enterprise reporting of care outcomes
- Implementation to assist in meeting standards of care documentation and legislated HIPAA requirements
- Implementation of technology to improve productivity, such as wireless devices for patient data entry
- Implementation of an EMR and bar code medication administration to reduce medical errors and improve patient safety
- Integration of multiple systems, clinical databases, and organizational constituents to allow more effective data collection, analysis, and reporting
- Reduction of operating costs by replacement of an outdated technology platform or application software
- Acquisition or creation of new business units/practices or service lines
Once the business drivers have been identified and documented, the solution framework can begin to be developed. The business case should review all organizational areas and processes that are likely to be affected and evaluate the impact of the potential solution.
Finally, the business case needs the support of the stakeholders. Once a high-level plan is determined, it is wise to obtain stakeholder “sign-off” for the project team to move forward.
Financial analysis and budget
Financial analysis should look at the return on the investment; it is sometimes difficult to quantify hard dollars of return on implementation of electronic records or other enterprise systems. Most now concede that implementation of an EMR in a health care enterprise is part of the cost of doing business. Increasing reporting requirements to CMS, quality organizations, management and reporting of care outcome data, and pay-for-performance initiatives make a strong case for electronic documentation, versus the time and effort to conduct retrospective chart audits to ascertain such information.
There must be clearly defined measures of success for the software selection and implementation effort to determine if the organization has been successful in the project endeavor and, ultimately, in meeting the business objectives for the effort. A clear understanding of the budget and budget requirements for a software selection and implementation effort, the cost of the selection effort, application software costs, and implementation costs is vital to understanding the total cost of ownership for the enterprise system selected. Your organization must understand through the software selection process both the fit of the solution with your organizational requirements and the feasibility of the solution selected, given budget and other constraints identified in the selection process.
Document the processes
As you begin documenting processes within a system selection project, you should ask, “What are the motivations for making the selection effort?” You can choose to focus process documentation primarily on those areas. Process documentation is the creation of current-state, or “as is,” process flows. Documenting all the stages of a particular function, such as patient admission and scheduling, will validate who is responsible for which steps, which forms or reports are used, the timing of each component, and the interrelationships between process steps and organizational departments. In addition, process documentation also helps prepare the organization for upcoming changes and identifies process gaps or inefficiencies.
Current-state process flows developed in the system selection process are used as a starting point in developing future-state process flows. The future-state flows document the functional processes your organization envisions to be the ideal state in the future. Often, the future-state envisioned can’t be achieved, given software limitations, physical space considerations, cost, and other variables. With selection of a software application, the current functionality is known, and this becomes the basis for your go-live, or reality-state, process flows. The reality-state flows document the functional processes with the integration of your new application software.
Documented reality-state flows provide the opportunity for in-depth analysis of process modifications required and can be used to educate end users in conjunction with application software training. Reality-state process flows can then be compared to the envisioned future-state flows for gap analysis. The information gained from this analysis becomes the basis for ongoing dialog with your vendor to understand the path to the future state your organization desires.
Gather and prioritize requirements
In any given industry sector, there are likely to be dozens, if not hundreds, of potential solutions. In health care, we have no fewer than 250 EMR vendors to select from. How do you know which one or combination of vendors is the right fit for your organization? When you buy a car, you don’t just show up at the dealer and take the first one you see. You more than likely already know that you are looking for a minivan versus a two-seat sports car because you have thought through the requirements. These may include the number of people in your family, how the vehicle will be used, etc. And, you typically prioritize these requirements.
You aren’t likely to choose a car because it is red if you can’t get the trailer hitch you need to pull your boat. Clearly, there are options that fall into the “nice to have” category, like cup holders in every seat, but this is probably not high on your list. You may decide to pass on the dealer-installed pinstripes in favor of adding this feature yourself at a more reasonable price. All of these items make up your prioritized requirements list. Selecting enterprise EMR/EHR software solutions is considerably more complex than buying a car, but there are many similarities in the processes. The best approach is to document all the requirements. Typically, this begins with interviews of the stakeholders (hospital and/or clinic and departmental leadership) and clinical end users. The list of requirements should be developed with a cross-functional team and should cover all the business functions identified in the business case, as well as supporting functions. For example, there may not be a business requirement that the system run on the Windows Server platform, but from a technical standpoint, if the organization has standardized on Windows Server rather than UNIX, this is likely to become a requirement from the technical side. There may be other requirements that are generated around security, compliance, reporting, and other supporting functions. This is a significant but necessary exercise because research indicates that one of the leading causes of project failure for system implementations is poorly defined requirements. Good requirements answer the question of “what” is needed, versus “how” the requirements should be met.
Requirements are organized by function and prioritized. Some will be “must haves” or “show stoppers,” others will be important, others will be “nice to have.” Requirements will also be assigned to a project team member who will be responsible for validating that the future solution meets the requirements.
From the master list of requirements, a subset of high-level requirements should be developed. This list will contain all the “show stoppers” and will be used in the next step of reviewing alternatives and solutions.
Research alternatives and create solution short list
Once the complete requirements list has been approved, research should commence to identify a short list (usually two to four) of potential solutions. The research exercise should review dozens of possible alternatives, and based on a high-level set of the requirements, the short list of solutions will rise to the top, filtering only those that are viable possibilities. Methods of research will include the following:
- Conversations with organizations that have implemented similar solutions.
- Reports and insight from industry organizations such as HIMSS, CCHIT, AICPA, and PMI.
- Reports and insight from research organizations such as Gartner, Forrester, and Yankee.
- Reports and insight from consulting organizations that work with similar solutions.
- Vendor websites.
- Review of KLAS ratings of the vendor application software, vendor implementation, and customer service capabilities provided by technology and consulting professionals in the industry who have implemented the various solutions.
All research should be well documented for review by the team. The final product of this phase is the selection of the short list of solutions.
Information will need to be gathered from the vendors on the short list. The vendor information request is a very important compilation of information. It is intended to provide the vendors with an understanding of the organization’s needs so they can effectively demonstrate their solutions. The information requests should include the following items:
- Full, prioritized requirements list.
- Scripted scenarios (use-cases) — Particular process flows that map out a “day in the life” so the vendor can show the selection team how its solution works for certain functions. These scripts can be extremely detailed and will incorporate your specific needs. An example may be as follows: Show how Medicare claims are electronically filed and how claim payments are reconciled against patient accounts.
- Demo data — In some cases, it may be useful to provide the vendor with some of your real data so the demonstration is more relevant. This data must be de-identified to shield protected health information (PHI) in conjunction with HIPAA requirements.
- Process flows — Providing process flows may help the vendor understand your unique environment.
- Details regarding the selection process, evaluation criteria, and timing of decisions.
- Confidentiality agreement — The vendor should be required to sign an agreement that requires it to treat all information provided in the information request or during on-site demonstrations in complete confidence.
This set of documents will be sent to each vendor several weeks in advance of their on-site demonstration visit, and the vendor should return its respective responses to the project team in advance of the scheduled date.
Conduct vendor demonstrations
To prepare for the on-site vendor demonstrations of their solutions, an agenda should be created that outlines the plan for the visit. Vendors will want to share a canned sales demo that highlights what they see as their solutions’ best facets. While there is some value in this, these presentations are packed with marketing flash and aren’t designed to talk about your specific business issues. It is important that this portion of the demo consume only a small percentage of the designated time. The other time should be managed with a series of scripted scenarios or “use-cases.” These scenarios are where most of the requirements validation will occur.
Throughout the demonstrations, a facilitator should be monitoring the time to make sure the entire agenda is addressed. In addition, this facilitator will be scoring the vendor responses to each requirement. Standard scoring awards points to responses on a sliding scale. The following list is rated from higher points to lower points:
• Solution fully meets requirement with the vendor’s “off the shelf” product.
• Solution fully meets requirement with custom configuration (drop-down lists, security options, etc.).
• Solution meets requirement with additional prepackaged integrated modules.
• Solution would require custom development to meet requirement.
• Vendor cannot meet the requirement (no points awarded).
After the conclusion of the vendor demonstrations, scores are tabulated according to the vendors’ ability to meet the prioritized requirements. Each solution will receive an objective score. The solution that is capable of providing the best fit is likely to score between 85% and 90%. It is highly unlikely that a single vendor can meet 100% of your requirements. It is important to remember that scoring is not absolute, but rather directional. When vendor scores are very close, dialog will be required to understand other variables that may sway the decision in one direction or another. An example may be that one vendor is local while the other is not.
Perform a gap analysis
If the best solution provides 90% of your needs, how do you close the gap to 100%? The project team needs to analyze this gap in order to make sure the project expectations are correctly aligned. In some cases, changing a process to better work with a solution is the right answer. Sometimes it may require adding another software package. The team may also decide to postpone some functionality to a later implementation phase.
The project team will use the scoring results and the gap analysis to identify the solution to best meet the needs of the organization. An important final step in the selection process is to understand the feasibility of the preferred solution. Contract negotiations are executed to identify implementation timelines, resource availability, and prices for software, hardware, and vendor/consulting resources for the implementation. Furthermore, the skills and effort required on an ongoing basis to support and maintain the application system need to be understood. This information allows for the development of the implementation project plan and budget. Information gathered in the contract negotiation process provides knowledge of the total cost of ownership for the enterprise application software. This understanding provides the basis upon which to know if the solution is feasible for your organization.
- Expectations – Sharing the same expectations for vision, objectives, and action outcome.
- Acceptance – Understanding and embracing the process, the options, and the recommendations.
- Resources – Having the right skills and knowledge available at the right times.
- Integration – Understanding the potential integration points and the “quality” of the information.
Managing the process
Selecting an enterprise EMR/EHR software package is not a trivial undertaking. There are considerable risks inherent in the decisions at hand, and the impact of making a poor decision can be felt for many years. One way to reduce your risk is to partner with an independent consulting firm that routinely manages the selection process for similar organizations. These consulting firms generally know the vendors and the likely solutions. They can also provide a structured, disciplined approach that keeps the process on track and reduces the uncertainty and subjectivity that can lead to a bad decision.
About the Authors
Janice Ahlstrom, CPHIMS, RN, BSN, is a partner in Wipfli’s health care practice. She has over 28 years of experience in the health care selecting, implementing and integrating enterprise information systems. She has helped a variety of organizations develop technology strategies, implement EMR applications, define business processes, enact operational performance improvements, and implement information systems. Contact Janice at 414.431.9352 or email her at email@example.com.
Kurt Hahlbeck is a partner in Wipfli’s consulting practice. He has extensive experience with helping organizations leverage technology investments to drive business value. Kurt focuses not only on the technology, but also on the related people and process components necessary to ensure utilization as well as aligning to the organizational strategies to ensure relevance.
Scott Owens, PMP, provides project management, business continuity planning, and management consulting services to health care organizations, helping them meet their business and technology objectives. A certified Project Management Professional, Scott specializes in the identification and management of initiatives that will reduce business risk and add value through more efficient processes and controls.
About Wipfli LLP
With more than 800 associates and 15 offices across the Midwest, Wipfli ranks among the largest accounting and business consulting firms in the nation. Serving businesses and individuals since the firm’s start in 1930, Wipfli has one of the region’s strongest health care practices, with an extensive list of clients across the Midwest. For more information, visit www.wipfli.com.