How to select the right EMR Software Vendor? - a Provider perspective

During a product demo for a Middle Eastern prospect I was intrigued with the meticulous preparation that they had done to rate us as an EMR software vendor and this article summarizes the steps that I have learnt from the experience, which are absolutely critical from a Healthcare IT Solutions provider’s perspective.

Implementing any EMR Software Solution, organization-wide calls for a massive re-engineering effort, considering that it revolutionizes the paper based operational and clinical processes to a digitized workflow. Selecting the right vendor is hence a vital decision that cannot be taken by just a few people at the top of an organogram and needs to be made jointly by involving stakeholders from each process in an informed manner.

1) Defining the Organizational needs: With several hundreds of EMR software vendors offering clinical and operational modules in different variations – the first step is to identify the organizational needs. This will enable the organization to identify what are its specific needs and not be influenced by vendors which claim to have implemented their product for a competitor or for another organization which may have had other prioritized needs.
Is it to store medical records electronically? Is it to automate the financial workflows and reduce revenue leakage? Is it to bring transparency into the information flow and integrate departments seamlessly? Is it to improve the inventory control of items, control pilferage and reduce medication errors? Is it to be technology savvy and provide hand held devices to all the staff?
These needs may be brainstormed across departments and a prioritized list created to differentiate what are the real, perceptual and desirable needs. You can probably go by a scale of P1, P2, P3, P4 and P5. P1 being the most critical to P5 being a desirable to-do item for the future. HIMSS (Health Information and Management Systems Society) recommends that you define an EMR Mission Statement highlighting your prioritized needs.

2) A scorecard of functional requirements: Once the prioritized list of needs is created, a scorecard can be made which would help each functional team differentiate its area of needs. 1 could be Technical Aspects, 2 – Patient Management Related, 3 – Clinical, 4 – Department wise functions, such as Diagnostics, Laboratory, Blood Bank, PACS, CSSD etc, 5 – Revenue Cycle related, 6 – Financial Accounting, 7 – Other Misc Management Related.
A page of instructions can also be given to each demo-participant to define how to score a vendor on a scale of say 1-3 or 1-5. But it should be clearly defined what each scale accurately means, such as a scale of 0-3 could mean 0 – not supported, 1- Supported via Customization (changes to source code), 2- Supported via modifications (screen configurations, reports, GUI tailoring etc), 3- Supported as delivered “out-of-box”.
The key is that all vendors must be evaluated against the same list.

3) Vendor research: Do a market survey on vendor wise product offerings available in the market. Some vendors can be directly eliminated if they do not qualify technically, do not have a specific module offering or do not have an established market presence etc. Depending on whether you are looking at using open source technology based vendors, can help bring down the total cost of ownership of the product. Also a criterion to look out for is whether they are web based and are scalable as per your organizational needs. Attending conferences, skimming through Healthcare magazines and searching the Internet will help identify potential vendors. Talking to colleagues will also throw light on vendors that are in the market. Some colleagues may also have an insight or two about vendors or EMR products they may have worked with in the past. Visiting offices of EMR vendors can help you understand their product and project management expertise better, maturity of the product, years in business, road map of the EMR for future development, total number of live installations, lessons learnt from implementations etc.
Consider floating an RFP (Request for Proposal) in the market. This will enable the vendors to understand your organizational needs better and the vendor response will allow you a chance to understand their product and evaluate their fit for the organization. Reviewing the RFP will also help short-list those vendors whose product demonstrations you would like to see.

4) Arrange a Product Demonstration: After short-listing the vendors which qualify as a perceivable organizational fit, invite the vendors to show case the product to your functional teams. The product demonstrations may ideally be done at your organizational premises to ensure minimal communication barriers but some vendors who are unable to travel exclusively for the demonstration may opt to do it remotely over the internet.
It would be ideal to share the expected work-flow of processes or frame out-patient or admission to discharge scenarios in the form of flow-charts with the vendor prior to scheduling the demonstration date to ensure the presenter sticks to the expected work-flow.

Ensure that the product demonstrations follow basic guidelines to ensure a productive and effective vendor analysis:

• Ensure that there are no communication barriers such as - mobile devices are placed in silent mode, muting the line if you are not an active speaker, testing microphone and speakers well before the demo start time, taking enough print outs of the evaluation forms for the participants, ensuring that the participants spend a dedicated time to evaluate the product and do not have other cross-priorities etc.
• Plan on spending at least 2 hours with the vendor for the demo and discussions.
• Make sure that the cross functional teams are made available during the full length of the relevant module-wise demo such as, those knowledgeable about billing, insurance, clinical staff, coders, technicians, pharmacists to help you evaluate the product.
• Use the pre-defined scorecard for evaluation based on the evaluation scale and make notes where necessary.
• Proactively notify the presenter to show what the team wants to see and ensure he is on track.

5) The price to pay!

Costs associated with an EMR falls under the following categories:

• Hardware: ask the software vendor what the technical infrastructure requirements are to run the EMR application. Does the EMR vendor run on licensed or open-source platforms? Is there a SaaS / cloud based / local server based model? Is the Operating Systems Linux or Windows based for the server and for end-users? Are there separate application and database servers required? What is the load expected to be on the servers considering the number of concurrent users per day? Where is the cloud server-hosted and what is the database backup policy?
• Software: What is the license fee for the software, is it based on the number of users? Is there a cloud or SaaS model based pricing per user?
• Implementation and training: Typically the provider has to bear the implementation and training costs, for bringing a vendor support executive/s to the office to do the requirements study, train, retrain and support the users of the application. This is usually a one-time fee during the initial stage of implementation which takes place over weeks/months.
• Support Personnel costs: You may need an project manager hired externally or nominated internally, a systems engineer to help with the wiring and LAN setup of the premises. What is the cost If the vendor’s support personnel is hired for additional training and support per day/month?
• Maintenance costs: Most EMR vendors charge anywhere between 15-25% of the software license cost on an annual basis from the start of the use of the application. This includes free software version upgrades, change management; patch releases, on-line support calls etc.

Calculate the Total cost of ownership considering the best, most probable and worst case scenarios incurred considering the above categories of cost.
Lastly, consider site visits of live implementations and interact with them to learn how you can learn from their experience and not repeat those same project/product related errors. Being proactive is always cheaper than being reactive.