Going Shopping?

Steps to EHR Success: a Best-practices approach

By Michael Uretz

ongratulations. You’ve finally decided to go for it! You’ve tried for two years to convince yourself that your practice was running just fine without an EHR system, that there was no substitute for a successful status quo and that maybe, if you just waited a while, EHR systems would get more affordable and easier to use. Of course, it also took you five years to pop for that first PC because you were convinced that it would be better to wait.

But, it appears that the writing is on the wall. For many reasons not in the scope of this article, it became apparent that this was one time you didn’t want to be left behind in a technological void. So, now you’re a willing participant in your own EHR adoption. But what comes next?

As I travel the country speaking on EHR best practices at conferences and symposia, I am fortunate to have met physicians willing to share their concerns, worries, apprehensions and their personal stories. Most concerns boil down to:

• How do I choose the right vendor?
• How do I get the best price?
• How do I get a fair contract that represents my interests?
• How do I make sure that I get the follow-up support I need?
• How do I choose the right vendor?

You could spend hundreds of dollars at Starbucks on triple-shot espressos while surfing the Internet late at night, reading opinions, comments and testimonials, hoping that one vendor will rise to the top. Or, you could buy your colleagues numerous expensive lunches in exchange for their thoughts and opinions. Or, you could have each of the 50 vendors you’re considering buy you lunch and get brain overload trying to absorb the 100-200 features being explained to you during your one-hour meals.

Or, as the British say, you could do it “properly” and let the vendors do a lot of the work for you with a nice little tool known as a Request for Proposal (or Request for Quote if you prefer). Because of the work involved from the vendor side in answering an RFP, this can give you an idea of who is willing to work with you, develop a partnership and address your needs. This document can consist of a number of elements, but at a minimum it should have:

• A vendor profile consisting of a laundry list of quantitative measures such as customer base, staff breakdown (R&D, support, etc.), support set-up, product maturity, etc;
• EHR feature requirements that interest you broken into a matrix of “must-have” and “desirable-but-not-essential” features;
• Hardware and infrastructure requirements;
• A quotation covering vendor products and services.

RFPs are important because they can communicate needs and expectations, provide for a side-by-side feature comparison and give you a complete vendor profile to help you choose. RFPs also document vendor commitments and promises the vendors make along the way. And, best of all, it doesn’t cost you anything at this point, except some “sweat equity.”

Vendor Soft Skills

So far, we’ve got the quantitative aspects of choosing a vendor covered. Now, let’s try an exercise. Think about when you were purchasing a big-ticket item and how much the salesperson’s interpersonal skills played in the decision.

After all, you will be developing a partnership with this vendor, possibly long-term, and there are certain traits to look for when interviewing perspective vendors:

• Ability to listen closely to your needs;
• A desire to understand, which is exhibited by asking questions; and
• An offering of different ideas and options to solve your problems.
• Most of all, you need a vendor who shares an enthusiasm and cares about your success.

Conversely, there are certain interpersonal skills or traits that I call vendor “red flags.” If the vendor exhibits these during your interview, politely excuse yourself. Be wary of vendors who tend to have a one sided conversation, discussing solutions before they even understand your needs. You kind of feel they are in “sell mode” all the time. Also, the liberal use of technical jargon to impress or confuse is a red flag. Finally, watch out for promises by vendors of great features to come, which might not materialize. These are known in the industry as “vaporware.”

At the end of the day, choosing your vendor turns out to be a combination of both quantifiable due diligence and personal gut feel.

How do I get the best price?

Let’s face it, nobody wants to feel that they paid full price while somebody else got a discount. However, caveat emptor, as this e-mail from a concerned physician warns. In fact, you might have run across the following unfortunate “used car scenario” yourself:

“I was told that an almost 60-percent discount was only available through Friday (this was on a Thursday afternoon) since a training session was beginning on Friday. I won’t be pressured into anything.”

Obviously, situations like these should put up a red flag, whereas the following physician e-mail deals with more of a win-win pricing negotiation:

“The bottom line is that everything is negotiable … You have to find what your leverage is in negotiations. When I was involved negotiating with [a vendor], they were very interested in breaking into the medium-size practice market and it was end of fourth quarter. We were able to get substantial discounts.”

