Select the Right EHR Vendor

Share This Post

Selecting the right Electronic Health Record (EHR vendor) can be tough. In addition to defining software requirements, you must also consider government regulations, costs, and certifications. Where to begin? We hope that the guide below allows you to tackle your EHR vendor selection and implementation project with confidence.

Elicit the top-level requirements first, then select a vendor using that level of detail. At the selection stage, do not try to dig into the details of how all individual processes are performed today. By staying high-level, you will force the selection team to focus on core capabilities instead of detailed design. Chances are, no system you are considering will implement all the capabilities the same way you currently do them in your organization. After the selection is made, work with the vendor to specify the detailed requirements necessary to configure and implement the solution, integrate it to existing systems, and customize, if necessary, to build missing functionality.

As you compare EHR vendor software, you will probably have to make some tough decisions. For example, let’s say you have 4 needed features. One EHR vendor may support features 1 through 3. Another vendor supports features 2 through 4. A decision maker on the project has to weigh all of the factors to make a choice between vendors, including things like: price to buy and implement each solution, price to build the missing feature in each case, cost of not having one of the features, or time to implement. But the reality of this situation is that someone may decide that feature 4 wasn’t really a requirement after all!

A proposed approach to selecting a vendor

Here is a sample process to follow to select a vendor:

  1. Define the high-level requirements. This may take the form of named use cases or features. Don’t forget to include certification as a requirement.
  2. Define the actors that will use the functionality.
  3. Specify more detailed requirements based on the highest risk areas.
  4. Research the marketplace to identify a list of potential vendors. This can be done by surveying SMEs, doing web research, talking with colleagues or using the Certified Health IT Product site to get a list of potential vendors.
  5. Verify that each potential vendor’s platform is certified, and what certifications they have, using the Certified Health IT Product list.
  6. Narrow the list of vendors down to the top three to five, based on how closely they match the requirements gathered.
  7. Have the vendors do high-level demos of their solution. Eliminate any vendors that do not seem to be a fit at this point.
  8. Create test cases using the requirements gathered to sufficiently demonstrate how each vendor measures against the requirements.
  9. Have the vendors demonstrate how their solution satisfies the detailed requirements, measured by execution of the test cases.
  10. Create a comparison matrix with each test case (and all other measurement criteria you care about) to directly compare the vendors.
  11. Gather information from the vendor, beyond just the functional capabilities.
    • Gather pricing data – licenses, support, installation, training, etc.
    • Ensure the vendor’s business operations are acceptable and meet security requirements and regulations.
    • Determine if their support structure is acceptable
    • Understand what their development roadmap looks like
    • Perform reference checks with colleague
    • Ask about an exit strategy. How easy is it to get data off the vendor’s system in the case that costs or your organization’s requirements change?
  12. Decision maker chooses a vendor.

Once a vendor is selected, the detailed requirements elicitation process should continue. Your detailed requirements should be focused on the scope dictated by the vendor you selected.

However, if there is an area in which there is a lot of flexibility in the vendor solution, you should specify that in more detail. Obviously if there is a gap between critical requirements and the solution the vendor provides, you need to go into greater depth on those requirements. Points of integration should be explored in detail.

It is worth noting that you will typically spend more time on updating existing processes to work with the vendor solution. Document existing processes, including the goal of each process, and work with the vendor to reproduce those processes in the new software. This not only allows you to elicit detailed requirements more easily, but also goes a long way to becoming comfortable with the solution you’ve selected.

More To Explore