Selecting a Vendor

June 1, 2004

Pros, cons, and how to use a request for proposal

When Cindy Miller, office manager for Lynn Eye Medical Group in Thousand Oaks, Calif., had to pick a practice management system, she did what most small medical practices do. She invited the two vendors she most respected to visit the practice. Then, she visited a few other practices that were using the vendors' systems. In the end, she chose Prime Clinical Systems because she liked the company's orientation to customer service.

It's not unusual for medical practices to make momentous technology decisions based on product demonstrations by just one or two companies. But as the software market grows -- and mergers and new players add to the countless companies eager to win physician dollars -- picking the right software gets more complicated. That's why a small but growing number of physicians are turning to a more sophisticated selection tool used widely in other industries: the request for proposal or RFP. In the RFP process, the practice sends a detailed list of what it requires to vendors who are asked to respond with their solutions and prices.

This somewhat formal approach has supporters and detractors, but all agree that to make an RFP -- or any other selection process -- work well, customers must first clearly define what they need. A productive selection process aims to fulfill the practice's needs, not just find a generically good product.

"It's not typical of a physician office to use an RFP process," says Simon Lee, vice president of marketing for Prime Clinical Systems. "It is a disadvantage if they don't use [an RFP], but it's also a disadvantage if they use ... the wrong one."

The RFP advantage

Hardy North, senior marketing manager in healthcare for Dell and a former hospital administrator, is a strong advocate for the RFP process.

"People who avoid the RFP process are people who either don't know about it ... or they are afraid they don't have the expertise to put one together. ... [RFPs] help you get better solutions at better prices. If nothing else, it empowers you as a consumer. You always want to have your vendors in a competitive situation," he explains.

Indeed, a well-written RFP can make it easier for you to compare vendors on your terms. That's a lot easier than trying to compare vendors based on each company's marketing materials. "Ninety percent of vendors don't want RFPs because they introduce competition," North says.

He suggests pushing the contest further: once you narrow the field to two or three vendors, invite dealers to your practice to present their solutions in front of each other. "You'll find out real quick who wants to work with you and who doesn't," he says.

Getting to the RFP

Don't know where to start? Grabbing a generic RFP online and customizing to your needs it is a good way to start sorting through vendors, North says. Search the Web for "RFP" and you'll find many suggested outlines.

Or consider hiring a consultant to help you write an RFP and make your final selection. North estimates it can cost $2,000 to $3,000 for these services, but that cost will seem negligible compared to an investment of $50,000 or more in software.

When he helped Texas Sport Medicine and Orthopedic Group in Houston select an EMR, consultant Bill Hayes encouraged the physicians to use an RFP instead of taking the less formal route that the group was used to.

"They hadn't been through a review like this. It was more like, 'I heard someone is doing well with a certain vendor ... and we ought to get them.' That's how they had made decisions on previous vendors," Hayes says. He insists that the real issue isn't whether to use an RFP, it's putting in the work ahead of time to identify the deficiencies in your practice that you want to the new software resolve.

"In going through this drill, you have to understand where your deficiencies are and what you are trying to do. And that has to be reflected in what you are asking these vendors," Hayes says.


When it comes to assessing technology needs, Hayes says most practices are like the proverbial frog immersed in increasingly hot water: they don't recognize how close they are to boiling alive until it's too late. "You just accept things. You accept the amount of paper; you accept the amount of staff," he says.

Struggling to pin down critical practice issues -- trying to view your practice's problems objectively -- not only helps to create an RFP that's relevant to your needs, it also supplies you with information you need to make wise decisions about technology, or any other purchase. Using the RFP process to weed through various vendors led Texas Sport Medicine and Orthopedic Group to select a system from NextGen, Hayes says.

In a sense, the process of writing an RFP that truly reflects the practice is a benefit in and of itself. Once through the process, the group understands its weaknesses and strengths and knows exactly what it needs technology to do.

Defining your practice's needs also helps save time in the selection process by taking some vendors out of the running from the very start. You won't waste time sending an RFP to a company that doesn't have the lab tracking, reporting, or some other tool you want.