Having personal experience as both a software purchaser and a vendor, I’ve been on both sides of this equation and I can tell you that the above e-mail speaks to the win-win nature of successful price negotiations. You can try to bully the vendor into accepting your terms, but my experience has shown me that you can be much more successful with a partnership approach.

If you try to understand your vendor’s situation and needs, many times there will be reason for your vendor to give you good pricing. The case above points out that the vendor was fairly new to the market and wanted to build up a customer base. Also, the timing was right and the vendor wanted to hit a certain sales quota. Maybe you’re willing to act as a beta site for their product and give them feedback or you could be a great referral site for potential customers. Get to know your vendor and ask them how you could help their efforts. That type of relationship is worth something.

How do I get a fair contract that represents my interests?

From the consulting and speaking engagements I’ve had, I’m convinced that EHR contracts is an area of great concern and apprehension to physicians and practice managers. The following e-mail outlines this:

“My question is whether anyone out there has suggestions on negotiating the fine points on a contract. Our biggest concern is that the contract only deals with our obligations ... nothing about their guarantee about service and functionality.”

After over 20 years of negotiating software contracts and support agreements myself, when I began looking at EHR contracts, I noticed that, on face value, they were fairly one-sided. This makes sense though. The vendor needs to look for maximum protection.

On the other hand, even if you’re a small or medium practice, you have as much right as a large practice or health care system to look out for your own interests. And, in fact, a bad contract can, in some cases, hurt a small to medium practice more because they don’t have the resources to absorb problems that can occur.

However, for whatever reason, practices don’t necessarily go out and hire an experienced software attorney to review and negotiate their EHR contracts and support agreements. So, they go it alone.

If you do decide to negotiate the contract yourself or have your general practice attorney get involved, I have put together some examples of contract areas to start thinking about. Please note that this discussion touches on a limited number of contract clauses and is neither exhaustive nor complete.

License Types

For the most part, you will run across two types of licenses specified in EHR contracts — concurrent licenses or provider licenses, sometimes referred to as “named user.” There are other license structures, but we will focus on these.

In general, a concurrent license lets you use a specified number of workstations simultaneously. For example, you purchase five concurrent licenses and you have 10 providers in your practice. So, any five of the 10 can simultaneously access the system. With a “provider,” or “named user” scenario, you would need to purchase licenses for all 10 providers.

Also, the term of the license is important. You can purchase a “perpetual” license that basically gives you the right to use the software indefinitely, as long as you purchase yearly maintenance and support. Or, you can have a “term license” which specifies a specific amount of time before the license expires.

So, a concurrent perpetual license would be preferred. This came into play when I was comparing contracts for a customer and the license type wasn’t really stated in the contract. When I looked into it further, it turned out that the software they were about to purchase needed to have licenses for each provider as opposed to the preferred concurrent license, a better option.

Third-Party Interfaces and Databases

Software companies are infamous for finger pointing when there are problems and the sheer number of third-party interfaces and databases integrated in an EHR package can help fuel the fire. Are the licenses for your lab interface and patient education modules directly from your EHR vendor or are they a pass-through from the lab and patient education companies? From a contract standpoint you want to understand the agreements that the vendor has with the third-party. Are there additional costs involved? Is the license type for a third party component different and are there any restrictions on its use? It is important to understand who supports the third-party application. The preference is that your vendor will take care of any problems. Otherwise there could be some finger pointing down the line. Make sure you understand how this will work if there are problems.

Source Code Escrow

Have you ever thought about what could happen if you purchase an EHR and your vendor goes out of business, changes direction or drops adequate support for your product? You have the right to request that your vendor put their software and documentation in escrow for a rainy day should they not be there at some point in the future.

Where major mistakes are made with software escrow is in what elements are required to go into the package. Imagine the scenario where the vendor goes out of business. You hire a consultant to fix problems in your EHR assuming that you’re covered because you have the software in an escrow account. Unfortunately, the vendor left the program code but didn’t leave any documentation or instructions as to how it worked. Or, there was program code left along with documentation, but no instructions to put it all together. Hiring an outside consultant to figure this out, if it is possible at all, would be quite expensive.

Another area to focus on is which “release events” need to take place in order for the above elements to be released to your practice. Be aware that the various components of a source code escrow are considered proprietary information by the vendors and they are hesitant to share all this information. Some events that can trigger the release of the escrow package to you are:

• The vendor becomes insolvent or bankrupt;
• The vendor is liquidating its business causing concern in meeting support obligations; or
• The vendor has discontinued support in accordance with its obligations.

