Computer Consult

Take a hard line on software support

Don't fixate on price; negotiate terms that also ensure successful implementation of your new program.

By Rosemarie Nelson

Remember real estate tycoon Donald Trump's memoir, Trump: The Art of the Deal? An update—titled, say, The Art of the E-Deal—might have helped four ENT doctors in Ohio who bought a practice management software program and hardware to match. The vendor's demo performed like a racehorse, but when the doctors tried out their own new system, it ran as slowly as a mule. A clerk would type in data on a patient registration screen, hit "enter," and have to wait 10 to 15 seconds before the next screen appeared.

Such a screen should "turn over" less than two seconds after you hit "enter." If the ENT doctors had specified that in their contract, the vendor probably would have recommended that they buy a more powerful server, or central computer, to run the software at the desired speed. Instead, to keep the price low, the vendor sold them a weaker server, the software program slow-poked along, and the doctors had to upgrade their server within three months—a considerable hassle.

Now you know why it's dangerous to focus exclusively on cost when you buy computer software. The sales contract isn't just about the price tag; it's about performance standards, services, and protecting your investment. True, it's easy to let down your guard once you select your dream technology. No doubt the vendor has taken you to fancy restaurants, showered you with gifts, and promptly returned all your calls. Everything he does suggests, "I'll take care of you after the deal is closed." A properly worded contract will help ensure that he does. So exploit the good rapport at the beginning of your relationship to get the terms and benefits you want.

What to negotiate up front

Contract negotiations begin the minute you meet a vendor. He may have given you a brochure stating that his program permits "quick and easy data entry by doctors at the point of care." If you end up choosing this product, staple the brochure to the contract and translate the sales pitch into binding language. For example, your contract might stipulate that a doctor will be able to generate a prescription electronically in less than 45 seconds. Take the same approach with other documents that spell out the vendor's promises.

When you evaluate a vendor, study his standard contract for clues as to whether he's eager to fleece you or please you. The contract might state that if the vendor accidentally introduces a software glitch during the installation process, he's not financially responsible for any problem that it causes you. Such a one-sided provision ought to raise a red flag. Feel him out about his willingness to revise this and other contract terms. If he sounds as flexible as a cinder block, walk away.

On the other hand, you might encounter a contract that defines performance standards for screen turnover, or promises that the system will produce a monthly financial report in less than two hours. (You don't want your system locked up by this task for longer than that.) Count your blessings: Here's a vendor who's voluntarily holding himself accountable to the customer. You'll probably find him easier to deal with than vendors who write performance standards into their contracts only at gunpoint.

Also, study the contract to see how the vendor intends to fix software glitches and enhance the program over time. Your dollars are at stake. Program enhancements—such as the ability to generate a new kind of report—appear on updated versions of the software. The vendor labels these with higher and higher numbers; the new version of Thingamajig 3.6, for example, might be called Thingamajig 4.6.

What you don't want is a contract that defines a fix as an enhancement. Let's say your program can't generate correct electronic claims for certain CPT codes. The contract should require the vendor to quickly remedy this bug with a software "patch." How quick is quickly? Well, if any bug hurts your cash flow, the vendor should be subject to a 60-day turnaround time. If he takes any longer to swat the bug, he should make up whatever subsequent losses you suffer.

Contractual language on future custom programming also is important. You may ask your vendor at the outset to tailor his electronic medical record to automatically receive test results from a local lab. What happens if, one year later, the lab reformats its test results, perhaps by adding a data-entry field for the patient's birthday? You may have to tweak your EMR software accordingly to preserve the interface. If so, you need more custom programming from the vendor. The contract should stipulate an hourly programming rate, which could range from $100 to $250, depending on your location and the operating system involved. Also, pencil in a turnaround time for the work, including how soon the vendor will respond with a price quote.

After the system is installed

Staff training can mean the difference between a successful computer system and a flop. Many vendors cram training into a few days, giving staffers little time to absorb the information. So during contract negotiations, ask your vendor to agree to stretch out the training over six months or longer, with lessons keyed to when staffers will be using software features for the first time. They won't be following up on past-due accounts in the new system, for instance, until several months down the line.

To be sure, if you ask a vendor to train your people over six months, he may reply, "That will cost you extra." Assuming the cost is reasonable, you'd be smart to pay it. If your staffers can't use new software properly, you might experience a drop in collections. And if they can't use all of its computing power, you're not getting your money's worth.

Similarly, don't stint on topnotch technical support. Most vendors offer different levels of support based on timeliness of response. If you're buying practice management software, you'll want same-day as opposed to 48-hour response; the latter is less expensive, but rougher on office productivity if a breakdown occurs. If you're buying an EMR system, contract for response within two hours. It's hard to see a patient without the medical chart.

Another critical ingredient of a software contract is the timetable for paying the vendor. A few predatory companies want full payment upfront, an arrangement that gives you no leverage if your system malfunctions a week after it's installed. More commonly, a vendor asks for 50 percent down, 30 percent after the software and hardware are installed, and the balance 30 days later. That's still not good enough. It's fine to pay 50 percent down, but you should tie the rest of your payments to milestones in using the system. For example, if you're buying a practice management system, give the vendor his last 50 percent in five payments—with each payment keyed to your reaching one of these goals:

• Your largest payer receives your first electronic-claims submission.

• You post your first electronic remittance from your largest payer.

• You generate your first weekly report showing accounts receivable.

• You generate your first month-end financial report.

• You generate your second month-end financial report. This isn't redundant, because the first report may not represent a complete test of the system. By the second month, your practice will have begun billing some patients for anything their insurers didn't pay. You want to make sure the system can handle that function.

If, ironically, your new software is a hit but the vendor goes out of business, your contract can minimize the damage. One potential problem is that you won't have access to your program's "source code" in case you want to upgrade it. The contract should require the vendor to place the code in escrow—a safe deposit box will do—so that if he closes up shop, you can retrieve your program's cyber-DNA.

Yes, contract negotiations with software vendors can take considerable time and energy. But don't get frustrated and lose sight of the goal: getting your system to work the way it's supposed to. Remind the vendor that your success is critical to his own. After all, you're his next reference—good or bad.

The author is a computer consultant in Syracuse.

Do you have a computer question? Write to Robert Lowes, the editor of this column, at Medical Economics magazine, 200 S. Bemiston Ave., Suite 306, St. Louis, MO 63105. You can also fax your question to 314-727-2214, or send an e-mail to mecomp@medec.com. Sorry, but we are unable to answer readers individually.

Rosemarie Nelson. Computer Consult: Take a hard line on software support.

Medical Economics

2001;13:14.