Focus on your needs

Generic RFPs that don't relate to practice needs waste time and, potentially, money. "A lot of people are taking RFPs from the American Academy of Family Physicians or a consultant - a standard one ... . It doesn't really address their specific needs. Pick things that will really make a difference," suggests Scott Reidel, director of marketing for MediNotes.

As a vendor, Reidel finds it frustrating to spend time answering, say, 200 questions on an RFP only to find out that the customer only cared about 10 of them. Getting a mountain of interesting but ultimately useless information about a product also wastes the practice's time. Physicians are especially vulnerable to falling into the trap of asking heaps of technical questions. Buying software does not require a degree in information technology. So don't get all wrapped up in assessing processing speeds and database types while ignoring more weighty questions like does the system do what you need it to do.

Don't forget to consider other critical issues, such as staffing levels or patient waiting times, that, at first, may seem unrelated to the software. "You can't just look at the functions of the software itself; look at how if affects the whole picture," Lee says. For example, think through your office's current workflow, what needs to change, and how you would like the new software or hardware to advance those goals.

Ann McCabe is a consultant with Industrial Wisdom, which helps companies make technology decisions. She says the most successful RFPs present a series of scenarios or real-life problems that need solutions.

"Keep it pretty real to what you are trying to do. Take it to a task level," she suggests. Ask vendors how they would solve a specific problem with reporting, workflow, or data entry. That way you can compare one vendor's solutions with those proposed by another.
Don't ask lots of broad, open-ended questions, McCabe warns. Asking, "Does your product offer good reporting?" might only give you a "yes" or "no" answer that reveals little about what the vendor does or whether the vendor understands your needs.

"I don't think you get the best thinking from vendors, either, when RFPs are not based on real problems. It doesn't help either side," McCabe says.

She also suggests taking it easy on legalese; in other words, don't start writing the terms of the purchase contract in the RFP. All that does is cause vendors to avoid direct answers out of fear that they may be held to unreasonable (or technically impossible) performance standards later on. While it is reasonable to ask vendors for their best estimates based on scenarios that you describe, don't hold them to a set price or timeline before they have had a chance to closely examine your situation and understand your needs.

How to Craft an RFP

When writing a request for proposal (RFP) for an information technology purchase, be sure to:

  • Describe the practice, including the number of physicians, number of people who will use the system, medical specialties, number of practice sites, and the practice's goals.
  • Describe your current information technology systems.
  • Assess the staff's comfort with and adoption of information technology. Will most be new users of PCs, or has your billing staff used PCs for 10 years?
  • State what you don't like about your current system, for example, "response time is too slow," "crashes often," or "doesn't do what we need."
  • Describe the conversion process you expect. That is, do you want to transfer seamlessly from your current system to the new one or are you OK with manually inputting previously collected data?
  • Make projections of practice growth, such as whether you will add more physicians or open another practice site with which you will need to communicate.
  • List the "must-haves" that are not negotiable, such as the ability to submit claims electronically.
  • Spell out your expectations for how much training you will need and how often you are willing to upgrade the system.
  • List all tasks the system must handle and all reports it must compile.
  • Describe other systems with which the new technology must integrate.
  • State privacy requirements and other known regulatory issues with which the system must comply.
  • Ask about implementation time.
  • Get answers about potential costs, such as how the company will handle, and possibly charge you for, staff training or upgrades of hardware and software.
  • Avoid using generic RFP formats that don't address your practice's most critical needs.

RFPs can be time-consuming, but when considering large investments, there is too much at stake to take shortcuts, North says. Certainly, creating RFPs, sending them out, waiting for replies, and weeding through the responses takes less time and trouble than finding a second technology partner because the first one didn't work out. And it's a lot cheaper. So, invest a little time now to learn more about yourself -- and the vendors -- before giving in to the impulse to buy a system based on the first great demo you see. n

Pamela Moore, PhD, senior editor, practice management, for Physicians Practice, last wrote about reducing claim denials in the April issue. She can be reached at pmoore@physicianspractice.com.

This article originally appeared in the June 2004 issue of Physicians Practice.