This is not an exhaustive list of release events, but it does point out the need to address any area of concern in terms of continued support of the product.

Data Base Schema

If the vendor will not provide a source code escrow, at least request what is known as a “data base schema,” including all associated documentation, to be included as an exhibit to the contract. This “techie term” basically describes the road map of how your data looks inside the system. Technically, you own your data, but if you ever need to transfer it to another system, it can be a very expensive endeavor for a consultant to figure it out if you don’t have the road map. By the way, in addition the data base schema, you should include the RFP response and any specification or performance documents with the contract.

Warranties

Many promises and assurances will be thrown your way during the sales process and you want to make sure you are covered after you sign the contract and begin making payments. Warranties are there to hold the vendor accountable for what they have represented. You can associate penalties and even termination for failure to adhere to some warranties. A few warranties to think about are:

• The vendor is not involved with ongoing or pending litigation;
• The system meets functional and performance specifications;
• The system will follow representations in Request for Proposal response;
• The services will be provided per service level agreement; and
• The system will be installed in accordance with implementation schedule.

This is by no means an exhaustive or complete list, but should give you an idea of what to think about.

Payment Terms and Implementation Milestones

If you were a vendor, you would want most of your money up front — correct? When you look at EHR contracts, this is typically the case. If you’re a large practice or health care organization, this is somewhat negotiable. So, how about the small to medium practice? Think accountability. You’re about to enter into an EHR implementation that has a number of phases and will take some time. And, as Murphy once stated, anything that can go wrong will go wrong. So, it’s certainly fair for you to ask for what is known as milestone-based payments. This means that as the vendor completes certain performance criteria, they receive certain payments. There is no standard for this, but could look something like: 20 percent upon contract signing, 20 percent upon basic installation, 20 percent upon template customization, 20 percent upon training completion and 20 percent upon acceptance testing and going live. Of course, the vendor can certainly expect you to adhere to your part of the agreed implementation plan and not hold things up.

The above points are just a few examples of contract areas that you might want to address after you receive the initial version of the contract. There are many more that we don’t have bandwidth for in this article.

How do I make sure I get the follow-up support I need?

For some reason, Murphy’s Law seems to be especially appropriate after a system is installed, the final payment is tendered and the practice is now dependent on the technology. To address support concerns, the Service Level Agreement, or SLA, is the standard mechanism to document vendor commitments. After all, you’re paying 15 to 20 percent of the license fee yearly for update and adequate service.

These agreements outline various areas of vendor accountability in which the vendor is willing to make a commitment to service and support:

• Actual hours of support. Can you get away with 9-5 support or are after-hours, weekends and holidays important?
• Methods of support. Do you have only e-mail or online chat during your hours of support? Or, can you have phone contact with a real support analyst?
• Severity level classification. A lab interface malfunction might be severity 1, whereas a patient education access problem might be a severity 3.
• Problem escalation and triage. How do problems move up the chain of command?
• Response times. What are the commitments to take care of various problem types? These are typically based on severity level.
• Introduction of new versions. How long will the vendor support the previous version or release?

Look at the needs of your practice in terms of support. This could change over time as you become more dependent on the technology. In some cases you might need to be more or less demanding than others. Typically, the more demands or accountability you have on your vendor, the more it will cost you. So, as you can see, there are a number of stops along this journey. Remember that this is still a fairly young industry. I find that normal concepts and practices that I have become accustomed to over the past 25 years in IT are just now finding their way into the process. The concepts and ideas outlined in this article hopefully will help you begin to understand steps involved in the successful EHR acquisition and implementation.

Michael Uretz has been involved with all aspects of software acquisition and implementation for over 25 years. He conducts EHR Best Practices seminars and workshops on both the state and national level and is author of the CD entitled “How to Survive Your EHR Contract.” In addition to his normal duties, he is a member of the working committee for EHR business practices based in Washington, D.C. He is Executive Director of The EHR Group, www.EHRgroup.com, a consultancy dedicated to providing tools, resources and education to physicians and practice managers as they navigate through EHR selection, contract negotiation and implementation. He can be reached at mikeu@EHRgroup.com or toll free 1-888-5 GET EHR.

© 2005 Michael Uretz all rights reserved. No part of this article may be reproduced in any form by any means without the written consent of Michael Uretz.