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.